{"type":"rich","version":"1.0","title":"Ariel Lorenzo-Luaces [ARCHIVE] wrote","author_name":"Ariel Lorenzo-Luaces [ARCHIVE] (npub1t5…vlpha)","author_url":"https://yabu.me/npub1t5mnh3ztdjmffuykas2g2ulx5y3tcv69t0qk0t0r4e3azxy3shfq0vlpha","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-12-14\n📝 Original message:\nI don't think it's so clear that any party refusing to go go first can be assumed to have lost data.\n\nIf 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.\n\nThere 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.\n\nThis 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.\n\nCheers\nAriel Lorenzo-Luaces\n\nOn Dec 13, 2020, 10:12 AM, at 10:12 AM, \"David A. Harding\" \u003cdave at dtrt.org\u003e wrote:\n\u003eOn Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:\n\u003e\u003e If c = 1 (i.e. the node is fine and it wants to continue the channel)\n\u003ethen\n\u003e\u003e it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it\n\u003epasses\n\u003e\u003e it sends the commitment blinding y back to prove that it doesn't have\n\u003ethe\n\u003e\u003e signature (i.e. prove c = 1). If verification fails then the node is\n\u003e\u003e malicious and it fails the channel. \n\u003e\n\u003eThis is really cool!  However, I don't understand why it's needed. \n\u003eYour\n\u003egoal seems to be for the sender to provide the commitment transaction\n\u003eand signatures before he learns whether the receiver actually needs\n\u003ethem.  That's just as easily accomplished by sending the data upfront\n\u003ein\n\u003eplain text.  For example, it seems to me that both of the following\n\u003eprotocols provide identical utility:\n\u003e\n\u003e1. On every reconnection, request the plain text unsigned commitment\n\u003e   transaction, send a pedersen commitment, and receive the encrypted\n\u003e   signature(s).  If c=1, verify the encrypted signature(s) and (on\n\u003e   success) send the blinding factor or (on failure) fail the channel\n\u003e   and ban the peer.  If c=0, decrypt the signature(s), apply them to\n\u003e   the commitment transaction, and broadcast.\n\u003e\n\u003e2. On every reconnection, request the plain text unsigned commitment\n\u003e   transaction with all of its signatures, also in plain text.  If our\n\u003e   database is intact, verify the commitment transaction and its\n\u003e   signatures are valid and (on success) continue or (on failure) fail\n\u003e   and ban.  If we lost data, broadcast the commitment transaction.\n\u003e\n\u003eUnless I'm forgetting something, there's no reason a node shouldn't\n\u003esend\n\u003eits latest commitment transaction to its counterparty in plain text\n\u003e(over the regular BOLT8 P2P encrypted and authenticated link).\n\u003e\n\u003eI think the challenge in either protocol above is deciding which peer\n\u003egoes first, because whoever sends the commitment transaction reveals\n\u003ewhat they think the current state is.  Any node that refuses to go\n\u003efirst\n\u003ecan then be suspected of having lost data.  BOLT2\n\u003eoption_static_remotekey has this same problem, which is reasonably\n\u003emitigated IMO by LN's penalty mechanism forcing any would-be thief to\n\u003erisk their own funds; this doesn't work for basic eltoo, though.\n\u003e\n\u003e-Dave\n\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003eLightning-dev mailing list\n\u003eLightning-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201214/eb2a5521/attachment-0001.html\u003e"}