{"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-08\n📝 Original message:\nHi AJ,\n\nI think the problem t-bast describes comes up here as well when you\n\u003e collapse the fast-forwards (or, anytime you update the commitment\n\u003e transaction even if you don't collapse them).\n\n\nYes, exactly.\n\nI think doing a synchronous update of commitments to the channel state,\n\u003e something like:\n\n\n\nAlice -\u003e Bob: propose_new_commitment\n\u003e channel id\n\u003e adaptor sigs for PTLCs to Bob\n\n\n\u003e Bob -\u003e Alice: agree_new_commitment\n\u003e channel id\n\u003e adaptor sigs for PTLCs to Alice\n\u003e sigs for Alice to spend HTLCs and PTLCs to Bob from her own\n\u003e commitment tx\n\u003e signature for Alice to spend funding tx\n\u003e\n\u003e Alice -\u003e Bob: finish_new_commitment_1\n\u003e channel id\n\u003e sigs for Bob to spend HTLCs and PTLCs to Alice from his own\n\u003e commitment tx\n\u003e signature for Bob to spend funding tx\n\u003e reveal old prior commitment secret\n\u003e new commitment nonce\n\u003e\n\u003e Bob -\u003e Alice: finish_new_commitment_2\n\u003e reveal old prior commitment secret\n\u003e new commitment nonce\n\u003e\n\u003e would work pretty well.\n\n\nI agree, this is better than my naive addition of a `remote_ptlcs_signed`\nmessage in both directions, and even though it changes the protocol messages\nit stays very close to the mechanisms we currently have.\n\nI'll spend some time specifying this in more details, to verify that we're\nnot missing anything. What I really like about this proposal is that we\ncan probably bundle that protocol change with `option_simplified_update` [0]\nwithout the adaptor sigs, and simply add the adaptor sigs as tlvs when we\ndo PTLCs. That lets us deploy this new update protocol separately from PTLCs\nand ensure it also simplifies the state machine and makes other features\nsuch as splicing [1] and dynamic channel upgrades [2] easier.\n\nThanks,\nBastien\n\n[0] https://github.com/lightning/bolts/pull/867\n[1] https://github.com/lightning/bolts/pull/863\n[2] https://github.com/lightning/bolts/pull/868\n\nLe mer. 8 déc. 2021 à 10:29, Anthony Towns \u003caj at erisian.com.au\u003e a écrit :\n\n\u003e On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev wrote:\n\u003e \u003e Alternately, fast-forwards, which avoid this because it does not change\n\u003e commitment transactions on the payment-forwarding path.\n\u003e \u003e You only change commitment transactions once you have enough changes to\n\u003e justify collapsing them.\n\u003e\n\u003e I think the problem t-bast describes comes up here as well when you\n\u003e collapse the fast-forwards (or, anytime you update the commitment\n\u003e transaction even if you don't collapse them).\n\u003e\n\u003e That is, if you have two PTLCs, one from A-\u003eB conditional on X, one\n\u003e from B-\u003eA conditional on Y. Then if A wants to update the commitment tx,\n\u003e she needs to\n\u003e\n\u003e   1) produce a signature to give to B to spend the funding tx\n\u003e   2) produce an adaptor signature to authorise B to spend via X from his\n\u003e      commitment tx\n\u003e   3) produce a signature to allow B to recover Y after timeout from his\n\u003e      commitment tx spending to an output she can claim if he cheats\n\u003e   4) *receive* an adaptor signature from B to be able to spend the Y output\n\u003e      if B posts his commitment tx using A's signature in (1)\n\u003e\n\u003e The problem is, she can't give B the result of (1) until she's received\n\u003e (4) from B.\n\u003e\n\u003e It doesn't matter if the B-\u003eA PTLC conditional on Y is in the commitment\n\u003e tx itself or within a fast-forward child-transaction -- any previous\n\u003e adaptor sig will be invalidated because there's a new commitment\n\u003e transaction, and if you allowed any way of spending without an adaptor\n\u003e sig, B wouldn't be able to recover the secret and would lose funds.\n\u003e\n\u003e It also doesn't matter if the commitment transaction that A and B will\n\u003e publish is the same or different, only that it's different from the\n\u003e commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT\n\u003e would fix this if it were available)\n\u003e\n\u003e So I think this is still a relevant question, even if fast-forwards\n\u003e make it a rare problem, that perhaps is only applicable to very heavily\n\u003e used channels.\n\u003e\n\u003e (I said the following in email to t-bast already)\n\u003e\n\u003e I think doing a synchronous update of commitments to the channel state,\n\u003e something like:\n\u003e\n\u003e    Alice -\u003e Bob: propose_new_commitment\n\u003e        channel id\n\u003e        adaptor sigs for PTLCs to Bob\n\u003e\n\u003e    Bob -\u003e Alice: agree_new_commitment\n\u003e        channel id\n\u003e        adaptor sigs for PTLCs to Alice\n\u003e        sigs for Alice to spend HTLCs and PTLCs to Bob from her own\n\u003e          commitment tx\n\u003e        signature for Alice to spend funding tx\n\u003e\n\u003e    Alice -\u003e Bob: finish_new_commitment_1\n\u003e        channel id\n\u003e        sigs for Bob to spend HTLCs and PTLCs to Alice from his own\n\u003e          commitment tx\n\u003e        signature for Bob to spend funding tx\n\u003e        reveal old prior commitment secret\n\u003e        new commitment nonce\n\u003e\n\u003e    Bob -\u003e Alice: finish_new_commitment_2\n\u003e        reveal old prior commitment secret\n\u003e        new commitment nonce\n\u003e\n\u003e would work pretty well.\n\u003e\n\u003e This adds half a round-trip compared to now:\n\u003e\n\u003e    Alice -\u003e Bob: commitment_signed\n\u003e    Bob -\u003e Alice: revoke_and_ack, commitment_signed\n\u003e    Alice -\u003e Bob: revoke_and_ack\n\u003e\n\u003e The timings change like so:\n\u003e\n\u003e   Bob can use the new commitment after 1.5 round-trips (previously 0.5)\n\u003e\n\u003e   Alice can be sure Bob won't use the old commitment after 2 round-trips\n\u003e   (previously 1)\n\u003e\n\u003e   Alice can use the new commitment after 1 round-trip (unchanged)\n\u003e\n\u003e   Bob can be sure Alice won't use the old commitment after 1.5 round-trips\n\u003e   (unchanged -- note: this is what's relevant for forwarding)\n\u003e\n\u003e Making the funding tx a musig setup would mean also supplying 64B\n\u003e of musig2 nonces along with the \"adaptor sigs\" in one direction,\n\u003e and providing the other side's 64B of musig2 nonces back along with the\n\u003e (now partial) signature for spending the funding tx (a total of 256B of\n\u003e nonce data, not 128B).\n\u003e\n\u003e Because it keeps both peers' commitments synchronised to a single channel\n\u003e state, I think the same protocol should work fine with the revocable\n\u003e signatures on a single tx approach too, though I haven't tried working\n\u003e through the details.\n\u003e\n\u003e Fast forwards would then be reducing the 2 round-trip protocol to\n\u003e update the state commitment to a 0.5 round-trip update, to reduce\n\u003e latency when forwarding by the same amount as before (1.5 round-trips\n\u003e to 0.5 round-trips).\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/e5173822/attachment.html\u003e"}