Eric Voskuil [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-05 📝 Original message:If only one could prove ...
📅 Original date posted:2021-07-05
📝 Original message:If only one could prove that he won’t get into a boating accident.
e
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:If only one could prove that he won’t get into a boating accident.
e
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev