[NMDF] Namecoin API Server [0.5BTC] [frozen]

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by indolering »

sugarpuff wrote:
indolering wrote:Besides, after UXTO arrives (~year, maybe two) the backend debate goes away, it's essentially becomes a legacy tech.
So, you told me this via IRC and I didn't understand what you meant by it there. Likewise, it makes no sense to me here.

What brief reading I did on UXTO tells me it doesn't supersede the functionality that DNSChain gives.
http://utxo.tumblr.com/post/51739920287/introduction

As well as https://www.youtube.com/watch?v=YRcPReUpkcU which doesn't "compete" or anything, a backend API is still necessary but you not longer have to rely on any signatures at all.
DNS is much more than a key->value datastore.

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by indolering »

sugarpuff wrote:I'll go through the list, with the answers for DNSChain:
phelix wrote:This would allow for lightweight applications: Firefox browser plugin with TLS, file signatures, name browsing

* Should use Nmcontrol (integrated or query) or maybe a custom Python script
Uses JSON-RPC2 to talk to namecoind, no need for nmcontrol.
Agreed, while expanding on an existing library is a nice idea, this does not do that. We need to pipe data between the database in Namecoind and an HTTP server, arbitrarily forcing the use of nmcontrol is just adds an additional layer of abstraction to the name_show RPC.
sugarpuff wrote:
phelix wrote: * Server should run on nginx, tornado, supervisord
I have nginx proxying requests to it, and DNSChain, like nginx, is an asynchronous, high-performance server written on top of NodeJS.
Specifying the use of any single technology only makes sense if that technology reduces the amount of work needed to perform the task. What we need to do is serve up the same exact requests for each query, there is no state to maintain or users to keep track of. We simply serve the same dumb response over and over again.

We need to preprocess the data and serve static copies. That is all.

High-performance python servers exist but we should just use the right tool for the right job. Since we are NOT handling complex queries there is NO need for complex processing on the server side.
sugarpuff wrote:
phelix wrote: * Should implement some kind of query time / size limit and DDOS protection in Nmcontrol
Don't use NMControl, and this is easily done using nginx's rate limiting options.
Agreed, this is a read only service! nginx is a great reverse proxy.
sugarpuff wrote:
phelix wrote:* Should have an ICANN domain name or subdomain (not on namecoin.org)
dns.dnschain.net (as examples above show), but that's just my personal server I'm letting others use for free.
Wait, so no namecoin.info domain? Anyway, yeah, I've got endpoints on speech.is and at Cloudant.

sugarpuff wrote:
phelix wrote: * All files need to be open source on github with a free license
Check.
Ditto, although I'm basically just using CouchDB. The JS for a scraper is online and FOSS. I'll probably just reimpliment the updating mechanism directly in Libcoin's SQLite and remove the scraper all-together.
sugarpuff wrote:
phelix wrote: * Should come with an example query file in python
Not sure what you need this for... or why it needs to be in python? It's just HTTP (language agnostic).
I think he means just example python code. CouchDB has libraries for every major language, including Python. There are several embeddable databases (For Android, iOS, and JavaScript) and there is at least one implementation of the replication API in Python (meaning we can sync databases in Python if need be).

Config files should be in a standard key=value list, YAML, coffee, or JSON.
sugarpuff wrote:
phelix wrote:* a .bit domain with TLS support would be nice (should be very simple with the config files above)
DNSChain is a DNS server, and so you can load .bit domains over it. To make HTTPS warnings go away, something like a browser extension is required.
We should use Namecoin's .bit website.
sugarpuff wrote:
phelix wrote:* should be reasonably performant (cached name list)
It is. Caching can be done in many ways (PowerDNS, built-in memory, using memcached, etc.).
Here is a general refutation of any complaints you could have about CouchDB's performance characteristics:

If you want to try and build specific benchmarks to show CouchDB being slower than some other database/server combo, go for it. But when it comes to serving static JSON requests it's very, very hard to beat CouchDB. The hype around couchDB was misguided at first: it is good at one thing but it is not a great general-purpose DB. The map/reduce syntax is weird to work with. It doesn't do well on latency. It's not a Javascript object-database. That's why MongoDB "won" over CouchDB.

