Lightning for those who haven’t checked in on it in a while

I haven’t checked in on Lightning in a while.

I last spent time on it in 2019 when I worked with Elizabeth Stark and other community leaders to organize the first Lightning Conference in Berlin. Since then I’ve spent most of my time on other protocols and although I’ve stayed friends with Elizabeth and others, my understanding of how Lightning actually works has atrophied. Upon taking a fresh look, I realized it’s not only my knowledge that’s atrophied — most of my friends are wildly out of date too.

This post is for those of you who haven’t taken a look at Lightning recently. It’ll address the misconceptions I’ve held or those I’ve seen others hold. DM me on Twitter if I’ve missed any good ones!

Misconception 1: You have to run your own node to use Lightning non-custodially, making mobile usage impossible for the average user.

This was true years ago, but thankfully today it’s possible to use Lightning on mobile with a non-custodial light client. A user is always in control of their own keys and has the same perceived wallet experience using Lightning with a light client as they would using Ethereum with RPC calls made to Alchemy or Infura.

Misconception 2: Both the sender and the recipient need to be online at the same time for the Lightning payment to succeed (there are no offline/async payments).

This is still somewhat true, but there are clever workarounds. Today, non-custodial Lightning mobile wallets are able to receive payments even if the wallet isn’t running on the foreground using background tasks or mobile notifications. However, there’s limits to this method imposed by the mobile operating systems. Modern OS’ limit the amount of computation that can be performed by background apps in order to conserve battery. Receiving a few LN payments is fine, but if there’s too many in a short time frame, they’ll start to fail as compute is throttled.

For the longer term, the Lightning protocol developers are working on the Async Payments spec, which will enable arbitrarily long, trustless delays. Essentially, the payment is credited from the sender’s node, but if the receiver’s node is offline, the payment just sits with the sender’s LSP (lightning/liquidity service provider, typically operated by the wallet itself) until the receiver comes back online. This upgrade is expected next year, but there’s no official date set for rollout. However, this requires participating wallets to have an LSP, which may hinder it from being adopted as a network-wide solution.

Misconception 3: Lightning requires both users to place the same amount of BTC in a channel to open it.

Not true. Channels are by default opened in one direction on most Lightning clients so only the sender puts money into it and the recipient can be a brand new, empty address. This misconception originates in the Lightning whitepaper where examples consistently refer to a dual-funded channel.

There’s actually an interesting backstory here. The very first payment channel (Spilman) only allowed one-way payments. The innovation of Lightning was to enable dual-funding, bi-directional payments, without an expiry time for the channel. That is probably why it got so much focus in the lightning paper. It was a big deal in terms of the protocol design relative to what was known at the time.

Misconception 4: Lightning requires a user to specify a specific, single use invoice, which is often terrible UX.

This was ~true in the beginning, but now there are Lightning Addresses, which are basically ENS for Lightning. They are enabled by lnurl-pay and allow you to send BTC via Lightning to viktor@example.com in whatever quantity and over whatever time frame you want.

Misconception 5: Users need to know and choose between Bitcoin and Lightning when sending BTC.

Definitely true before! But not as much anymore. Now they have Unified QRs which cleverly bundles the onchain address and Lightning invoice so the sending wallet can choose the right path. Open your Cash App and go to the Bitcoin tab. Notice there’s no option to select Lightning, even though Cash App supports it. That’s because they’re using the Unified QR.

However, this does not solve the single balance problem — a user can still have their BTC balance split between onchain and Lightning. This is partially solved by submarine swaps and/or splicing, but my long term belief is that users won’t even be aware this is an issue, or that Lightning exists at all, as these issues will be tucked away behind a slick UX as wallets and other providers handle the underlying complexity.

Misconception 6: Lightning’s capital inefficiency makes it unworkable.

This is nuanced and I’ll try to toe the line so that no matter which side of the debate you’re on, you can be equally mad at me.

Lightning follows a hub and spoke model. The hub to hub portion of the network is highly capital efficient as big channels between exchanges, custodial wallets, LSPs, and the best routing nodes have high `volume per capital allocated` ratios.

However, where the Lightning network is capital inefficient is at the edges — non-custodial users. For custodial Lightning users a wallet can just maintain large channels with other hubs and do its own internal accounting for its user balances. For non-custodial users, a wallet must maintain individual open, funded channels with each of their users. The challenge is in the ongoing liquidity allocation and management between these channels.

As a specific example: a non-custodial wallet user would like to send .1 BTC to their friend via Lightning. Assuming they have sufficient liquidity in the channel with their wallet provider, and at every node along the route, the payment will succeed. But now the wallet has a problem — they have .1 BTC on their side in the channel. If the user isn’t receiving any payments (thereby rebalancing the channel), that .1 BTC just sits there unused, which creates inefficiencies for the wallet provider. The wallet provider must then decide whether to keep the liquidity there or extract it by closing the channel (which creates a bad UX) or splicing it (which is ~invisible to the user).

This capital inefficiency at the edges for non-custodial users is a hard and annoying optimization problem, and it’s objectively worse than an account-based model with arbitrary transaction sizing. However, it’s not an unworkable problem. And as long as it’s not unworkable, it can be made to work, which is literally the motto of the Bitcoin developer community.

In addition to the difficulty of capital optimization, another challenge arises in the costs associated with channel and liquidity management, as each splicing, channel closing, etc. action requires an onchain transaction. Bitcoin is relying on tx fees rising significantly for its security budget, but if fees rise to $30-$60, channel management will be extremely expensive at scale, and non-custodial Lightning may become unusable for large swaths of the world’s population. As the incentives are set up, custodial Lightning wallets have an advantage today, and may grow their advantage as onchain fees grow, since their omnibus account model makes channel management orders of magnitude less frequent. The community is working to address this and ensure non-custodial Lightning continues to be a first class citizen on the network, but there is no clear solution at this time.

Lightning still has a long way to go to be easy, seamless, and completely abstracted. There are still a lot of edge cases and non-custodial users are not currently having the best time of their lives. However, a lot of problems have been solved, and many more will be solved in the coming years. You’ve seen the Lightning, hopefully soon you’ll hear the thunder.

I hope this was helpful! Want to give Lightning a go? Try out Phoenix Wallet or Breez for a non-custodial option, Wallet of Satoshi for a custodial option, or get your hands dirty the DIY way by running LND.

Thank you to Elizabeth Stark, Ryan Gentry, David Marcus, Patrick McCorry, Roy Sheinfeld, and Udi Wertheimer for their feedback on this post. Not happy with this post? I’d love your feedback! Please send it to cory@swanbitcoin.com and it will find its way to me on twitter.