rich1.0Bastien TEINTURIER [ARCHIVE] (npub17f…ntr0s)https://yabu.me/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://yabu.me📅 Original date posted:2021-12-07 📝 Original message: Hi Z, Lloyd, Let's ignore the musig nonce exchanges for now. I believe these can be easily included in existing messages: they probably aren't the reason we need more round-trips (at least not the one I'm concerned about for now). Basically, if my memory and understanding are accurate, in the above, > it is the *PTLC-offerrer* which provides an adaptor signature. > That adaptor signature would be included in the `update_add_ptlc` message. Neat, you're completely right, I didn't realize that the adaptor signature could be completed by the other party, this is a great property I had missed. Thanks for pointing it out, it does simplify the protocol a lot! I don't think you can include it in `update_add_ptlc` though, it has to be in `commitment_signed`, because if you do a batch of updates before signing, you would immediately invalidate the adaptor signatures you previously sent. But it would be a simple change, where the signatures in `commitment_signed` would actually be adaptor signatures for PTLC-success transactions and normal signatures for PTLC-timeout transactions. Isn't it the case that all previous PTLC adaptor signatures need to be > re-sent for each update_add_ptlc message because the signatures would > no longer be valid once the commit tx changes Yes indeed, whenever the commitment changes, peers need to create new signatures and adaptor signatures for all pending PTLCs. This is completely fine for PTLC-success and PTLC-timeout transactions, but we also need to exchange signatures for the new pre-signed transactions that spend a PTLC from the remote commitment. Let's call this new pre-signed transaction PTLC-remote-success (not a great name). I believe these new transactions may require an additional round-trip. Let's take a very simple example, where we have one pending PTLC in each direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A. Now A makes some unrelated updates and wants to sign a new commitment. A cannot immediately send her `commitment_signed` to B. If she did, B would be able to broadcast this new commitment, and A would not be able to claim PTLC_BA from B's new commitment (even if she knew the payment secret) because she wouldn't have B's signature for the new PTLC-remote-success transaction. So we first need B to send a new message `remote_ptlcs_signed` to A that contains B's adaptor signatures for the PTLC-remote-success transactions that would spend B's future commitment. After that A can safely send her `commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B before B can send its `commitment_signed`. It's actually not that bad, we're only adding one message in each direction, and we're not adding more data (apart from nonces) to existing messages. If you have ideas on how to avoid this new message, I'd be glad to hear them, hopefully I missed something again and we can make it better! Thanks, Bastien Le mar. 7 déc. 2021 à 09:04, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit : > Good morning LL, and t-bast, > > > > Basically, if my memory and understanding are accurate, in the above, > it is the *PTLC-offerrer* which provides an adaptor signature. > > > That adaptor signature would be included in the `update_add_ptlc` > message. > > > > Isn't it the case that all previous PTLC adaptor signatures need to be > re-sent for each update_add_ptlc message because the signatures would no > longer be valid once the commit tx changes. I think it's better to put it > in `commitment_signed` if possible. This is what is done with pre-signed > HTLC signatures at the moment anyway. > > Agreed. > > This is also avoided by fast-forwards, BTW, simply because fast-forwards > delay the change of the commitment tx. > It is another reason to consider fast-forwards, too.... > > Regards, > ZmnSCPxj > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211207/55feef47/attachment.html>