What is Splicing
A Lightning payment channel is limited by the total capacity committed to a payment channel. This means that the channel can only move payments as big as the total funds locked in the funding transaction for that channel. You can think of a channel like an hourglass. The sand inside of it can move to and fro, but one can’t add more sand to the hourglass without breaking it.
Sometimes, this limitation can result in a bad user experience. Wallets supporting Bitcoin and Lightning need to show two separate balances: one for on-chain Bitcoin and another that can be sent off-chain via Lightning. This can be counter-intuitive when onboarding new users.
Also, routing nodes need to reallocate their liquidity to better serve the market constantly. Since they can’t add or remove Bitcoin from a payment channel, they need to close and open new channels, which results in on-chain fees for two payments, one for the close and one for the funding transaction. Besides, they also need to have a stored amount of unspent funds, ready to be used should demand appear elsewhere.
Wouldn’t it be nice if it was possible to add more sand to an hourglass on the fly? This is what splicing enables: resizing channels. With splicing, wallets can operate with only one balance, making the experience much better for the end user. Also, routing nodes wouldn’t need to close and open their channels when they need to reallocate liquidity; it’s just a matter of adding or removing funds to their existing lightning channels.
How Splicing Works
Before diving into the protocol, remember that peers on Lightning communicate by sending messages. These packets of data flow through the network containing relevant information for what they are trying to achieve. In the next paragraphs, these messages will be formatted like this.
At a high level, splicing is very simple: peers need to sign and broadcast a new 2-of-2 multi-signature that spends from the first 2-of-2 multi-signature from the funding transaction, while also adding or removing funds from the channel. The tricky part is making the process trustless and coordinated.
The first step is to make the channel enter a quiescence mode, pausing the channel in its current state, signaling that “SomeThing Fundamental is Underway,” or STFU, for short. This prepares both nodes for splicing, ensuring that the current channel doesn’t change while the peers construct the new 2-of-2 multi-signature. This is achieved by having a channel partner send a stfu message to its peer. If the other peer chooses to proceed, it’ll reply back with another stfu message.
With the channel in STFU mode, a peer can initiate a splice by sending the splice message, which signals the amount the peer wishes to add or remove. If the channel partner receiving the splice message wants to proceed, it’ll reply with a splice_ack message.
Now the channel partners can begin the negotiation of the splice. This is done using the interactive tx protocol, the same one used for dual-funded channels. During negotiation, both parties send messages called tx_add_input (to add an input to the transaction), and tx_add_output (to add an output to the transaction). The initiator of the splice has some obligations in this process. It must:
- Include an input that spends the current funding transaction output.
- Cover the costs associated with the negotiation.
- Add an output with zero value that pays to the channel partners – the new channel funding output (this zero value will be replaced subsequently).
Interestingly, both channel partners can add inputs and outputs for an unrelated activity, like opening a different channel, making another splice, or moving funds elsewhere. It’s even possible for other people to join the transaction. Sharing the splice with other activities essentially allows people to pay less fees. It’s the equivalent of hitching a ride on Bitcoin’s blockchain.
The negotiation proceeds until they agree on the transaction and send consecutive tx_complete messages. After that, they calculate the channel capacity for each side, considering the previous balance, new inputs, new outputs, and the total fee paid for the splice transaction. Afterward, the zero-value funding output is replaced with the total channel capacity.
The funding transaction (on the left) and the splice transaction (on the right). Note how the splice adds 0.5 BTC to the channel and is used by a third party (Charlie) to move funds elsewhere.
Finally, both peers will send their signatures for this new transaction in a tx_signatures message, the negotiation is considered complete, and the transaction can be broadcasted on-chain. From here on now, peers can quit STFU mode and continue operation. When the splice transaction reaches six confirmations, the channel partners can forget about the old channel state, which results in quite a large amount of database savings.
After quitting STFU mode, payments can be sent, received, and routed again. But while the splice for the new channel is not confirmed or trusted, the node has to sign for the existing and new channels.
Here’s a simplified animation of the whole process:
Development and Research
The Core Lightning developer Dusty Daemon created splicing. He announced the proposal back in 2021. It alters BOLTs 2, 7, and 9. You can see the pull request here. Dusty has already made a splice on main net, as shown here. Multiple Lightning Protocol implementations are currently working on Splicing, such as CLN and Eclair. Besides the UX improvements that Splicing offers, it has great potential to increase Bitcoin’s privacy, as the splice transaction can be used as a coinjoin. You can read more about it here.
Phoenix 3rd generation self-custodial Lightning wallet
Recently, the Eclair team added a splicing prototype to its Lightning node. This allowed the self-custodial Lightning wallet, Phoenix, to launch its third generation of self-custodial wallets. Now, instead of creating multiple channels based on usage patterns, splicing allows Phoenix to manage a single dynamic channel per user. This eliminates the issues of scattered liquidity and unpredictability associated with creating new channels.
The adoption of splicing reduces the cost of channel management significantly. Earlier, Phoenix charged a 1% fee on inbound liquidity or a minimum of 3000 sat. The only cost associated with managing channels is the mining fee for the underlying on-chain transaction, which is a direct result of the ability to “splice” funds into existing channels.
As mentioned in the post, splicing makes the distinction between on-chain and off-chain transactions blurry. This allows users to make on-chain transactions directly from their channel without needing a swap service.
Finally, the upgrade enables better control and predictability for the user. With splicing, instead of creating a new channel for each transaction, the wallet “splices in” funds into the existing channel. This helps to accurately predict when an incoming Lightning payment will incur a channel management fee and the fee is displayed to the user beforehand.
The new version is available now for Android phones, and the team expects to launch the update in iOS in the upcoming weeks.
Summary
- Current limitations of the Lightning Network include that it only allows the movement of payments up to the total funds committed to a channel.
- Splicing allows the resizing of payment channels.
- It improves user experience and helps routing nodes reallocate liquidity more efficiently.
- Splicing works by signing a new 2-of-2 multi-signature to lock the funds for the Lightning channel.
- Splicing was proposed by Core Lightning developer Dusty Daemon in 2021, and alters BOLTs 2, 7, and 9. Dusty has made a splice on the mainnet, and several Lightning Protocol implementations are working on Splicing.
- Splicing has potential to increase Bitcoin’s privacy, as the splice transaction can be used as a coinjoin.
Start building on Voltage today!