However, all of those complaints have little to do with CouchDB. We want a read-only datastore, if you are comparing map/reduce to SQL you should just use SQL because you're task probably doesn't need map/reduce preprocessing, nothing is faster than local reads, and it isn't meant to serve HTTP queries. Use a Javascript object DB if you want to store generic Javascript data objects which include functions.

It was made using Erlang so has great parallelism, the hot spots have been rewritten in C, and the performance comes from using an HTTP protocol that leverages the vast number of HTTP caches between the server and the client. Your local ISP doesn't cache binary data used by most databases, it does, however, cache all of the HTTP calls.

Finally, this is all based on full-node, master-to-master replication. The wireline latency doesn't matter because I can just shove the entire DB into the client. We can scale to the size of the .biz domain on only 5 megs of storage space, so just fucking do full replication and store everything on the client.

You can't beat CouchDB in this very specific niche without spending more time and effort than it would take to just use CouchDB.
sugarpuff wrote:
phelix wrote:* For much later: offer some security by adding the original block + a couple of following blockheaders
Not sure what you mean by this, but DNSChain will soon sign all its replies.
Right, I will add signing as well. Blockchain validation stuff will come with UXTO, so let's not do a crappy implementation of that here.
sugarpuff wrote:
phelix wrote:API (json):
* name_show (just like namecoind or nmcontrol)
* name_show at previous height, return failure if older than e.g. 100k blocks (nice to have)
Just load the URLs, it's a RESTful API (examples given already).
I've limited records to current, non-expired domains and included the block at which they expire. I will eventually get to creating a map/reduce job (AKA view) that filters expired domains. This is trivial, indeed, I will have a cleaned view which will serve as the "master database" clients copy from and I will add in all of the other restrictions we have (like valid JSON, etc).
sugarpuff wrote:
phelix wrote:Edit:
You will receive 0.3BTC now and 0.2BTC after one year.
Query names could be hashed and results encrypted with the name or something to protect the server operator from liabilities.

edited 2014-01-19
DNSChain supports dnscrypt! See the GitHub page (I'm using it now!). :)

As for encrypting HTTPS, that can also be added easily using NodeJS (and will be added soon). Currently HTTP is supported.
That is, sadly, not the type of encryption Phelix is referring to. I will integrate this when mainline does or sooner if it becomes an issue.

Okay, I should stop saying "CouchDB" and just start saying REST, because that's what makes CouchDB sp performant. Check out this PhD thesis which explains why REST scales so well, it has some 3K citations. CouchDB is the only database that uses REST as it's communication protocol, that's what makes it scale so well. You can do the same thing by sharding databases and throwing reverse proxies in front of them and doing off-line map/reduce jobs to preprocess queries. CouchDB simply encapsulates a known architectural pattern into a single package.

I'm solving all of the problems one needs to care about in an API by reusing a system that is purpose built for that task. Additional API features are just map/reduce jobs which create a new view. As a bonus, we get to freeload off of the libraries, the embeddable implementations, replication, and validation (read code signing) with close to zero maintenance. That's the hallmark of good engineering.

Sugarpuff is totally correct when he says that it is not hard to implement the backend. He is a much more competent coder than I am and wrote a good one in 600 lines of Coffeescript. I wrote one up a fairly crappy PHP version which used Namecoind directly as well, then I wrote client side software and then I said, "Fuck this, I'm just going to reimplement everything using industrial grade components because it will be better than anything I can write."

As I said before, arguing about the backend is rather silly, all of this goes away once we have UXTO. I probably will toss CouchDB entirely and try to reuse BitTorrent or another P2P protocol in the future. UXTO does not replace the problems which Speech.is is trying to solve (web interoperability) nor what OKTurtles is trying to solve (authentication and encryption over existing services, basically transparent PGP for Facebook).

I really wish we had collaborated early on because I really need to work on the front-end, not the backend. I honestly would have just used Sug's backend had I understood what he was doing early on. However, retooling for either one will take time and I don't think either of us really want to redo that work again. I think mine can be beefed up more quickly and require less work in the long run, but I suggest that we both get to work on the front-end and start providing real value before we worry about existential engineering choices.

I would like the money to be used productively and I think covering hosting costs and setting up bounties for additional features are a good way to do that. I would still strongly suggest using my API setup, but I don't really care.
DNS is much more than a key->value datastore.

sugarpuff
Posts: 110
Joined: Tue Oct 22, 2013 10:17 pm

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by sugarpuff »

indolering wrote:
sugarpuff wrote:
indolering wrote:Besides, after UXTO arrives (~year, maybe two) the backend debate goes away, it's essentially becomes a legacy tech.
So, you told me this via IRC and I didn't understand what you meant by it there. Likewise, it makes no sense to me here.

What brief reading I did on UXTO tells me it doesn't supersede the functionality that DNSChain gives.
http://utxo.tumblr.com/post/51739920287/introduction

As well as https://www.youtube.com/watch?v=YRcPReUpkcU which doesn't "compete" or anything, a backend API is still necessary but you not longer have to rely on any signatures at all.
K, read that too, still of the same opinion.

Try phrasing a sentence like this: "UXTO makes DNSChain obsolete because ______."

I can at least respond to that and explain why you are mistaken. ;) Kidding, maybe I'll agree, but right now it's hard for me to understand what point you are trying to make.
Last edited by sugarpuff on Sun Feb 23, 2014 2:48 am, edited 1 time in total.

