I am breaking this into a couple of pieces as my first response has been in a moderator queue for some time because it is too long. TL;DR version - Wallet Name Service has always been a decentralized and distributed service that it no way requires you to ever touch the Netki infrastructure. We want to work with the community, as we have been from the beginning, to come up with the best standard possible. Longer answers inline below. On Tue, Jul 14, 2015 at 12:07 PM, Riccardo Spagni wrote: > > >> In terms of comparisons to OpenAlias, I think there are a lot of >> similarities, but a few differences. First the similarities: >> >> >> 1> We both use DNSSEC. >> >> 2> We both have the option of storing the address directly in the DNS >> record. >> >> >> Differences: >> >> 1> We do not use DNSCrypt. I understand why you chose to, but we were >> concerned about broad interoperability and easy broad distribution of >> hosting, so decided not to use it. We have other ways of achieving >> privacy, using HD Wallets and Payment Requests. >> > > And this is the part where you guys look really, really incompetent (and I > don't mean that in a terribly demeaning way, it's just that you're in a > space where you want to be a domain expert, not make a series of > embarrassing and public faux pas). > > > I appreciate the thought :) I think where we differ is on where we believe the trade offs should be on perceived privacy versus censorship resistance and centralization. By having a limited number of proxies people need to go through to easily implement, be it the 4 you recommend, or 53, you actually have a very limited number of actors for an authority or hacker to go to in order to be able to install/force logging, or censorship. This very centralization forces us back to a model where we need to trust a very small number of actors in order for the system to operate as designed. This, to me, appears to be the opposite of the goals of the bitcoin ecosystem. To ensure this point is clear, I strongly believe recommending people focus all lookups through 4 centralized "proxies" is a bad idea and counter to bitcoin's ideals. The fact that hackers or state actors need to corrupt only a small number of servers/services in order to gain global visibility into all queries, I believe, breaks any perceived privacy gains from using DNSCrypt. A very small number of hacks or subpoenas and everyone's records are fair game in one place. For the highly privacy conscious they can, today do their DNS lookups over a non logging VPN connection without forcing everyone else through a handful of centralized servers. Or they can use DNSCrypt optionally themselves. All of our tools have always been open source and folks can modify them for their own desired uses, or submit pull requests with their own ideas. We'd love to hear others thoughts on this. While I believe that for now the centralization trade offs required to use DNSCrypt today (via a limited number of proxies) outweigh any perceived privacy benefits it provides, we are always open to what others in the community believe and have made modifications to how things work before as a result of feedback from industry participants. > > >> 2> We have the option of storing a URL rather than just a wallet >> address in the TXT record. This allows a second level lookup against >> the URL to get back a unique HD Wallet address or Payment Request each >> time, further protecting user privacy and security. Using Wallet >> Names with Payment Requests allows for the user experience of typing >> in an easy to remember name and getting back the "green lock" and who >> the validated recipient is. This also provides an auto audit of the >> end to end DNS SEC process, in the case the path were somehow >> compromised, the signature on the payment request can provide an >> additional check. >> > > OpenAlias supports this as well, except it does it better by allowing the > KV pairs to also contain a TLSA record before the request, which > effectively makes it a DANE-secured interaction. Your interaction requires > the trusting of multiple CAs, which is an inherent weakness. > I think DANE is a great idea. We were just discussing that with Andreas S., and are currently looking at whether we want to add this as optional versus mandatory, based on how widely available DANE is for folks using services like Cloudflare, Akamai, etc for their DNS, which many providers in the space today are. Of course, the security conscious could setup DANE on the URL we use AS IS. There is no need to create a special kv pair for this as is done in OpenAlias. As you know, DNSSEC and HTTPS support this today out of the box. The CA validation, in our case, is an ADDITIONAL signature based validation to the DNSSEC chain, not a replacement for it. [CONTINUED]