Ariel Lorenzo-Luaces [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-14 📝 Original message: I don't think it's so ...
📅 Original date posted:2020-12-14
📝 Original message:
I don't think it's so clear that any party refusing to go go first can be assumed to have lost data.
If the rule is that the party receiving the connection is the one that must send the oblivious signatures then a party that has both lost data and is receiving a connection can just ignore the connection request.
There is plausible denyability because knowingly not answering a request can't be distinguished from just having connection issues or distinguished from a machine is just turned off.
This reasoning should work well into the future because as long as machine failures are common, the node with data loss can hide in that anonymity set. And if human kind resolves all machine failures then by definition there shouldn't be lightning channel data loss.
Cheers
Ariel Lorenzo-Luaces
On Dec 13, 2020, 10:12 AM, at 10:12 AM, "David A. Harding" <dave at dtrt.org> wrote:
>On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:
>> If c = 1 (i.e. the node is fine and it wants to continue the channel)
>then
>> it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it
>passes
>> it sends the commitment blinding y back to prove that it doesn't have
>the
>> signature (i.e. prove c = 1). If verification fails then the node is
>> malicious and it fails the channel.
>
>This is really cool! However, I don't understand why it's needed.
>Your
>goal seems to be for the sender to provide the commitment transaction
>and signatures before he learns whether the receiver actually needs
>them. That's just as easily accomplished by sending the data upfront
>in
>plain text. For example, it seems to me that both of the following
>protocols provide identical utility:
>
>1. On every reconnection, request the plain text unsigned commitment
> transaction, send a pedersen commitment, and receive the encrypted
> signature(s). If c=1, verify the encrypted signature(s) and (on
> success) send the blinding factor or (on failure) fail the channel
> and ban the peer. If c=0, decrypt the signature(s), apply them to
> the commitment transaction, and broadcast.
>
>2. On every reconnection, request the plain text unsigned commitment
> transaction with all of its signatures, also in plain text. If our
> database is intact, verify the commitment transaction and its
> signatures are valid and (on success) continue or (on failure) fail
> and ban. If we lost data, broadcast the commitment transaction.
>
>Unless I'm forgetting something, there's no reason a node shouldn't
>send
>its latest commitment transaction to its counterparty in plain text
>(over the regular BOLT8 P2P encrypted and authenticated link).
>
>I think the challenge in either protocol above is deciding which peer
>goes first, because whoever sends the commitment transaction reveals
>what they think the current state is. Any node that refuses to go
>first
>can then be suspected of having lost data. BOLT2
>option_static_remotekey has this same problem, which is reasonably
>mitigated IMO by LN's penalty mechanism forcing any would-be thief to
>risk their own funds; this doesn't work for basic eltoo, though.
>
>-Dave
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201214/eb2a5521/attachment-0001.html>;
📝 Original message:
I don't think it's so clear that any party refusing to go go first can be assumed to have lost data.
If the rule is that the party receiving the connection is the one that must send the oblivious signatures then a party that has both lost data and is receiving a connection can just ignore the connection request.
There is plausible denyability because knowingly not answering a request can't be distinguished from just having connection issues or distinguished from a machine is just turned off.
This reasoning should work well into the future because as long as machine failures are common, the node with data loss can hide in that anonymity set. And if human kind resolves all machine failures then by definition there shouldn't be lightning channel data loss.
Cheers
Ariel Lorenzo-Luaces
On Dec 13, 2020, 10:12 AM, at 10:12 AM, "David A. Harding" <dave at dtrt.org> wrote:
>On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:
>> If c = 1 (i.e. the node is fine and it wants to continue the channel)
>then
>> it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it
>passes
>> it sends the commitment blinding y back to prove that it doesn't have
>the
>> signature (i.e. prove c = 1). If verification fails then the node is
>> malicious and it fails the channel.
>
>This is really cool! However, I don't understand why it's needed.
>Your
>goal seems to be for the sender to provide the commitment transaction
>and signatures before he learns whether the receiver actually needs
>them. That's just as easily accomplished by sending the data upfront
>in
>plain text. For example, it seems to me that both of the following
>protocols provide identical utility:
>
>1. On every reconnection, request the plain text unsigned commitment
> transaction, send a pedersen commitment, and receive the encrypted
> signature(s). If c=1, verify the encrypted signature(s) and (on
> success) send the blinding factor or (on failure) fail the channel
> and ban the peer. If c=0, decrypt the signature(s), apply them to
> the commitment transaction, and broadcast.
>
>2. On every reconnection, request the plain text unsigned commitment
> transaction with all of its signatures, also in plain text. If our
> database is intact, verify the commitment transaction and its
> signatures are valid and (on success) continue or (on failure) fail
> and ban. If we lost data, broadcast the commitment transaction.
>
>Unless I'm forgetting something, there's no reason a node shouldn't
>send
>its latest commitment transaction to its counterparty in plain text
>(over the regular BOLT8 P2P encrypted and authenticated link).
>
>I think the challenge in either protocol above is deciding which peer
>goes first, because whoever sends the commitment transaction reveals
>what they think the current state is. Any node that refuses to go
>first
>can then be suspected of having lost data. BOLT2
>option_static_remotekey has this same problem, which is reasonably
>mitigated IMO by LN's penalty mechanism forcing any would-be thief to
>risk their own funds; this doesn't work for basic eltoo, though.
>
>-Dave
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201214/eb2a5521/attachment-0001.html>;