Lightning payment channels — a flavor for every palette
Payment channels are fundamental components of the Lightning Network. As such, their development directly affects the shape and operation of the network as a whole. If you want to see where Lightning is and where it might be going, payment channels are a good place to look.
Different designs for payment channels are proliferating fast. Not even four years ago, payment channels were just one of many ideas in one of many bitcoin-related whitepapers. Lightning has since grown into the most viable way to help bitcoin finally become a medium of exchange, and there are now three different varieties of payment channel live or in beta. So let’s take a look at the different flavors out there, what problems they solve, and what trade-offs they entail.
Standard payment channels
The basic design for payment channels was articulated in the original Lightning Network whitepaper, where they were (partially) defined like this:
Micropayment channels create a relationship between two parties to perpetually update balances, deferring what is broadcast to the blockchain in a single transaction netting out the total balance between those two parties. This permits the financial relationships between two parties to be trustlessly deferred to a later date, without risk of counterparty default. Micropayment channels use real bitcoin transactions, only electing to defer the broadcast to the blockchain in such a way that both parties can guarantee their current balance on the blockchain … (emphasis added)
As I’ve explained before, two parties commit funds to their mutual payment channel, and they can transact by moving funds back and forth from one end to the other. Only the original transaction opening the channel and the final transaction closing the channel need to be broadcasted to the chain.
The only way for one party to cheat would be to broadcast a previous channel state in favor of the thief. But as long as the victim publishes a more recent state within a given time limit, the victim’s funds are returned plus a penalty out of the thief’s pocket. Used properly, these channels are trustless.
These micropayment channels are the vanilla of the Lightning Network. It may not sound glamorous, but vanilla is the most popular, most versatile ice cream of all. It’s the standard against which other flavors are measured — just like standard payment channels.
The trade-off
Standard payment channels are (generally) private, safe, and trustless. Nonetheless, other kinds of payment channel are in development or live, so why improve the standard variety if it already works? In a word, the UX can be rough with extra ugh.
The principal trade-off is the delay. In order to use a standard channel, the user must wait until its initial state has been broadcast to the chain. The best — and most expensive — scenario is a delay of about 10 minutes.
Telling incoming users “We’ll be right with you” is not the most effective onboarding strategy. Still, there is usually more than one solution to any given problem, so let’s look at some of the recent contenders.
Zero-configuration channels aka “Turbo” channels
When a standard channel is opened, the funds it contains can’t be used until the initial channel state has been posted to the public ledger. Zero-configuration channels are designed to overcome that UX obstacle.
Let’s say Alice wants to open a channel with Bob that is active immediately and funded with inbound liquidity. A zero-configuration channel would allow her to buy a voucher, using fiat or crypto, for Bob’s channel-opening service off chain, submit the voucher to Bob, who would then open the channel and push a portion of the voucher’s value to Alice’s end immediately.
Since Alice has prepaid the channel, Bob can let her start using it even before it’s been broadcast. Alice can spend her local balance without risk, because Bob is shouldering that risk until the channel has been confirmed. That’s one obstacle overcome. So far, so good.
The trade-off
As usual, convenience comes with a trade-off. In order to find it, we have to locate the trust:
Let’s say Alice buys a voucher from Bob’s service, Bob now has her funds, and she’ll have to trust him. There are two ways to remove the trust from this relationship. For one, she can spend those funds and deplete her local balance. In that case, Bob can no longer steal or lose them.
In parallel, publishing the transaction to the chain and obtaining confirmation also removes trust completely. Once the transaction has been confirmed, Bob and Alice effectively share a standard channel, and Alice would enjoy the same protection as any other standard-channel user. The risk involved in zero-conf channels depends on the length of the interval, Bob’s thoroughness, and his trustworthiness.
Note also that in current zero-conf implementations, Alice can’t receive any payments before the channel has been confirmed because there’s always a risk that the funding transaction could be ejected from the mempool. That would leave Bob in debt to Alice for an amount exceeding the value of the initial voucher.
It’s like having a video feed of the parking lot on your phone, but trusting a valet to park your car there. In the interval between the time you hand over the keys and when you see your car safely parked, you’re trusting the valet not to go out for pizza, to moonlight as an Uber driver, or to go on the road trip of his dreams.
In spite of the trade-off, some initial ventures are promising. Bitrefill has been doing great with their Thor Turbo channels, which allow users to get started immediately with their existing crypto. The Zap wallet includes zero-conf channels in its “Olympus” service, which lets users buy bitcoin with fiat and have it ready to spend within seconds.
Custodial aka “hosted” channels
Anton Kumaigorodski at Bitcoin Lightning Wallet also has an idea about how to eliminate setup delays: custodial channels. His idea is to keep users’ funds on custodians’ servers, but with a meta-ledger based on Lightning to keep track of those funds.
Existing custodial solutions on the Lightning Network manage their users’ funds over just one or a few nodes, and they forego operating a channel with each user. Instead, they keep an internal, private ledger to record which funds belong to which user at what time. Therefore, users don’t have to wait until payment channels are broadcast to the chain. The result is a decentralized network of custodians, each of which runs a centralized sub-network with its users.
Anton, however, writes that the “current generation of LN custodians basically destroys everything which makes Lightning an interesting offer in [the] first place by lowering privacy and [raising] trust assumptions to never before seen lengths.” I couldn’t agree more.
That’s where the innovation comes in. The meta-ledger works like a network of Lightning payment channels, specifically:
it’s a protocol intended to replace current custodians with a novel approach which retains unique Lightning privacy properties and provides remote accountability for those funds which are no longer under full local control.
Technically, a new type of channel is introduced which has no on-chain funding but otherwise works according to LN rules, it is designed to coexist with normal channels and be seamlessly used for payments including advanced payment techniques like AIR or AMP.
Instead of trying to improve the P2P network, Anton’s solution comes at the UX problem from the other direction: by improving how custodial wallets work. It’s effectively an auditable system of IOUs between custodial hubs and their users.
This is good news. Custodial channels finally take the role of custodians seriously by attempting to answer the key question: quis custodiet ipsos custodes? The meta-ledger gives users a means to monitor their custodians. Is this an improvement over other existing custodial models? Yes. Definitely.
The trade-off
Are custodians anything more than a necessary evil? Assuming everyone could secure their own bodies and property, would we still want to have police? If we can make P2P Lightning scalable, secure, easy, and economical, why would anyone need or want custodial services?
Custodians are the ones in control. It’s delegated to them. Custodians corrode users’ sovereignty. If bitcoin is about users’ freedom and autonomy, we must leave custodial models behind.
And then there are the limitations of monitoring. Yes, custodial channels give users a means to audit custodians, but monitoring is not restitution. If a custodian is careless with users’ keys and the users’ funds are stolen, what redress do those users have? Most countries have some form of deposit insurance to cover fiat held in commercial banks. Even if custodial-wallet providers insured their users’ funds privately, it would still require trust in the insurers.
The trust invested in a custodian varies directly with the scope of its functions. The only way to achieve minimal trust is to make the custodian superfluous.
Any commercial custodian of a user’s funds is effectively a bank. And as a “person that provides money transmission services or any other person engaged in the transfer of funds,” custodians are legally money transmitters who need the requisite FinCen license. Licensing, compliance, insurance, and regulation are expensive, and that expense can only be recouped through user fees. If reinventing fiat banks were good enough, we wouldn’t need bitcoin or Lightning in the first place. And given that economical, non-custodial, peer-to-peer solutions exist, custodians are already obsolete.
There’s more to progress than optimization
The Lightning Network is a system of many complex moving parts from the end-user devices and their operating systems all the way to the mining rigs. Nobody knows how it will look in a decade, so optimizing from the top-down cannot work. Instead, the only viable strategy is to aim for local improvements without compromising the integrity of the larger whole. Though we can’t even define what would constitute perfection, it’s usually easy to tell when a function or an app is better than its predecessor.
Payment channels are a vital component of a non-custodial Lightning Network, so they deserve the attention and effort they’re receiving. Lightning can only benefit from all this creative energy. All of us can learn from each others’ innovations, whether successful or not.
The future we’re trying to build is a peer-to-peer Lightning economy, including full, mobile user nodes (eventually), LSPs using a variety of models and providing various kinds of network services, with bitcoin as the default medium of exchange. We’re working on technology to realize that future.
