reply on: Transaction Batch Lightning Channel Close \ stacker news ~bitcoin

pull down to refresh

81.3k sats \ 0 replies \ @shibe 11 Jun 2023 \ on: Transaction Batch Lightning Channel Close bitcoin

After a bit of searching through the BOLTs (very dense information) I seem to understand it. The tl;dr is that while opening is a fairly simple process (one party is usually in control of all the inputs and the outputs), closing is a fair bit more complex, there's negotiations of feerates involved, then the transaction gets passed around etc. I'm guessing to minimize the complexity, the BOLT explicitly defines the format of a closing transaction:

The transaction must have only one input, and the first input of this transaction should be the channel UTXO
The transaction can have 0, 1, or 2 outputs (one for each party's balances)

So in this current format, it's just not possible to have multiple channel closes in a single transaction, which would also add a fair bit of complexity to an already back-and-forth process between the two parties initiating a close.

Unilateral closes would be even trickier, since they're pre-signed and so you can't add more outputs/inputs to them later (unless you use the SIGHASH_SINGLE | ANYONECANPAY flags, but in that case you could only commit to one output in the transaction, whereas a force-close usually has 2 outputs).

Thus Lightning needs a new way to communicate between nodes that "I want to close this channel, and I also want these inputs and outputs added to this transaction", and Lightning implementations also need a way to batch such transactions automatically.

Which is where the splicing proposal comes in. Splicing basically closes a channel and opens a new one in the same transaction, so it already is more advanced than closing. Reading the mailing lists I see that people have proposed transaction cut-through as a generalization of splicing. The idea is to allow Lightning nodes to tell the other nodes which inputs they wish to add to the closing transaction, and the resulting inputs will go into the party's final UTXO balance (so it gets added to what the party had in the channel).

Through this generalized "cut-through", you could have the node add other closing transactions to the closing transaction itself, and also get splicing on top of this protocol. But I'm not sure how far along work on this is yet.