Olaoluwa Osuntokun <laol...@gmail.com> writes: > Hi Rusty, > > Happy to get the splicing train rolling! > >> We've had increasing numbers of c-lightning users get upset they can't >> open multiple channels, so I guess we're most motivated to allow splicing > of >> existing channels > > Splicing isn't a substitute for allowing multiple channels. Multiple > channels allow nodes to: > > * create distinct channels with distinct acceptance policies. > * create a mix of public and non-advertised channels with a node. > * be able to send more than the (current) max HTLC amount > using various flavors of AMP. > * get past the (current) max channel size value > * allow a link to carry more HTLCs (due to the current super low max HTLC > values) given the additional HTLC pressure that > AMP may produce (alternative is a commitment fan out)
These all seem marginal to me. I think if we start hitting max values, we should discuss increasing them. > Is there a fundamental reason that CL will never allow nodes to create > multiple channels? It seems unnecessarily limiting. Yeah, we have a daemon per peer. It's really simple with 1 daemon, 1 channel. My own fault: I was the one who insisted we mux multiple connections over the same transport; if we'd gone for independent connections our implementation would have been trivial. >> Splice Negotiation: > > Any reason to now make the splicing_add_* messages allow one to add several > inputs in a single message? Given "acceptable" constraints for how large the > witness and pkScripts can be, we can easily enforce an upper limit on the > number of inputs/outputs to add. Mainly limitations of our descriptor language, TBH. > I like that the intro messages have already been designed with the > concurrent case in mind beyond a simpler propose/accept flow. However is > there any reason why it doesn't also allow either side to fully re-negotiate > _all_ the funding details? Splicing is a good opportunity to garbage collect > the prior revocation state, and also free up obsolete space in watch towers. I thought about restarting the revocation sequence, but it seems like that only saves a tiny amount since we only store log(N) entries. We can drop old HTLC info post-splice though, and (after some delay for obscurity) tell watchtowers to drop old entries I think. > Additionally, as the size of the channel is either expanding or contracting, > both sides should be allowed to modify things like the CSV param, reserve, > max accepted htlc's, max htlc size, etc. Many of these parameters like the > CSV value should scale with the size of the channel, not allowing these > parameters to be re-negotiated could result in odd scenarios like still > maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k > satoshis. Yep, good idea! I missed that. Brings up a side point about these values, which deserves its own post... >> 1. type: 40 (`splice_add_input`) (`option_splice`) > > In order to add nested p2sh inputs, we'll need to also expose the redeem > script here, or add additional fields to allow sides to set a sig script as > well as witness during the signing phase. > >> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL' > > So no P2SH? :( Another omission, yeah, we'd want that too I think. >> * [`4`:`feerate_per_kw`] > > What fee rate is this? IMO we should do commitmentv2 before splicing as then > we can more or less do away with the initiator distinction and have most > fees be ad hoc. We're basically co-generating a tx here, just like shutdown, except it's funding a new replacement channel. Do we want to CPFP this one too? >> Splice Signing > > It seems that we're missing some fields here if we're to allow the splicing > of inputs to be done in a non-blocking manner. We'll need to send two > revocation points for the new commitment: one to allow it to be created, and > another to allow updates to proceed right after the signing is completed. In > this case we'll also need to update both commitments in tandem until the > splicing transaction has been sufficiently confirmed. I think we can use the existing revocation points for both. > Also, what about change addresses? Are they to be explicitly specified as > splice outs? They'd be splice-outs, yeah. >> 1. type: 43 (`splice_commitment_signature`) (`option_splice`) > > It may be worth pointing out there that we're able to transfer all existing > HTLCs over to the new commitment as additional context. Yeah, I think people missed that it was non-blocking like that. >> 1. type: 45 (`splice_witness`) (`option_splice`) > > Should also allow either side to specify the sig script here if we're to > allow nested p2sh (which we should IMO!). Yep. >> * [`2`:`len`] >> * [`len`:`witnesses`] > > Is the extra length needed if all the witness elements themselves are length > delimited? Yes, we always length-delimit fields so we can add options later. > > It isn't clear in the current draft, but I take it that the splice_signature > is for the old multi-sig? Yes, that's the signature required to spend the old funding txout. >> so we append to the existing `channel_update` for the original channel, >> using a new `message_flags` field: > > IMO, we need to hold off on optional fields for now, until we revisit the > formatting in order to actually get it right. As is now, all the optional > fields are basically serial mandatory soft forks. So clients must understand > the prior in order to understand the following fields. Instead, we > essentially need more of a map design. You need to add prior options to your wire parser, but that's usually the most trivial part of handling them. And they may waste space on the wire since we treat them as append-only, but OTOH it avoids combinatorial testing explosion. >> The post-splice reserve is 1% of post-splice capcacity (rounded down). > > This should be re-negotiated at time of splice creation, rather than a new > hard coded value in the protocol. > >> In addition, you can forget everything about the old channel (including >> old HTLCs and revocation requirements). > > We still have the same shachain state however (if we don't allow new state > to be exchanged during the start of the splicing scenario), correct? Yep. Thanks, Rusty. > -- Laolu > > -- Laolu PS, Damn, I always suspected there were multiple Roasbeefs, and we're simply dealing with the output of an advanced multiplexing protocol. I present the above as conclusive evidence of this thesis... _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
