Transaction Batch Lightning Channel Close \ stacker news ~bitcoin

Transaction Batch Lightning Channel Close

542 sats \ 2 comments \ @nerd2ninja 9 Jun 2023 bitcoin

I would like for someone to do a write-up on transaction batching as it applies to lightning channels.

I already know about transaction batching for opening channels, although its alright to start the write-up with a brief blurb about that. What I'm trying to learn is about batch closing channels.

I see this comment in the LND repo: https://github.com/lightningnetwork/lnd/issues/3772#issuecomment-559904987

What I want to understand is why it isn't possible to co-op close multiple channels in a single transaction, and then since roastbeef says "in the current protocol" I would like insight into what changes need to be made for it to become possible (no one knows is an acceptable answer, but it must be a definitive "no one" and not just that you don't know)

Then I would like this now introduced concepts applied to the current channel splicing models (for reference: https://bitcoinops.org/en/topics/splicing/) Can you transaction batch splice in and can you transaction batch splice out.

80,000 sats paid

nerd2ninja's bounties

view all past bounties

81.3k sats \ 0 replies \ @shibe 11 Jun 2023

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.

397 sats \ 0 replies \ @TonyGiorgio 9 Jun 2023

I don't care about the bounty and don't feel like doing a write up, but it's related to the multiple coordinations involved in introducing multiple parties into the closing of the transaction. By "protocol supports" it's all the back and forth messages involved.

And yes, splicing will bring the protocol support for it.