{"type":"rich","version":"1.0","author_name":"npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","author_url":"https://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-07-05\n📝 Original message:@ ZmnSCPxj, Good Evening\n\n\u003e  The two participants in the channel can sign a plaintext containing\ntheir node pubkeys and how much each owns\n\nSure, but even if both participants in the channel sign a correct statement\nof truth, one of the participants can send funds out in the next second,\ninvalidating that truth. While proof of ownership of on-chain UTXOs can be\nseen publicly in real time if they are spent, LN transactions aren't public\nlike that. So any balance attestation is at best only valid the instant its\ntaken, and can't be used as verification the money is still owned by the\nsame channel partner in the next second.\n\n\u003e  a custodian Lightning node is unable to \"freeze\" a snapshot of its\ncurrent state and make an atomic proof-of-reserves of *all* channels\n\nThat would be a neat trick. But yeah, I don't know how that would be\npossible.\n\n\u003e  I believe it is one reason why custodian proof-of-reserves is not that\npopular ... it does not prove that the key will not get lost\n\nTrue, but at least if funds do get lost, it would be come clear far\nquicker. Today, an insolvent company could go many months without the\npublic finding out.\n\nOn Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning e,\n\u003e\n\u003e\n\u003e \u003e If only one could prove that he won’t get into a boating accident.\n\u003e\n\u003e At least in the context of Lightning channels, if one party in the channel\n\u003e loses its key in a boating accident, the other party (assuming it is a true\n\u003e separate person and not a sockpuppet) has every incentive to unilaterally\n\u003e close the channel, which reveals the exact amounts (though not necessarily\n\u003e who owns which).\n\u003e If the other party then uses its funds in a new proof-of-reserves, then\n\u003e obviously the other output of the unilateral close was the one lost in the\n\u003e boating accident.\n\u003e\n\u003e On the other hand, yes, custodians losing custodied funds in boating\n\u003e accidents is much too common.\n\u003e I believe it is one reason why custodian proof-of-reserves is not that\n\u003e popular --- it only proves that the funds were owned under a particular key\n\u003e at some snapshot of the past, it does not prove that the key will not get\n\u003e lost (or \"lost and then salvaged by a scuba diver\") later.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e \u003e\n\u003e \u003e e\n\u003e \u003e\n\u003e \u003e \u003e On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev\n\u003e bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e \u003e \u003e Good morning Billy,\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e I wonder if there would be some way to include the ability to prove\n\u003e balances held on the lightning network, but I suspect that isn't generally\n\u003e possible.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Thinking about this in terms of economic logic:\n\u003e \u003e \u003e Every channel is anchored onchain, and that anchor (the funding txout)\n\u003e is proof of the existence, and size, of the channel.\n\u003e \u003e \u003e The two participants in the channel can sign a plaintext containing\n\u003e their node pubkeys and how much each owns.\n\u003e \u003e \u003e One of the participants should provably be the custodian.\n\u003e \u003e \u003e\n\u003e \u003e \u003e -   If the counterparty is a true third party, it has no incentive to\n\u003e lie about its money.\n\u003e \u003e \u003e -   Especially if the counterparty is another custodian who wants\n\u003e proof-of-reserves, it has every incentive to overreport, but then the first\n\u003e party will refuse to sign.\n\u003e \u003e \u003e     It has a disincentive to underreport, and would itself refuse to\n\u003e sign a dishonest report that assigns more funds to the first party.\n\u003e \u003e \u003e     The only case that would be acceptable to both custodians would be\n\u003e to honestly report their holdings in the Lightning channel.\n\u003e \u003e \u003e\n\u003e \u003e \u003e -   If the counterparty is a sockpuppet of the custodian, then the\n\u003e entire channel is owned by the custodian and it would be fairly dumb of he\n\u003e custodian to claim to have less funds than the entire channel.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Perhaps a more practical problem is that Lightning channel states\n\u003e change fairly quickly, and there are possible race conditions, due to\n\u003e network latency (remember, both nodes need to sign, meaning both of them\n\u003e need to communicate with each other, thus hit by network latency and other\n\u003e race conditions) where a custodian Lightning node is unable to \"freeze\" a\n\u003e snapshot of its current state and make an atomic proof-of-reserves of all\n\u003e channels.\n\u003e \u003e \u003e Regards,\n\u003e \u003e \u003e ZmnSCPxj\n\u003e \u003e \u003e\n\u003e \u003e \u003e bitcoin-dev mailing list\n\u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210705/8f6b1e68/attachment-0001.html\u003e"}