> Mainly limitations of our descriptor language, TBH. I don't follow...so it's a size issue? Or wanting to avoid "repeated" fields?
> I thought about restarting the revocation sequence, but it seems like that > only saves a tiny amount since we only store log(N) entries Yeah that makes sense, forgetting the HTLC state is a big enough win in and of itself. >>> 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. Yep, if we retain the existing shachain trees, then we just continue to extend the leaves! > 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? It'd be nice to be able to also anchor down this splicing transaction given that we may only allow a single outstanding splicing operation to begin with. Being able to CPFP it (and later on provide arbitrary fee inputs) allows be to speed up the process if I want to queue another operation up right afterwards. -- Laolu On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell <ru...@rustcorp.com.au> wrote: > 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
