LN-Address has demonstrated the value of human-readable names in Bitcoin payment instructions, but has a number of fundamental drawbacks -
(a) its only for lightning (b) it does not allow for succinct proofs of name mappings. This means you can't simply hand a hardware wallet a small bit of data to prove that you're paying a@b.c so that it can display that in the UI (c) it reveals the sender's IP address to recipients, resulting in a loss of censorship resistance and privacy as recipients geofilter and track senders, (d) it relies on the TLS CA infrastructure, which is generally a total mess (e) a user of a custodial wallet can't simply map their own domain to their payment info at the custodial service.
This proposal replaces LN-Address with a DNS(SEC)-based scheme, addressing all of the above drawbacks by putting standard bitcoin: URIs in DNS TXT records (which anyone with a domain can easily configure).
Thanks to t-bast for coming up with the high level idea here and writing up the original proposal. You can find a full implementation of this proposal at https://git.bitcoin.ninja/index.cgi?p=lightning-resolver;a=summary
Now we just need to get offers working
This spec is generic across any bitcoin payment method. It works for on-chain as much as it does BOLT12, fedimint, or cashu. All it needs is a static invoice (so not BOLT11) that can go in a bitcoin: URI.
Which is awesome! I'm just overly anxious for BOLT12 :)
Time to start saving for the full-back tattoo QR!
Need wallets to adopt them
Since you don't welcome contrarian opinions on the bip proposal, I'd like to address your points here...
a) It is just a json file that can be extended to support everything, it is actually already used for nostr zaps b) true c) Arguably better than revealing it to a centralized dns provider d) Subjective e) Yes, they can. This is mapped to alby: zap@rblb.it
Drawbacks to the DNS proposalDrawbacks to the DNS proposal
a) It needs dns resolution that is not available on webapps unless using a proxy server or DoH provider, increasing centralization b) Very limited control over cache invalidation by the domain owner c) Relies on the user or the user's os to set encrypted dns for privacy
Now, i understand that you do not care about arguments in favor of HTTP vs DNS, totally fair, but you are putting out subjective and technically inaccurate facts as if they were unchallenged truths.
This solution is over due, imho.
What does this even mean?
I just mean, it feels like a good idea, and I would have thought it would have emerged sooner.
So apparently I was more calorie-defecient when I read this than I was thinking...I somehow read it as "this solution is over dude, imho", which made kinda no sense to me.
Overdue* lol
How do we contact the maintainers, where is the repo, for this english language? Feels like abandonware. Feels like time for a hostile fork, or to petition for a 2.0. When was the last release!?!?!?
Really interesting and needed. I am against a format that is identical to email. In my opinion this was a mistake in lightning address approach. In some cases it creates confusion. We can go UMA way (https://www.uma.me/) which adds $ in the front. I'd suggest to use ₿ so we don't have to use fiat symbol. Eg:
₿saunter@getalby.com
Alternatively: saunter₿getalby.com
LNURL-lightning addresses were designed to handle multiple protocols, e.g. LNURLp, AMP, Bolt12, Cashu etc. Would your standard also allow for this?
I don't understand why a wallet should fail the Lightning address if it finds multiple TXT records. Couldn't multiple TXT records be used to achieve the above, e.g. one record for a stealth onchain address, another for LNURLp, Bolt12, AMP or keysend?
Yes, not only does this allow for multiple protocols, its reliance on BIP 21 URIs means it can reuse wallets’ existing multiple protocol logic!
BIP 21 today is usually implemented by providing a single URI with multiple payment protocols embedded in different query parameters. This takes advantage of that standard and uses a single record to express as many protocols as a recipient wants. It could be relaxed to allow multiple TXT records, but given there’s no need for it and it may cause ambiguity or indicate misconfiguration, it seems best to disallow.
So I'd create a single BIP21 code with a stealth address, an LNURL a cashu endpoint and a Bolt12 offer for maximum interoperability?
Yep! Whatever your wallet supports, put it in there!
Awesome, thanks for the explanation!
does this really need to be a bip?
cool
ln is cool technology
Yes yes good 👍
https://m.stacker.news/15711