{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-04-03\n🗒️ Summary of this message: Developers discuss challenges with implementing 0-conf splicing in Bitcoin's Lightning Network, including the risk of double-spending and potential vulnerabilities.\n📝 Original message:\nHi Bastien,\n\nThanks for the update on the state of splicing.\n\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\nI think halting 0-conf splicing is pretty easy for a counterparty by\nabusing Bitcoin Core mempool replacement rule #5 on the maximum number of\noriginal transactions replaced.\n\nLet's say you have Alice with 10% of the channel capacity as a balance in\nthe \"inactive\" commitment and the 90% remaining in favor of Bob. Bob has\ninitiated a splice out of 70% of the channel capacity. On the interactive\ntransaction, Alice adds 4 unrelated confirmed inputs and then broadcasts 4\nchains of 25 unconfirmed transactions from those inputs.\n\nWhen Bob broadcasts the splice-out, it should be rejected by the network\nmempools on the grounds of RBF rule #5, whatever the absolute fee and\nfeerate. So the \"0-conf\" splicing might be maintained under risk of\ndouble-spend by your counterparty for a while.\n\nIt sounds like Bob's splice out funds should be segregated until the\ncorresponding \"active commitment\" is confirmed, i.e no use to fund another\nchannel,\nwith inbound/outbound HTLC flows.\n\nBest,\nAntoine\n\nLe lun. 3 avr. 2023 à 00:25, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e a écrit :\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/20230403/ef027b9b/attachment-0001.html\u003e"}