Gonna watch the Super Mario movie now LFG. ✌️
Oh! Yeah the Lightning Address is broken, just a sec
Epic! Blixt Wallet 0.6.6 has been released, and it's better than ever before.
It includes lnd 0.16 with support for bimodal pathfinding (based on Pickhardt Payments).
Enjoy potentially speedier payment by enabling it in settings.
Happy Blixting! 🟡
```
## Common
* Updated lnd to v0.16
* Added support for bimodal pathfinding (based on Pickhardt payments). Enable it in Settings!
* Added the ability to set a label for a contact in the contact list
* Sats amount on Overview screen is now grouped
## Android
* Lowered the scheduled sync job interval from 4h to 2h
## macOS
* Fixed restoring not working properly
```
https://github.com/hsjoberg/blixt-wallet/releases/tag/v0.6.6
Yeah plans for receiving to a Lightning Address in Blixt Wallet is planned via Lightning Box.
But support for zaps is not planned. Note that you can still of course receive tips from nostr though.
⚡️ hampus@blixtwallet.com
This Lightning Address is special.
When you pay to it, my Lightning Box solution will forward the request to the phone, where Blixt Wallet respond with an invoice.
This is the first time a self-custodial LN wallet supports Lightning Address.
This is part of my on-going work to support receiving via Lightning Address for mobile self-custodial wallets.
https://github.com/hsjoberg/lightning-box
Android supports foreground services, meaning that Blixt Wallet can stay online all the time to answer incoming requests (no effect on battery).
Though the normal mode of operation for Lightning Box is that it'll take the payment on behalf of the user and then next time the user opens wallet, it will auto-withdraw from the Box, thanks to LNURL-withdraw.
But if the wallet is online already, it can just forward the request.
Well, one of the concerns is the one your raised on Twitter.
Few people seem to understand or know that your channel opening transactions leak in your invoice routehints.
This can be fixed either by blinded routing (BOLT11/12) or alias scid (BOLT11).
Another concern I have is the fact that seemingly no LN wallet today let’s you enforce min X number of hops.
As Lightning is an onion routed payment network, the more hops you do, the more privacy you potentially get.
Fewer hops lead to bigger risk of de-anonymising your payment.
A lot of people are using custodial LN wallets in order to have a Lightning Address, simply by the fact that it’s by far the easiest option. The only options available right now are custodial or a self-hosted routing node (which few have).
I’ve a project called Lightning Box that tries to improve things by forwarding the LNURL-pay request to the phone. Privacy-minded people can use a wallet that has Tor integrated to not leak info.
#[2]
Miner fees primary purpose is to support the network’s security. That’s how it has to sustain itself when block reward decreases.
Bitcoiners who don't like ordinals & wizards need to understand that the original true meaning of Bitcoin Maximalism is that Bitcoin will cover all use-cases.
It's a good thing that we now see higher miner fees, leading to a more healthy and robust network.
Depends on what you mean by that.
Yes, Blixt Wallet basically has full coverage of the LNURL suite.
It does not support receiving via a Lightning Address however, which is true for all non-custodial wallets today.
Yeah it’s in beta, but there are many people using Blixt on a daily basis.
I agree. It’s actually not that important.
In fact it’s not important at all.
Real payments are important.
Just forget about the federated part. It’s confusing af.
Basically it’s a service that will connect to your LN node somehow (lnd REST etc) and request an invoice.
I am working on a zap protocol based LUD-18.
It will be very similar to NIP57, so should be easy to implement.
But it’s me against the world here, so I don’t really expect widespread support.
But I will at least try to do what I think is the right thing, instead of just complaining.
I don’t think it matters that LUD-18 wasn’t sufficiently supported by wallets.
Nostr clients want to consume the LNURL-pay code anyway and then send the BOLT11 invoice to the LN wallet, so zaps could’ve just used LUD-18 and wallets would not have to support LUD-18.
Though hypothetically, if wallets supported LUD-18 too, both nostr clients and LN wallets could support LUD-18 zaps.
Also, I’m not blaming people having fun with zaps. I’m just very sad and frustrated at how things came to be.
Yeah it solves it depending on how you view things. This introduces a completely new protocol. A hardfork.
So what happens if you want to use some LNURL-pay extension together with zaps, for example LUD-18 (https://github.com/lnurl/luds/blob/luds/18.md)?
You kinda can’t. All must obey NIP57, as it takes precedence.
It’s simply not compatible.
NIP57 zap mandates that the description hash of the invoice has to be the zap request note, whereas conventional with LNURL-pay invoices, it’s the LNURL-pay metadata that should be the desc hash.
So basically a zap is not really using LNURL-pay, it’s just the same URL endpoint.
So now all LNURL-pay servers has to also support this new propertary protocol.
If we’re going to think long-term, this can have some seriously bad implications, as both LNURL-pay and NIP57 progresses and moves forward.
But I can give you a clear-cut example: LUD-18 (https://github.com/lnurl/luds/blob/luds/18.md) also let’s you commit arbitrary payer identities to a payment (which is the primary goal of NIP57).
But seeing how NIP57 takes precedence, there’s no way to use NIP57 and LUD-18 at the same time, which is just sad.
To make things in the right way, zaps should’ve just used the already specified and established way to commit data, which is LUD-18.
I don’t like zaps.
It breaks LNURL-pay compatibility for no good reason.
It’s a very sad state of affairs.
