243 sats \ 2 replies \ @TonyGiorgio 9 Jan \ on: How to Build the Ultimate Bandaid Wallet bitcoin
I really despise this made up term "bandaid" wallet to describe Mutiny and others. I really don't know in what way you define this. Is it not being relied upon anyone else's infrastructure? You are aware almost all mobile Bitcoin wallets rely upon third party block explorers and indexers? Would you call BlueWallet a bandaid wallet too?
You're also defining it as infrastructure you can't host, however the entire mutiny stack is self hostable and we have multiple users that go that route on their start9. Neither the self hosted stack nor the hosted stack relies on an LSP either. You can open a channel with any other node on the network.
You're also conflating different features of LN to being something specific to "bandaid" wallets or not. Splicing is not a "bandaid" only feature, having onchain vs LN accounting is not self hosted only, having an LSP is not specific to "bandaids" only, different fee mechanisms can apply to all (not sure why you think receiving on chain to a "bandaid" wallet takes a fee as well, unless you're talking about one specific wallet which I think Phoenix might).
In general, I think you're nit picking many different properties across the wide variety of LN apps or setups that exist and you're applying those properties across the ones you're trying to make some argument for. The reality is there's a lot of different features, trade offs, and setups to each mobile wallet but honestly you're interchanging the worst/best properties of each wallet and applying it to all in an overly generic bucket as a blanket statement.
Preferences are typically given to the route hint, and besides, if they had enough inbound with other channels then the JIT channel wasn't needed. Multi LSP is totally possible.
This is false.
Async payments don't exist anywhere yet..? Are you describing something else that's specific to a single wallet implemention (Zeus)? Because that's not async payments, that's hodl invoices.
I really despise this made up term "bandaid" wallet to describe Mutiny and others. I really don't know in what way you define this.
I'm sorry I've offended you, but I'm comparing between bitcoin wallets and lightning wallets. In order to get a similar experience to bitcoin, our lightning wallets have to make a lot of concessions. Concessions in privacy, concessions in fees to service providers (block explorers don't charge this).
Describing Mutiny, Phoenix, Muun as bandaid experiences isn't a dig at y'all. You guys have made very useful, very clever solutions to the challenges in front of you. But those solutions are fundament bandaids of the limitations of the baselayer.
I'm in the middle of building what I describe as a bandaid wallet myself. We, implementors are bridging gaps that shouldn't exist in my opinion. All of lightning exists as a way to bridge the gap of restricting blocksize as usage increases while still allowing for day-to-day transactions. It's a dig at a lack of supporting features at the base layer, not a dig at your (or my) work.
People want Bitcoin to grow, without scaling Bitcoin in any way. Now, the onus of support is left to us to make and make use of bandaids.
You're also defining it as infrastructure you can't host, however the entire mutiny stack is self hostable and we have multiple users that go that route on their start9
Sure, in those cases it's not what I'd call a bandaid wallet, but what I'd call a self-hosted wallet. Which does not have ease of use or easy onboarding as an attribute.
Splicing is not a "bandaid" only feature
I concede
having onchain vs LN accounting is not self hosted only
I address this above. "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." If I had to guess, if you're going to go to the trouble of going self-hosted, you might as well optimize on fees. Bandaid wallets don't aim to optimize on fees, they aim to profit off them (nothing wrong with this!)
(not sure why you think receiving on chain to a "bandaid" wallet takes a fee as well, unless you're talking about one specific wallet which I think Phoenix might).
If the bandaid wallet supports unified accounting (yours does not), then they likely use swap-ins which have a mining fee + provider, with one notable exception.
This is false.
Please elaborate!
Async payments don't exist anywhere yet..? Are you describing something else that's specific to a single wallet implemention (Zeus)? Because that's not async payments, that's hodl invoices.
I'm describing async payments to be implemented by LDK
reply
But those solutions are fundament bandaids of the limitations of the baselayer... It's a dig at a lack of supporting features at the base layer
Wouldn't it be more fair to say that the argument that you're trying to make is that Lightning is not a solution for end consumers and that Lighting is in fact the bandaid in the first place? Instead of calling out specific types of wallets? Whether that's a mobile lightning wallet or running something like LND on an umbrel, I would imagine your point is that both is a bandaid. Mobile wallets are just opinionated implementations of lightning, with their own features that can be shared across self-hosted solutions.
Also, bandaid has a negative connotation attached to it, I would find a different word when calling out competitors and describing your own product.
If the bandaid wallet supports unified accounting (yours does not), then they likely use swap-ins which have a mining fee + provider
Yes, but phoenix is the only one that incurs a fee for incoming on chain receives and that's only recently with their new splicing model. Muun provides unified accounting but is on chain naturally and does not incur a fee for on chain receives. Do you know of another wallet that has a unified balance but charges fees to receive on chain? Part of my problem with much of your thoughts here is that you're applying one wallet's feature to all.
Please elaborate!
You say "Voltage’s Flow2.0 uses wrapped invoices... This is not supported in the greater network, and will require the sender to understand it to send the intermediary payment to the LSP."
Yes voltage uses wrapped invoices, but it is supported by the entire network because it is just a normal invoice, and it's even supported by the entire network to be the recipient of a voltage wrapped invoice because it's a single very simple API call.
I'm describing async payments to be implemented by LDK
That's not how async payments work on a spec level, which is how they'll implement it. It's a sender-LSP (or always online sending-node) to recipient-LSP protocol that works through onion messages. There's no stuck/held payments.
reply