Lightning Everywhere

Lightning usage is growing, and while it may be far from perfect and might not have some of the mass adoption we would have wanted by now, the superior payment technology will win out. Nothing comes close when it comes to instant payments derived directly from the base chain.

The use cases that Lightning facilitates are much more than just one person paying another. E-commerce, tipping, automation, and services benefit from what Lightning offers. However, the sad truth is that there are still many missing pieces to solve to reach its true potential as a self-custodial privacy-preserving instant payment network.

I’ll review some problems and the solutions to them, both for the Lightning ecosystem and what we’re doing about it at Mutiny. If we can work around some of today’s pain points, we can unlock the full potential of the internet’s native currency. Lightning usability

I aim to make self-custody for Lightning easy for as many use cases as possible. I want to do all this while preserving as much privacy as possible for users. One of the biggest downfalls of Bitcoin has been the need for more privacy. However, Lightning can fix this if done correctly. One of the beautiful things about Lightning is that we have essentially built a Tor Network on top of Bitcoin. The problem is that there are far too many gotcha’s in it to pitch it that way. If we fix privacy on top of Bitcoin & Lightning, we must make it easy for people from start to finish. One of the first steps is to move off of custodians.

Custodian usage dominates the Lightning ecosystem today. It’s one thing to say that everyone should self-custody on-chain Bitcoin. Yet, the complexities involved in Lightning make it that much harder to apply or suggest to others. It’s hard to blame people. It is difficult for wallets, application devs, and general users.

Let’s examine why custodial Lightning solutions exist and which applications become custodial. I want to make the argument that we can do better and we can replace that. Now can we always be perfect? Absolutely not. But when have we as a community given up and said, “Well, I guess I’ll just recommend a custodial solution. We have no other choice. It is just too hard.” Wallets

One example of dominating custodian usage is wallets themselves. There are a few great self-custodial Lightning wallets like Pheonix and Breez, and I hope we can one day make Mutiny into that class of wallets. But why are they not recommended sometimes? I feel that it is due to two things. The online nature that Lightning requires and the fees associated with opening channels.

For receiving payments, being online is a non-starter for many use cases. You can’t expect someone to keep the app open while someone is paying you. You also can’t expect them to manually create an invoice and copy-paste it to someone else on the internet every time they want to receive money. It can’t be global money if half of the world wants to do commerce while you’re asleep. This is one area where custodial lightning wallets thrive because they are run by businesses that specialize in keeping their lightning node(s) online. Sure, someone can run their own server with a node, but that won’t be a solution for the world.

A protocol specification called Async Payments will allow for a simulated offline receive scenario, but that may still be 6 to 12 months away. Afterward, many of the problems around offline payments will go away.

The other aspect of fees and opening channels is also something custodial lightning wallets can avoid exposing to users. Many users can use all the Lightning channels a custodian has. However, with self-custodial Lightning, it’s a one-to-one relationship. Opening a channel for each user will one day be a non-starter. But can we do better? I believe so. Federated Wallets

One of the exciting things I want to do when feasible is to incorporate Fedimint into Mutiny so that any user can get started with Lightning at any amount. If it’s a small payment or a new bitcoiner with only a handful of sats, opening a channel does not make sense. They won’t have any money left over even if they did. If a user kept that in a federation (multi-sig for custodians), it would allow for greater security than trusting a single actor while supporting lower amounts. Once a user has enough funds on the Fedimint, they should transfer that to a self-custodial wallet.

In practice, I believe it is the minority of people who move on to a self-custodial wallet. How often do you hear the excuse that bitcoiners make when they onboard a user to a custodial Lightning wallet but say they will “come back later and inform the user about self-custody”? That’s the biggest lie bitcoiners tell themselves when it is called out. No, you don’t return to that coffee shop you visited once on vacation to educate them about self-custody. Sorry but nobody is buying that. Is it a good thing you got them on Bitcoin? Probably. But at what cost? Will you inform them what happens when the custodian inevitably goes away? Are you aware of how many custodial Lightning wallets have shut down?

Combining Fedimint & self-custodial into the same app would be a game changer. Federated custodianship for small amounts and onboarding, then in-app prompts to upgrade them to self-custodianship while maintaining the same UX they were onboarded to in the first place. No need to go back and migrate new users to an entirely different wallet. No confusion around the nuances the user has gotten acquainted with. Applications

