From rusty at rustcorp.com.au  Tue Oct 16 22:30:15 2018
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 17 Oct 2018 09:00:15 +1030
Subject: [Lightning-dev] Splicing Proposal: Feedback please!
In-Reply-To: <87k1mn7q36.fsf@rustcorp.com.au>
References: <878t36a2hk.fsf@rustcorp.com.au>
	<CAJ5H3Z5-8JKwsxgzi5UCncgoH0ga8TkURrDdDhFjWrHwprGmNg@mail.gmail.com>
	<87d0sh8gr5.fsf@rustcorp.com.au>
	<CALxbBHXa0nrV3ZRF_G7NA5nzBTfoFc1f9QwVLx937qDs9nob6g@mail.gmail.com>
	<87k1mn7q36.fsf@rustcorp.com.au>
Message-ID: <87in21h6dk.fsf@rustcorp.com.au>

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.