{"type":"rich","version":"1.0","title":"Anthony Towns [ARCHIVE] wrote","author_name":"Anthony Towns [ARCHIVE] (npub17r…x9l2h)","author_url":"https://yabu.me/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-12-08\n📝 Original message:\nOn Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev wrote:\n\u003e Alternately, fast-forwards, which avoid this because it does not change commitment transactions on the payment-forwarding path.\n\u003e You only change commitment transactions once you have enough changes to justify collapsing them.\n\nI think the problem t-bast describes comes up here as well when you\ncollapse the fast-forwards (or, anytime you update the commitment\ntransaction even if you don't collapse them).\n\nThat is, if you have two PTLCs, one from A-\u003eB conditional on X, one\nfrom B-\u003eA conditional on Y. Then if A wants to update the commitment tx,\nshe needs to\n\n  1) produce a signature to give to B to spend the funding tx\n  2) produce an adaptor signature to authorise B to spend via X from his\n     commitment tx\n  3) produce a signature to allow B to recover Y after timeout from his\n     commitment tx spending to an output she can claim if he cheats\n  4) *receive* an adaptor signature from B to be able to spend the Y output\n     if B posts his commitment tx using A's signature in (1)\n\nThe problem is, she can't give B the result of (1) until she's received\n(4) from B.\n\nIt doesn't matter if the B-\u003eA PTLC conditional on Y is in the commitment\ntx itself or within a fast-forward child-transaction -- any previous\nadaptor sig will be invalidated because there's a new commitment\ntransaction, and if you allowed any way of spending without an adaptor\nsig, B wouldn't be able to recover the secret and would lose funds.\n\nIt also doesn't matter if the commitment transaction that A and B will\npublish is the same or different, only that it's different from the\ncommitment tx that previous adaptor sigs committed to. (So ANYPREVOUT\nwould fix this if it were available)\n\nSo I think this is still a relevant question, even if fast-forwards\nmake it a rare problem, that perhaps is only applicable to very heavily\nused channels.\n\n(I said the following in email to t-bast already)\n\nI think doing a synchronous update of commitments to the channel state,\nsomething like:\n\n   Alice -\u003e Bob: propose_new_commitment\n       channel id\n       adaptor sigs for PTLCs to Bob\n\n   Bob -\u003e Alice: agree_new_commitment\n       channel id\n       adaptor sigs for PTLCs to Alice\n       sigs for Alice to spend HTLCs and PTLCs to Bob from her own\n         commitment tx\n       signature for Alice to spend funding tx\n\n   Alice -\u003e Bob: finish_new_commitment_1\n       channel id\n       sigs for Bob to spend HTLCs and PTLCs to Alice from his own\n         commitment tx\n       signature for Bob to spend funding tx\n       reveal old prior commitment secret\n       new commitment nonce\n\n   Bob -\u003e Alice: finish_new_commitment_2\n       reveal old prior commitment secret\n       new commitment nonce\n\nwould work pretty well.\n\nThis adds half a round-trip compared to now:\n\n   Alice -\u003e Bob: commitment_signed\n   Bob -\u003e Alice: revoke_and_ack, commitment_signed\n   Alice -\u003e Bob: revoke_and_ack\n\nThe timings change like so:\n\n  Bob can use the new commitment after 1.5 round-trips (previously 0.5)\n\n  Alice can be sure Bob won't use the old commitment after 2 round-trips\n  (previously 1)\n\n  Alice can use the new commitment after 1 round-trip (unchanged)\n\n  Bob can be sure Alice won't use the old commitment after 1.5 round-trips\n  (unchanged -- note: this is what's relevant for forwarding)\n\nMaking the funding tx a musig setup would mean also supplying 64B\nof musig2 nonces along with the \"adaptor sigs\" in one direction,\nand providing the other side's 64B of musig2 nonces back along with the\n(now partial) signature for spending the funding tx (a total of 256B of\nnonce data, not 128B).\n\nBecause it keeps both peers' commitments synchronised to a single channel\nstate, I think the same protocol should work fine with the revocable\nsignatures on a single tx approach too, though I haven't tried working\nthrough the details.\n\nFast forwards would then be reducing the 2 round-trip protocol to\nupdate the state commitment to a 0.5 round-trip update, to reduce\nlatency when forwarding by the same amount as before (1.5 round-trips\nto 0.5 round-trips).\n\nCheers,\naj"}