{"type":"rich","version":"1.0","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://nostr.ae/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-12-08\n📝 Original message:\nHi thread,\n\nI was indeed mistaken. It does require four rounds for both parties to\nfully transition to the next comimit tx and I don't think there is any easy\nway around this. As you've pointed out there it's still only three rounds\nbefore the message is forwarded so no performance decrease for forwarding.\n\nI wanted to add a theoretical note that you might be aware of. The final\nmessage \"Bob -\u003e Alice: revoke_and_ack\" is not strictly necessary. Alice\ndoes not care about Bob revoking a commit tx that gives her strictly more\ncoins. Bob's new commit tx can use the same revocation key as the previous\none i.e. only the offerer of the PTLC/HTLC does a revocation and increments\ntheir revocation key. Not sending messages you don't need to is usually\nboth more performant and simpler but given that it introduces some\nasymmetry so I'm not sure if it's worth it. It's also worth noting that\nwith fast forwards + symmetric commit tx you will need to do the full four\nrounds always I think.\n\nCheers,\n\nLL\n\nOn Thu, 9 Dec 2021 at 02:03, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\n\u003e Hi again AJ and list,\n\u003e\n\u003e I have slightly re-worked your proposal, and came up with the following\n\u003e (I also added the musig2 nonces for completeness):\n\u003e\n\u003e Alice -\u003e Bob: commitment_proposed\n\u003e     channel id\n\u003e     adaptor sigs for PTLCs to Bob in Alice's next commitment\n\u003e     musig nonces for Alice to spend funding tx\n\u003e     musig nonces for Bob to spend funding tx\n\u003e\n\u003e Bob -\u003e Alice: commitment_proposed\n\u003e     channel id\n\u003e     adaptor sigs for PTLCs to Alice in Bob's next commitment\n\u003e     musig nonces for Alice to spend funding tx\n\u003e     musig nonces for Bob to spend funding tx\n\u003e\n\u003e Bob -\u003e Alice: commitment_signed\n\u003e     channel id\n\u003e     signature for Alice to spend funding tx\n\u003e     sigs for Alice to spend HTLCs and PTLCs from her next commitment\n\u003e\n\u003e Alice -\u003e Bob: revoke_and_ack\n\u003e     channel id\n\u003e     reveal previous commitment secret\n\u003e     next commitment point\n\u003e\n\u003e Alice -\u003e Bob: commitment_signed\n\u003e     channel id\n\u003e     signature for Bob to spend funding tx\n\u003e     sigs for Bob to spend HTLCs and PTLCs from his next commitment\n\u003e\n\u003e Bob -\u003e Alice: revoke_and_ack\n\u003e     channel id\n\u003e     reveal previous commitment secret\n\u003e     next commitment point\n\u003e\n\u003e I believe it's exactly the same flow of data between peers as your\n\u003e proposal, but I simply split the data into several messages. Let me\n\u003e know if that's incorrect or if I missed a subtlety in your proposal.\n\u003e\n\u003e This has some small advantages:\n\u003e\n\u003e * commitment_signed and revoke_and_ack are mostly unchanged, we just\n\u003e add a new message before the commit / revoke dance. The only change\n\u003e happens in commitment_signed, where the signatures for PTLC-success\n\u003e transactions will actually become adaptor signatures.\n\u003e * the new adaptor signatures are in commitment_proposed instead of being\n\u003e in commitment_signed, which ensures that we can still have 2*483\n\u003e pending (H|P)TLCs: since the message size is limited to 65kB, we would\n\u003e otherwise decrease our maximum to ~2*335 with your proposal (very rough\n\u003e calculation)\n\u003e * the messages are now symmetrical, which may be easier to reason about\n\u003e\n\u003e One thing to note is that we reversed the order in which participants\n\u003e sign new commitments. We previously had Alice sign first, whereas now\n\u003e if Alice initiates, Bob will sign the updated commitment first. This is\n\u003e why we add only 0.5 RTT instead of 1 RTT compared to the current protocol.\n\u003e I don't think this is an issue, but if someone sees a way to maliciously\n\u003e exploit this, please share it!\n\u003e\n\u003e I updated my article [0], people jumping on the thread now may find it\n\u003e helpful to better understand this discussion.\n\u003e\n\u003e Thanks,\n\u003e Bastien\n\u003e\n\u003e [0] https://github.com/t-bast/lightning-docs/pull/16\n\u003e\n\u003e Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e a\n\u003e écrit :\n\u003e\n\u003e\u003e Hi AJ,\n\u003e\u003e\n\u003e\u003e I think the problem t-bast describes comes up here as well when you\n\u003e\u003e\u003e collapse the fast-forwards (or, anytime you update the commitment\n\u003e\u003e\u003e transaction even if you don't collapse them).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Yes, exactly.\n\u003e\u003e\n\u003e\u003e I think doing a synchronous update of commitments to the channel state,\n\u003e\u003e\u003e something like:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Alice -\u003e Bob: propose_new_commitment\n\u003e\u003e\u003e channel id\n\u003e\u003e\u003e adaptor sigs for PTLCs to Bob\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\u003e Bob -\u003e Alice: agree_new_commitment\n\u003e\u003e\u003e channel id\n\u003e\u003e\u003e adaptor sigs for PTLCs to Alice\n\u003e\u003e\u003e sigs for Alice to spend HTLCs and PTLCs to Bob from her own\n\u003e\u003e\u003e commitment tx\n\u003e\u003e\u003e signature for Alice to spend funding tx\n\u003e\u003e\u003e\n\u003e\u003e\u003e Alice -\u003e Bob: finish_new_commitment_1\n\u003e\u003e\u003e channel id\n\u003e\u003e\u003e sigs for Bob to spend HTLCs and PTLCs to Alice from his own\n\u003e\u003e\u003e commitment tx\n\u003e\u003e\u003e signature for Bob to spend funding tx\n\u003e\u003e\u003e reveal old prior commitment secret\n\u003e\u003e\u003e new commitment nonce\n\u003e\u003e\u003e\n\u003e\u003e\u003e Bob -\u003e Alice: finish_new_commitment_2\n\u003e\u003e\u003e reveal old prior commitment secret\n\u003e\u003e\u003e new commitment nonce\n\u003e\u003e\u003e\n\u003e\u003e\u003e would work pretty well.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e I agree, this is better than my naive addition of a `remote_ptlcs_signed`\n\u003e\u003e message in both directions, and even though it changes the protocol\n\u003e\u003e messages\n\u003e\u003e it stays very close to the mechanisms we currently have.\n\u003e\u003e\n\u003e\u003e I'll spend some time specifying this in more details, to verify that we're\n\u003e\u003e not missing anything. What I really like about this proposal is that we\n\u003e\u003e can probably bundle that protocol change with `option_simplified_update`\n\u003e\u003e [0]\n\u003e\u003e without the adaptor sigs, and simply add the adaptor sigs as tlvs when we\n\u003e\u003e do PTLCs. That lets us deploy this new update protocol separately from\n\u003e\u003e PTLCs\n\u003e\u003e and ensure it also simplifies the state machine and makes other features\n\u003e\u003e such as splicing [1] and dynamic channel upgrades [2] easier.\n\u003e\u003e\n\u003e\u003e Thanks,\n\u003e\u003e Bastien\n\u003e\u003e\n\u003e\u003e [0] https://github.com/lightning/bolts/pull/867\n\u003e\u003e [1] https://github.com/lightning/bolts/pull/863\n\u003e\u003e [2] https://github.com/lightning/bolts/pull/868\n\u003e\u003e\n\u003e\u003e Le mer. 8 déc. 2021 à 10:29, Anthony Towns \u003caj at erisian.com.au\u003e a écrit :\n\u003e\u003e\n\u003e\u003e\u003e On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e \u003e Alternately, fast-forwards, which avoid this because it does not\n\u003e\u003e\u003e change commitment transactions on the payment-forwarding path.\n\u003e\u003e\u003e \u003e You only change commitment transactions once you have enough changes\n\u003e\u003e\u003e to justify collapsing them.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I think the problem t-bast describes comes up here as well when you\n\u003e\u003e\u003e collapse the fast-forwards (or, anytime you update the commitment\n\u003e\u003e\u003e transaction even if you don't collapse them).\n\u003e\u003e\u003e\n\u003e\u003e\u003e That is, if you have two PTLCs, one from A-\u003eB conditional on X, one\n\u003e\u003e\u003e from B-\u003eA conditional on Y. Then if A wants to update the commitment tx,\n\u003e\u003e\u003e she needs to\n\u003e\u003e\u003e\n\u003e\u003e\u003e   1) produce a signature to give to B to spend the funding tx\n\u003e\u003e\u003e   2) produce an adaptor signature to authorise B to spend via X from his\n\u003e\u003e\u003e      commitment tx\n\u003e\u003e\u003e   3) produce a signature to allow B to recover Y after timeout from his\n\u003e\u003e\u003e      commitment tx spending to an output she can claim if he cheats\n\u003e\u003e\u003e   4) *receive* an adaptor signature from B to be able to spend the Y\n\u003e\u003e\u003e output\n\u003e\u003e\u003e      if B posts his commitment tx using A's signature in (1)\n\u003e\u003e\u003e\n\u003e\u003e\u003e The problem is, she can't give B the result of (1) until she's received\n\u003e\u003e\u003e (4) from B.\n\u003e\u003e\u003e\n\u003e\u003e\u003e It doesn't matter if the B-\u003eA PTLC conditional on Y is in the commitment\n\u003e\u003e\u003e tx itself or within a fast-forward child-transaction -- any previous\n\u003e\u003e\u003e adaptor sig will be invalidated because there's a new commitment\n\u003e\u003e\u003e transaction, and if you allowed any way of spending without an adaptor\n\u003e\u003e\u003e sig, B wouldn't be able to recover the secret and would lose funds.\n\u003e\u003e\u003e\n\u003e\u003e\u003e It also doesn't matter if the commitment transaction that A and B will\n\u003e\u003e\u003e publish is the same or different, only that it's different from the\n\u003e\u003e\u003e commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT\n\u003e\u003e\u003e would fix this if it were available)\n\u003e\u003e\u003e\n\u003e\u003e\u003e So I think this is still a relevant question, even if fast-forwards\n\u003e\u003e\u003e make it a rare problem, that perhaps is only applicable to very heavily\n\u003e\u003e\u003e used channels.\n\u003e\u003e\u003e\n\u003e\u003e\u003e (I said the following in email to t-bast already)\n\u003e\u003e\u003e\n\u003e\u003e\u003e I think doing a synchronous update of commitments to the channel state,\n\u003e\u003e\u003e something like:\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Alice -\u003e Bob: propose_new_commitment\n\u003e\u003e\u003e        channel id\n\u003e\u003e\u003e        adaptor sigs for PTLCs to Bob\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Bob -\u003e Alice: agree_new_commitment\n\u003e\u003e\u003e        channel id\n\u003e\u003e\u003e        adaptor sigs for PTLCs to Alice\n\u003e\u003e\u003e        sigs for Alice to spend HTLCs and PTLCs to Bob from her own\n\u003e\u003e\u003e          commitment tx\n\u003e\u003e\u003e        signature for Alice to spend funding tx\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Alice -\u003e Bob: finish_new_commitment_1\n\u003e\u003e\u003e        channel id\n\u003e\u003e\u003e        sigs for Bob to spend HTLCs and PTLCs to Alice from his own\n\u003e\u003e\u003e          commitment tx\n\u003e\u003e\u003e        signature for Bob to spend funding tx\n\u003e\u003e\u003e        reveal old prior commitment secret\n\u003e\u003e\u003e        new commitment nonce\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Bob -\u003e Alice: finish_new_commitment_2\n\u003e\u003e\u003e        reveal old prior commitment secret\n\u003e\u003e\u003e        new commitment nonce\n\u003e\u003e\u003e\n\u003e\u003e\u003e would work pretty well.\n\u003e\u003e\u003e\n\u003e\u003e\u003e This adds half a round-trip compared to now:\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Alice -\u003e Bob: commitment_signed\n\u003e\u003e\u003e    Bob -\u003e Alice: revoke_and_ack, commitment_signed\n\u003e\u003e\u003e    Alice -\u003e Bob: revoke_and_ack\n\u003e\u003e\u003e\n\u003e\u003e\u003e The timings change like so:\n\u003e\u003e\u003e\n\u003e\u003e\u003e   Bob can use the new commitment after 1.5 round-trips (previously 0.5)\n\u003e\u003e\u003e\n\u003e\u003e\u003e   Alice can be sure Bob won't use the old commitment after 2 round-trips\n\u003e\u003e\u003e   (previously 1)\n\u003e\u003e\u003e\n\u003e\u003e\u003e   Alice can use the new commitment after 1 round-trip (unchanged)\n\u003e\u003e\u003e\n\u003e\u003e\u003e   Bob can be sure Alice won't use the old commitment after 1.5\n\u003e\u003e\u003e round-trips\n\u003e\u003e\u003e   (unchanged -- note: this is what's relevant for forwarding)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Making the funding tx a musig setup would mean also supplying 64B\n\u003e\u003e\u003e of musig2 nonces along with the \"adaptor sigs\" in one direction,\n\u003e\u003e\u003e and providing the other side's 64B of musig2 nonces back along with the\n\u003e\u003e\u003e (now partial) signature for spending the funding tx (a total of 256B of\n\u003e\u003e\u003e nonce data, not 128B).\n\u003e\u003e\u003e\n\u003e\u003e\u003e Because it keeps both peers' commitments synchronised to a single channel\n\u003e\u003e\u003e state, I think the same protocol should work fine with the revocable\n\u003e\u003e\u003e signatures on a single tx approach too, though I haven't tried working\n\u003e\u003e\u003e through the details.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Fast forwards would then be reducing the 2 round-trip protocol to\n\u003e\u003e\u003e update the state commitment to a 0.5 round-trip update, to reduce\n\u003e\u003e\u003e latency when forwarding by the same amount as before (1.5 round-trips\n\u003e\u003e\u003e to 0.5 round-trips).\n\u003e\u003e\u003e\n\u003e\u003e\u003e Cheers,\n\u003e\u003e\u003e aj\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/dcadd171/attachment-0001.html\u003e"}