📅 Original date posted:2023-04-04
🗒️ Summary of this message: A proposal for simplifying and improving the splicing protocol has been shared, including sending one `commitment_signed` message per active commitment and not revoking previous commitments during a splice. A new name for `funding_amount` is suggested.
📝 Original message:
This all works for me, I will update my implementation to be compatible
with this approach.
Perhaps we should pick another name than `funding_amount` though?
The current spec (for `splice` & `splice_ack`) proposal uses
* [`u64`:`funding_satoshis`]
How about we go with something like:
* [`s64`:`relative_satoshis`]
In this new mid-splice single commit_sig approach, `tx_signature` will be a
little
overloaded as the commit ACK as well as the ending of STFU mode.
Which should work fine but we will need to modify the spec to no longer
"MUST" reply
`revoke_and_ack` to `commitment_signed` with a carve out for this special
case.
On Sun, Apr 2, 2023 at 7:25 PM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Good morning list,
>
> As some of you may know, we've been hard at work experimenting with
> splicing [1]. Splicing is a complex feature with a large design space.
> It was interesting to iterate on two separate implementations (eclair
> and cln) and discover the pain points, edge cases and things that could
> be improved in the protocol specification.
>
> After a few months trying out different approaches, we'd like to share
> changes that we believe make the splicing protocol simpler and more
> robust.
>
> We call "active commitments" the set of valid commitment transactions to
> which updates must be applied. While one (or more) splices are ongoing,
> there is more than one active commitment. When signing updates, we send
> one `commitment_signed` message per active commitment. We send those
> messages in the order in which the corresponding funding transactions
> have been created, which lets the receiver implicitly match every
> `commitment_signed` to their respective funding transaction.
>
> Once we've negotiated a new splice and reached the signing steps of the
> interactive-tx protocol, we send a single `commitment_signed` for that
> new commitment. We don't revoke the previous commitment(s), as this adds
> an unnecessary step. Conceptually, we're simply adding a new commitment
> to our active commitments set.
>
> A sample flow will look like this:
>
> Alice Bob
> | stfu |
> |----------------------------->|
> | stfu |
> |<-----------------------------|
> | splice_init |
> |----------------------------->|
> | splice_ack |
> |<-----------------------------|
> | |
> | <interactive-tx> |
> |<---------------------------->|
> | |
> | tx_complete |
> |----------------------------->|
> | tx_complete |
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | tx_signatures |
> |----------------------------->|
> | tx_signatures |
> |<-----------------------------|
> | |
> | update_add_htlc | Alice and Bob use the channel while
> the splice transaction is unconfirmed.
> |----------------------------->|
> | update_add_htlc |
> |----------------------------->|
> | commit_sig | Sign the old commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | revoke_and_ack |
> |<-----------------------------|
> | commit_sig | Sign the old commitment.
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | revoke_and_ack |
> |----------------------------->|
> | |
> | splice_locked | The splice transaction confirms.
> |----------------------------->|
> | splice_locked |
> |<-----------------------------|
> | |
> | update_add_htlc | Alice and Bob can use the channel
> and forget the old commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | revoke_and_ack |
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | revoke_and_ack |
> |----------------------------->|
> | |
>
> You can find many more details and sample flows in [2].
>
> We require nodes to store data about the funding transaction as soon as
> they send their `commitment_signed` message. This lets us handle every
> disconnection scenario safely, allowing us to either resume the signing
> steps on reconnection or forget the funding attempt. This is important
> because if peers disagree on the set of active commitments, this will
> lead to a force-close. In order to achieve that, we only need to add
> the `next_funding_txid` to the `channel_reestablish` message, and fill
> it when we're missing signatures from our peer. Again, you can find more
> details and sample flows in [2].
>
> Finally, after trying various approaches, we believe that the funding
> amounts that peer exchange in `splice_init` and `splice_ack` should be
> relative amounts based on each peer's current channel balance.
>
> If Alice sends `funding_amount = 200_000 sats`, it means she will be
> adding 200 000 sats to the channel's capacity (splice-in).
>
> If she sends `funding_amount = -50_000 sats`, it means she will be
> removing 50 000 sats from the channel's capacity (splice-out).
>
> This makes it easier to compute the new channel balances (otherwise we
> have to deal with millisatoshi to satoshi truncation) and better matches
> the UX that node operators are expecting, which means there is less need
> to glue code between the RPC exposed to the node operator and the actual
> underlying protocol.
>
> We've also discovered that implementing 0-conf splicing is tricky: you
> need to be very careful about scenarios where your peer force-closes
> using an *inactive* commitment that ends up double-spending what you
> think is the only *active* commitment but is unconfirmed. We'd be happy
> to discuss that in more details with other implementers to reduce the
> risk of introducing new vulnerabilities when shipping that feature.
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/863
> [2] https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230404/925b7825/attachment-0001.html>;
Dustin Dettmer [ARCHIVE] /
npub1x5…kqsqu
2023-06-09 13:13:02
in reply to nevent1q…4vr4
Author Public Key
npub1x54n25utwk7dzwzvk2v0aknptez5gxdwcyrxx2wgc0lnhgvwu72qmkqsquPublished at
2023-06-09 13:13:02Event JSON
{
"id": "574452617ec6b2d9afa607552d886a1f26f5db3617c9cefc36543c36e7d7f395",
"pubkey": "352b35538b75bcd1384cb298feda615e454419aec1066329c8c3ff3ba18ee794",
"created_at": 1686316382,
"kind": 1,
"tags": [
[
"e",
"e4dd4b516f11823d5a3200101fb7503d8725eac868884fee4589e56659df2340",
"",
"root"
],
[
"e",
"002b26638f82d03b43495eb33c2716b0fe7714dc6de3bf0b2ea02850a24cb119",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2023-04-04\n🗒️ Summary of this message: A proposal for simplifying and improving the splicing protocol has been shared, including sending one `commitment_signed` message per active commitment and not revoking previous commitments during a splice. A new name for `funding_amount` is suggested.\n📝 Original message:\nThis all works for me, I will update my implementation to be compatible\nwith this approach.\n\nPerhaps we should pick another name than `funding_amount` though?\n\nThe current spec (for `splice` \u0026 `splice_ack`) proposal uses\n* [`u64`:`funding_satoshis`]\n\nHow about we go with something like:\n* [`s64`:`relative_satoshis`]\n\nIn this new mid-splice single commit_sig approach, `tx_signature` will be a\nlittle\noverloaded as the commit ACK as well as the ending of STFU mode.\n\nWhich should work fine but we will need to modify the spec to no longer\n\"MUST\" reply\n`revoke_and_ack` to `commitment_signed` with a carve out for this special\ncase.\n\n\n\nOn Sun, Apr 2, 2023 at 7:25 PM Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\n\u003e Good morning list,\n\u003e\n\u003e As some of you may know, we've been hard at work experimenting with\n\u003e splicing [1]. Splicing is a complex feature with a large design space.\n\u003e It was interesting to iterate on two separate implementations (eclair\n\u003e and cln) and discover the pain points, edge cases and things that could\n\u003e be improved in the protocol specification.\n\u003e\n\u003e After a few months trying out different approaches, we'd like to share\n\u003e changes that we believe make the splicing protocol simpler and more\n\u003e robust.\n\u003e\n\u003e We call \"active commitments\" the set of valid commitment transactions to\n\u003e which updates must be applied. While one (or more) splices are ongoing,\n\u003e there is more than one active commitment. When signing updates, we send\n\u003e one `commitment_signed` message per active commitment. We send those\n\u003e messages in the order in which the corresponding funding transactions\n\u003e have been created, which lets the receiver implicitly match every\n\u003e `commitment_signed` to their respective funding transaction.\n\u003e\n\u003e Once we've negotiated a new splice and reached the signing steps of the\n\u003e interactive-tx protocol, we send a single `commitment_signed` for that\n\u003e new commitment. We don't revoke the previous commitment(s), as this adds\n\u003e an unnecessary step. Conceptually, we're simply adding a new commitment\n\u003e to our active commitments set.\n\u003e\n\u003e A sample flow will look like this:\n\u003e\n\u003e Alice Bob\n\u003e | stfu |\n\u003e |-----------------------------\u003e|\n\u003e | stfu |\n\u003e |\u003c-----------------------------|\n\u003e | splice_init |\n\u003e |-----------------------------\u003e|\n\u003e | splice_ack |\n\u003e |\u003c-----------------------------|\n\u003e | |\n\u003e | \u003cinteractive-tx\u003e |\n\u003e |\u003c----------------------------\u003e|\n\u003e | |\n\u003e | tx_complete |\n\u003e |-----------------------------\u003e|\n\u003e | tx_complete |\n\u003e |\u003c-----------------------------|\n\u003e | commit_sig | Sign the new commitment.\n\u003e |-----------------------------\u003e|\n\u003e | commit_sig | Sign the new commitment.\n\u003e |\u003c-----------------------------|\n\u003e | tx_signatures |\n\u003e |-----------------------------\u003e|\n\u003e | tx_signatures |\n\u003e |\u003c-----------------------------|\n\u003e | |\n\u003e | update_add_htlc | Alice and Bob use the channel while\n\u003e the splice transaction is unconfirmed.\n\u003e |-----------------------------\u003e|\n\u003e | update_add_htlc |\n\u003e |-----------------------------\u003e|\n\u003e | commit_sig | Sign the old commitment.\n\u003e |-----------------------------\u003e|\n\u003e | commit_sig | Sign the new commitment.\n\u003e |-----------------------------\u003e|\n\u003e | revoke_and_ack |\n\u003e |\u003c-----------------------------|\n\u003e | commit_sig | Sign the old commitment.\n\u003e |\u003c-----------------------------|\n\u003e | commit_sig | Sign the new commitment.\n\u003e |\u003c-----------------------------|\n\u003e | revoke_and_ack |\n\u003e |-----------------------------\u003e|\n\u003e | |\n\u003e | splice_locked | The splice transaction confirms.\n\u003e |-----------------------------\u003e|\n\u003e | splice_locked |\n\u003e |\u003c-----------------------------|\n\u003e | |\n\u003e | update_add_htlc | Alice and Bob can use the channel\n\u003e and forget the old commitment.\n\u003e |-----------------------------\u003e|\n\u003e | commit_sig | Sign the new commitment.\n\u003e |-----------------------------\u003e|\n\u003e | revoke_and_ack |\n\u003e |\u003c-----------------------------|\n\u003e | commit_sig | Sign the new commitment.\n\u003e |\u003c-----------------------------|\n\u003e | revoke_and_ack |\n\u003e |-----------------------------\u003e|\n\u003e | |\n\u003e\n\u003e You can find many more details and sample flows in [2].\n\u003e\n\u003e We require nodes to store data about the funding transaction as soon as\n\u003e they send their `commitment_signed` message. This lets us handle every\n\u003e disconnection scenario safely, allowing us to either resume the signing\n\u003e steps on reconnection or forget the funding attempt. This is important\n\u003e because if peers disagree on the set of active commitments, this will\n\u003e lead to a force-close. In order to achieve that, we only need to add\n\u003e the `next_funding_txid` to the `channel_reestablish` message, and fill\n\u003e it when we're missing signatures from our peer. Again, you can find more\n\u003e details and sample flows in [2].\n\u003e\n\u003e Finally, after trying various approaches, we believe that the funding\n\u003e amounts that peer exchange in `splice_init` and `splice_ack` should be\n\u003e relative amounts based on each peer's current channel balance.\n\u003e\n\u003e If Alice sends `funding_amount = 200_000 sats`, it means she will be\n\u003e adding 200 000 sats to the channel's capacity (splice-in).\n\u003e\n\u003e If she sends `funding_amount = -50_000 sats`, it means she will be\n\u003e removing 50 000 sats from the channel's capacity (splice-out).\n\u003e\n\u003e This makes it easier to compute the new channel balances (otherwise we\n\u003e have to deal with millisatoshi to satoshi truncation) and better matches\n\u003e the UX that node operators are expecting, which means there is less need\n\u003e to glue code between the RPC exposed to the node operator and the actual\n\u003e underlying protocol.\n\u003e\n\u003e We've also discovered that implementing 0-conf splicing is tricky: you\n\u003e need to be very careful about scenarios where your peer force-closes\n\u003e using an *inactive* commitment that ends up double-spending what you\n\u003e think is the only *active* commitment but is unconfirmed. We'd be happy\n\u003e to discuss that in more details with other implementers to reduce the\n\u003e risk of introducing new vulnerabilities when shipping that feature.\n\u003e\n\u003e Cheers,\n\u003e Bastien\n\u003e\n\u003e [1] https://github.com/lightning/bolts/pull/863\n\u003e [2] https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230404/925b7825/attachment-0001.html\u003e",
"sig": "ee1b45835c70d24a11719dbfe7d510d91927eede3eec12ad0bde5ccf4a2e57ca38fe11f31614dae0d05cfe7ebbeb621aea08f05ae69bde3fdb04adbbdc50df6d"
}