Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-16 📝 Original message: Hi Benjamin, Glad you ...
📅 Original date posted:2022-02-16
📝 Original message:
Hi Benjamin,
Glad you found it helpful, always happy to help clarify stuff like this. I
hope to eventually be able to leverage some recent research [1] in this area
to improve the specification, as well as general understanding of the update
protocol.
> 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.
The commitment state for the type of revocation channels we use today are
_asymmetric_: we both have our own copy of the latest channel state (though
symmetric state revocation designs do exist [2][3]). When I send an add,
then a sig to you and you revoke, then only _you_ have the HTLC on your
latest commitment. Another round is required for _me_ (the one that
proposed the new HTLC in the first place) to obtain a commitment with this
new HTLC.
When a party sends a new signature, that new signature only commits to any
_remoteu_ pdates included _before_ my last revocation message. As an example
let's say Alice and Bob both send new HTLCs htlc_a, and htlc_b, then
concurrently send new signatures. Alice's initial signature to Bob _does not
include_ htlc_b, only htlc_a. The opposite is true for Bob. At the end of
this initial exchange, Alice's commitment contains htlc_a and Bob's has
htlc_b.
This type of interaction is mentioned in passing in the spec:
> Counter-intuitively, these updates apply to the other node's commitment
> transaction; the node only adds those updates to its own commitment
> transaction when the remote node acknowledges it has applied them via
> revoke_and_ack.
Another signature exchange is required to synchronize both commitments.
Depending on the processing order of the concurrent messages, additional
states may be created. However this isn't strictly required (stop and try to
synchronize commitments), as the protocol is non-blocking and as soon as the
HTLC is included in _both_ commitments (developers usually refer to this as
HTLCs being _locked in_), then they're safe to forward. The spec calls out
this interaction in this fragment:
> As the two nodes' updates are independent, the two commitment transactions
> may be out of sync indefinitely. This is not concerning: what matters is
> whether both sides have irrevocably committed to a particular update or
> not (the final state, above).
> 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?
Putting it another way: that extra round is needed to _remove_ the HTLC from
_both_ commitment transactions. You're correct that since they have the
pre-image they have the option of going to chain whenever, but then that
means they need to hold onto that HTLC in the commitment transaction
"forever". Today there're a limited amount of slots for HTLCs, so keeping
that extra HTLC reduces the available throughput of a channel.
Reading the initial message I'm not sure I fully understand the
question/ambiguity, but I _think_ the above answers it? Happy to carry on so
we can sync our mental models.
-- Laolu
[1]: https://github.com/kit-dsn/payment-channel-tla
[2]: https://eprint.iacr.org/2020/476
[3]:
https://stanford2017.scalingbitcoin.org/files/Day1/SB2017_script_2_0.pdf
On Wed, Feb 16, 2022 at 1:01 PM Benjamin Weintraub <
weintraub.b at northeastern.edu> wrote:
> 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> 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
> 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/ce0b18d1/attachment-0001.html>;
📝 Original message:
Hi Benjamin,
Glad you found it helpful, always happy to help clarify stuff like this. I
hope to eventually be able to leverage some recent research [1] in this area
to improve the specification, as well as general understanding of the update
protocol.
> 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.
The commitment state for the type of revocation channels we use today are
_asymmetric_: we both have our own copy of the latest channel state (though
symmetric state revocation designs do exist [2][3]). When I send an add,
then a sig to you and you revoke, then only _you_ have the HTLC on your
latest commitment. Another round is required for _me_ (the one that
proposed the new HTLC in the first place) to obtain a commitment with this
new HTLC.
When a party sends a new signature, that new signature only commits to any
_remoteu_ pdates included _before_ my last revocation message. As an example
let's say Alice and Bob both send new HTLCs htlc_a, and htlc_b, then
concurrently send new signatures. Alice's initial signature to Bob _does not
include_ htlc_b, only htlc_a. The opposite is true for Bob. At the end of
this initial exchange, Alice's commitment contains htlc_a and Bob's has
htlc_b.
This type of interaction is mentioned in passing in the spec:
> Counter-intuitively, these updates apply to the other node's commitment
> transaction; the node only adds those updates to its own commitment
> transaction when the remote node acknowledges it has applied them via
> revoke_and_ack.
Another signature exchange is required to synchronize both commitments.
Depending on the processing order of the concurrent messages, additional
states may be created. However this isn't strictly required (stop and try to
synchronize commitments), as the protocol is non-blocking and as soon as the
HTLC is included in _both_ commitments (developers usually refer to this as
HTLCs being _locked in_), then they're safe to forward. The spec calls out
this interaction in this fragment:
> As the two nodes' updates are independent, the two commitment transactions
> may be out of sync indefinitely. This is not concerning: what matters is
> whether both sides have irrevocably committed to a particular update or
> not (the final state, above).
> 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?
Putting it another way: that extra round is needed to _remove_ the HTLC from
_both_ commitment transactions. You're correct that since they have the
pre-image they have the option of going to chain whenever, but then that
means they need to hold onto that HTLC in the commitment transaction
"forever". Today there're a limited amount of slots for HTLCs, so keeping
that extra HTLC reduces the available throughput of a channel.
Reading the initial message I'm not sure I fully understand the
question/ambiguity, but I _think_ the above answers it? Happy to carry on so
we can sync our mental models.
-- Laolu
[1]: https://github.com/kit-dsn/payment-channel-tla
[2]: https://eprint.iacr.org/2020/476
[3]:
https://stanford2017.scalingbitcoin.org/files/Day1/SB2017_script_2_0.pdf
On Wed, Feb 16, 2022 at 1:01 PM Benjamin Weintraub <
weintraub.b at northeastern.edu> wrote:
> 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> 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
> 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/ce0b18d1/attachment-0001.html>;