{"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-07\n📝 Original message:\nHi Z, Lloyd,\n\nLet's ignore the musig nonce exchanges for now. I believe these can be\neasily included in existing messages: they probably aren't the reason we\nneed more round-trips (at least not the one I'm concerned about for now).\n\nBasically, if my memory and understanding are accurate, in the above,\n\u003e it is the *PTLC-offerrer* which provides an adaptor signature.\n\u003e That adaptor signature would be included in the `update_add_ptlc` message.\n\n\nNeat, you're completely right, I didn't realize that the adaptor signature\ncould be completed by the other party, this is a great property I had\nmissed.\nThanks for pointing it out, it does simplify the protocol a lot!\n\nI don't think you can include it in `update_add_ptlc` though, it has to\nbe in `commitment_signed`, because if you do a batch of updates before\nsigning, you would immediately invalidate the adaptor signatures you\npreviously sent.\n\nBut it would be a simple change, where the signatures in `commitment_signed`\nwould actually be adaptor signatures for PTLC-success transactions and\nnormal signatures for PTLC-timeout transactions.\n\nIsn't it the case that all previous PTLC adaptor signatures need to be\n\u003e re-sent for each update_add_ptlc message because the signatures would\n\u003e no longer be valid once the commit tx changes\n\n\nYes indeed, whenever the commitment changes, peers need to create new\nsignatures and adaptor signatures for all pending PTLCs.\n\nThis is completely fine for PTLC-success and PTLC-timeout transactions,\nbut we also need to exchange signatures for the new pre-signed transactions\nthat spend a PTLC from the remote commitment. Let's call this new pre-signed\ntransaction PTLC-remote-success (not a great name).\n\nI believe these new transactions may require an additional round-trip.\nLet's take a very simple example, where we have one pending PTLC in each\ndirection: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A.\n\nNow A makes some unrelated updates and wants to sign a new commitment.\nA cannot immediately send her `commitment_signed` to B.\nIf she did, B would be able to broadcast this new commitment, and A would\nnot be able to claim PTLC_BA from B's new commitment (even if she knew\nthe payment secret) because she wouldn't have B's signature for the new\nPTLC-remote-success transaction.\n\nSo we first need B to send a new message `remote_ptlcs_signed` to A that\ncontains B's adaptor signatures for the PTLC-remote-success transactions\nthat would spend B's future commitment. After that A can safely send her\n`commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B\nbefore B can send its `commitment_signed`.\n\nIt's actually not that bad, we're only adding one message in each direction,\nand we're not adding more data (apart from nonces) to existing messages.\n\nIf you have ideas on how to avoid this new message, I'd be glad to hear\nthem, hopefully I missed something again and we can make it better!\n\nThanks,\nBastien\n\nLe mar. 7 déc. 2021 à 09:04, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning LL, and t-bast,\n\u003e\n\u003e \u003e \u003e Basically, if my memory and understanding are accurate, in the above,\n\u003e it is the *PTLC-offerrer* which provides an adaptor signature.\n\u003e \u003e \u003e That adaptor signature would be included in the `update_add_ptlc`\n\u003e message.\n\u003e \u003e\n\u003e \u003e Isn't it the case that all previous PTLC adaptor signatures need to be\n\u003e re-sent for each update_add_ptlc message because the signatures would no\n\u003e longer be valid once the commit tx changes. I think it's better to put it\n\u003e in `commitment_signed` if possible. This is what is done with pre-signed\n\u003e HTLC signatures at the moment anyway.\n\u003e\n\u003e Agreed.\n\u003e\n\u003e This is also avoided by fast-forwards, BTW, simply because fast-forwards\n\u003e delay the change of the commitment tx.\n\u003e It is another reason to consider fast-forwards, too....\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211207/55feef47/attachment.html\u003e"}