📅 Original date posted:2018-10-16
📝 Original message:
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 <rusty at rustcorp.com.au> wrote:
> 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.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181016/6855b1ec/attachment.html>;
lisa neigut [ARCHIVE] /
npub1sp…s64t2
2023-06-09 12:51:39
in reply to nevent1q…r9kk
Author Public Key
npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2Published at
2023-06-09 12:51:39Event JSON
{
"id": "6334f00121c48919fd08550900ff9a9b095f40c0596695b45a361264f34b9249",
"pubkey": "804770eb58d163d63f0f996fd6bebabe1b8c582a5dd544cf61bba0bc5335720a",
"created_at": 1686315099,
"kind": 1,
"tags": [
[
"e",
"d33837a10906296cdab5e5ff391835a12bd3f5d27bdac072961b20f094855a4d",
"",
"root"
],
[
"e",
"ac8e9f27b3c75db0033d462ae83a7e606af8524ec8cfc0885f8af1b972eda2ac",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-10-16\n📝 Original message:\nTo add some context to this, if you start accepting HTLC's for the new\nbalance after the parallel commitment is made, but before the re-anchor is\nburied, there's the potential for a race condition between a unilateral\nclose (or any revoked commitment transaction) and the re-anchoring\ncommitment transaction, that spends the 'pre-committed' UTXO of splicing in\nfunds and the original funding transaction.\n\nYou can get around this by waiting until both the pre-commitment UTXO and\nthe re-anchor have cleared a minimum depth before accepting HTLC's for the\nnew balance totals, but that's twice as long of a wait as the first,\nsynchronized re-commitment scheme that Rusty originally proposed.\n\nIt also makes leaving the original funding transaction 'exposed' (ie Rene's\nversion of parallel splice) untenable, as there's always the risk of an old\nstate being published to consume that input. This foobars your current HTLC\ncommitments.\n\nOn Tue, Oct 16, 2018 at 3:31 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Rusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e \u003e If we're going to do side splice-in like this, I would use a very\n\u003e \u003e different protocol: the reason for this protocol was to treat splice-in\n\u003e \u003e and splice-out the same, and inline splice-in requires wait time. Since\n\u003e \u003e splice-out doesn't, we don't need this at all.\n\u003e \u003e\n\u003e \u003e It would look much more like:\n\u003e \u003e\n\u003e \u003e 1. Prepare any output with script of specific form. eg:\n\u003e \u003e OP_DEPTH 3 OP_EQUAL OP_IF\n\u003e \u003e \u003cfunding_pubkey1\u003e \u003cfunding_pubkey2\u003e OP_CHECKMULTISIG\n\u003e \u003e OP_ELSE\n\u003e \u003e \u003cblockheight\u003e OP_CHECKLOCKTIMEVERIFY OP_DROP\n\u003e \u003e \u003cmyrescue_pubkey\u003e OP_CHECKSIG\n\u003e \u003e OP_ENDIF\n\u003e \u003e\n\u003e \u003e 1. type: 40 (`splice_in`) (`option_splice`)\n\u003e \u003e 2. data:\n\u003e \u003e * [`32`:`channel_id`]\n\u003e \u003e * [`8`: `satoshis`]\n\u003e \u003e * [`32`: `txid`]\n\u003e \u003e * [`4`: `txoutnum`]\n\u003e \u003e * [`4`: `blockheight`]\n\u003e \u003e * [`33`: `myrescue_pubkey`]\n\u003e \u003e\n\u003e \u003e 1. type: 137 (`update_splice_in_accept`) (`option_splice`)\n\u003e \u003e data:\n\u003e \u003e * [`32`:`channel_id`]\n\u003e \u003e * [`32`: `txid`]\n\u003e \u003e * [`4`: `txoutnum`]\n\u003e \u003e\n\u003e \u003e 1. type: 138 (`update_splice_in_reject`) (`option_splice`)\n\u003e \u003e data:\n\u003e \u003e * [`32`:`channel_id`]\n\u003e \u003e * [`32`: `txid`]\n\u003e \u003e * [`2`:`len`]\n\u003e \u003e * [`len`:`errorstr`]\n\u003e \u003e\n\u003e \u003e The recipient of `splice_in` checks that it's happy with the\n\u003e \u003e `blockheight` (far enough in future). Once it sees the tx referred to\n\u003e \u003e buried to its own `minimum_depth`, it checks output is what they\n\u003e \u003e claimed, then sends `update_splice_in_accept`; it's followed up\n\u003e \u003e `commitment_signed` like normal, but from this point onwards, all\n\u003e \u003e commitment txs signatures have one extra sig.\n\u003e\n\u003e Lisa started asking pointed questions, and so I noticed that parallel\n\u003e splice doesn't work with Poon-Dryja channels.\n\u003e\n\u003e The counterparty can spend the old funding txout with a revoked spend.\n\u003e Sure, I can take all the money from that, but what about the spliced\n\u003e input?\n\u003e\n\u003e I came up with increasingly elaborate workarounds, but nothing stuck.\n\u003e\n\u003e Back to Plan A...\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181016/6855b1ec/attachment.html\u003e",
"sig": "c1df83a70b714dff81d394046de6e6b9c017ea2ab20f37b454916783fd5468d319482fdeb6cb51d7b12728e0cb8bdaa880a76e81a554482aaee303ff0ed98c6c"
}