[Lightning-dev] Splicing Proposal: Feedback please!

[Rusty Russell]

Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>> Mainly limitations of our descriptor language, TBH.
>
> I don't follow...so it's a size issue? Or wanting to avoid "repeated"
> fields?

Not that smart: tools/extract-formats.py extracts descriptions from the
spec for each message.  It currently requires constants in the field
lengths, and these would be variable.

We'd have to teach it about messages within messages, eg:

1. subtype: 1 (`splice_add_input`)
2. data:
   * [`8`: `satoshis`]
   * [`32`: `prevtxid`]
   * [`4`: `prevtxoutnum`]
   * [`2`: `wscriptlen`]
   * [`wscriptlen`: `wscript`]
   * [`2`: `scriptlen`]
   * [`scriptlen`: `scriptpubkey`]

1. subtype: 2 (`splice_add_output`)
2. data:
   * [`32`:`channel_id`]
   * [`8`: `satoshis`]
   * [`2`: `scriptlen`]
   * [`scriptlen`: `outscript`]

1. type:  40 (`splice_add`) (`option_splice`)
   * [`32`:`channel_id`]
   * [`2`: `num_splice_in`]
   * [`num_splice_in*splice_add_input`: `inputs`]
   * [`2`: `num_splice_out`]
   * [`num_splice_out*splice_add_output`: `outputs`]

>> 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.

That has some elegance (we would whatever fee scheme we will use for
commitment txs), but means we will almost always *have* to CPFP, which
is unfortunate for chain bloat.

Cheers,
Rusty.