sugarpuff
Posts: 110
Joined: Tue Oct 22, 2013 10:17 pm

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by sugarpuff »

indolering wrote:I really wish we had collaborated early on because I really need to work on the front-end, not the backend. I honestly would have just used Sug's backend had I understood what he was doing early on. However, retooling for either one will take time and I don't think either of us really want to redo that work again.
This I also don't understand. It shouldn't take much time at all. It could potentially be as simple as change a single URL (if you wrote your code in a modular way), and if you didn't, there's still no reason that I can think of as to why it would take more than a day.

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by indolering »

sugarpuff wrote:
indolering wrote:I really wish we had collaborated early on because I really need to work on the front-end, not the backend. I honestly would have just used Sug's backend had I understood what he was doing early on. However, retooling for either one will take time and I don't think either of us really want to redo that work again.
This I also don't understand. It shouldn't take much time at all. It could potentially be as simple as change a single URL (if you wrote your code in a modular way), and if you didn't, there's still no reason that I can think of as to why it would take more than a day.
Because, for legal reasons, I need to not be the source of information for the browser. Relying on a central server is only a short-term crutch. Eventually, my servers will be reduced to linking clients to miners whom bootstrap them into the larger network. Since, I'm going to be relying on browser-to-browser and browser-to-miner communication I need a durable, client-side information store which can smooth out unreliable communication to peers.

I built a proof-of-concept JSON-RPC bridge in PHP which was only intended to be used for the demo-launch which was scuttled over Christmas break. Switching back to such a system that doesn't come with master-to-master replication would *not* just be a change in URLs. This would require migrating back to the home-grown client-storage I had developed and have subsequently discarded, reimplementing replication, and spending thousands of person-hours to develop all of the libraries and services supporting this protocol.
DNS is much more than a key->value datastore.

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by indolering »

K, read that too, still of the same opinion.

Try phrasing a sentence like this: "UXTO makes DNSChain obsolete because ______."

I can at least respond to that and explain why you are mistaken. ;) Kidding, maybe I'll agree, but right now it's hard for me to understand what point you are trying to make.
UXTO makes DNSChain obsolete because they remove relying on a trusted 3rd party to sign the certificates. UXTO and SPV take the security model offered by the blockchain and compresses into something we can fit inside of a browser, ~10megs (by my back-of-the-envelope calculations).

The real innovation you provide is not within DNSChain: you are signing records and the trust required does not differ fundamentally than that of trusted required of cert-authorities. That your trust root is different is an improvement on general security, but it's not the radical leap that moving the blockchain into the browser provides.

If you take SCIP to it's natural conclusion, you can use an API in a similar fashion to a traditional web API but have mathematical proof that the person sitting in-between you and the blockchain did not mess with the calculation.

