2023.05 Vol.3

Splicing

Splicing is a new tech on the horizon which would allow users to re-size lightning channels. I think it might also be a useful tool for the last-mile on-ramp challenge.

Opening and closing lightning channels is relatively expensive. This cost can be amortized by opening a large channel and routing payments through it, grabbing a bunch of fees, but that requires some foresight (or luck). Ideally, capital could be cheaply added or removed from a channel instead of requiring two on-chain transactions (close + re-open). Enter the new splicing protocol which merges these two transactions into one while still remaining trustless. The splice operation updates a channel’s original funding transaction’s UTXO voiding all of the channel’s commitment transactions. It’s a fresh start.

So how could this be useful in the last-mile?

Let’s say an end-user is willing to trade some trust to an LSP for a quick on-ramp experience. The user pays out-of-band for a low capacity channel (~$5 USD) from the LSP to their wallet. In order to have a quick on-ramp, it is a zero-conf channel. The end-user does not have any bitcoin, so the funding transaction must be funded by the LSP. This is the source of the trust the end-user must have in the LSP. Until the channel is confirmed, theoretically, the LSP could double spend the UTXO of the funding transaction and rug the user. The end-user probably wants some liquidity on their side of the channel so they will also be trusting the LSP to push some sats over, but after that, all trust is in baked into the un-confirmed UTXO.

Normally node operators would want the funding transaction to be confirmed relatively quickly, even if they are using a zero-conf. But in this on-ramp scenario, the capacity of the channel is so low that it might not be worth setting a fee to get the funding transaction confirmed any time soon…maybe never. We have already established trust in this scenario and it is capped by the small capacity of the channel. What if instead of the trust existing until the funding transaction gets confirmed, it exists until the end-user is serious about loading up some more bitcoin? How could we do this?

If the LSP purposely sets the fee on the funding transaction to almost nothing the transaction will most likely fall out of the mempool. Unless it happens to be at a time when the mempool is empty, which great, the transaction gets confirmed for a low fee. But if it does fall out (the more likely scenario these days) this doesn’t invalidate the transaction, it can always be re-broadcasted later. At that later point we might want to bump the fee on the transaction to make sure it makes it into a block.

This is starting to sound similar to commitment transactions in the lightning protocol. Commitment transactions are created but not broadcasted immediately. If a channel needs to be forced closed later for whatever reason, the commitment transaction is broadcasted by one of the nodes. Maybe the blockspace market has dramatically changed since when the transaction was signed and now the transaction doesn’t have a high enough fee to make it into a block. The fee needs to be bumped. This scenario has been addressed by anchor outputs which allow node operators to use CPFP to bump a fee on a commitment transaction.

We aren’t looking to bump the fee on a commitment transaction, but the funding transaction. Funding transactions don’t have anchor outputs, but…slicing updates a channel by paying the original funding transaction’s UTXO into a new transaction. Starts to look a little like a CPFP.

So pulling this all together:

1. The LSP and end-user establish a small capacity, zero-conf channel with a funding transaction with minimum fees. End-user is fine with the trust required for the time being.
2. End-user becomes comfortable with using the lightning wallet and wants to load in more funds, but enough funds that they no longer want it to be trust-based.
3. LSP uses splicing to load more funds into the channel AND leverage the splice transaction as a CPFP to pull the original funding transaction into the blockchain.

What does this buy us? The end-user is able to on-board to lightning quick and cheap, avoiding the heavy upfront costs. Once comfortable, they can then smoothly transaction into a trust-less environment. A user could also choose to just close the original channel and use the closing transaction as the CPFP, although this would probably not be very economical since the channel’s capacity is so low. But this is another cap on the amount of trust required in step #1 above, at any point the user could decided to take the un-confirmed funding transaction on chain

Should be noted that this flow can theoretically work in a non-splicing world, but it has more steps and thus more expensive. A user would want to close the original channel and open a larger one, doubling the costs compared to the splicing technique which eats away at what will already be pretty low margins given the use-case.