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