https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
> On Jul 5, 2021, at 21:54, ZmnSCPxj <zmnsc...@protonmail.com> wrote: > > Good morning Billy, > > >> >>> The two participants in the channel can sign a plaintext containing their >>> node pubkeys and how much each owns >> >> Sure, but even if both participants in the channel sign a correct statement >> of truth, one of the participants can send funds out in the next second, >> invalidating that truth. While proof of ownership of on-chain UTXOs can be >> seen publicly in real time if they are spent, LN transactions aren't public >> like that. So any balance attestation is at best only valid the instant its >> taken, and can't be used as verification the money is still owned by the >> same channel partner in the next second. > > The same problem really also exists onchain --- a thief (or "thief") who has > gotten a copy of the key can sign a transaction that spends it, one second > after the proof-of-reserves is made. > > Really, though, the issue is that ownership of funds is conditional on > *knowledge* of keys. > And *knowledge* is easily copyable. > > Thus, it is possible that the funds that are "proven" to be the reserve of a > custodian is actually *also* owned by someone else who has gotten to the > privkeys (e.g. somebody threw a copy of it from a boating accident and a > fearless scuba diver rescued it), and thus can also move the funds outside of > the control of the custodian. > This condition can remain for many months or years, as well, without > knowledge of the custodian clients, *or* of the custodian itself. > > There is no way to prove that there is no alternate copy of the privkeys, > hence "if only one could prove that he won't get into a boating accident". > > On the other hand, one could argue that at least the onchain proof requires > more conditions to occur, so we might plausibly live with "we cannot prove we > will never get into a boating accident but we can show evidence that we live > in a landlocked city far from any lakes, seas, or rivers". > > Regards, > ZmnSCPxj > >> >>> a custodian Lightning node is unable to "freeze" a snapshot of its >>> current state and make an atomic proof-of-reserves of *all* channels >> >> That would be a neat trick. But yeah, I don't know how that would be >> possible. >> >>> I believe it is one reason why custodian proof-of-reserves is not that >>> popular ... it does not prove that the key will not get lost >> >> True, but at least if funds do get lost, it would be come clear far quicker. >> Today, an insolvent company could go many months without the public finding >> out. >> >> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <zmnsc...@protonmail.com> wrote: >> >>> Good morning e, >>> >>>> If only one could prove that he won’t get into a boating accident. >>> >>> At least in the context of Lightning channels, if one party in the channel >>> loses its key in a boating accident, the other party (assuming it is a true >>> separate person and not a sockpuppet) has every incentive to unilaterally >>> close the channel, which reveals the exact amounts (though not necessarily >>> who owns which). >>> If the other party then uses its funds in a new proof-of-reserves, then >>> obviously the other output of the unilateral close was the one lost in the >>> boating accident. >>> >>> On the other hand, yes, custodians losing custodied funds in boating >>> accidents is much too common. >>> I believe it is one reason why custodian proof-of-reserves is not that >>> popular --- it only proves that the funds were owned under a particular key >>> at some snapshot of the past, it does not prove that the key will not get >>> lost (or "lost and then salvaged by a scuba diver") later. >>> >>> Regards, >>> ZmnSCPxj >>> >>>> >>>> e >>>> >>>>> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev >>>>> bitcoin-dev@lists.linuxfoundation.org wrote: >>>>> Good morning Billy, >>>>> >>>>>> I wonder if there would be some way to include the ability to prove >>>>>> balances held on the lightning network, but I suspect that isn't >>>>>> generally possible. >>>>> >>>>> Thinking about this in terms of economic logic: >>>>> Every channel is anchored onchain, and that anchor (the funding txout) is >>>>> proof of the existence, and size, of the channel. >>>>> The two participants in the channel can sign a plaintext containing their >>>>> node pubkeys and how much each owns. >>>>> One of the participants should provably be the custodian. >>>>> >>>>> - If the counterparty is a true third party, it has no incentive to lie >>>>> about its money. >>>>> - Especially if the counterparty is another custodian who wants >>>>> proof-of-reserves, it has every incentive to overreport, but then the >>>>> first party will refuse to sign. >>>>> It has a disincentive to underreport, and would itself refuse to >>>>> sign a dishonest report that assigns more funds to the first party. >>>>> The only case that would be acceptable to both custodians would be >>>>> to honestly report their holdings in the Lightning channel. >>>>> >>>>> - If the counterparty is a sockpuppet of the custodian, then the entire >>>>> channel is owned by the custodian and it would be fairly dumb of he >>>>> custodian to claim to have less funds than the entire channel. >>>>> >>>>> Perhaps a more practical problem is that Lightning channel states change >>>>> fairly quickly, and there are possible race conditions, due to network >>>>> latency (remember, both nodes need to sign, meaning both of them need to >>>>> communicate with each other, thus hit by network latency and other race >>>>> conditions) where a custodian Lightning node is unable to "freeze" a >>>>> snapshot of its current state and make an atomic proof-of-reserves of all >>>>> channels. >>>>> Regards, >>>>> ZmnSCPxj >>>>> >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
