📅 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:51:39
in reply to nevent1q…ywlr
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:51:39Event JSON
{
"id": "ac8e9f27b3c75db0033d462ae83a7e606af8524ec8cfc0885f8af1b972eda2ac",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315099,
"kind": 1,
"tags": [
[
"e",
"d33837a10906296cdab5e5ff391835a12bd3f5d27bdac072961b20f094855a4d",
"",
"root"
],
[
"e",
"25f2b2f68a8b3e16d936485bd64e99e5c9f033cee3452d9ef30c3fecf9c6f7af",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-10-16\n📝 Original message:\nRusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e If we're going to do side splice-in like this, I would use a very\n\u003e different protocol: the reason for this protocol was to treat splice-in\n\u003e and splice-out the same, and inline splice-in requires wait time. Since\n\u003e splice-out doesn't, we don't need this at all.\n\u003e\n\u003e It would look much more like:\n\u003e\n\u003e 1. Prepare any output with script of specific form. eg:\n\u003e OP_DEPTH 3 OP_EQUAL OP_IF\n\u003e \u003cfunding_pubkey1\u003e \u003cfunding_pubkey2\u003e OP_CHECKMULTISIG\n\u003e OP_ELSE\n\u003e \u003cblockheight\u003e OP_CHECKLOCKTIMEVERIFY OP_DROP\n\u003e \u003cmyrescue_pubkey\u003e OP_CHECKSIG\n\u003e OP_ENDIF\n\u003e\n\u003e 1. type: 40 (`splice_in`) (`option_splice`)\n\u003e 2. data:\n\u003e * [`32`:`channel_id`]\n\u003e * [`8`: `satoshis`]\n\u003e * [`32`: `txid`]\n\u003e * [`4`: `txoutnum`]\n\u003e * [`4`: `blockheight`]\n\u003e * [`33`: `myrescue_pubkey`]\n\u003e\n\u003e 1. type: 137 (`update_splice_in_accept`) (`option_splice`)\n\u003e data:\n\u003e * [`32`:`channel_id`]\n\u003e * [`32`: `txid`]\n\u003e * [`4`: `txoutnum`]\n\u003e\n\u003e 1. type: 138 (`update_splice_in_reject`) (`option_splice`)\n\u003e data:\n\u003e * [`32`:`channel_id`]\n\u003e * [`32`: `txid`]\n\u003e * [`2`:`len`]\n\u003e * [`len`:`errorstr`]\n\u003e\n\u003e The recipient of `splice_in` checks that it's happy with the\n\u003e `blockheight` (far enough in future). Once it sees the tx referred to\n\u003e buried to its own `minimum_depth`, it checks output is what they\n\u003e claimed, then sends `update_splice_in_accept`; it's followed up\n\u003e `commitment_signed` like normal, but from this point onwards, all\n\u003e commitment txs signatures have one extra sig.\n\nLisa started asking pointed questions, and so I noticed that parallel\nsplice doesn't work with Poon-Dryja channels.\n\nThe counterparty can spend the old funding txout with a revoked spend.\nSure, I can take all the money from that, but what about the spliced\ninput?\n\nI came up with increasingly elaborate workarounds, but nothing stuck.\n\nBack to Plan A...\nRusty.",
"sig": "730939d32d4cb4fadef6c7888199b40b56ba50eff7289289ffa0ca4a28932de8596b94735c64428ba59eea48d54f32557bca0f7114782a9b656c0de4b7486bd0"
}