Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-16 📝 Original message: Rusty Russell <rusty at ...

📅 Original date posted:2018-10-16
📝 Original message:
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.