Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-08 📝 Original message: Hi AJ, I think the ...
📅 Original date posted:2021-12-08
📝 Original message:
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 <aj at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/e5173822/attachment.html>;
📝 Original message:
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 <aj at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/e5173822/attachment.html>;