Lightning Network’s promise is fast and cheap bitcoin payments; this is what users expect when they connect to Lightning. But to send or receive payments via Lightning, you need to have at least one payment channel that connects you to the network.
Once a payment channel is opened, paying via Lightning doesn’t require on-chain transactions. Opening and closing channels still have to abide by the riles of on-chain transactions, making these actions expensive and slow.
As a responsible bitcoiner who is looking to spend their satoshis non-custodial fashion, you already would have well-funded channels at the moment of making or receiving a Lightning payment.
Unfortunately, channel management isn’t always something we consider, and sometimes, you may find yourself having to open a channel at the moment of the payment itself. Having to create a channel and wait for it to confirm three times would not make for a smooth purchase.
To resolve this emergency payment issue and what I see as a relatively fringe use case comes Turbo channels.
Turbo channels (Zero-conf channels)
A turbo channel is a Lightning channel that is accepted without confirmations on the bitcoin blockchain. This requires trust in the party opening the channel to not double-spend the channel opening transaction.
This trust may be gained by opening the channel from a 2-of-2 multi-signature address held by the opening party and a co-signer trusted with not signing a double-spend transaction. Turbo channels have been around for at least three years now but are still unknown to many Lightning users.
Who uses turbo channels?
Turbo channels are commonly used in mobile wallets and Lightning merchant services to allow users to immediately receive and send funds over the Lightning Network without waiting for a channel to confirm on the bitcoin blockchain. If you’re using a Lightning wallet like Muun, then turbo channels are set up by default, and you can opt-out if you’re not comfortable using the feature.
More haste, less security?
Using Turbo Channels gives you the smooth UX of a custodial managed Lightning wallet, and while you may have less thrid party risk than a custodial offering, it is not an option that comes without its trade-offs.
While the channel opening transaction remains unconfirmed by the bitcoin base chain and remains in the mempool, there is nothing on-chain that enforces the channel’s existence. If the wallet provider goes rogue and cancels the transaction in the mempool, the user formally loses all the funds they didn’t send while the channel was open:
- If the user didn’t use the channel before the wallet provider cancelled it, then they lose the exact amount they sent on-chain in the beginning.
- If the user used some part of the funds in the channel (for example, they paid a 50,000 sats invoice to a merchant), they lose what they sent on-chain minus the 50,000 sats.
- In the “best-case scenario”, the user sent all their local balance before the wallet provider’s attack and are short nothing except Bitcoin mining fees for the on-chain transaction and the wallet provider’s processing fees.
Once the channel opening transaction has one confirmation, it is much harder for the wallet provider to execute the same attack. It would require a reorganisation (reorg) of the blockchain.
A reorg of depth 1 is still feasible (and even happens spontaneously), but any double-spend occurring would be detected and scrutinised by the Bitcoin network’s constituents.
Turbo channels require trust because you cannot verify.
That’s where reputation comes into play and the cost-benefit analysis. The wallet provider needs to choose, is it worth stealing your channel funds or allowing you to use them and keep earning fees from you with a good experience.
Any attempt from the wallet provider to fool the user would require publishing a bitcoin transaction and would be publically available for all to see.
Even when replacing a transaction in the mempool, even if the original transaction isn’t mined yet, it is known to a large portion of the network. Therefore, the wallet’s provider malice can’t go unnoticed, and the proof remains on chain.
Could covenants provide cover for turbo channels?
As a bitcoiner, having to trust someone else to perform any transaction with your funds is a major red flag and may not sit well with some of us. Code is law, and if you don’t have the confirmation from the time chain and eminence hash power to back you up, you have no foot to stand on.
What could help reduce the exposure to trust could be using Turbo Channels in combination with OP_CHECKTEMPLATEVERIFY and creating a covenant that doesn’t allow that bitcoin to move before certain conditions being met.
If you prefer security and trustlessness
Turbo channels are an excellent option for a specific use case, but they should be used sparingly. If you are planning to be your own bank and eliminate third-party risk, you should opt for a standard channel and prepare your channels well before you need to spend out in the wild.
When creating an opening transaction, you have three confirmations before using the channel and begin making payments. Otherwise, your counterparty in the channel could make a double-spend attack on you by invalidating the opening transaction.
Waiting 30 minutes for the channel to be confirmed can be a bit of a bother, but the security it offers is well worth the wait.
