We all know that the Bitcoin blockchain is a limited resource (and that is also important and necessary to maintain Bitcoin's decentralization). In order to scale Bitcoin as a means of payment for the entire planet, a layer 2 solution to transfer Bitcoin is therefore essential.
Fortunately, it is already the year 2023 and a lot has already happened. We now have Lightning Productive on Bitcoin Main Net. The technology is evolving rapidly - new, cool features are constantly being added (multipath payments, Hold-Invoices, LN-URL, Bolt12, etc.) and as the network grows, Lightning payments work more smoothly and reliably every day.
But of course there is always room for improvement:
In the current adoption phase of Lightning (you have to be that honest), you can by no means pay with Lightning everywhere where Bitcoin is already accepted. Time and again, you get into a situation where you still have to (or want to) carry out on-chain Bitcoin transactions.
If a user now stores their Bitcoin in a Lightning wallet, it is sometimes difficult or cumbersome to make an on-chain payment with this wallet. Although there are now services such as Lightning Loop (or equivalent similar services provided by wallet providers) that enable atomic swap between Lightning and on-chain. This simply means that you send Bitcoin to a swap partner (Lightning Loop operator or wallet provider) and this sends atomic (i.e. simultaneously and irrevocably) an on-chain Bitcoin transaction to the desired destination.
This allows you to make on-chain payments from a Lightning wallet (which Phoenix wallet Does that happen in the background, for example), but you depend on a peer (even if you don't have to trust them) and there are usually fees for the service, so that such a payment is always a bit more expensive than a “normal” on-chain transaction.
This perceived separation of funds in a wallet between on-chain and lighting is therefore still a major hurdle that is difficult to communicate to new users even from a conceptual point of view.
Imagine starting out as a Lightning Routing Operator (this is now possible thanks to projects such as Raspiblitz, Umbrel, MyNode etc. ever easier). With a certain amount of credit, you open a few channels, establish yourself as a routing node, open a few more channels, slowly grow in, open up larger channels, and suddenly you have a few old channels that have been online for a long time but that have become “small” over time because maybe more Lightning routing traffic is now going through your own node, or you want to provide more liquidity for routing.
Yes, of course, you can now simply open a second additional channel to the same peer. But then you have two channels that also need two separate closing transactions and so on. Wouldn't that be better?
In short: Yes, it's better!
Splicing: English for”liaise”,”sticking”, the term is also known in the world of network cabling, the connection of two fiber optic ends is also called “splicing”).
In simple terms, a single Lightning Channel is nothing more than a 2-of-2 multi-sig wallet address between 2 partners that contains a certain number of BTC. These funds at this address are locked up on the blockchain, so to speak. That is the”funding transaction” (and that transaction must have at least three confirmations on the blockchain).
The two peers then generate new child transactions together (because yes 2-of-2 multisig, which is why both always have to co-sign), in which they would pay out a certain portion of the credit to one partner and the rest to the other partner (if there was a closing transaction).
However, this transaction does not end up on the blockchain for now, but is constantly being replaced by newer versions, where the distribution of funds (“which part belongs to one person and which belongs to the other”) is adjusted accordingly when satoshis flow through the channel. (For easier understanding, I have deliberately omitted a few more complex details here, such as revoking old channel states).
At the end of the life cycle of a channel, a final transaction is simply browcasted on the blockchain, which sends exactly the funds in the 2-of-2 wallet to the two partners in accordance with the last “distribution status” in the channel. That is the “closing transaction.”
The idea of channel splicing is now — in simple terms — to close an existing channel and open a new channel in a single transaction, or in other words: to replace the “funding transaction” of a channel with a new transaction.
Because the new transaction is based on the old funding transaction, you could also design it in such a way that you don't have to wait for 3 confirmations. In this case, relying on a 0-conf transaction is secure, as it ensures that there can be no double spend. Since the old funding transaction is a 2-of-2 MultiSig address, each of the two partners can be sure that the other cannot create a double-spend transaction without the partner's intervention. And if the new transaction is never confirmed or only confirmed very late, in the meantime, all incoming routing HTLCs are simply set up in parallel on both funding transactions.
Well then, as you can see, a lot:
These features (no channel downtime, removal or addition of funds in a channel with just one transaction) provide a solution to both problems presented at the beginning.
Channel splicing is currently not yet in the protocol (the so-called Lightning BOLTs), i.e. channel splicing is not yet possible and is not available in any Lightning implementation. However, the Phoenix wallet mentioned above is on the verge of a corresponding Update.
As early as 2018, initial suggestions were discussed on the Lightning-Dev mailing list (see This post from Rusty Russel from the c-lightning team and this optimization suggestion from René Pickhardt).
However, the topic was then changed in favor of other topics that were also not yet implemented at the time (e.g. Multipath payments, more flexible data structure in onion routing - keyword “TLV”, keysend, etc.) repeatedly postponed.
In spring 2021, however, Rusty Russel began a concrete draft as a PULL request (proposed change) for the specification (see here), which has been discussed regularly among developers of the various Lightning implementations ever since.
Lightning is great, but we can't forget that it's still in its infancy. Even though the network is constantly (and rapidly) growing, there are still many ideas and technical improvements that have simply not yet been implemented due to lack of time.
So if Lightning isn't perfect today, have some forbearance and confidence. The developer community is working on it. There are plenty of ideas in the pipeline.
Let's build the money of the future. :-)
Thank you for reading my post on this topic and until next time - yours johnny.
