Published on: 2018-11-22T01:29:29+00:00
The email exchange between Lisa Neigut and Rusty Russell revolves around the `splice_confirm` feature in the Lightning Network protocol. Lisa proposes that the `signature` field may not be necessary for this feature since the signatures for inputs can be obtained from the witness stack. However, it is noted that there is a risk of channel closure in extenuating circumstances such as a fee spike if fees exceed the value of the updated splice transaction.Splicing is considered risky because only one splice can occur at a time, and if something goes wrong, no further splices can take place. In such cases, closing the channel may be the solution. Regarding message changes during splicing, commitment transactions need to be duplicated for each splice transaction. The question arises whether HTLCs should also be duplicated, and it is suggested that CPFP (Child Pays For Parent) is a neater construction than RBF (Replace-By-Fee) as it avoids fee rate negotiation and management of ballooning HTLCs/commitment transactions.However, Rusty argues that using RBF is better for on-chain space. Finally, Lisa suggests moving towards using TLV (Type-Length-Value) in line with new specification guidelines, and Rusty agrees to try that in the next revision.In another message, ZmnSCPxj discusses the complexity of RBF and its impact on fee payment responsibilities. They propose that only the initiator of a splice should be allowed to add splice-ins and outs, with the other party adding their own once the initiator indicates satisfaction with the splice. However, implementing RBF for multiple exclusive splices at once would require extensive testing. ZmnSCPxj suggests starting with a dual-funding RBF protocol to practice for splice RBF.The context discusses proposed changes in the Replace-By-Fee (RBF) system to simplify it and provide more clarity. Multiple exclusive splices will be required, necessitating thorough testing. Various changes have been made since the initial proposal. The initiator must ensure that each splice_input refers to an existing UTXO, and a null splice is allowed to reset parameters or discard history.Sufficient funds post-splice above the reserve must be ensured by the initiator to pay for the splice transaction at the given feerate_per_kw. The receiver of a splice_init must respond according to specified parameters and reply with splice_accept. If both nodes have advertised the option_upfront_shutdown_script feature and any splice_output has shutdown_scriptpubkey not equal to script, the connection must fail. Splice_accept considers the splice_limit, total number of splice_input and splice_output from splice_init, with a minimum of 2.To confirm a splice, the sender needs to set the signature field to the signature for the splice transaction. The details of this splice transaction must be remembered, and splice_confirm should be sent. The recipient should apply the signature and witness to the splice transaction and broadcast the result. If the current splice transaction will not confirm in a timely manner, splice_rbf should be sent. Once splice_confirm is sent, each commitment transaction needs to be duplicated for every splice transaction, following the RBF order.Additionally, the context also mentions two message types in the Lightning Network protocol: commitment_signed and channel_reestablish. In case of reconnection between sending and receiving splice_confirm or splice_closed, the channel_reestablish message includes a new field to flag that the end considers themselves to be splicing. This message contains 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 options for splicing.If the sender receives the channel_reestablish message, they need to set num_splice to the number of splice_confirm received for the current splice operation, or 0 if there is no current splice operation.In summary, the discussed email thread covers various aspects related to the 'splice_confirm' function in the Lightning Network. It explores the need for the 'signature' field, the risk of channel closure, message changes during splicing, the choice between CPFP and RBF, and the suggestion to move towards using TLV. The context also mentions proposed changes in the RBF system, including the requirements for splice_input, sufficient funds post-splice, and handling of various messages like splice_accept, splice_rbf, and splice_closed.
Updated on: 2023-07-31T20:48:29.434565+00:00