Lightning Deep Dive: What is Channel Splicing?

We all know the Bitcoin blockchain is a limited resource (and that is also important and necessary to maintain Bitcoin's decentralization). Therefore, in order to scale Bitcoin as a means of payment for the entire planet, a Layer 2 solution for transferring Bitcoin is inevitable.

Fortunately, it is already 2023 and a lot has happened. We now have Lightning in production on the Bitcoin Main Net. The technology is evolving rapidly - new cool features are being added all the time(multipath payments, hold-invoices, LN-URL, Bolt12, etc.) and Lightning payments are working smoother and more reliably every day as the network grows.

But of course there is always room for improvement:

‍

First problem: On-Chain Balance
"versus" Lightning Balance

In the current adoption phase of Lightning (one has to be that honest), you can by far not yet pay with Lightning everywhere where Bitcoin is already accepted. Every now and then, you find yourself in a situation where you still have to (or want to) perform on-chain Bitcoin transactions.

If you store your Bitcoin in a Lightning wallet, it is sometimes difficult or cumbersome to make an on-chain payment with this wallet. There are now services such as Lightning Loop (or similar services provided by wallet providers) that allow atomic swaps between Lightning and on-chain. This simply means that you send a swap partner (Lightning Loop operator or wallet provider) Bitcoin via Lightning and they send a Bitcoin transaction atomically (i.e. simultaneously and irrevocably) on-chain to the desired destination.

‍

This allows you to make on-chain payments from a Lightning wallet (the Phoenix wallet does it that way in the background, for example), but you have to rely on a peer (even if you don't have to trust them) and there are mostly fees for the service, so such a payment is always a bit more expensive than a "normal" on-chain transaction.

‍

This perceived separation of balances in a wallet between on-chain and lighting is therefore still a major hurdle that is also conceptually difficult to convey to new users.

‍

Second problem: Invariant
channel capacity

Imagine you start as a Lightning routing operator (this is now easier and easier thanks to projects like Raspiblitz, Umbrel, myNode etc.). You open a few channels with a certain amount of credit, establish yourself as a routing node, open a few more channels, slowly grow into it, open larger channels, and suddenly you have a few old channels that have been online for a long time, but which have become too "small" over time, because perhaps more Lightning routing traffic now goes 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 work better?

In short: Yes, it can be done better!

‍

Channel Splicing enters the game: What exactly is
this and what does it mean for Lightning?

SplicingThe term is also used in the world of network cabling, where the joining of two optical fiber ends is also called "splicing").

‍

Quick refresher: What exactly is a Lightning Channel? 

In simplified terms, a single Lightning Channel is nothing more than a 2-of-2 multi-sig wallet address between 2 partners where a certain number of BTC reside. These funds on this address are locked up on the blockchain, so to speak. This is the "funding transaction" (and this transaction must have at least three confirmations on the blockchain).

‍

The two peers then jointly generate (because 2-of-2 multisig, therefore both must always co-sign) new child transactions, in which they would pay out a certain part of the credit to one partner and the rest to the other partner (if a closing transaction were to occur).

However, this transaction will not end up on the blockchain for the time being, but will be continuously replaced by newer versions, where the distribution of the funds ("which part belongs to one and which to the other") will be adjusted accordingly when satoshis flow through the channel. (For easier understanding, I have deliberately left out some more complex details, such as the revocation of old channel states).

‍

At the end of a channel's lifecycle, a final transaction is simply broadcast on the blockchain that sends exactly the funds in the 2-of-2 wallet corresponding to the last "split state" in the channel, to the two partners. This is the "closing transaction."

‍

Concept Channel Splicing:

The idea of channel splicing is to close an existing channel and open a new one in a single transaction, or in other words: to replace the funding transaction of a channel with a new transaction. 

By having the new transaction build on the old funding transaction, this could also be done in such a way that you don't have to wait for 3 confirmations. In this case, relying on a 0-conf transaction is safe, as it is guaranteed that there cannot be a 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 is confirmed very late, in the meantime all accruing routing HTLCs are simply set up on both Funding transactions in parallel.

‍

What's in it for us?

Well then, as you can see very much:

• The new channel can be used immediately (without waiting for 3 confirmations)
  
  
• One can design the new funding transaction in two ways:
  
  

1. You can either add new outputs to any on-chain addresses(i.e. remove funds from the channel and send them to any on-chain addresses)
   → this is called splice-out
   
   
2. Or you can also add additional, new inputs(i.e. increase the channel capacity).
   → this is called Splice-In

‍

These features (no downtime of the channel, removing or adding funds in a channel with only one transaction) provide a solution to both problems presented at the beginning.

‍

On-Chain Payments:

• Suppose a user has his entire balance in Lightning Channels, but wants to make an on-chain payment → splice out to the on-chain address to be paid. The channel has no downtime and is simply "shrunk" afterwards by the amount taken out for the on-chain payment.
  
  The whole thing costs only one transaction (which, as things stand today, would be slightly larger, and therefore more expensive, than a "normal" standard transaction due to the Bitcoin script included). However, as soon as Lightning uses Taproot transactions, one can also perform transactions with complex script conditions in such a way that they are indistinguishable from standard transactions on the blockchain and also do not cost more fees.
  
  This means that one can easily perform on-chain payments from one's Lightning balance. There is no need to think in terms of "on-chain balance" and "lightning balance" anymore.

‍

Adjust channel capacity:

• Splicing can also be used to adjust the capacity of a channel in both directions (and in principle both peers can do this). So if the channel becomes too narrow, add more funds, or if you notice that the capacity in a channel is not used or seems oversized, simply reduce it again (but still keep the channel open).

‍

Current status

Currently, channel splicing is not yet specified in the protocol (the so-called Lightning BOLTs), which means that at the moment channel splicing is not yet possible and not available in any Lightning implementation. However, the Phoenix wallet mentioned above is about to be updated accordingly.  

Already in 2018, first proposals were discussed on the Lightning-Dev mailing list (see this post by Rusty Russel from the c-lightning team and this optimization proposal by René Pickhardt).

‍

However, the topic was then postponed again and again in favor of other topics that were not yet implemented at that time (e.g. multipath payments, more flexible data structure in onion routing - keyword "TLV", keysend, etc.).

However, in the spring of 2021, Rusty Russel started a concrete draft as a pull-request (proposed change) to the specification(see here), which has since been discussed regularly among developers of the various Lightning implementations.

‍

Conclusion

Lightning is great, but we must remember that it is still in its infancy. Even though the network is constantly (and rapidly) growing, there are still many ideas and technical improvements that simply haven't been implemented yet due to lack of time.

So if Lightning isn't perfect yet today, have some indulgence 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. :-)

‍

Thanks for reading my contribution to this topic and until next time - yours Johnny.