The innovation that you offer is in the front-end, in providing security and privacy within in services which do not offer it natively. That is a radical improvement and it is why I admire your work: you clearly understand that part of the problem better than most developers. It's where we get to make Namecoin actually useful, instead of a nice theoretical piece of technology that we wish everyone would switch to but never will because it's a total pain-in-the-ass.

Indeed, that is where I think collaboration would be the most useful to us: I want to build an extension which can allow users to securely and anonymously receive individualized DNS information for use of the ICANN network. Then, if WikiLeaks is blocked in my country, I can simply follow @wikileaks on Twitter and my browser will receive a personalized URL endpoint (like https://randomusername:randompassword@w ... ittens.com) which will act as a DNAME/Translation field. That's something OkTurtles provides which no-one else can.
DNS is much more than a key->value datastore.

sugarpuff
Posts: 110
Joined: Tue Oct 22, 2013 10:17 pm

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by sugarpuff »

indolering wrote:
K, read that too, still of the same opinion.

Try phrasing a sentence like this: "UXTO makes DNSChain obsolete because ______."

I can at least respond to that and explain why you are mistaken. ;) Kidding, maybe I'll agree, but right now it's hard for me to understand what point you are trying to make.
UXTO makes DNSChain obsolete because they remove relying on a trusted 3rd party to sign the certificates. UXTO and SPV take the security model offered by the blockchain and compresses into something we can fit inside of a browser, ~10megs (by my back-of-the-envelope calculations).
1. It's not a 3rd party. It's you, your own party. That is what... 1st party?
2. Show us those calculations please. Where does it get these 10 magical megs from that have all of the necessary info from the blockchain? How long does it take to get them? What are the threat models?

Sounds like BS to me, but I'm open minded enough to believe in the tooth fairy with enough evidence.

