[Lightning-dev] Splicing Proposal: Feedback please!

Rusty Russell rusty at rustcorp.com.au
Tue Oct 16 22:30:15 UTC 2018


Rusty Russell <rusty at rustcorp.com.au> writes:
> If we're going to do side splice-in like this, I would use a very
> different protocol: the reason for this protocol was to treat splice-in
> and splice-out the same, and inline splice-in requires wait time.  Since
> splice-out doesn't, we don't need this at all.
>
> It would look much more like:
>
> 1. Prepare any output with script of specific form. eg:
>         OP_DEPTH 3 OP_EQUAL OP_IF
>                 <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
>         OP_ELSE
>                 <blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
>                 <myrescue_pubkey> OP_CHECKSIG
>         OP_ENDIF
>
> 1. type: 40 (`splice_in`) (`option_splice`)
> 2. data:
>    * [`32`:`channel_id`]
>    * [`8`: `satoshis`]
>    * [`32`: `txid`]
>    * [`4`: `txoutnum`]
>    * [`4`: `blockheight`]
>    * [`33`: `myrescue_pubkey`]
>
> 1. type: 137 (`update_splice_in_accept`) (`option_splice`)
>    data:
>    * [`32`:`channel_id`]
>    * [`32`: `txid`]
>    * [`4`: `txoutnum`]
>
> 1. type: 138 (`update_splice_in_reject`) (`option_splice`)
>    data:
>    * [`32`:`channel_id`]
>    * [`32`: `txid`]
>    * [`2`:`len`]
>    * [`len`:`errorstr`]
>
> The recipient of `splice_in` checks that it's happy with the
> `blockheight` (far enough in future).  Once it sees the tx referred to
> buried to its own `minimum_depth`, it checks output is what they
> claimed, then sends `update_splice_in_accept`; it's followed up
> `commitment_signed` like normal, but from this point onwards, all
> commitment txs signatures have one extra sig.

Lisa started asking pointed questions, and so I noticed that parallel
splice doesn't work with Poon-Dryja channels.

The counterparty can spend the old funding txout with a revoked spend.
Sure, I can take all the money from that, but what about the spliced
input?

I came up with increasingly elaborate workarounds, but nothing stuck.

Back to Plan A...
Rusty.


More information about the Lightning-dev mailing list