Human Readable Bitcoin Payment Instructions \ stacker news ~bitcoin

pull down to refresh

Human Readable Bitcoin Payment Instructions github.com/bitcoin/bips/pull/1551

17.7k sats \ 25 comments \ @bluematt 11 Feb bitcoin

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

view all related items

10 sats \ 0 replies \ @saunter 12 Feb

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

10 sats \ 4 replies \ @sathoarder 11 Feb

Now we just need to get offers working

27 sats \ 2 replies \ @bluematt OP 11 Feb

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.

57 sats \ 1 reply \ @sathoarder 11 Feb

Which is awesome! I'm just overly anxious for BOLT12 :)

0 sats \ 0 replies \ @joda 11 Feb

Time to start saving for the full-back tattoo QR!

0 sats \ 0 replies \ @moneyball 11 Feb

Need wallets to adopt them

0 sats \ 0 replies \ @w3irdrobot 12 Feb

does this really need to be a bip?

0 sats \ 0 replies \ @phorcik 11 Feb

cool

0 sats \ 4 replies \ @leo 11 Feb

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?

5 sats \ 3 replies \ @bluematt OP 11 Feb

Yes, not only does this allow for multiple protocols, its reliance on BIP 21 URIs means it can reuse wallets’ existing multiple protocol logic!

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?

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.

0 sats \ 2 replies \ @leo 11 Feb

So I'd create a single BIP21 code with a stealth address, an LNURL a cashu endpoint and a Bolt12 offer for maximum interoperability?

5 sats \ 1 reply \ @bluematt OP 11 Feb

Yep! Whatever your wallet supports, put it in there!

0 sats \ 0 replies \ @leo 12 Feb

Awesome, thanks for the explanation!

0 sats \ 5 replies \ @jeff 11 Feb

This solution is over due, imho.

21 sats \ 4 replies \ @bluematt OP 11 Feb

What does this even mean?

0 sats \ 1 reply \ @theinstagibbs 11 Feb

Overdue* lol

0 sats \ 0 replies \ @jeff 11 Feb freebie

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!?!?!?

0 sats \ 1 reply \ @jeff 11 Feb

I just mean, it feels like a good idea, and I would have thought it would have emerged sooner.

70 sats \ 0 replies \ @bluematt OP 11 Feb

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.

0 sats \ 0 replies \ @phorcik 11 Feb freebie

ln is cool technology

0 sats \ 3 replies \ @rblb 11 Feb freebie

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 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.

0 sats \ 0 replies \ @SaToSHiWoMaN 11 Feb outlawed

stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.