At its core Splicing is a simple concept, the ability to resize Lightning channels. But what's become apparent over time is the ability to resize Lightning channels gives us many additional benefits that were not intuitively obvious at first, and will fundamentally improve the utility of Lightning.
There are really two sides to what Splicing brings:
The first side is easier to explain: There are a lot of bitcoin wallet apps now — which is great. These developers run into a problem when they develop their apps: should it be bitcoin or Lightning?
Most apps choose one or the other but some ambitious ones choose both! Which, from a fundamentals perspective, is the best solution.
But this creates a problem. These wallets now have "two balances" — one for bitcoin and one for Lightning. I don't know if you've ever onboarded someone new to bitcoin before so let me tell you: this really confuses new users. It works great advanced, or "OG," bitcoiners — but we want bitcoin to work for everybody.
This "two balance" problem isn't just a design problem, it is because the two modes are fundamentally different and aren't able to be made "one" without creating a new user problem: long delays and / or impractically high fees.
Splicing, once implemented across the network, is the secret sauce that makes 'one balance' wallets possible. Splicing makes the two interoperable at low cost.
The second side, backend liquidity improvements, can be more complex to understand but has an even bigger impact on Lightning than the enabling of 'one balance' apps.
Lightning operates by having many "mini" banks across its network. These banks only offer one service: the ability to move money across their section of the network.
Traditional banking requires one mega "central" bank to approve a select few "real" banks to be in the trusted network. Lightning asks a different question: what if we opened up banking to everyone? What if there were so many interoperable banks we could create a "de-central bank"? If enough people did it, we could eventually create something as reliable as the central bank — or perhaps even more reliable!
This has in fact already happened. The number of Lightning "mini-banks" keeps growing and soon we will reach some one hundred thousand of these banks — far outstripping the United State's five thousand banks.
These mini-banks are all competing to route your payments as cheaply as possible. For one of these mini-banks to be selected to route a given payment, they need to have already stored some bitcoin in the right "lightning account" at the moment of a user's transaction.
To give you a sense of this: a successful lightning bank will typically maintain 100 different accounts. They are constantly moving their funds around these accounts trying to guess where the user will need to make a payment next. If they happen to have a 100,000 sat account balance along the path to Sally's Sandwich Shop, right when you buy a sandwich there — BAM — they're going to get selected to route and be rewarded.
Now imagine being one of these mini-banks with 100 accounts, constantly shuffling them around trying to guess consumer behavior. It's quite a hard job! Turns out people are quite unpredictable and you have a lot of competition trying to do the exact same thing!
Okay so how does Splicing help this? Well turns out moving money between these accounts is rather expensive — in practice these Lightning banks are actually closing and opening accounts all the time. They also need to keep a "reserve" of unused funds, ready to be deployed at a moment's notice should demand appear somewhere unexpectedly.
Splicing removes both the need for expensive closing and opening of accounts, as well as the need for an idle "reserve" fund. This will dramatically lower operating costs, complexity, and idle capital challenges faced by these mini banks. Splicing does this by enabling the direct transfer of funds between "Lightning accounts", at the lowest cost possible. Even better, splicing makes the network more robust by helping these mini Lightning banks stay independent — ending their reliance on so-called "centralized liquidity providers."
This news should be very exciting to the people running these Lightning mini-banks but also to you, the Lightning user. When these 'mini banks' run more efficiently the savings quickly get passed on to the users in the form of even cheaper fees and more reliable payments.
Splicing is the process of moving a lightning channel's funding utxo into a new "spliced" utxo. The exact steps involved are quite simple — sign the 2of2 multisignature transaction to a new location. Doing it in a trustless manner however, is not simple at all.
The pending commitment transaction must be re-built for the new "splice" utxo before the moving of the utxo as well as any child HTLC transactions.
Before we can recreate a duplicate commitment state however, we need to ensure the current one doesn't change while we're working on it. So we introduce a new Lightning state called SomeThing Fundamental is Underway, or STFU for short.
STFU that quiets the channel and prevents the commitment state from changing for a short while.
Afterwards we begin the transaction negotiation using the interactive-tx protocol. This involves each side taking turns adding inputs & outputs one at a time. The existing channel funding utxo is added as an input to this negotiated transaction.
Both nodes can add additional inputs & outputs as desired for unrelated activity, for instance opening a different channel or even a second splice. All these will be merged together into a single transaction.
Once completed, both parties validate the final transaction, confirming the new balance is what was expected and the correct amount of fees are being paid to miners. Then they sign the transaction and pass the signature over to each other.
After broadcasting, each node waits for 6 confirmations before considering the splice "valid". At this point they are able to forget about the old channel state and move over to the new splice one. This results in quite a large amount of database savings.
The process of taking a Lightning implementation from pre-splicing to splicing has many steps.
First you must decide if your channel state will support having its funding details overwritten or if you will treat the splice channel as an entirely new state. Both approaches work and the which one is ideal will depend on how the given implementation built their channel state so far.
The pros of two duplicate channel states:
The pros of one channel state:
In either case, extra work to manage channel ids & short channel ids, particularly when used as keys, will need to be done throughout the code base.
For your given code base you should reflect on the complexity of each of these pros and cons — both on difficulty to refactor and complexity risk that may introduce bugs.
Next, you will want a re-usable interactive transaction module. This module handles all TX_ADD_INPUT/TX_ADD_OUTPUT type messages. You will need this module for dual funding as well, and many implementations start with dual funding for this reason.
The module will also be useful in the future for "splice to close" and potentially other Lightning spec additions in the future.
The interactive transaction protocol is very similar to the dual funding variant but has slight differences. Be sure to keep these differences in mind when building the module so it can operate in both use cases.
The next logical step is implementing "STFU" logic. Many find the STFU protocol more complicated than expected. This is because the STFU message is actually a request for STFU mode. It is not considered active until STFU is received back.
If the other side is busy with a task, say adding an HTLC and updating the commitment transaction, it will not reply STFU back until it has completed that operation.
So you will need some kind of STFU state management console, and a way to pause your task (splicing) until stfu is completed when it can be resumed.
At the time of this writing, only splicing using STFU mode but that is quite likely to change. So building your STFU module with future proofing in mind is an excellent idea here.
There are also special considerations around STFU mode for ties. This is when a race condition occurs where both sides want to initiate a splice at the same moment. Be sure to handle these ties correctly.
On initiation you should typically have a PSBT of inputs & outputs your user would like to add to the transaction and a relative channel adjustment amount. You will need to send the relative amount change to send splice as well as splice_ack. Keep in mind both sides of the splice get to provide changes — so be sure to build a plug-in routine for the accepting side to suggest it's PSBT of changes.
You can also view some of Dusty Daemon's video explanations of how splicing works.