Splicing Proposal: Now with RBF

Summary:

The context discusses proposed changes in the Replace-By-Fee (RBF) system that have been simplified to add more clarity. Multiple exclusive splices will be required, which will require extensive testing. Since the initial proposal, various changes have been made. The initiator should ensure that each splice_input refers to an existing UTXO. A null splice is allowed to reset parameters or discard history. An initiator should ensure that they have adequate funds post-splice above their reserve to pay for the splice transaction at the given feerate_per_kw.The receiver of a splice_init must ensure that they respond to max_htlc_value_in_flight_msat, channel_reserve_satoshis, htlc_minimum_msat, minimum_depth, to_self_delay as specified in accept_channel and must reply with splice_accept. If both nodes advertised the option_upfront_shutdown_script feature and any splice_output that shutdown_scriptpubkey is not equal to script, the connection must fail. Splice_accept considers the splice_limit, the total number of splice_input and splice_output from splice_init, with a minimum of 2.To confirm a splice, the sender must set signature to the signature for the splice transaction. It must remember the details of this splice transaction and send splice_confirm. The recipient should check that it should apply signature and witness to the splice transaction and broadcast the result. If the current splice transaction will not confirm in a timely manner, the sender should send splice_rbf. Once you've sent splice_confirm, each commitment transaction needs to be duplicated for every splice transaction. These are in rbf-received order (increasing fee order, if initiator is spec compliant). Finally, once the splice transaction has reached its own minimum_depth, you can send splice_closed.This context also pertains to the Lightning Network protocol and describes two message types: commitment_signed and channel_reestablish. Additionally, if a reconnection occurs between sending and receiving splice_confirm or splice_closed, there is a new field in channel_reestablish to flag that the end considers themselves to be splicing. The channel_reestablish message includes data such as the channel ID, next local commitment number, next remote revocation number, your last per-commitment secret, my current per-commitment point, and option for splicing.If the sender receives this message, they are required to set num_splice to the number of splice_confirm it has received for the current splice operation, or 0 if there is no current splice operation. The suggested changes in the RBF system have been simplified to add more clarity. It is important to ensure that each splice_input refers to an existing UTXO and that there are adequate funds post-splice above the reserve to pay for the splice transaction at the given feerate_per_kw. The recipient must handle splice_commitment_signature on the new splice transaction and continue negotiation as before. Finally, there is a suggestion that the option_data_loss_protect fields should be set if option_splice is used.

Updated on: 2023-05-25T17:15:53.916278+00:00