Author: Rusty Russell 2018-10-16 04:33:57
Published on: 2018-10-16T04:33:57+00:00
Olaoluwa Osuntokun and Rusty Russell discuss the implementation of splicing in c-lightning, a Bitcoin Lightning Network Implementation. The discussion highlights the limitations of c-lightning, which has only one daemon per peer, making it difficult to create multiple channels. However, Olaoluwa Osuntokun believes that allowing multiple channels will help nodes to create distinct channels with distinct acceptance policies, mix public and non-advertised channels with a node, send more than the max HTLC amount, get past the current max channel size value, and allow a link to carry more HTLCs. The discussions also cover several aspects of splicing, including Splice Negotiation, Splice Signing, Splice Commitment Signature, and Splice Witness. They consider various elements such as nested p2sh inputs, change addresses, signature scripts, and HTLCs. They also discuss the need for both sides to modify the CSV param, reserve, max accepted htlc's, max htlc size, etc., and how these parameters should scale with the size of the channel to avoid odd scenarios.Additionally, they consider garbage collecting prior revocation state and freeing up obsolete space in watchtowers. They also suggest restarting the revocation sequence, dropping old HTLC info post-splice, and telling watchtowers to drop old entries. There is a suggestion to renegotiate the post-splice reserve at the time of splice creation, rather than having a new hard-coded value in the protocol. Finally, Laolu suspects that there are multiple Roasbeefs, and they're dealing with the output of an advanced multiplexing protocol.
Updated on: 2023-05-25T14:12:06.487224+00:00