pull down to refresh

102 sats \ 0 replies \ @bluematt OP 11 Feb \ parent \ on: Human Readable Bitcoin Payment Instructions bitcoin
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).
write
preview