To add some context to this, if you start accepting HTLC's for the new balance after the parallel commitment is made, but before the re-anchor is buried, there's the potential for a race condition between a unilateral close (or any revoked commitment transaction) and the re-anchoring commitment transaction, that spends the 'pre-committed' UTXO of splicing in funds and the original funding transaction.
You can get around this by waiting until both the pre-commitment UTXO and the re-anchor have cleared a minimum depth before accepting HTLC's for the new balance totals, but that's twice as long of a wait as the first, synchronized re-commitment scheme that Rusty originally proposed. It also makes leaving the original funding transaction 'exposed' (ie Rene's version of parallel splice) untenable, as there's always the risk of an old state being published to consume that input. This foobars your current HTLC commitments. On Tue, Oct 16, 2018 at 3:31 PM Rusty Russell <ru...@rustcorp.com.au> wrote: > 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 > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
