This impetus for this post was heavily inspired by Ben’s post here #379225. Not a direct response, but a lot of conversation swirled around wallets like Muun and Mutiny so I figured a bit of elaboration on these kind of wallets would be beneficial.
So, for starters, what are these kind of wallets and how do they differ from normal (lightning) wallets?
Self-Hosted vs. Bandaid Wallets
Muun, Mutiny, and Phoenix are what I and others affectionately call Bandaid wallets. Wallets that attempt to solve the shortcomings of self custodial lightning wallets by leveraging LSPs in some form or fashion. They can use LSPs in varying capacities, but fundamentally - while your keys are entirely yours, the infrastructure required to facilitate the usage of your keys to their fullest extent are not. This is a departure from classic wallets in Bitcoin, which never require an always on connection.
Self hosted lightning wallets allow you to own your own infrastructure (or bring it yourself with an umbrel or voltage node), but they don’t get any of the benefits of using an LSP. They’re also really hard to set up, hard to maintain, and (unlike bandaid wallets), require you to manage your own channels.
Challenges with Split Accounting
Self hosted wallets also tend to suffer from split accounting, which is separate accounting for onchain balances and lightning balances. Split accounting is really tough for new users (especially the nontechnical to understand), exacerbated when their first experience in bitcoin is a wallet with this feature.
It’s confusing to new users because they’re barely aware of the existence of lightning, let alone it’s fundamental characteristics, but going forward - this is the ideal way to use bitcoin, so this is the world new bitcoiners find themselves in. It confuses them because they’re not aware why they have two balances, often they’re not aware that just because it says they have some bitcoin in lightning, doesn’t mean they can pay an onchain address (of course, the difference between an invoice and an address being lost on them). And it’s especially confusing when they try to understand why some transactions have high fees and others don’t, and what they could have possibly done differently to avoid that next time. In my opinion, custodial wallets are superior to most self hosted wallets purely because they support unified accounting and because they don’t put the onus of channel management on the user.
There isn’t an explicit reason why self hosted wallets lack unified accounting, though without the help of LSPs, the fees are higher. So let’s talk about the real elephant in the room with bandaid wallets.
The Compromise of Bandaid Wallets
| Your Keys? | Your Infra? | Easy? | |
|---|---|---|---|
| Bandaid Wallets | ✅ | ❌ | ✅ |
| Self Hosted | ✅ | ✅ | ❌ |
| Custodial | ❌ | ❌ | ✅ |
Notice how their isn’t a row with all ✅? It’s because the perfect, elegant bitcoin/lightning wallet doesn’t exist. This is because of onchain restrictions imposed by lack of consensus and lightning’s fundamental nature of trading out-of-band metadata.
To quote Mathew Mcconaughey in Wolf of Wallstreet:
It’s fairy dust, it doesn’t exist, it’s never landed, it is no matter, it’s not on the elemental chart, it’s not fuckin real.
Bandaid wallets are the superior option for most people, with the following achilles heel: a lack of understanding of your self-custodial infra leads to a lack of understanding over fees. Many actions in bandaid wallets are assisted by an LSP, which charges fees.
Fee Structure Comparison
A quick breakdown of fees across wallet types:
Not hosting your own infra combined with relying on more infra than normal (not just an LND node!) results in bandaid wallets having the most egregious fees. The worst attribute of this design is the mining cost to accept onchain. Bandaid wallets can avoid this fee by embrace split accounting, however the whole point of a bandaid wallet is to make things easier not harder… So most don’t.
The Cost of Accepting Onchain in Bandaid Wallets
The mining cost to accept onchain comes from using submarine swaps to move funds into the lightning channel. Unified accounting is normally achieved by just moving funds in and out of your lightning channel, and never holding onchain keys beyond channel requirements. Submarine swaps have a mining fee associated because it costs the provider a fee to move funds out of the HTLC onchain.
Alternatively, we could use splice-in transactions to accept monies onchain which would avoid paying a provider fee. However, this has some other complications. For starters, the user would have to be online to finalize the transaction. No async payments LSP workaround. This also means if someone paid you and you didn’t have your wallet open, next time you opened it (maybe when trying to buy that cup of joe) you’d be forced to wait a few confirmations while your wallet finalized the queue. Not great. This could also be exploited by bad actors to constantly take your mobile wallet offline by sending you dust. Of course, this could be mitigated by allowing the user to sweep onchain funds at their discretion, again not great since we have to teach users the difference between bitcoin/lightning which as we’ve covered earlier, is confusing.
To quote the hit tv show Chernobyl:
Not good, not great.
Unfortunately, this attribute of bandaid wallets affects a core mechanism. Accepting bitcoin onchain. People may argue that it shouldn’t be something most concern themselves with. But it currently is. The Bitcoin ecosystem is slim as it is, double charging a user to move funds into a wallet (fees on moving off exchange, fees on moving into wallet) is bad and penalizing onchain usage more than it already is only increases friction for already friction-full lightning adoption. Remember, thew lightning ecosystem is significantly smaller than bitcoin.
JIT Channels and Async Payment LSPs
Bandaid wallets have other tricks that aren’t nearly as problematic, which is good. They ought to rely on JIT channels and async payment LSPs.
JIT channels are pretty simple. JIT stands for Just-In-Time channels, and are also known as zero-conf channels. A wallet that has no channels can worry about getting their first channel set up when they receive funds that first time. The LSP accepts the risk of moving funds with zero confirmations for a fee, typically a percentage and the channel is immediately usable. This removes several frictions if done well. It’s a chance for the wallet to axe channel and peer management if they enforce only channels with their JIT LSP. It’s also a chance to heavily simplify the onboarding experience into lightning, both are serious user experience issues when it comes to self-hosted wallets. JIT Channels are a necessity.
There are many vendors to choose from for a JIT LSP, but the two I recommend would be c=’s and voltage. One downside with JIT vendors is how they communicate the intermediary node. C= uses routehints to try to coax routing through their node, but if the wallet has channels with anyone else, this might fail. Another reason to enforce exclusive peer with the LSP.
Voltage’s Flow2.0 uses wrapped invoices, which basically means their invoice has a secondary invoice inside it. This is not supported in the greater network, and will require the sender to understand it to send the intermediary payment to the LSP. It will also require communication between the intermediary and wallet to construct the wrapped invoice.
Async payments are little more complex, and can fail at a higher rate than typical payments - especially as the network isn’t ready to differentiate between stuck payments and held payments. But success rates will likely increase as this feature is adopted more and more. I’d argue they’re a necessity as well, though less than JIT channels.
Conclusion
In conclusion, bandaid wallets are named so because they use bandaids to make the lightning experience palatable for new users. The bandaids they use are mostly LSPs, with the exception being splice-out. They focus on a great user experience, with the downside being inconsistent fees depending on specific actions. They have great onboarding experiences for lightning, something sorely lacking, and remove lots of confusing and unnecessary functionality many lightning wallets have.
They’re also our best hope for onboarding new users if we don’t softfork some really cool features in, but even then they’ll probably still be necessary.