Now what about general consumer applications? Well, there are a lot of apps out there that are or can be Lightning native. Think Stacker News, a Hacker News clone with sats as the upvote mechanism. Or Value-4-Value applications like Podcasting 2.0, where you stream sats to a podcaster as you listen to them. For sending sats, none of these have to be custodial. Breez even supports self-custodial payments to a podcaster as you listen to the podcast in the wallet.

However, there’s currently no other easy option besides custodial for receiving sats. This goes back to the offline receive problem. Because Stacker News allows upvotes to go to the post author, it has to either be custodial or require each stacker news author to run an always-online lightning node and provide invoice macaroons with an exposed IP address for someone to upvote them. If there’s a hiccup or the author’s node goes offline, the ability to upvote disappears. Degrading the experience for all users. This will inevitably cause Stacker News users to move to other third-party custodians anyways, defeating the purpose of trying to make it self-custodial and ending up with a worse experience.

And suppose it will be custodial for authors to get upvoted. What’s the extra step in making it custodial for senders as well? It turns the application into a custodian and money transmitter simply because they want to allow sats to be the upvotes. You might say, “Don’t put too much on there,” but it doesn’t absolve them of their legal requirements and risks. It’s not just Stacker News, either. That’s every application wanting to offer their users non-custodial receives and frictionless spending. They should not have to be a custodian to ship a new lightning-native app. Built-in Lightning

So how do we do better? We make it so Lightning can run anywhere because Lightning should be everywhere!

Part of the reasoning for Mutiny running on the web was to get around app store censorship, which will get worse over time, not better. People have theories about how it’ll end up, but until things change, it has only gotten worse.

The other reason is that if we can get a Lightning node to run on the web, we can argue that Lightning can run anywhere. In fact, it only took 5 days for me to build the Android version, and I mostly did that with some spare time at night. Should you store your life savings on the web app version? Absolutely not. But can we be better than custodial? Yes, from both a privacy perspective and ease of onboarding. We can even inform users to move to the mobile apps after they acquired enough sats.

We built the web wallet specifically to dogfood our own node implementation, called mutiny-node, which can run anywhere. So any web app or native mobile app dev can import it into their application to take their hands hands off user funds. If we can solve the offline receive problem, and incorporate federations for smaller amounts with the same UX and API calls, then applications can truly flourish. You shouldn’t need to be a lightning dev to incorporate Lightning, and you shouldn’t need to be a bank to include it, either.

There are many ways it can play out, but I think one of the end goals is to have a single “login” with just twelve words to access your funds. You may want to manage your wallet and funds on the Mutiny mobile app. Still, when you want to link your non-custodial wallet to a website like Stacker News, you can get the same exact balance and Lightning state there. We recently incorporated Versioned Storage Service (VSS) as an encrypted data store that can restore your lightning state with just your seed words, making the restore process simple.

I acknowledge that restoring seed words onto just any site is a bad practice. Still, Mutiny specializes in being a spending wallet, not a life savings wallet. If you’re worried about how much is on there and what might happen if you restored your seed words on a bad site, then you’ve put too much on there for how you use it. Mutiny is also a lightning-first wallet. All lightning wallets are hot, so if you’re putting too much on a hot wallet in the first place or have a problem with it being treated as hot, you need to reevaluate what you know about Lightning and what standards to compare it with.

The alternative here is to have multiple Mutiny wallets. It’s just seed words that power the wallet’s identity, authentication, encryption, and funds. So if you don’t want to risk the funds from the Mutiny Wallet mobile app, create a new wallet for each app you interact with and deposit sats as you go.

This removes applications from being a custodian while having a better risk model than before, where you were logging into your wallet (or application’s wallet) with an email and password to access your funds. In the future, Validating Lightning Signer (VLS) is something we could incorporate to keep the keys off of the user’s device or browser too.

And topping up all the application wallets you may have should also be seamless. We support Just-In-Time channels that create a lightning channel for you whenever needed. So a brand new wallet (or new account on a lightning-enabled app) should be able to receive their first lightning deposit within seconds of creating it. AI Use Cases

