Rusty Russell <ru...@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. _______________________________________________ Lightning-dev mailing list Lightningfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev