David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-13 📝 Original message: On Fri, Dec 11, 2020 at ...
📅 Original date posted:2020-12-13
📝 Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201213/778f3af7/attachment.sig>;
📝 Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201213/778f3af7/attachment.sig>;