{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-10-11\n📝 Original message:\nOn Thu, Oct 11, 2018 at 3:40 AM Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e \u003e * Once we have enough confirmations we merge the channels (either\n\u003e \u003e automatically or with the next channel update). A new commitment tx is\n\u003e \u003e being created which now spends each output of each of the two funding tx\n\u003e \u003e and assigns the channel balance to the channel partners accordingly to\n\u003e the\n\u003e \u003e two independent channels. The old commitment txs are being invalidated.\n\u003e \u003e * The disadvantage is that while splicing is not completed and if the\n\u003e \u003e funder of the splicing tx is trying to publish an old commitment tx the\n\u003e \u003e node will only be punished by sending all the funds of the first funding\n\u003e tx\n\u003e \u003e to the partner as the special commitment tx of the 2nd output has no\n\u003e newer\n\u003e \u003e state yet.\n\u003e\n\u003e Yes, this is the alternative method; produce a parallel funding tx\n\u003e (which only needs to support a single revocation, or could even be done\n\u003e by a long timeout) and then join them when it reaches the agreed depth.\n\u003e\n\u003e It has some elegance; particularly because one side doesn't have to do\n\u003e any validation or store anything until it's about to splice in.  You get\n\u003e asked for a key and signature, you produce a new one, and sign whatever\n\u003e tx they want.  They hand you back the tx and the key you used once it's\n\u003e buried far enough, and you check the tx is indeed buried and the output\n\u003e is the script you're expecting, then you flip the commitment tx.\n\u003e\n\u003e But I chose chose not to do this because every transaction commitment\n\u003e forever will require 2 signatures, and doesn't allow us to forget old\n\u003e revocation information.\n\u003e\n\u003e And it has some strange side-effects: onchain this looks like two\n\u003e channels; do we gossip about both?  We have to figure the limit on\n\u003e splice-in to make sure the commitment tx stays under 400kSipa.\n\u003e\n\nThis is a lot closer to my original proposal for splicing, and I\nstill like it a lot more since the transition from old to new\nchannel is bascially atomic (not having to update state on both\npre-splice and post-splice version). The new funds will remain\nunavailable for the same time, and since we allow only one\nconcurrent splice in your proposal we don't even lose any\nadditional time regarding the splice-outs.\n\nSo pulling the splice_add_input and splice_add_output up to\nsignal the intent of adding funds to a splice. Splice_all_added\nis then used to start moving the funds to a pre-allocated 2-of-2\noutput where the funds can mature. Once the funds are\nmatured (e.g., 6 confirmations) we can start the transition: both\nparties claim the funding output, and the pre-allocated funds, to\ncreate a new funding tx which is immediately broadcast, and we\nflip over to the new channel state. No need to keep parallel\nstate and then disambiguating which one it was.\n\nThe downsides of this is that we now have 2 on-chain\ntransactions (pre-allocation and re-open), and splice-outs are no\nlonger immediate if we have a splice-in in the changeset as well.\nThe latter can be remediatet with one more reanchor that just\nconsiders splice-ins that were proposed.\n\n\n\n\u003e\n\u003e \u003e I believe splicing out is even safer:\n\u003e \u003e * One just creates a spent of the funding tx which has two outputs. One\n\u003e \u003e output goes to the recipient of the splice out operation and the second\n\u003e \u003e output acts as a new funding transaction for the newly spliced channel.\n\u003e \u003e Once signatures for the new commitment transaction are exchanged\n\u003e (basically\n\u003e \u003e following the protocol to open a channel) the splicing operation can be\n\u003e \u003e broadcasted.\n\u003e \u003e\n\u003e \u003e * The old channel MUST NOT be used anymore but the new channel can be\n\u003e \u003e operational right away without blockchain confirmation. In case someone\n\u003e \u003e tries to publish an old state of the old channel it will be a double\n\u003e spent\n\u003e \u003e of the splicing operation and in the worst case will be punished and the\n\u003e \u003e splicing was not successful.\n\u003e \u003e\n\u003e \u003e  if one publishes an old state of the new\n\u003e \u003e channel everything will just work as normal even if the funding tx is not\n\u003e \u003e yet mined. It could only be replaced with an old state of the previous\n\u003e \u003e channel (which as we saw is not a larger risk than the usual operation\n\u003e of a\n\u003e \u003e lightning node)\n\u003e\n\u003e Right, you're relying on CPFP pushing through the splice-out tx if it\n\u003e gets stuck.  This requires that we check carefully for standardness and\n\u003e other constraints which might prevent this; for example, we can't allow\n\u003e more than 20 (?) of these in a row without being sufficiently buried\n\u003e since I think that's where CPFP calculations top out.\n\u003e\n\nWe shouldn't allow more than one pending splice operation anyway, as\nstated in your proposal initially. We are already critically reliant on our\ntransaction being confirmed on-chain, so I don't see this as much of an\nadded issue.\n\n\n\u003e \u003e As mentioned maybe you had this workflow already in your mind but I don't\n\u003e \u003e see why we need to send around all the messages twice with my workflow.\n\u003e We\n\u003e \u003e only need to maintain double state but only until it is fair / safe to do\n\u003e \u003e so. I would also believe that with my approach it should be possible (but\n\u003e \u003e not really necessary) to have multiple splicing operations in parallel.\n\u003e\n\u003e The extra sigs are only needed in transition, though; once splicing is\n\u003e over the channel looks exactly like a newly created one, which is nice.\n\u003e\n\nI'm less worried about the bandwidth overhead, rather the\nparallel state updates are error prone and there might be\ncorner-cases that we simply don't see right now. Having parallel\nstate-updates just for the sake of saving some on-chain\nfees (fees that we'd spend in purely on-chain cases anyway) has a\ndirect impact on the channel state machine.\n\n\n\u003e \u003e One other question: What happens to the short_channel_id of a channel to\n\u003e \u003e which founds have been spliced in?\n\u003e\n\u003e In the parallel splice world, they look like two channels.  In my\n\u003e proposal it looks like a new channel, with a channel_update to make sure\n\u003e modern nodes know that the transition is happening.\n\u003e\n\nWith the pre-allocation the final effect is the same, we've just\npulled some of the waiting time above the re-anchoring and added\none more TX.\n\n\nThis is one of the cases where a simpler solution (relatively\nspeaking ^^) is to be preferred imho, allowing for future\niterations.\n\nCheers,\nChristian\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181011/f7fa9632/attachment.html\u003e"}