{"type":"rich","version":"1.0","title":"Bastien TEINTURIER [ARCHIVE] wrote","author_name":"Bastien TEINTURIER [ARCHIVE] (npub17f…ntr0s)","author_url":"https://yabu.me/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-12-06\n📝 Original message:\nGood morning list,\n\nThere was a great recent post on the mailing list detailing how we could\ndo PTLCs on lightning with a lot of other goodies [0]. This proposal\ncontained heavy changes to the transaction structure and the update\nprotocol. While it's certainly something we'll want to do in the long\nrun, I wanted to explore the minimal set of changes we would need to be\nable to deploy PTLCs as soon as possible.\n\nThe current result is a somewhat high-level article, where each section\ncould be a separate update of the lightning protocol [1].\n\nI tried to make PTLCs work with minimal changes to the transaction\nstructure and the update protocol, but they introduce a fundamental\nchange which forces us to make more changes than I'd like.\n\nWith HTLCs, the payment secret (the preimage of the payment hash) was\ndirectly revealed in the witness of a spending transaction.\n\nWith PTLCs, this isn't the case anymore. The payment secret is a private\nkey, and a spending transaction only reveals that key if you have a\nmatching adaptor signature. This forces us to make two changes:\n\n1. We must obtain adaptor signatures before sending our commit_sig\n2. We must use a pre-signed HTLC-success transaction not only with our\nlocal commit, but also with the remote commit\n\nThis means that we will need more round-trips whenever we update our\ncommitment. I'd like to find the right design trade-off where we don't\nintroduce too many changes in the protocol while minimizing the number\nof additional round-trips.\n\nWe currently exchange the following messages:\n\nAlice                       Bob\n      update_add_htlc\n  ---------------------------\u003e\n      update_add_htlc\n  ---------------------------\u003e\n      update_add_htlc\n  ---------------------------\u003e\n        commit_sig\n  ---------------------------\u003e\n       revoke_and_ack\n  \u003c---------------------------\n        commit_sig\n  \u003c---------------------------\n       revoke_and_ack\n  ---------------------------\u003e\n\nIt works well because the commit_sig sent by Alice only contains signatures\nfor Bob's transactions (commit and htlc transactions), and the commit_sig\nsent by Bob only contains signatures for Alice's transactions, and Alice\nand Bob don't need anything else to spend outputs from either commitment.\n\nBut with PTLCs, Bob needs a signature from Alice to be able to fulfill a\nPTLC from Alice's commitment. And Alice needs Bob to provide an adaptor\nsignature for that transaction before she can give him her signature.\nWe don't have the clean ordering that we had before.\n\nThe designs I came up with that keep the current messages and just insert\nnew ones are either too costly (too many additional round-trips) or too\ncomplex (most likely broken in some edge cases).\n\nI believe we need to change the commit_sig / revoke_and_ack protocol if\nwe want to find the sweet spot I'm looking for. I'd like to collect ideas\nfrom this list's participants on how we could do that. This is probably\nsomething that should be bundled with option_simplified_commitment [2]\n(or at least we must ensure that option_simplified_commitment is a first\nstep towards the protocol we'll need for PTLCs). It's also important to\nnote that the protocol changes must work for both HTLCs and PTLCs, and\nshouldn't change the structure of the transactions (not more than the\nsimple addition of PTLC outputs done in [1]).\n\nCheers,\nBastien\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html\n[1] https://github.com/t-bast/lightning-docs/pull/16\n[2] https://github.com/lightning/bolts/pull/867\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211206/c474a332/attachment-0001.html\u003e"}