Benjamin Weintraub [ARCHIVE] on Nostr: ð Original date posted:2022-02-16 ð Original message: Hi Laolu! Thanks for the ...
ð
Original date posted:2022-02-16
ð Original message:
Hi Laolu!
Thanks for the helpful reply. A couple follow up questions:
1) Why would concurrent signatures generate additional messages? My understanding is that by the time the signatures are sent, the HTLCs are already locked in.
2) Perhaps I didn't just understand your explanation, but I still don't get why the additional `commitment_signed` and `revoke_and_ack` messages are necessary. The initial pair of `commitment_signed` and `revoke_and_ack` messages establish a new state _conditioned_ on possessing the pre-image, right? So after the pre-image is shared, then all parties have assurance of the new state and therefore _could_ go to the chain (even if they don't want to, because they want to keep the channel open). Since the new state is already guaranteed by the previous commitments and revocations, what purpose do the additional commitments and revocations provide?
Thanks again!
Ben
--
Ben Weintraub
PhD Student
Khoury College of Computer Sciences
Northeastern University
https://ben-weintraub.com/
________________________________
From: Olaoluwa Osuntokun <laolu32 at gmail.com>
Sent: Tuesday, February 15, 2022 18:13
To: Benjamin Weintraub <weintraub.b at northeastern.edu>
Cc: Lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Normal operation questions
Hi Benjamin,
> 1) Multiple sources indicate that after Alice sends the `update_add_htlc`,
> she should then send the `commitment_signed`, but why is it important that
> she sends it first (before Bob)? As far as I understand, as long as she
> doesn't revoke the old state before Bob commits to the new state, there
> shouldn't be a problem. In that case, the order wouldn't matter---they could
> even send their commitments concurrently. So does the order matter?
You're correct that it isn't absolutely necessary that she sends a new
signature after adding a new HTLC to the pending set of HTLCs. Alice may
want to delay her signature if she has other HTLCs she wants to add to the
commitment transaction, which allows her to batch/pipeline updates to the
channel.
If Alice is forwarding that HTLC, and Bob's side of the channel has been
dormant (not making many updates), then it's her best interest to propose a
new state immediately as she may generate some routing fees from a
successful forward.
Concurrent signatures aren't an issue, but will end up generating additional
state transitions for both sides to have the exact same set of locked in
HTLCs.
> 2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange
> `commitment_signed` and `revoke_and_ack` messages again. Why is this
> necessary? After Alice receives the preimage, doesn't she have enough
> information to claim her funds (with the new state)?
If Bob is sending the pre-image, then _he_ is the one that is claiming the
funds. Once Bob learns of the pre-image, he can go to chain if he wants to
in order to claim the HTLC. However that'll be a lot slower and also cost
more in chain fees than doing an update off-chain to settle the HTLC from
the PoV of the commitment transaction of both parties. Both sides exchange
those messages in order to update their commitment state _off chain_.
Once Alice receives the pre-image (assuming a multi-hop scenario), she can
opt to not wait for the full exchange, and instead _pipeline_ the pre-image
back upstream in the route. In practice, this can reduce perceived user
latency for payments, as you can side step the 1.5 RTTs at each hop in the
route, and simply sling the pre-image all the way back to the original
sender.
-- Laolu
On Tue, Feb 15, 2022 at 7:32 AM Benjamin Weintraub <weintraub.b at northeastern.edu<mailto:weintraub.b at northeastern.edu>> wrote:
Hi all,
I have a couple questions about the Normal Operation protocol. For the following, consider a single-hop payment between Alice and Bob over a single channel.
1) Multiple sources indicate that after Alice sends the `update_add_htlc`, she should then send the `commitment_signed`, but why is it important that she sends it first (before Bob)? As far as I understand, as long as she doesn't revoke the old state before Bob commits to the new state, there shouldn't be a problem. In that case, the order wouldn't matter---they could even send their commitments concurrently. So does the order matter?
2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange `commitment_signed` and `revoke_and_ack` messages again. Why is this necessary? After Alice receives the preimage, doesn't she have enough information to claim her funds (with the new state)?
Thanks!
Ben
--
Ben Weintraub
PhD Student
Khoury College of Computer Sciences
Northeastern University
https://ben-weintraub.com/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben-weintraub.com%2F&data=04%7C01%7Cweintraub.b%40northeastern.edu%7Cd033116731cd4050291708d9f0d8d9bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637805637505660537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ip73Qo2E1UUud0LxEuMVCpYJQNxYQYLB3YtW0xIrtUA%3D&reserved=0>;
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org<mailto:Lightning-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev&data=04%7C01%7Cweintraub.b%40northeastern.edu%7Cd033116731cd4050291708d9f0d8d9bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637805637505660537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=V1m2qqncyahnT7crpeYhCmgGcBjep%2Ft%2FIBnjzuDbRJk%3D&reserved=0>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220216/16cb3180/attachment.html>;
ð Original message:
Hi Laolu!
Thanks for the helpful reply. A couple follow up questions:
1) Why would concurrent signatures generate additional messages? My understanding is that by the time the signatures are sent, the HTLCs are already locked in.
2) Perhaps I didn't just understand your explanation, but I still don't get why the additional `commitment_signed` and `revoke_and_ack` messages are necessary. The initial pair of `commitment_signed` and `revoke_and_ack` messages establish a new state _conditioned_ on possessing the pre-image, right? So after the pre-image is shared, then all parties have assurance of the new state and therefore _could_ go to the chain (even if they don't want to, because they want to keep the channel open). Since the new state is already guaranteed by the previous commitments and revocations, what purpose do the additional commitments and revocations provide?
Thanks again!
Ben
--
Ben Weintraub
PhD Student
Khoury College of Computer Sciences
Northeastern University
https://ben-weintraub.com/
________________________________
From: Olaoluwa Osuntokun <laolu32 at gmail.com>
Sent: Tuesday, February 15, 2022 18:13
To: Benjamin Weintraub <weintraub.b at northeastern.edu>
Cc: Lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Normal operation questions
Hi Benjamin,
> 1) Multiple sources indicate that after Alice sends the `update_add_htlc`,
> she should then send the `commitment_signed`, but why is it important that
> she sends it first (before Bob)? As far as I understand, as long as she
> doesn't revoke the old state before Bob commits to the new state, there
> shouldn't be a problem. In that case, the order wouldn't matter---they could
> even send their commitments concurrently. So does the order matter?
You're correct that it isn't absolutely necessary that she sends a new
signature after adding a new HTLC to the pending set of HTLCs. Alice may
want to delay her signature if she has other HTLCs she wants to add to the
commitment transaction, which allows her to batch/pipeline updates to the
channel.
If Alice is forwarding that HTLC, and Bob's side of the channel has been
dormant (not making many updates), then it's her best interest to propose a
new state immediately as she may generate some routing fees from a
successful forward.
Concurrent signatures aren't an issue, but will end up generating additional
state transitions for both sides to have the exact same set of locked in
HTLCs.
> 2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange
> `commitment_signed` and `revoke_and_ack` messages again. Why is this
> necessary? After Alice receives the preimage, doesn't she have enough
> information to claim her funds (with the new state)?
If Bob is sending the pre-image, then _he_ is the one that is claiming the
funds. Once Bob learns of the pre-image, he can go to chain if he wants to
in order to claim the HTLC. However that'll be a lot slower and also cost
more in chain fees than doing an update off-chain to settle the HTLC from
the PoV of the commitment transaction of both parties. Both sides exchange
those messages in order to update their commitment state _off chain_.
Once Alice receives the pre-image (assuming a multi-hop scenario), she can
opt to not wait for the full exchange, and instead _pipeline_ the pre-image
back upstream in the route. In practice, this can reduce perceived user
latency for payments, as you can side step the 1.5 RTTs at each hop in the
route, and simply sling the pre-image all the way back to the original
sender.
-- Laolu
On Tue, Feb 15, 2022 at 7:32 AM Benjamin Weintraub <weintraub.b at northeastern.edu<mailto:weintraub.b at northeastern.edu>> wrote:
Hi all,
I have a couple questions about the Normal Operation protocol. For the following, consider a single-hop payment between Alice and Bob over a single channel.
1) Multiple sources indicate that after Alice sends the `update_add_htlc`, she should then send the `commitment_signed`, but why is it important that she sends it first (before Bob)? As far as I understand, as long as she doesn't revoke the old state before Bob commits to the new state, there shouldn't be a problem. In that case, the order wouldn't matter---they could even send their commitments concurrently. So does the order matter?
2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange `commitment_signed` and `revoke_and_ack` messages again. Why is this necessary? After Alice receives the preimage, doesn't she have enough information to claim her funds (with the new state)?
Thanks!
Ben
--
Ben Weintraub
PhD Student
Khoury College of Computer Sciences
Northeastern University
https://ben-weintraub.com/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben-weintraub.com%2F&data=04%7C01%7Cweintraub.b%40northeastern.edu%7Cd033116731cd4050291708d9f0d8d9bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637805637505660537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ip73Qo2E1UUud0LxEuMVCpYJQNxYQYLB3YtW0xIrtUA%3D&reserved=0>;
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org<mailto:Lightning-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev&data=04%7C01%7Cweintraub.b%40northeastern.edu%7Cd033116731cd4050291708d9f0d8d9bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637805637505660537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=V1m2qqncyahnT7crpeYhCmgGcBjep%2Ft%2FIBnjzuDbRJk%3D&reserved=0>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220216/16cb3180/attachment.html>;