When to 'commit' to the updated channel parameter during splicing?

[optout21]

During the splicing process some important channel parameters change:

• capacity
• underlying funding transaction
• channel ID (#5)
• commitment transactions

When exactly to commit to the splicing and update to the new values? It makes sense to update all the above parameters at once.

The splicing process consists of a number of steps:

1. LDK user initializes the splicing, announcing the intended new capacity (or the delta relative to the current)
2. the counterparty node is informed (splice msg)
3. the counterparty node acknowledges the intent (splice_ack msg)
4. the two nodes specify the inputs and outputs of the new funding transactions, through the interactive transaction building protocol, in turns, so both of them have the transaction at the end (tx_add* msgs)
5. the two nodes create and exchange the new commitment transactions (commitment_signed msg)
6. the two nodes sign and exchange the signature for the new funding transactions, more precisely for the input which is the old funding transaction (tx_signatures msg)
7. LDK broadcasts the new funding transaction
8. When the funding transaction is confirmed (to sufficient depth), both nodes acknowledge this. (splice_locked msg)

Some constraints are:

• before 4. the ID of the new funding transaction is not known, so after 4. is the earliest possible time
• after 8. the process is done, so that's the latest time.
• LDK can safely broadcast the new funding transaction only after 6. (safely after 5., practically after 6). Therefore the channel should not be committed to the new funding transaction before completing 6.
• It makes sense to wait for the broadcasting to complete, so after 7.

Between 7. and 8. there is an interesting situation: the new transaction has been broadcast, but there is not guarantee that it will be accepted, it will get into a block, and it will be confirmed. If the channel is attempted to be closed during this period:

• if the new transaction gets into a block eventually (happy path), closing will work only with the new funding transaction
• but if the new transaction does not get into a block for some reason (bad signature, having mistaken invalid inputs, insufficient fees, etc.), the channel can be closed only with the old funding transaction, so funding should not be updated.

Note that splicing process is somewhat analogous to channel open, but there the funding TX can be saves as soon as possible, as there is no previous TX to be masked by it.

[optout21]

Conclusion (may be non final):

Transition to the new capacity and funding tx should be done only when the new splice tx has locked.

In the transitional period -- between splice tx created and getting locked -- both funding txs have to be kept around. During this period it is unknown which of the two TXs (old and new) are spend/unspent. So at an eventual close both should be attempted to be closed. See also #2 .

[optout21]

Note: in a new version, prototype has been updated in this manner (commit only upon lock). (https://github.com/optout21/rust-lightning/tree/splicing-hapa4)