Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-08 📝 Original message: On Tue, Dec 07, 2021 at ...
📅 Original date posted:2021-12-08
📝 Original message:
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
📝 Original message:
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