{"type":"rich","version":"1.0","title":"David A. Harding [ARCHIVE] wrote","author_name":"David A. Harding [ARCHIVE] (npub16d…x4wrd)","author_url":"https://yabu.me/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-12-13\n📝 Original message:\nOn Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:\n\u003e If c = 1 (i.e. the node is fine and it wants to continue the channel) then\n\u003e it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes\n\u003e it sends the commitment blinding y back to prove that it doesn't have the\n\u003e signature (i.e. prove c = 1). If verification fails then the node is\n\u003e malicious and it fails the channel. \n\nThis is really cool!  However, I don't understand why it's needed.  Your\ngoal seems to be for the sender to provide the commitment transaction\nand signatures before he learns whether the receiver actually needs\nthem.  That's just as easily accomplished by sending the data upfront in\nplain text.  For example, it seems to me that both of the following\nprotocols provide identical utility:\n\n1. On every reconnection, request the plain text unsigned commitment\n   transaction, send a pedersen commitment, and receive the encrypted\n   signature(s).  If c=1, verify the encrypted signature(s) and (on\n   success) send the blinding factor or (on failure) fail the channel\n   and ban the peer.  If c=0, decrypt the signature(s), apply them to\n   the commitment transaction, and broadcast.\n\n2. On every reconnection, request the plain text unsigned commitment\n   transaction with all of its signatures, also in plain text.  If our\n   database is intact, verify the commitment transaction and its\n   signatures are valid and (on success) continue or (on failure) fail\n   and ban.  If we lost data, broadcast the commitment transaction.\n\nUnless I'm forgetting something, there's no reason a node shouldn't send\nits latest commitment transaction to its counterparty in plain text\n(over the regular BOLT8 P2P encrypted and authenticated link).\n\nI think the challenge in either protocol above is deciding which peer\ngoes first, because whoever sends the commitment transaction reveals\nwhat they think the current state is.  Any node that refuses to go first\ncan then be suspected of having lost data.  BOLT2\noption_static_remotekey has this same problem, which is reasonably\nmitigated IMO by LN's penalty mechanism forcing any would-be thief to\nrisk their own funds; this doesn't work for basic eltoo, though.\n\n-Dave\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201213/778f3af7/attachment.sig\u003e"}