📅 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>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:04:37
in reply to nevent1q…yp83
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:04:37Event JSON
{
"id": "a9948f05e2349463625121b08bd070c11f841b9017bed16b7811a4479d8e9db1",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315877,
"kind": 1,
"tags": [
[
"e",
"86d882af7142eecbdb4ce698181b82aaa475c9b46541e1e4831400616b496e77",
"",
"root"
],
[
"e",
"3e18c87858a4aaae7b3d25bcef5bc2db239e41a3f748a33911aa3e855fbf0741",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-12-07\n📝 Original message:\nHi Z, Lloyd,\n\nLet's ignore the musig nonce exchanges for now. I believe these can be\neasily included in existing messages: they probably aren't the reason we\nneed more round-trips (at least not the one I'm concerned about for now).\n\nBasically, if my memory and understanding are accurate, in the above,\n\u003e it is the *PTLC-offerrer* which provides an adaptor signature.\n\u003e That adaptor signature would be included in the `update_add_ptlc` message.\n\n\nNeat, you're completely right, I didn't realize that the adaptor signature\ncould be completed by the other party, this is a great property I had\nmissed.\nThanks for pointing it out, it does simplify the protocol a lot!\n\nI don't think you can include it in `update_add_ptlc` though, it has to\nbe in `commitment_signed`, because if you do a batch of updates before\nsigning, you would immediately invalidate the adaptor signatures you\npreviously sent.\n\nBut it would be a simple change, where the signatures in `commitment_signed`\nwould actually be adaptor signatures for PTLC-success transactions and\nnormal signatures for PTLC-timeout transactions.\n\nIsn't it the case that all previous PTLC adaptor signatures need to be\n\u003e re-sent for each update_add_ptlc message because the signatures would\n\u003e no longer be valid once the commit tx changes\n\n\nYes indeed, whenever the commitment changes, peers need to create new\nsignatures and adaptor signatures for all pending PTLCs.\n\nThis is completely fine for PTLC-success and PTLC-timeout transactions,\nbut we also need to exchange signatures for the new pre-signed transactions\nthat spend a PTLC from the remote commitment. Let's call this new pre-signed\ntransaction PTLC-remote-success (not a great name).\n\nI believe these new transactions may require an additional round-trip.\nLet's take a very simple example, where we have one pending PTLC in each\ndirection: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A.\n\nNow A makes some unrelated updates and wants to sign a new commitment.\nA cannot immediately send her `commitment_signed` to B.\nIf she did, B would be able to broadcast this new commitment, and A would\nnot be able to claim PTLC_BA from B's new commitment (even if she knew\nthe payment secret) because she wouldn't have B's signature for the new\nPTLC-remote-success transaction.\n\nSo we first need B to send a new message `remote_ptlcs_signed` to A that\ncontains B's adaptor signatures for the PTLC-remote-success transactions\nthat would spend B's future commitment. After that A can safely send her\n`commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B\nbefore B can send its `commitment_signed`.\n\nIt's actually not that bad, we're only adding one message in each direction,\nand we're not adding more data (apart from nonces) to existing messages.\n\nIf you have ideas on how to avoid this new message, I'd be glad to hear\nthem, hopefully I missed something again and we can make it better!\n\nThanks,\nBastien\n\nLe mar. 7 déc. 2021 à 09:04, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning LL, and t-bast,\n\u003e\n\u003e \u003e \u003e Basically, if my memory and understanding are accurate, in the above,\n\u003e it is the *PTLC-offerrer* which provides an adaptor signature.\n\u003e \u003e \u003e That adaptor signature would be included in the `update_add_ptlc`\n\u003e message.\n\u003e \u003e\n\u003e \u003e Isn't it the case that all previous PTLC adaptor signatures need to be\n\u003e re-sent for each update_add_ptlc message because the signatures would no\n\u003e longer be valid once the commit tx changes. I think it's better to put it\n\u003e in `commitment_signed` if possible. This is what is done with pre-signed\n\u003e HTLC signatures at the moment anyway.\n\u003e\n\u003e Agreed.\n\u003e\n\u003e This is also avoided by fast-forwards, BTW, simply because fast-forwards\n\u003e delay the change of the commitment tx.\n\u003e It is another reason to consider fast-forwards, too....\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211207/55feef47/attachment.html\u003e",
"sig": "070a00cb587c5c1fc97d94aaf50880ec6880c6bdb685412478a31455667554ce1af6456fa43c14895768cdd697261556a060b0596350f7b8c92f9a85cb4cfd75"
}