rich1.0Bastien TEINTURIER [ARCHIVE] (npub17f…ntr0s)https://yabu.me/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://yabu.me📅 Original date posted:2021-12-06 📝 Original message: Good morning list, There was a great recent post on the mailing list detailing how we could do PTLCs on lightning with a lot of other goodies [0]. This proposal contained heavy changes to the transaction structure and the update protocol. While it's certainly something we'll want to do in the long run, I wanted to explore the minimal set of changes we would need to be able to deploy PTLCs as soon as possible. The current result is a somewhat high-level article, where each section could be a separate update of the lightning protocol [1]. I tried to make PTLCs work with minimal changes to the transaction structure and the update protocol, but they introduce a fundamental change which forces us to make more changes than I'd like. With HTLCs, the payment secret (the preimage of the payment hash) was directly revealed in the witness of a spending transaction. With PTLCs, this isn't the case anymore. The payment secret is a private key, and a spending transaction only reveals that key if you have a matching adaptor signature. This forces us to make two changes: 1. We must obtain adaptor signatures before sending our commit_sig 2. We must use a pre-signed HTLC-success transaction not only with our local commit, but also with the remote commit This means that we will need more round-trips whenever we update our commitment. I'd like to find the right design trade-off where we don't introduce too many changes in the protocol while minimizing the number of additional round-trips. We currently exchange the following messages: Alice Bob update_add_htlc ---------------------------> update_add_htlc ---------------------------> update_add_htlc ---------------------------> commit_sig ---------------------------> revoke_and_ack <--------------------------- commit_sig <--------------------------- revoke_and_ack ---------------------------> It works well because the commit_sig sent by Alice only contains signatures for Bob's transactions (commit and htlc transactions), and the commit_sig sent by Bob only contains signatures for Alice's transactions, and Alice and Bob don't need anything else to spend outputs from either commitment. But with PTLCs, Bob needs a signature from Alice to be able to fulfill a PTLC from Alice's commitment. And Alice needs Bob to provide an adaptor signature for that transaction before she can give him her signature. We don't have the clean ordering that we had before. The designs I came up with that keep the current messages and just insert new ones are either too costly (too many additional round-trips) or too complex (most likely broken in some edge cases). I believe we need to change the commit_sig / revoke_and_ack protocol if we want to find the sweet spot I'm looking for. I'd like to collect ideas from this list's participants on how we could do that. This is probably something that should be bundled with option_simplified_commitment [2] (or at least we must ensure that option_simplified_commitment is a first step towards the protocol we'll need for PTLCs). It's also important to note that the protocol changes must work for both HTLCs and PTLCs, and shouldn't change the structure of the transactions (not more than the simple addition of PTLC outputs done in [1]). Cheers, Bastien [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html [1] https://github.com/t-bast/lightning-docs/pull/16 [2] https://github.com/lightning/bolts/pull/867 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211206/c474a332/attachment-0001.html>