Human Readable Bitcoin Payment Instructions \ stacker news ~bitcoin

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 \ 3 replies \ @rblb 11 Feb

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 \ 2 replies \ @bluematt OP 11 Feb

I believe you missed the drawbacks section in the BIP text. Specifically, of the 4 listed there, HTTP fails (a) lacking succinct proofs of namespace to public key mappings, (b) revealing sender IP addresses to recipients or other intermediaries as a side-effect of payment, (c) relying on the bloated TLS Certificate Authority infrastructure.

(a) is important as it allows a wallet to provide a small (< 1KB) proof to a hardware wallet, which can then display "you're paying a@b.c" rather than "you're paying 1Abcasdfqreysfda". This is not possible with TLS-based solutions as a general matter.

(b) is critical for censorship resistance. We already see LNURL-pay recipients filter who can send based on source IP address, and its absolutely a legal requirement for companies to do so. I fully do not understand how any bitcoiner thinks an HTTP-based protocol is okay for this reason alone - if we don't have censorship resistance what's the point of Bitcoin at all?

(c) is a bit nicer to have, admittedly, but TLS + all the certificate authorities out there is a huge pile of crap that you're trusting for your payments, and I'd very much rather not trust all 100 certificate authorities, including the a number of governments all over the world to "secure" my payments.

As for your specific points:

a) It needs dns resolution that is not available on webapps unless using a proxy server or DoH provider, increasing centralization

Sure, but you can query 4 or 5 DoH providers and not need to worry too much about it. Even better, that extra hop gives the sender privacy and nets substantially more censorship resistance, so it seems like a great tradeoff!

b) Very limited control over cache invalidation by the domain owner

Huh? You can pick a TTL and requesters will cache for exactly as long as you say. This simply isn't true.

c) Relies on the user or the user's os to set encrypted dns for privacy

No it doesn't, the application making the query can choose how they make requests for themselves.

0 sats \ 1 reply \ @rblb 11 Feb

I didn't miss the drawbacks section of the BIP, i just think you are wrong

a) This is true, i think you are correct as i've already said in my previous reply

is critical for censorship resistance. We already see LNURL-pay recipients filter who can send based on source IP address, and its absolutely a legal requirement for companies to do so. No it doesn't, the application making the query can choose how they make requests for themselves.

b) With your system you reveal your ip and payment intentions to the dns resolver that is a centralized entity that can absolutely filter out records, requests and log your ip. That is even more true if you force the dns resolver from the app to use DoH as suggested. You even said that yourself, in the BIP and you suggested to use isp provided dns... Let me cite your BIP:

While public recursive DNS resolvers are very common (e.g. 1.1.1.1, 8.8.8.8, and 9.9.9.9), using such resolvers directly (even after validating DNSSEC signatures) introduces drawback (b), at least in regard to a centralized intermediary. Resolving payment instructions recursively locally would instead introduce drawback (b) directly to the recipient, which may well be worse. For payers not using VPN or other proxying technologies, they generally trust their ISP for protection against denial of service anyway, so using ISP-provided recursive DNS resolvers is sufficient.

So let me get this straight, if i ask you how to protect against dns resolvers logging my ip your answer is "use a vpn bro" but the same answer is not valid to protect you against the http server logging your ip? More so, your solution has a clear fingerprint that stands out for the resolver, since it asks for a record that is unique, contrary to a common domain resolution request.

Huh? You can pick a TTL and requesters will cache for exactly as long as you say. This simply isn't true.

As i've said... TTL is not guaranteed to be respected, DNS is not intented to be realtime. TTL it is just an expiration, with http headers you can control much more than that.

There is a moving goalpost here

sometimes it is about privacy : but you've admitted in your BIP that there are drawbacks
sometimes it is for size or complexity of the sw stack : and i think you have a valid point here
sometimes it is for censorship resistance: but if that's the goal we should probably avoid dns entirely, since there is history that proves that dns is very easy to use for censorship, see for example thepiratebay that is dns blocked by many resolvers. Why do you think they would never block or track a very specific dns query? You just need one law that mandates that, actually, very easy.

102 sats \ 0 replies \ @bluematt OP 11 Feb

With your system you reveal your ip and payment intentions to the dns resolver that is a centralized entity that can absolutely filter out records, requests and log your ip. That is even more true if you force the dns resolver from the app to use DoH as suggested. You even said that yourself, in the BIP and you suggested to use isp provided dns...

Indeed, there are several different options and they provide different tradeoffs. Some users may wish to use a few public resolvers (which are at least far less likely to geoblock than payment recipients, which are legally mandated to geoblock in most places in the world), and risk they log. Others may choose to use their ISP's resolver, with similar tradeoffs. Still others may choose to run their own resolver and reveal their IP to the payer. At least the sender gets to pick here, whereas with HTTP they do not, they're stuck not only depending on the same DNS infrastructure you're talking about with the same resolution censorship risks plus always revealing your IP to the recipient, modulo using a real proxy.

In the lightning context, where this idea originated, we can actually do much better - https://github.com/lightning/blips/pull/32 defines a protocol to make DNS queries using lightning onion messages, ie a built-in privacy layer to do these lookups completely privately!

Its worth pointing out that this is only possible with DNS, not with HTTP - that protocol lets you query 20 untrusted lightning nodes and as long as one is honest you get your payment instructions. With TLS you cannot build a succinct proof that the data is correct, so you have to actually have a full TCP stream proxy like Tor.

As i've said... TTL is not guaranteed to be respected, DNS is not intented to be realtime. TTL it is just an expiration, with http headers you can control much more than that.

Sure, if you set your TTL to 1 second DNS resolvers are going to ignore you and use a minute or two, but in general DNS TTLs are respected. More specifically, however, DNSSEC adds an expiry time which is absolutely always respected - the whole point of this protocol is that senders validate the DNSSEC signatures and will check the time in those signatures for an expiration.

There is a moving goalpost here

No, its about all of those!

sometimes it is about privacy : but you've admitted in your BIP that there are drawbacks

Yep, this is Bitcoin, its definitely about that. Re: drawbacks, not really, please see above for the lightning built-in OM-based solution. It makes very few tradeoffs on the privacy front!

sometimes it is for size or complexity of the sw stack

Yep

sometimes it is for censorship resistance: but if that's the goal we should probably avoid dns entirely, since there is history that proves that dns is very easy to use for censorship, see for example thepiratebay that is dns blocked by many resolvers. Why do you think they would never block or track a very specific dns query? You just need one law that mandates that, actually, very easy.

You're suggesting we use HTTP instead? Which is wholly dependent on the entire DNS infrastructure, in addition to CAs and other infrastructure on top. Indeed, there are blockchain-based alternatives to DNS which we could use, and someone arguing we should instead rely on the Ethereum Name Service arguably has a point, as I note in the BIP. I think the lack of succinct proofs there kinda suck, but that's definitely the tradeoff for much better censorship resistance.

Still, I think you make a great point about thepiratebay - in spite of one of the most powerful governments in the world wanting to take it off the internet, it not only still has a domain name, it still has a .org domain name, operated in the US! In practice, the DNS is incredibly censorship resistant, just sometimes you have to do the resolution yourself (or rely on someone other than your ISP).

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

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 \ 0 replies \ @SaToSHiWoMaN 11 Feb outlawed

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