<oembed><type>rich</type><version>1.0</version><author_name>npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx</author_name><author_url>https://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2018-10-16&#xA;📝 Original message:&#xA;Rusty Russell &lt;rusty at rustcorp.com.au&gt; writes:&#xA;&gt; If we&#39;re going to do side splice-in like this, I would use a very&#xA;&gt; different protocol: the reason for this protocol was to treat splice-in&#xA;&gt; and splice-out the same, and inline splice-in requires wait time.  Since&#xA;&gt; splice-out doesn&#39;t, we don&#39;t need this at all.&#xA;&gt;&#xA;&gt; It would look much more like:&#xA;&gt;&#xA;&gt; 1. Prepare any output with script of specific form. eg:&#xA;&gt;         OP_DEPTH 3 OP_EQUAL OP_IF&#xA;&gt;                 &lt;funding_pubkey1&gt; &lt;funding_pubkey2&gt; OP_CHECKMULTISIG&#xA;&gt;         OP_ELSE&#xA;&gt;                 &lt;blockheight&gt; OP_CHECKLOCKTIMEVERIFY OP_DROP&#xA;&gt;                 &lt;myrescue_pubkey&gt; OP_CHECKSIG&#xA;&gt;         OP_ENDIF&#xA;&gt;&#xA;&gt; 1. type: 40 (`splice_in`) (`option_splice`)&#xA;&gt; 2. data:&#xA;&gt;    * [`32`:`channel_id`]&#xA;&gt;    * [`8`: `satoshis`]&#xA;&gt;    * [`32`: `txid`]&#xA;&gt;    * [`4`: `txoutnum`]&#xA;&gt;    * [`4`: `blockheight`]&#xA;&gt;    * [`33`: `myrescue_pubkey`]&#xA;&gt;&#xA;&gt; 1. type: 137 (`update_splice_in_accept`) (`option_splice`)&#xA;&gt;    data:&#xA;&gt;    * [`32`:`channel_id`]&#xA;&gt;    * [`32`: `txid`]&#xA;&gt;    * [`4`: `txoutnum`]&#xA;&gt;&#xA;&gt; 1. type: 138 (`update_splice_in_reject`) (`option_splice`)&#xA;&gt;    data:&#xA;&gt;    * [`32`:`channel_id`]&#xA;&gt;    * [`32`: `txid`]&#xA;&gt;    * [`2`:`len`]&#xA;&gt;    * [`len`:`errorstr`]&#xA;&gt;&#xA;&gt; The recipient of `splice_in` checks that it&#39;s happy with the&#xA;&gt; `blockheight` (far enough in future).  Once it sees the tx referred to&#xA;&gt; buried to its own `minimum_depth`, it checks output is what they&#xA;&gt; claimed, then sends `update_splice_in_accept`; it&#39;s followed up&#xA;&gt; `commitment_signed` like normal, but from this point onwards, all&#xA;&gt; commitment txs signatures have one extra sig.&#xA;&#xA;Lisa started asking pointed questions, and so I noticed that parallel&#xA;splice doesn&#39;t work with Poon-Dryja channels.&#xA;&#xA;The counterparty can spend the old funding txout with a revoked spend.&#xA;Sure, I can take all the money from that, but what about the spliced&#xA;input?&#xA;&#xA;I came up with increasingly elaborate workarounds, but nothing stuck.&#xA;&#xA;Back to Plan A...&#xA;Rusty.</html></oembed>