{"type":"rich","version":"1.0","author_name":"npub1zlxd3xlzjhq2ue03e5m5p2w6mp8v3dkhq5r39flsftjjsje04wvsdd2k4w","author_url":"https://nostr.ae/npub1zlxd3xlzjhq2ue03e5m5p2w6mp8v3dkhq5r39flsftjjsje04wvsdd2k4w","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-10-10\n📝 Original message:\nDear Rusty,\n\nthanks for the initiative. You suggested in your paragraph \"messages\nchanges during splicing\" during splicing to duplicate each commitment\ntransaction. One which spends the old funding tx and one which spends the\nspliced tx. I believe this can be simplified. Though I think my workflow\npretty much resembles what you have written in \"Splice Signing\" from point\n1. to 6. Maybe I might have misunderstood some parts of your suggestion.\n\nI will not write this down as formal as your proposal as I believe we are\ncurrently in the feedback and discussion phase. Maybe you already had\n\"those details\" that I am suggesting in mind. In that case sorry for my\nmail.\n\nSo let us take the example of Splicing in:\n* The situation before splicing is that we have one output in our funding\ntx that is being spent with each commitment tx. (actually if the channel\nwas spliced before we have more inputs but that should not change anything)\n* Splice in would create one additional output that can be spent in future\ncommitment tx.\n* I propose while splicing in this output should be spent by a special\ncommitment tx which goes to the funder of the splicing operation. This\nshould happen before the actual funding takes place. The other commitment\ntx spending the original output continues to operate (assuring non blocking\nsplice in operation).\n* Once we have enough confirmations we merge the channels (either\nautomatically or with the next channel update). A new commitment tx is\nbeing created which now spends each output of each of the two funding tx\nand assigns the channel balance to the channel partners accordingly to the\ntwo independent channels. The old commitment txs are being invalidated.\n* The disadvantage is that while splicing is not completed and if the\nfunder of the splicing tx is trying to publish an old commitment tx the\nnode will only be punished by sending all the funds of the first funding tx\nto the partner as the special commitment tx of the 2nd output has no newer\nstate yet.\n\nI believe splicing out is even safer:\n* One just creates a spent of the funding tx which has two outputs. One\noutput goes to the recipient of the splice out operation and the second\noutput acts as a new funding transaction for the newly spliced channel.\nOnce signatures for the new commitment transaction are exchanged (basically\nfollowing the protocol to open a channel) the splicing operation can be\nbroadcasted.\n* The old channel MUST NOT be used anymore but the new channel can be\noperational right away without blockchain confirmation. In case someone\ntries to publish an old state of the old channel it will be a double spent\nof the splicing operation and in the worst case will be punished and the\nsplicing was not successful. if one publishes an old state of the new\nchannel everything will just work as normal even if the funding tx is not\nyet mined. It could only be replaced with an old state of the previous\nchannel (which as we saw is not a larger risk than the usual operation of a\nlightning node)\n\nAs mentioned maybe you had this workflow already in your mind but I don't\nsee why we need to send around all the messages twice with my workflow. We\nonly need to maintain double state but only until it is fair / safe to do\nso. I would also believe that with my approach it should be possible (but\nnot really necessary) to have multiple splicing operations in parallel.\n\nOne other question: What happens to the short_channel_id of a channel to\nwhich founds have been spliced in?\n\nbest Rene\n\nOn Wed, Oct 10, 2018 at 5:46 AM Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Hi all!\n\u003e\n\u003e         We've had increasing numbers of c-lightning users get upset they\n\u003e can't open multiple channels, so I guess we're most motivated to allow\n\u003e splicing of existing channels.  Hence this rough proposal.\n\u003e\n\u003e For simplicity, I've chosen to only allow a single splice at a time.\n\u003e It's still complex :(\n\u003e\n\u003e Feedback welcome!\n\u003e --\n\u003e Splice Negotiation:\n\u003e\n\u003e 1. type: 40 (`splice_add_input`) (`option_splice`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`8`: `satoshis`]\n\u003e    * [`32`: `prevtxid`]\n\u003e    * [`4`: `prevtxoutnum`]\n\u003e    * [`2`: `scriptlen`]\n\u003e    * [`scriptlen`: `scriptpubkey`]\n\u003e\n\u003e 1. type: 41 (`splice_add_output`) (`option_splice`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`8`: `satoshis`]\n\u003e    * [`2`: `scriptlen`]\n\u003e    * [`scriptlen`: `outscript`]\n\u003e\n\u003e 1. type: 42 (`splice_all_added`) (`option_splice`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`4`:`feerate_per_kw`]\n\u003e    * [`4`:`minimum_depth`]\n\u003e\n\u003e Each side sends 0 or more `splice_add_input` and 0 or more\n\u003e `splice_add_output` followed by `spice_all_added` to complete the splice\n\u003e proposal.  This is done either to initiate a splice, or to respond to a\n\u003e `splice_*` from the other party.\n\u003e\n\u003e `splice_add_input` is checked for the following:\n\u003e - must not be during a current splice\n\u003e - scriptpubkey is empty, or of form 'HASH160 \u003c20-byte-script-hash\u003e EQUAL'\n\u003e - `satoshis` doesn't wrap on addition.\n\u003e - MAY check that it matches outpoint specified (sig will simply be\n\u003e   invalid if so), and that outpoint is segwit.\n\u003e\n\u003e `splice_add_output` is checked for the following:\n\u003e - must not be during a current splice\n\u003e - `satoshis` is less than or equal to amount owing to proposer, minus\n\u003e   current reserve, and greater than or equal to `dust_limit_satoshis` we\n\u003e   sent in our open_channel/accept_channel ,sg.\n\u003e - script is one of the approved forms as it is for `shutdown`.\n\u003e\n\u003e FIXME: Do we disallow splice-out if they specified\n\u003e        option_upfront_shutdown_script?\n\u003e\n\u003e `splice_all_added` is checked for the following:\n\u003e - average of `feerate_per_kw` by both sides (round down) is sufficient.\n\u003e - average of `feerate_per_kw` by both sides not grossly excessive, if we're\n\u003e   paying some of the fees (see below!)\n\u003e - both sides can afford the fees from their post-splice funds (see\n\u003e   Verification Changes below)\n\u003e - maximum of the two `minimum_depth` is not grossly excessive.\n\u003e - There is at least one splice_add_input or splice_add_output.\n\u003e\n\u003e Splice negotiation, like closing negotiation, does not have persistent\n\u003e state.  Reconnecting forgets previous negotiation.\n\u003e\n\u003e\n\u003e Splice Signing\n\u003e --------------\n\u003e\n\u003e Once `splice_all_added` is both sent and received, we need to create and\n\u003e sign both the splice tx itself, and the first commitment transaction\n\u003e which spends it (but not in that order!).\n\u003e\n\u003e 1. One input spends the current funding tx output.\n\u003e 2. There is one additional input for each splice_add_input.\n\u003e 3. One output creates the new funding tx.\n\u003e 4. There is one additional output for each splice_add_output.\n\u003e 5. The entire transaction is sorted into BIP69 order.\n\u003e 6. The feerate is the sum of the two `feerate_per_kw` divided by 2,\n\u003e    rounded down.\n\u003e\n\u003e 1. type: 43 (`splice_commitment_signature`) (`option_splice`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`64`:`commitment_signature`]\n\u003e    * [`2`:`num_htlcs`]\n\u003e    * [`num_htlcs*64`:`htlc_signature`]\n\u003e\n\u003e 1. type: 44 (`splice_signature`) (`option_splice`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`64`:`splice_signature`]\n\u003e\n\u003e 1. type: 45 (`splice_witness`) (`option_splice`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`2`: `num_witness_elements`\n\u003e    * [`2`:`len`]\n\u003e    * [`len`:`witnesses`]\n\u003e\n\u003e `witnesses` itself is serialized as `num_witness_elements` of:\n\u003e * `2`:`len`\n\u003e * `len`: `witness_element`\n\u003e\n\u003e Each side sends `splice_commitment_signature` and waits to receive and\n\u003e verify the other side's `splice_commitment_signature` before sending\n\u003e `splice_signature` and `splice_witness` for each `splice_add_input` it\n\u003e proposed, in BIP69 input order.\n\u003e\n\u003e Once a node has sent `splice_commitment_signature` it should remember\n\u003e the splice proposal across reconnects.  Once it has both sent\n\u003e `splice_signature`, the splice is locked in.\n\u003e\n\u003e\n\u003e Splice Announcement\n\u003e -------------------\n\u003e\n\u003e We have to tell the network about the new channel, otherwise there will\n\u003e be a distruption when it sees the old funding transaction spent.  This\n\u003e is inevitable for older nodes who won't understand splicing anyway.\n\u003e\n\u003e We can't send out a `channel_announcement` or `channel_update` for the\n\u003e new channel until after the new funding transaction has 6 confirmations,\n\u003e so we append to the existing `channel_update` for the original channel,\n\u003e using a new `message_flags` field:\n\u003e\n\u003e | Bit Position  | Name                      | Field\n\u003e     |\n\u003e | ------------- | ------------------------- |\n\u003e -------------------------------- |\n\u003e | 0             | `option_channel_htlc_max` | `htlc_maximum_msat`\n\u003e     |\n\u003e | 1             | `option_channel_moving`   | `moving_txid\n\u003e      |\n\u003e\n\u003e The `channel_update` gains the following field:\n\u003e     * [`32`: moving_txid`] (option_channel_moving)\n\u003e\n\u003e If a current `channel_update` for a closing channel contains\n\u003e `option_channel_moving` a node SHOULD ignore the channel close for at\n\u003e least 100 blocks iff spent by `moving_txid`.\n\u003e\n\u003e A node SHOULD immediately forward a `channel_update` it sees containing\n\u003e `option_channel_moving` if neither previous `channel_update` for the\n\u003e channel contains `option_channel_moving`.\n\u003e\n\u003e Each side of the splice can send these unilaterally, and SHOULD allow a\n\u003e few minutes for propagation (remember, average propagation from old\n\u003e nodes is still 30 seconds) prior to broadcast of the splice transaction.\n\u003e\n\u003e\n\u003e Message Changes During Splicing\n\u003e -------------------------------\n\u003e Once you've sent `splice_commitment_signature` each commitment\n\u003e transaction is duplicated: one spends the old funding transaction, one\n\u003e spends the splice transaction:\n\u003e\n\u003e 1. type: 39 (`closing_signed`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`8`:`fee_satoshis`]\n\u003e    * [`64`:`signature`]\n\u003e    * [`64`:`splice_signature`] (`option_splice`)\n\u003e\n\u003e 1. type: 132 (`commitment_signed`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`64`:`signature`]\n\u003e    * [`2`:`num_htlcs`]\n\u003e    * [`num_htlcs*64`:`htlc_signature`]\n\u003e    * [`num_htlcs*64`:`htlc_splice_signature`] (`option_splice`)\n\u003e\n\u003e If a reconnection occurs between between sending and receiving\n\u003e `splice_commitment_signature`) the peer's status is uncertain (similarly\n\u003e for closing).  This we have a new field in `channel_reestablish` to flag\n\u003e that we consider ourselves to be splicing:\n\u003e\n\u003e 1. type: 136 (`channel_reestablish`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e    * [`8`:`next_local_commitment_number`]\n\u003e    * [`8`:`next_remote_revocation_number`]\n\u003e    * [`32`:`your_last_per_commitment_secret`] (`option_data_loss_protect`)\n\u003e    * [`33`:`my_current_per_commitment_point`] (`option_data_loss_protect`)\n\u003e    * [`32`:`splice_txid`] (`option_splice`)\n\u003e\n\u003e The splice_txid field indicates that this side considers itself to be\n\u003e splicing.\n\u003e\n\u003e The sender:\n\u003e - if it has sent `splice_commitment_signature` and not sent the\n\u003e corresponding\n\u003e   `splice_closed`, MUST set `splice_txid` to the txid of the splice tx.\n\u003e    - Otherwise MUST NOT.\n\u003e\n\u003e The recipient:\n\u003e - if it has sent `splice_commitment_signature` and not sent the\n\u003e corresponding\n\u003e   `splice_closed`:\n\u003e   - if `splice_txid` does not exist or does not match the current splice:\n\u003e     - SHOULD fail the channel\n\u003e   - otherwise:\n\u003e     - MUST retransmit `splice_signature`\n\u003e - otherwise:\n\u003e   - if `splice_txid` field exists and is not all zeroes:\n\u003e     - MUST send `splice_closed`\n\u003e\n\u003e\n\u003e Validation Changes During Splicing\n\u003e ----------------------------------\n\u003e We track \"post-splice\" values as well as current values during\n\u003e splicing.\n\u003e\n\u003e The post-splice reserve is 1% of post-splice capcacity (rounded down).\n\u003e\n\u003e The fees for the splicing transaction itself are divided into parts by\n\u003e the number of `splice_add_input` plus `splice_add_output`, rounded up.\n\u003e Each side pays as many parts as it proposed `splice_add_input` plus\n\u003e `splice_add_output`.\n\u003e\n\u003e (So if Alice proposes two and Bob proposes one, and the total fee is 1000\n\u003e satoshi, each part is 334 satoshi: Alice pays 668 and Bob pays 334.)\n\u003e\n\u003e Each side's post-splice funds are debited their `splice_add_output`\n\u003e amounts, and credited their `splice_add_input` amounts, a debited the\n\u003e splice tx fees.  If any debiting occurs, the funds must be above the\n\u003e post-splice reserve (ie. you can have below reserve, but you can't spend\n\u003e if you're below reserve).\n\u003e\n\u003e All update_add_htlc must be valid for the *both* the current and\n\u003e post-splice balances.\n\u003e\n\u003e Completing Splicing\n\u003e -------------------\n\u003e Once you've seen both side's `minimum_depth` confirmations of the splice\n\u003e transaction (ie. the maximum of the two `minimum_depth` values), you can\n\u003e complete the splice by sending:\n\u003e\n\u003e 1. type: 46 (`splice_closed`) (`option_splice`)\n\u003e 2. data:\n\u003e    * [`32`:`channel_id`]\n\u003e\n\u003e Once you've sent and received `splice_closed` you can send\n\u003e `announcement_signatures` for the new channel as per normal rules (ie. 6\n\u003e confirmations, `announce_channel` bit set).\n\u003e\n\u003e In addition, you can forget everything about the old channel (including\n\u003e old HTLCs and revocation requirements).\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\n\n-- \nhttps://www.rene-pickhardt.de\n\nSkype: rene.pickhardt\n\nmobile: +49 (0)176 5762 3618\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181011/d0a500b9/attachment-0001.html\u003e"}