[Lightning-dev] Splicing Proposal: Feedback please!

Olaoluwa Osuntokun laolu32 at gmail.com
Tue Nov 6 07:02:24 UTC 2018


> 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 <rusty at rustcorp.com.au> wrote:

> Olaoluwa Osuntokun <laolu32 at 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...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/15a6f5a1/attachment-0001.html>


More information about the Lightning-dev mailing list