{"type":"rich","version":"1.0","author_name":"npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","author_url":"https://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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."}