0 sats \ 3 replies \ @rblb 11 Feb freebie \ on: Human Readable Bitcoin Payment Instructions bitcoin
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.
write
preview
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.
reply
0 sats \ 1 reply \ @rblb 11 Feb freebie
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.