Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-07 📝 Original message: Hi Z, Lloyd, Let's ignore ...
📅 Original date posted:2021-12-07
📝 Original message:
Hi Z, Lloyd,
Let's ignore the musig nonce exchanges for now. I believe these can be
easily included in existing messages: they probably aren't the reason we
need more round-trips (at least not the one I'm concerned about for now).
Basically, if my memory and understanding are accurate, in the above,
> it is the *PTLC-offerrer* which provides an adaptor signature.
> That adaptor signature would be included in the `update_add_ptlc` message.
Neat, you're completely right, I didn't realize that the adaptor signature
could be completed by the other party, this is a great property I had
missed.
Thanks for pointing it out, it does simplify the protocol a lot!
I don't think you can include it in `update_add_ptlc` though, it has to
be in `commitment_signed`, because if you do a batch of updates before
signing, you would immediately invalidate the adaptor signatures you
previously sent.
But it would be a simple change, where the signatures in `commitment_signed`
would actually be adaptor signatures for PTLC-success transactions and
normal signatures for PTLC-timeout transactions.
Isn't it the case that all previous PTLC adaptor signatures need to be
> re-sent for each update_add_ptlc message because the signatures would
> no longer be valid once the commit tx changes
Yes indeed, whenever the commitment changes, peers need to create new
signatures and adaptor signatures for all pending PTLCs.
This is completely fine for PTLC-success and PTLC-timeout transactions,
but we also need to exchange signatures for the new pre-signed transactions
that spend a PTLC from the remote commitment. Let's call this new pre-signed
transaction PTLC-remote-success (not a great name).
I believe these new transactions may require an additional round-trip.
Let's take a very simple example, where we have one pending PTLC in each
direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A.
Now A makes some unrelated updates and wants to sign a new commitment.
A cannot immediately send her `commitment_signed` to B.
If she did, B would be able to broadcast this new commitment, and A would
not be able to claim PTLC_BA from B's new commitment (even if she knew
the payment secret) because she wouldn't have B's signature for the new
PTLC-remote-success transaction.
So we first need B to send a new message `remote_ptlcs_signed` to A that
contains B's adaptor signatures for the PTLC-remote-success transactions
that would spend B's future commitment. After that A can safely send her
`commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B
before B can send its `commitment_signed`.
It's actually not that bad, we're only adding one message in each direction,
and we're not adding more data (apart from nonces) to existing messages.
If you have ideas on how to avoid this new message, I'd be glad to hear
them, hopefully I missed something again and we can make it better!
Thanks,
Bastien
Le mar. 7 déc. 2021 à 09:04, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning LL, and t-bast,
>
> > > Basically, if my memory and understanding are accurate, in the above,
> it is the *PTLC-offerrer* which provides an adaptor signature.
> > > That adaptor signature would be included in the `update_add_ptlc`
> message.
> >
> > Isn't it the case that all previous PTLC adaptor signatures need to be
> re-sent for each update_add_ptlc message because the signatures would no
> longer be valid once the commit tx changes. I think it's better to put it
> in `commitment_signed` if possible. This is what is done with pre-signed
> HTLC signatures at the moment anyway.
>
> Agreed.
>
> This is also avoided by fast-forwards, BTW, simply because fast-forwards
> delay the change of the commitment tx.
> It is another reason to consider fast-forwards, too....
>
> Regards,
> ZmnSCPxj
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211207/55feef47/attachment.html>;
📝 Original message:
Hi Z, Lloyd,
Let's ignore the musig nonce exchanges for now. I believe these can be
easily included in existing messages: they probably aren't the reason we
need more round-trips (at least not the one I'm concerned about for now).
Basically, if my memory and understanding are accurate, in the above,
> it is the *PTLC-offerrer* which provides an adaptor signature.
> That adaptor signature would be included in the `update_add_ptlc` message.
Neat, you're completely right, I didn't realize that the adaptor signature
could be completed by the other party, this is a great property I had
missed.
Thanks for pointing it out, it does simplify the protocol a lot!
I don't think you can include it in `update_add_ptlc` though, it has to
be in `commitment_signed`, because if you do a batch of updates before
signing, you would immediately invalidate the adaptor signatures you
previously sent.
But it would be a simple change, where the signatures in `commitment_signed`
would actually be adaptor signatures for PTLC-success transactions and
normal signatures for PTLC-timeout transactions.
Isn't it the case that all previous PTLC adaptor signatures need to be
> re-sent for each update_add_ptlc message because the signatures would
> no longer be valid once the commit tx changes
Yes indeed, whenever the commitment changes, peers need to create new
signatures and adaptor signatures for all pending PTLCs.
This is completely fine for PTLC-success and PTLC-timeout transactions,
but we also need to exchange signatures for the new pre-signed transactions
that spend a PTLC from the remote commitment. Let's call this new pre-signed
transaction PTLC-remote-success (not a great name).
I believe these new transactions may require an additional round-trip.
Let's take a very simple example, where we have one pending PTLC in each
direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A.
Now A makes some unrelated updates and wants to sign a new commitment.
A cannot immediately send her `commitment_signed` to B.
If she did, B would be able to broadcast this new commitment, and A would
not be able to claim PTLC_BA from B's new commitment (even if she knew
the payment secret) because she wouldn't have B's signature for the new
PTLC-remote-success transaction.
So we first need B to send a new message `remote_ptlcs_signed` to A that
contains B's adaptor signatures for the PTLC-remote-success transactions
that would spend B's future commitment. After that A can safely send her
`commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B
before B can send its `commitment_signed`.
It's actually not that bad, we're only adding one message in each direction,
and we're not adding more data (apart from nonces) to existing messages.
If you have ideas on how to avoid this new message, I'd be glad to hear
them, hopefully I missed something again and we can make it better!
Thanks,
Bastien
Le mar. 7 déc. 2021 à 09:04, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning LL, and t-bast,
>
> > > Basically, if my memory and understanding are accurate, in the above,
> it is the *PTLC-offerrer* which provides an adaptor signature.
> > > That adaptor signature would be included in the `update_add_ptlc`
> message.
> >
> > Isn't it the case that all previous PTLC adaptor signatures need to be
> re-sent for each update_add_ptlc message because the signatures would no
> longer be valid once the commit tx changes. I think it's better to put it
> in `commitment_signed` if possible. This is what is done with pre-signed
> HTLC signatures at the moment anyway.
>
> Agreed.
>
> This is also avoided by fast-forwards, BTW, simply because fast-forwards
> delay the change of the commitment tx.
> It is another reason to consider fast-forwards, too....
>
> Regards,
> ZmnSCPxj
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211207/55feef47/attachment.html>;