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