(Edit: nevermind the fact that DNSChain is more than an API to the blockchain, it's also a DNS server.)
The real innovation you provide is not within DNSChain: you are signing records and the trust required does not differ fundamentally than that of trusted required of cert-authorities. That your trust root is different is an improvement on general security, but it's not the radical leap that moving the blockchain into the browser provides.
... OK, this part of the conversation suddenly has devolved rather quickly. I await your "radical leap" and will continue to work on my project that apparently "does not differ fundamentally [from] cert-authorities" (<-- that is complete BS btw.).

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by indolering »

sugarpuff wrote: 1. It's not a 3rd party. It's you, your own party. That is what... 1st party?
OkTurtles white paper wrote:DNSNMC provides the missing “glue” to the Namecoin blockchain that makes it immediately accessible to clients of all types with zero configuration. A network administrator need only enter the IP address of a DNSNMC-compliant DNS server to instantly make the information within the blockchain accessible to all of the users that she (or he) provides internet access to.
Clients trusting servers ... that is a one party trusting a third party.
sugarpuff wrote: 2. Show us those calculations please. Where does it get these 10 magical megs from that have all of the necessary info from the blockchain? How long does it take to get them? What are the threat models?

Sounds like BS to me, but I'm open minded enough to believe in the tooth fairy with enough evidence.


They are rough estimates based on posts which gave the UXTO size and the size of the BTC blockchain, I just used the same ratio based on Namecoin's blockchain. I don't really know how to lookup the number of unspent transaction outputs so it's probably off but I'll quote from the canonical thread on the issue,
This provides the same compression as the simpler unspent-TxOut merkle tree, but also gives nodes a way to download just the unspent-TxOut list for each address in their wallet, and verify that list directly against the blockheaders. Therefore, even lightweight nodes can get full address information, from any untrusted peer, and with only a tiny amount of downloaded data (a few kB).
...
(2b) Uncertainties about lite-node bootstrap data: Depending on how the data is structured, there may still be a bit of a data for a lite node to download to get the full security of a full node. It will, undoubtedly, be much less than downloading the entire chain. But, there is obviously implications if this security comes at the cost of 1 MB/wallet, or 100 MB/wallet (still better than 4GB, as of this writing). UPDATE: My initial estimate based on the "Hybrid PATRICIA/Brandais Tree" (aka Reiner-Tree), is that a wallet with 100 addresses could verify its own balance with about 250 kB.
sugarpuff wrote: (Edit: nevermind the fact that DNSChain is more than an API to the blockchain, it's also a DNS server.)
Are we talking about a web API or DNSChain? I think the meta-tld is clever and it provides a different kind of API. The mechanics and needs of your specific API are important and that's why I suggested that both of us are too busy to give a shit about the backend server that handles the actual calls. However, again, NamecoinToBind and a standard DNS server would provide a much more robust backend than what you are proposing.
sugarpuff wrote:
indolering wrote:The real innovation you provide is not within DNSChain: you are signing records and the trust required does not differ fundamentally than that of the trust required of cert-authorities. That your trust root is different is an improvement, but it's not the radical leap that moving the blockchain into the browser provides.
... OK, this part of the conversation suddenly has devolved rather quickly. I await your "radical leap" and will continue to work on my project that apparently "does not differ fundamentally [from] cert-authorities" (<-- that is complete BS btw.).
I'm not able to take ANY credit for UXTO in the browser nor do I think I have the programming chops to implement it in Javascript. Speech.js will adopt that technology and when it becomes available and I'll be lucky if I can have the honor of putting those pieces in place. However, I am going to have to rely on other peoples work (just as I rely on the very, very smart people behind Namecoin, Bitcoin, and CouchDB) for the core components.

In our last conversation on IRC, you told me that I sounded like a bad politician. That's because whenever someone gives you feedback on your project you take it as a personal attack. I've been overly nice to you because I don't want to elicit that reaction, I respect you, I respect what you are trying to do. I want you to know that I'm a human being and that I am trying to help you.

On your website, you say that your work has been peer-reviewed. I ran my own research study once, before I got into UW. There were no faculty at the college with usability expertise, so I was relying on psychology professors to review my work. I sent it in to a usability journal for peer review and received one vote for and two votes against. The critiques were stinging but also liberating, it was the first time professionals really engaged with my work at a deep level. Their review was firm but fair and, ultimately a very kind act: they spent a great deal of time reviewing what I had done and explaining my errors to me. The editor told me I was on the right path, that my work was very good for being a students first attempt, and they encouraged me to continue. I would like to give you the same advice.

The consensus opinion between myself and at least two other developers whom have reviewed your proposal is that, while it's very interesting and has many valuable contributions, your core claim is fundamentally flawed. You changed the trust root to Namecoin, which is a big step. The front-end will provide what PGP should have provided: transparent encryption for normal people. Those are excellent goals and they show that you understand these problems better than most programmers. I would strongly encourage you to continue with your project and to pursue those goals.

However, DNSChain doesn't sign data any differently than anyone else. We can skip the existential crisis of what counts as a "third party" and analyze it another way: DNSChain take information stored in one type of verifiable data structure (hash trees) and stuffs into another type of verifiable data structure (public-key crypto). DNSChain and certificate authorities take information and stuff it into the same verifiable data structure. The root is different, you trust what the blockchain tells you, CA authorities trust whatever people with $50 and domain name tell them. Beyond that, the methods and the security profile are exactly the same: a client has to trust that the data has not been tampered with by the server which performed the encryption.

You berate Convergence, but if Convergence used the blockchain as the root authority it would provide the same service which DNSChain provides except that it would distribute trust across more than one server and it would reduce the ability for any single server to target an individual computer and connection.

Trying to claim that handling TLS certificates through DNS somehow makes your solution special is also a faulty claim: you are basically recreating some combination of NamecoinToBind, DNSCurve, and DANE. That's not to say that it is fundamentally flawed, but, in regards to how the client front-end receives the data, the security model it is no different.
DNS is much more than a key->value datastore.

sugarpuff
Posts: 110
Joined: Tue Oct 22, 2013 10:17 pm

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by sugarpuff »

indolering wrote:
sugarpuff wrote: 1. It's not a 3rd party. It's you, your own party. That is what... 1st party?
OkTurtles white paper wrote:DNSNMC provides the missing “glue” to the Namecoin blockchain that makes it immediately accessible to clients of all types with zero configuration. A network administrator need only enter the IP address of a DNSNMC-compliant DNS server to instantly make the information within the blockchain accessible to all of the users that she (or he) provides internet access to.
Clients trusting servers ... that is a one party trusting a third party.
That piece of documentation describes one possible setup. Plastered throughout that same PDF in other locations, and all over the GitHub README, it is emphasized:
GitHub README wrote:DNSChain is meant to be run by individuals!
If the client owns the server, that is by definition a first party.

If their friend owns the server, well, that's either 2nd or 3rd party, and I hope they have a good friend.

This is a completely different reality than the one we currently live in. Go register your own CA and get browsers to accept it if you don't believe me. To argue that DNSChain and CAs are "the same thing" is to display complete ignorance about these realities.

Edit: that previous paragraph isn't clear. Please see next post for clarification.
indolering wrote:They are rough estimates based on posts which gave the UXTO size and the size of the BTC blockchain, I just used the same ratio based on Namecoin's blockchain. I don't really know how to lookup the number of unspent transaction outputs so it's probably off but I'll quote from the canonical thread on the issue,
This provides the same compression as the simpler unspent-TxOut merkle tree, but also gives nodes a way to download just the unspent-TxOut list for each address in their wallet, and verify that list directly against the blockheaders. Therefore, even lightweight nodes can get full address information, from any untrusted peer, and with only a tiny amount of downloaded data (a few kB).
...
(2b) Uncertainties about lite-node bootstrap data: Depending on how the data is structured, there may still be a bit of a data for a lite node to download to get the full security of a full node. It will, undoubtedly, be much less than downloading the entire chain. But, there is obviously implications if this security comes at the cost of 1 MB/wallet, or 100 MB/wallet (still better than 4GB, as of this writing). UPDATE: My initial estimate based on the "Hybrid PATRICIA/Brandais Tree" (aka Reiner-Tree), is that a wallet with 100 addresses could verify its own balance with about 250 kB.
That is how much data is needed for a wallet to "verify its own balance". That is not the same as verifying an arbitrary namecoin entry, which is what is needed.

Case closed on the UXTO thing?
indolering wrote:In our last conversation on IRC, you told me that I sounded like a bad politician. That's because whenever someone gives you feedback on your project you take it as a personal attack.
It's because to me, you sound like a bad politician, and that's all. I haven't gotten that vibe from anyone else who has critiqued my work so far. Your self-criticism, that you write/say too much, is a near acknowledgement of this. Too many words, without enough quality content to justify them.
You berate Convergence
berate (verb): scold or criticize (someone) angrily

I actually gave them some praise, along with a few criticisms. I never "berated" them.
Last edited by sugarpuff on Thu Feb 27, 2014 6:39 am, edited 1 time in total.

sugarpuff
Posts: 110
Joined: Tue Oct 22, 2013 10:17 pm

Re: [NMDF] Namecoin API Server [0.5BTC]

Post by sugarpuff »

sugarpuff wrote:This is a completely different reality than the one we currently live in. Go register your own CA and get browsers to accept it if you don't believe me. To argue that DNSChain and CAs are "the same thing" is to display complete ignorance about these realities.
Sorry, I wasn't as clear as I could have been there, let me elaborate on that.

Yes, you can get a browser to accept your CA ala Convergence, or by manually installing a certificate. That's not the difference that I'm highlighting. In terms of getting browsers to acknowledge a non-bundled CA, yes, DNSChain would have to jump through similar hurdles (via a browser extension).

The differences I'm emphasizing are between CAs and DNSChain, not Convergences and DNSChain:

- You pay money to CAs to get a cert, while you don't pay money to your own DNSChain, or anyone else's. You simply self-sign.
- CAs are organizations, companies in of themselves, whereas DNSChain is just a server/proxy-to-blockchain
- Any one of the CAs can lead to a cert compromise of all websites online via MITM, whereas DNSChain specifically is designed to prevent that.
- Related to the above is trusting the least-trustworthy of 600+ CAs (whom you have no reason at all to trust) vs trusting a single server that you own.
- You have to go to your CA to update a cert. You go to the blockchain with DNSChain.

Those are some (maybe most) of the significant differences between a world with CAs and a world with DNSChain. As you can see, they are very different.

If you want to compare DNSChain with Convergence, that is a different matter.

Locked