The Lightning Network – Bitcoin’s ultimate scaling solution. In less than a decade, it has grown from a small experiment into an enterprise-ready payments solution that powers 25% of CashApp’s bitcoin transactions.
And yet, in spite of Lightning’s growing enterprise adoption, people sometimes say things like “Lightning self-custody doesn’t work”. And how can we blame them for saying this? At conferences and on podcasts, you’ll hear people saying that Lightning is more like a “glue” that binds together other bitcoin protocols. “Lightning isn’t for users, it’s just infrastructure”.
While it’s true that Lightning helps to bind together many different bitcoin protocols and companies, it doesn’t end there. I argue that Lightning isn’t only for settlements between big players. Lightning-self custody works for end-users.
But before I describe why it works, I want to first dispel some of the things that do not work.
A node in every home?
This was the Lightning rallying cry of the Bitcoin bull-run that started in late 2020. Lightning technology was finally reaching a very mature state. At the time, there was much excitement around projects like Umbrel and Start 9. Put simply, these are small computers you can run in your home. They allow you to host Lightning nodes (among many other things).
It was inspiring to see waves of people excited to run these devices in their homes, including people who ordinarily wouldn’t touch cutting-edge technology. However, as the years passed, the excitement began to fade.
The reality is that running a server in your home is simply not for everybody. While it’s great that there are options for people who are interested in self-hosting, I do not think it is how Lightning will scale to serve the entire planet. From my personal experiences, I think many people formed an incorrect impression during this period that Lightning requires people to run servers in their homes.
Lightning nodes, however, can take many forms.
A node in every phone!
We must broaden our view on what it means to “run a Lightning node”.
For some people, when they hear “run a node”, it brings to mind images of hobbyists flashing Umbrel onto a Raspberry Pi. But a Lightning node could be many things:
- A RaspberryPi in your living room - for the home hobbyist
- A cloud node on Voltage - for the enterprise
- An app on your phone - for the end user
That’s right: you can have a Lightning node on your phone.
“But wouldn’t that require a ton of system resources?” Well, that depends on what you want to do. If you are running a business and you need an enterprise level of support, you would be better served with a solution like Voltage, where we can give you a server with a lot of dedicated resources so you can process a high volume of payments.
On the other hand, let’s just say you are a normal user who wants to receive occasional payments in bitcoin. For this specific use-case, there are ways you can slim things down:
- Cut down on P2P gossip and sync from a trusted source - it’s probably an acceptable trade-off for a node on a mobile device
- Limit the number of channels - the use-case here is payments, not routing, so one healthy channel from an LSP will suffice
- No routing - since the purpose of this node is receiving, then you do not need to worry about routing payments meaning you don’t need all that database storage
So what you end up with is a much more lightweight lightning node on a phone. It has only what the user needs to receive payments and send them back out later!
Haven’t we tried this already?
Although I have taken the time to walk you through the line of reasoning that gets you to “a node on every phone”, this is not a new idea. It was pioneered by projects like Breez and Phoenix, and has also been tried with projects like Mutiny wallet, Blixt, and the newer versions of Zeus.
Given that so many other projects have successfully done this, we can push back on the claim that it’s “impossible”. It’s very possible, and has been done many times before.
But if we’re being honest here, it’s had some rough edges:
Lightning invoices are weird
Lightning invoices are not an intuitive user experience. From most of our modern fintech apps, we expect to be able to send money and identify the recipient by an email address, phone number, or simple user name. Instead, the default experience of Lightning for much of its existence has been “invoices”, which can only safely be used once and have an expiration date.
Offline payments are a necessity
Even the sharpest performing mobile lightning wallets suffer from a lack of offline payments. The problem is simple: when I put my phone in my pocket, it goes to sleep. When it goes to sleep, the lightning node goes offline. When the lightning node is offline, it can’t receive a payment.
This has been a huge issue for the UX of self-custodial Lightning. From our modern fintech apps, we expect to be able to receive a payment any time of day, whether I have the app open or closed, whether the phone is awake or asleep. The lack of offline payments has, in my opinion, severely tarnished the perception of Lightning. This limitation feels clunky and not what we intuitively expect from the phrase “magical internet money”. Hang tight, we’ll talk about some of the solutions later in the article.
Channels are annoying
While many of the best Lightning experiences have found ways to abstract away the channels or hide the technical details, it still can create weird edge cases.
For example, I heard one story where a user frequently received bitcoin to their mobile Lightning wallet. They received so much, in fact, that the LSP was continually opening new channels to the user’s mobile Lightning wallet. Even if the channels are hidden from the user, it creates an awkward scenario where their funds are split across multiple channels, making it perhaps more difficult to spend all the funds in a single payment.
Even when limited to a single channel, concepts such as the “channel reserve balance” create the impression that the user can not spend all of their money on Lightning. With a larger balance, you may never brush up against this issue. But a newer user is more likely to have a smaller balance, and so they are more likely to encounter this jagged edge.
Where are the Lightning service providers?
It’s been rough for Lightning Service Providers (LSPs). If you’re not familiar with the term LSP, it’s basically a service that will provide inbound liquidity to other lightning nodes. The idea is that the LSP can be incentivized to provide this service with the promise of earning routing fees or by simply charging a fee upfront to open a channel.
I think that a robust ecosystem of LSPs are necessary in order for Lightning to thrive. Like with many other technologies and ideas, I think LSPs suffered from the Gartner Hype Cycle. We saw a proliferation of LSPs for a time, but many have moved out of the USA or shut down entirely.
Why is this the case? The specifics vary from one LSP to the next. For some, it might be attributed to a lack of regulatory clarity. But for many, it may just be that they were not making enough money. There is an opportunity cost to capital allocation. While a lot of activity has moved to Lightning, it’s still early days. Lightning wallets may be a daily driver for some folks, but it’s just a fun experiment for many others.
For example, suppose 100 people download a Lightning wallet from the app store. An LSP opens 100 Lightning channels, 1 to each user. How much revenue does the LSP see in routing fees? Well, that depends. Some of the users might be receiving and sending payments constantly, which gives the LSP frequent revenue. Other users, however, might have simply downloaded the wallet as an experiment. They are just trying out different wallets. As such, they rarely use the wallet, and that Lightning channel sits dormant, when the capital could have been deployed elsewhere to greater effect.
But all of these things have solutions
Given all the problems we can find with existing “node on a phone” options, why would one still advocate for this approach? Because bringing self-custody to instant payments is worth bringing fully to fruition. These problems actually have solutions. It’s been a long road getting to these solutions. However, like Bitcoin itself, these solutions are open source and have been built in public.
A payment identifier you can use more than once
Last year, BOLT 12 was officially merged into the Lightning specification. In the time since, we have seen many projects adopt this new protocol spec. What does BOLT 12 give us? It gives “offers”, which are an alternative to the traditional lightning invoice.
While BOLT 11 invoices can only safely be used once, BOLT 12 offers can safely be re-used indefinitely.
It sounds like a simple idea, but it’s very powerful. This removes the annoyances of needing to generate a new invoice every time you want to receive a payment, and having to re-generate them if they expire. It paves the way for us to give users the kind of experiences they expect.
Of course, BOLT 12 offers still look pretty nasty and technical:
lno1zrxq8pjw7qjlm68mtp7e3yvxee4y5xrgjh
hyf2fxhlphpckrvevh50u0qtx73q79y9dt5ug5
d7tk7qs90klazggchdtppd90cae522cu3rpj7q
szg0mtgk7qhrrvm2pvqnhtl25nd7gl38gnc4n9
re0v2y4kkumtl4esqve77ean3258rvhlywwte0
eyhm4qzy2833r7xdcz67r4nv4pm4ghsheg6j37
wscjrwc8eufxf2fgqecvkm9lqd7wehq27m2tgp
zymmpun8t9yeweyd6mq74pz207sa53hcmkrtkv
2qqs9fwd9svuvz80x0uz4pqp6ugy4u
This is where BIP-353 comes in. This allows us to create something that looks similar to an email address, but serves as a lookup for bitcoin payment information. Instead of using the above payment offer, I could instead share something like:
₿stephen@twelve.cash
BIP-353 user names are distributed via the global DNS system. This aids with decentralization, as there is not a single point of failure such as one web server that handles providing the payment information. Furthermore, DNSSEC is used so that a lightning node can cryptographically verify that the payment information in the DNS record can not be tampered with!
Async Payments
In the very near future, mobile Lightning nodes will be able to receive payments while offline! How does this work? It involves a project called “async payments”.
This process requires a bit of collaboration between a mobile Lightning node and an LSP. Effectively, if your node is offline, an LSP can hold on to a payment for you. When you come back online, the LSP recognizes your node is online and completes the payment. This is done in a trustless manner; if you are not online to receive the payment, the LSP can not steal your funds.
Several PRs have been merged recently into LDK (Lightning Dev Kit) that pave the way for async payments. As this is actively being worked on, I won’t comment as to when this will be ready. But it appears to me that this is coming soon. From there, we need to convince LSPs to adopt this spec. Once we have 1 or 2 LSPs that use this, we can demonstrate functioning async payments on the Lightning network.
Easing capital constraints for Lightning Service Providers
Of course, none of this magic works without a robust ecosystem of LSPs. How can we incentivize the world we want to see?
I think one important part of the solution is to not overhype this. While I think there’s incredible opportunity to be had in running Lightning infrastructure, it’s also a long-game. As we build excellent products that solve real problems for users using Lightning, even more activity will go on the Lightning network. As activity increases, so does the opportunity for LSPs to make money.
But there is still the issue of “opportunity cost” we discussed earlier. Namely, liquidity locked in a lightning channel that does not get utilized could have been used elsewhere, perhaps for greater gain.
Enter splicing
Splicing is a powerful tool for easing capital constraints for LSPs. Put simply, splicing allows us to change the size of Lightning channels after they are created. Need more inbound liquidity? Simple, I can splice funds into our Lightning channel to give you more inbound liquidity. Is your channel mostly dormant? Ok, I can splice some of my funds out of the channel to deploy that capital elsewhere.
Splicing gives LSPs the ability to nourish a single channel for a single mobile Lightning node instead of juggling multiple channels. It also gives them a more efficient way of reallocating capital depending on how much a given channel is used.
Splicing is key for enterprises who begin scaling Lightning payments. Businesses can remove capital where it is no longer needed, and deploy it where it is most in demand.
Removing channel reserve requirements
Another recent development is “option_zero_reserve”. Put simply, this is an option where two Lightning channel partners can choose to not use a channel reserve balance. While it is great to have a channel reserve for adversarial environments, it is a hindrance to the UX. By using the zero reserve option, we can give users the option to spend their entire balance. This also means that the entire balance of the channel can be used for routing payments, which is a more efficient allocation of capital for the LSP as well.
Graduated wallets
Another way to use capital more efficiently on the Lightning network is to build a graduated wallet. Put simply, this is a wallet that begins with a balance using a custodial service or trust-minimized technology. For example, smaller balances could use the Ark protocol or a custodial provider. As the user’s balance grows, so may their incentive to safely self-custody it. Once their balance hits a certain threshold, the LSP can open a Lightning channel to the user with the funds swept into self-custody.
How might this help with capital efficiency? First off, a graduated wallet model could help an LSP avoid opening “non-productive” Lightning channels to users who are simply experimenting with the app. For example, somebody wants to tip a bartender 5,000 sats in bitcoin and asks them to download a Lightning wallet. While we hope the bartender appreciates the bitcoin and wants to use it, that’s not guaranteed.
Do we really want to open a Lightning channel so that somebody can self-custody 5,000 sats and not touch the wallet again until the next bull-run? It’s not the most effective use of capital. In the graduated wallet model, we use another technology for that first 5k sats. If the bartender’s stack grows to a certain threshold, then they get a Lightning channel.
Another way that graduated wallets may improve capital efficiency is that the users balance can offset the capital required for the channel. For example, suppose an LSP opens channels that are 500,000 sats in size. This means that they need to have 500k sats on-hand for every user they hope to serve. However, under the graduated wallet model, they may only need to keep 400k sats on-hand for every user. This is because if the threshold for getting a channel is a balance of 100k sats, then the user’s 100k sats can form the other portion of that 500k sats.
But it gets better: if you consider that not every user will even hit the hypothetical threshold, then it means the LSP needs to open up fewer channels overall. Suppose a given lightning wallet and LSP are onboarding 100 users. Their default channel size is 500k sats, their threshold for self-custody is 100k sats, and the number of users who actually hit the self-custody threshold is 25%. Under the graduated model, they are opening 75% less channels and each channel requires 20% less capital. This uses 80% less capital overall than without graduated wallets.
Isn’t that cheating?
Sure, it’s true that a graduated wallet model is not true self-custody until a certain threshold is reached. But consider the cost of an on-chain transaction in terms of fees. Even if I have a Lightning channel which I can unilaterally close, if the balance on that channel is very low, then it’s not cost efficient to even settle it on-chain if I lose money due to fees.
Consider, for example, somebody receiving a tip of 21 sats via a Nostr zap. This amount is far below the dust limit and would not be claimable on-chain anyways.
So as we consider self-custody, it’s important to remember that it’s not technically feasible for super small amounts. With that detail in mind, we can set our sights on improving self-custody for “serious users” – in other words, people who actually are using Lightning products for sending and receiving real payments instead of just in an experimental capacity.
Conclusion
Self-custodial Lightning is not just possible – it’s ready today for those who want to build with it. It was a hard process to get here – it took a ton of specifications, code, pull requests, and good old fashioned open source collaboration. The result is a very mature technology that’s ready for enterprise adoption.
Building a world where people can make instant payments and have full self-custody of their funds is a beautiful future. The opportunity for businesses to build products and services on Lightning is huge.
Lightning is here, and it’s a better time than ever to build with it. Will you take this opportunity?
