rich1.0npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxhttps://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://nostr.ae📅 Original date posted:2018-10-10 📝 Original message: René Pickhardt <r.pickhardt at googlemail.com> writes: > So let us take the example of Splicing in: > * The situation before splicing is that we have one output in our funding > tx that is being spent with each commitment tx. (actually if the channel > was spliced before we have more inputs but that should not change anything) > * Splice in would create one additional output that can be spent in future > commitment tx. > * I propose while splicing in this output should be spent by a special > commitment tx which goes to the funder of the splicing operation. This > should happen before the actual funding takes place. The other commitment > tx spending the original output continues to operate (assuring non blocking > splice in operation). > * Once we have enough confirmations we merge the channels (either > automatically or with the next channel update). A new commitment tx is > being created which now spends each output of each of the two funding tx > and assigns the channel balance to the channel partners accordingly to the > two independent channels. The old commitment txs are being invalidated. > * The disadvantage is that while splicing is not completed and if the > funder of the splicing tx is trying to publish an old commitment tx the > node will only be punished by sending all the funds of the first funding tx > to the partner as the special commitment tx of the 2nd output has no newer > state yet. Yes, this is the alternative method; produce a parallel funding tx (which only needs to support a single revocation, or could even be done by a long timeout) and then join them when it reaches the agreed depth. It has some elegance; particularly because one side doesn't have to do any validation or store anything until it's about to splice in. You get asked for a key and signature, you produce a new one, and sign whatever tx they want. They hand you back the tx and the key you used once it's buried far enough, and you check the tx is indeed buried and the output is the script you're expecting, then you flip the commitment tx. But I chose chose not to do this because every transaction commitment forever will require 2 signatures, and doesn't allow us to forget old revocation information. And it has some strange side-effects: onchain this looks like two channels; do we gossip about both? We have to figure the limit on splice-in to make sure the commitment tx stays under 400kSipa. > I believe splicing out is even safer: > * One just creates a spent of the funding tx which has two outputs. One > output goes to the recipient of the splice out operation and the second > output acts as a new funding transaction for the newly spliced channel. > Once signatures for the new commitment transaction are exchanged (basically > following the protocol to open a channel) the splicing operation can be > broadcasted. > > * The old channel MUST NOT be used anymore but the new channel can be > operational right away without blockchain confirmation. In case someone > tries to publish an old state of the old channel it will be a double spent > of the splicing operation and in the worst case will be punished and the > splicing was not successful. > > if one publishes an old state of the new > channel everything will just work as normal even if the funding tx is not > yet mined. It could only be replaced with an old state of the previous > channel (which as we saw is not a larger risk than the usual operation of a > lightning node) Right, you're relying on CPFP pushing through the splice-out tx if it gets stuck. This requires that we check carefully for standardness and other constraints which might prevent this; for example, we can't allow more than 20 (?) of these in a row without being sufficiently buried since I think that's where CPFP calculations top out. > As mentioned maybe you had this workflow already in your mind but I don't > see why we need to send around all the messages twice with my workflow. We > only need to maintain double state but only until it is fair / safe to do > so. I would also believe that with my approach it should be possible (but > not really necessary) to have multiple splicing operations in parallel. The extra sigs are only needed in transition, though; once splicing is over the channel looks exactly like a newly created one, which is nice. > One other question: What happens to the short_channel_id of a channel to > which founds have been spliced in? In the parallel splice world, they look like two channels. In my proposal it looks like a new channel, with a channel_update to make sure modern nodes know that the transition is happening. Cheers, Rusty.