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