{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-12-14\n📝 Original message:\nHi Dave,\n\nThanks for taking a read. You brought up really good points that need\naddressing.\n\nThis is really cool!  However, I don't understand why it's needed.  Your\n\u003e goal seems to be for the sender to provide the commitment transaction\n\u003e and signatures before he learns whether the receiver actually needs\n\u003e them.  That's just as easily accomplished by sending the data upfront in\n\u003e plain text.\n\u003e\n\nTo be clear: The goal is to offer a cooperative settlement transaction up\nfront to the (possibly) recovering party -- *not a commitment transaction*.\nNote we cannot send a cooperative settlement tx up front for each\nconnection since they are not revocable -- the channel is over once it has\nbeen received.\n\nI admit I didn't properly consider just sending commitment transactions\nover. This is probably because it exposes the recovering party to the\npunishment mechanism and in my most recent line of research you *really*\ndon't want to do this. The idea I'm working with in revocable signature\nbased channels [1] is to make the node lose its static secret key if it\nposts a revoked commitment tx. This means they could lose ALL funds from\nALL their channels with ALL their peers if they ever broadcast a single\nrevoked commitment transaction. This would be a very bad thing to happen\nwhile you're trying to recover funds.\n\nI agree with your core point that in LN as it exists today the security\nassumption of both methods is that the adversary will be unable to\ndistinguish a connection attempt after data loss from an ordinary one. If\nthey can reliably do this then both methods can lead to loss of funds so\nwhy bother with the wonky crypto?\n\nI think there is a subtle reason why oblivious settlement signatures are\nstill preferable: it is difficult to provide a coherent UX for recovery\nwhen just sending YOLO commitment transactions. It would be best if the\nrecovery UX was \"hey user I've found 0.367 Bitcoin across these three\nchannels would you like to recover them?\". The user can then accept this or\ncancel the recovery process and go through some extra trouble to recover\ntheir data (in practice, data is often not completely lost but recoverable\nwith some effort). This is how it could work using the oblivious settlement\ntxs I proposed.\n\nUsing YOLO commitment transactions this becomes \"hey user I've found 0.523\nBitcoin across three channels\" which may actually be more than you are owed\nto entice you to shoot yourself in the foot. Even if it's exactly what you\nare owed, when you confirm the recovery your next message might be \"aaaand\nit's gone\" because one of the commit txs was revoked.\n\nIt seems difficult to recommend YOLO commitment transactions becoming the\nstandard way to recover funds. It could be preferable to the current system\nbut even that is up for debate I guess. I feel like I can recommend\noblivious settlements because (i) it's covert (like YOLO commitments txs\nunlike current system) and (ii) it's  \"what you see is what you get\" -- you\nare guaranteed to recover the funds that you are presented with once you\nfinally trigger the recovery.\n\nAlthough I do think oblivious settlement txs is a good idea I am working on\nyet *another* recovery idea for doing peer provided encrypted backup and\nfull channel restoration in a way that provides another guarantee: If the\npeer sends you an outdated encrypted backup (perhaps in the hope that it\nhas a revoked commitment tx in it) -- you can punish them immediately upon\nreceiving the backup (if you haven't actually had data loss).\nUnfortunately, It looks like this will use more heavy cryptographic\nprimitives.\n\nI think the challenge in either protocol above is deciding which peer\n\u003e goes first, because whoever sends the commitment transaction reveals\n\u003e what they think the current state is.  Any node that refuses to go first\n\u003e can then be suspected of having lost data.  BOLT2\n\u003e option_static_remotekey has this same problem, which is reasonably\n\u003e mitigated IMO by LN's penalty mechanism forcing any would-be thief to\n\u003e risk their own funds; this doesn't work for basic eltoo, though.\n\u003e\n\nWhat is the story with option_static_remotekey? I am interested to know how\nthe negotiation of that option has a security issue but I don't see how it\ncould.\n\n[1]: https://github.com/LLFourn/witness-asymmetric-channel\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201214/160c7de0/attachment.html\u003e"}