There’s also the evolution of AI that could benefit from this. Just like you wouldn’t put your life savings on a hot lightning wallet, you also need to limit how much you would give to any automation / AI tool. An easy-to-use self-custodial lightning wallet that can run anywhere is a perfect tool for developers building in automation.

The L402 (formerly LSAT) specification that allows for an HTTP protocol using error code 402 to communicate when a payment needs to be made to access resources could use this. This can be used in many settings, but one of them is allowing more web automation and monetizing resources as you go. Bots can now be “paying users” instead of huge resource consumptions.

One advantage of using our SDK is that you can build the wallet straight into your AI application. We develop our SDK in Rust and compile it for web assembly. It has pretty good support across many languages, including Python. There is no need to spin up an LND node, expose ports, build in Python GPRC bindings, and manage an entire node just for the small amounts of funds you want your app to access.

For two, you can send funds to it as you go. Keep your lightning funds secured elsewhere and top up this specific AI. Is your bot not behaving correctly? Stop feeding it sats. Has it been successful in its job? Pay it right from your mobile lightning wallet to keep it going.

Or better yet, let it request more straight from your main wallet when empty! It’s a tangent for another day, but Mutiny has built-in payment requests. You can give out a specific “API key” that allows others to request funds from you that you have to approve, revocable at any time. We use the protocol called “Nostr Wallet Connect” for this. We’re testing this out with the concept of “subscriptions” on Lightning and for sending tips on nostr (zaps). There are many more use cases, like digital purchases or topping up other wallets or services. Everywhere

Lightning could not be everywhere before, at least in a non-custodial way. The main challenges are:

Offline receives
Instant onboarding (even for small amounts)
Easy-to-use SDKs for developers
A wallet/node that can run on any environment
Instant onboarding
Protocol for payments

However, these things are being solved right now. So what will it look like to have Lightning everywhere?

My dream is that every site has Lightning. New user account, new lightning wallet. Top up as you go, or bring an existing wallet if you already have one. Reward users directly for actions taken inside the site (could be a game or p2p rewards), then they can turn around and spend those sats within the site. Lightning knowledge or setup doesn’t have to be a prereq. It can look like in-site points.

We already see this “points” system EVERYWHERE, which the world has figured out. Starbucks Stars, Airline Miles, Twitch Bits, etc. Bitcoin isn’t the problem here. Onboarding is. If everyone had to sign up for an exchange with KYC info, then wait for approval, link a bank account, wait 3 - 5 days, then download a separate wallet on their mobile phone that they have to switch to any time they want to spend their Starbucks points, then change back to the Starbucks app to complete the order, it would NEVER HAPPEN. The key is to build it straight in, which all these wildly successful companies have done.

And when you have “points” that can be transferred or used for purchases, the circular economy can be born from this. The Nostr ecosystem is the closest to figuring this out. New users are coming in, getting tipped in sats, and turning around to spend it on paid-only relays or tips for other new users. This is the adoption we want, and it’s already happening. The problem is it’s happening with custodians. Self-custody is seldom the case. All the income, spending, and behavior are being monitored, in addition to the risk of rug pulls or seizures.

After Lightning is incorporated into sites, you can start integrating Lightning into APIs. A single website owner doesn’t need to be the provider of the APIs either. We can begin making API requests across domains and allowing the 402 payment-required response to prompt the user to make the payment (or automate it). 402 can remove the identity from the resource consumption too. So no need to have accounts across the entire internet to use a one-off functionality.

What would websites look like if they were more modular, pulling in premium resources or services from a configurable collection of paid-only one-off APIs from any third-party providers? All without website operators needing to custody user funds or maintain all those services themselves.

There has never been much modularity in HTTP APIs because there has not been much monetary incentive to either maintain third-party APIs or integrate with billing systems and expose that to the user directly. Frontend-only websites can prosper with significantly less upfront costs and full-stack expertise. Conclusion

Lightning on consumer websites, service APIs, and even hardware devices to protect the user keys even further. This is all possible. We have to keep pushing toward it, which is what I’m doing here.

Suppose Lightning is going to be the instant payment network of the internet. In that case, it must be capable of running anywhere to support endless applications. It should be easy for devs to utilize and not require them to be a custodian. Preserving the user’s privacy is important as well. We can keep using custodians, or we can put the power into the user’s hands. Which side of this do you want to be on?