It still seems bizarre to me that this system lets people register arbitrary TLDs. If nothing else, sooner or later a new ICANN gTLD will conflict with a Handshake registration. At that point, Handshake will no longer be a backwards compatible extension of the existing DNS, so systems will have to choose one or the other. Maybe the Handshake authors think that when that day comes (and it's probably not that far off), Handshake will already have achieved enough popularity that operating systems and browsers will choose Handshake instead of ICANN. Somehow, I doubt it...
Imagine IPv6, but if it was somehow designed to squat on top of the IPv4 namespace, so that switching to IPv6 would cause existing addresses to start pointing somewhere else. That's pretty much the situation Handshake has chosen to be in.
Not to mention that allocating TLDs
- confuses non-technical users ("what do you mean, there's no dot in the address?")
- conflicts with the choice of most browsers to unify the address and search bar (if I type refrigerators and press enter, I want a search results page, not the homepage of whoever registered the TLD 'refrigerators')
- may conflict with other non-standard domain name systems, including special-purpose TLDs like .onion – though they've at least reserved the existing ones, so it would only be a problem for not-yet-developed systems
It's strange, because I want to support decentralized name systems, and Handshake seems better designed than some of the previous attempts, but that one decision makes it seemingly guaranteed to fail.
Its just one example of the entire governance problem thats conspicuously absent from the post. How is dispute resolution handled? Identity verification? Attestation?
Reasonable answers to those questions are generally counter to the raison d’etre of setups like this. And without it you have a spam and scam goldrush to squat the most “valuable” entries and pretty big gap in _human_ trust in the system.
When you become big, famous, influential, anything like that. Then people can register your domains and misrepresent you or just use your namesake as a platform to attack you (write bad things about you at best, do some really nasty damage at worst). Need to play defense preemptively.
I prefer technology to deal with the technical issues and individuals to deal with their individual issues.
Tech can't possibly cater to everyone's special needs.
I'm totally fine with domain names being the interface between thr protocol and the human user. All other mappings (e.g. legal names) fall in the realm of human politics.
The problem is that you cannot do anything about it, other than suing the author - if you can find them and they're in a reasonable jurisdiction.
Well, you can try to break the system by splitting it in half, introducing an overlapping domain. If collisions is the desired way of dealing with it, the whole thing is ultimately broken.
Just imagine Amazon breaking Google domains because they have a better cloud.
With ICANN and registrars, there is a point you can directly attack legally, and a root of trust.
Yes, this. DNS and CAs are effectively rooted in internationally recognized legal systems with rules, precedent, and procedure (flawed though they may be). Approaches which circumvent that give up those protections. Which leaves something like “first actor is precedence” and “mightiest compute is rightest.” Maybe theres a technical framework that can address those problems. But I havent seen it before, and its not even mentioned in the parent article.
Its not that registration requires id. And i dont mean an individual providing gov id. I mean verifying that “store.sony” is managed by a legal entity representing Sony Corporation of America. Basically the entire (ongoing) problem behind DV/EV certs etc. Identity is essentially what underpins trust and dispute resolution.
This paragraph from the blog post doesn't completely address your comment (or even most of it), but it seems useful to have as a reference as I've almost always missed it:
> How Handshake conflicts with ICANN
> All 1500 of the existing ICANN TLDs are blacklisted on Handshake for backwards-compatibility. This means that end-users resolving their DNS through Handshake can still access .com domains as normal. New ICANN TLDs can theoretically conflict with Handshake TLDs, but ICANN isn't issuing new TLDs for another few years. When ICANN does issue new TLDs, they’ll only allow at most 500 new TLDs per year. The likelihood of conflict is low even though conflicts can technically happen. In the future, it's up to the community to decide which names take precedence. We believe Handshake names will take precedence because people will find them more useful, and I’ll cover why I think Handshake can gain adoption even in the face of ICANN’s network effects in another blog post.
> When ICANN does issue new TLDs, they’ll only allow at most 500 new TLDs per year. The likelihood of conflict is low even though conflicts can technically happen.
Oh, "only" 500? Out of which a substantial fraction will be common words and therefore likely to be squatted on if Handshake is even remotely popular? I wondered if Handshake was at least trying to reserve English words, but apparently not, judging by this:
Names which were added _after_ the final snapshot:
- `charity` - A new gTLD added on ICANN's system.
- `inc` - A new gTLD added on ICANN's system.
This isn't a coherent thought, which illustrates why they fail. A name _system_ is something you have exactly _one_ of, because otherwise they conflict. To support more than one is to give up altogether, it might actually be slightly worse than just not caring at all.
So you'd need to pick one and then, even if clearly better alternatives are subsequently proposed, you _must_ stick by your choice or you destroy the value of choosing at all. That's clearly a bad idea, you're more or less guaranteeing a sub-optimal outcome for yourself.
I'm not seeing any explanation behind any of your attestations. Are they assumptions?
Saying conflicts are inevitable/unavoidable between name systems seems simplistic: it's a problem to solve. Not necessarily easy, but I know of no hard law making it implicitly insurmountable.
Why does changing name system destroy all value? Sure, changing any system is disruptive and can be relatively destructive; such changes must be weighed against benefits of change, but I see no reason choosing generally better alternatives must destroy all value.
The conflict is intuitively obvious. A name system maps names _to_ something. If system A and system B have the same mapping, that's just the same system under a different name. If they have different mappings they conflict because the mapping will give me different results from system A versus system B. It's that fundamental.
The address bar in Chrome shows both the string as a potential search, and URLs in recent history/tabs with that string. Why wouldn't a Handshake-supporting browser do something similar?
Most alternative domain name systems nest everything under a single TLD – .eth, .onion, etc. In theory, either the standard DNS or a different alternative name system could cause a conflict by using the same TLD themselves. But unsurprisingly, ICANN/IETF are a lot more receptive to "please avoid using this one semi-branded TLD" than "please hand over the entire namespace to us". .onion is already formally reserved by IETF RFC as a "special-use domain name", and hopefully .eth will join it in the future. As for a different alternative name system, conflict over .eth could theoretically happen if Ethereum forks again or if ENS itself is somehow forked, but an independent effort would presumably pick a different name.
I love the idea but it seems like like a long shot to get the network effect working in your favor instead of against you. You mention a bottoms up approach and what happened in Catalonia but that is such a tiny percentage of the population facing problems that most people will hopefully never face. How does this go mainstream? Why should the average person care about a more secure solution to DNS? Most people happily ship their data off to Google and Facebook and are blissfully ignorant about the potential consequences. It seems like you would have to make people care more about internet privacy before something like this would work on a large scale.
IMO, it faces the problem that most crypto projects are running into; it might be good solution, but the problem doesn’t effect the average person enough for it gain mainstream traction.
There are many instances where an intolerant minority is able to get a neutral majority to adopt their will. Nassim Taleb describes this as the minority rule. It’s the same reason why all lemonade is kosher*
A small minority of people NEED censorship-resistant and seizure-resistant DNS, and the bet is that they can get the majority to adopt Handshake. The key is that Handshake is backwards compatible with existing DNS, so for the majority that don’t care, they can switch to Handshake without problem. I’d also emphasize that in addition to the minority that absolutely needs it, there are millions of prosumers who care about privacy and security as well, as evident by how quickly Cloudflare’s 1.1.1.1 has grown.
On the point of Cloudflare, 1.1.1.1 often gets a lot of usage in countries with strict DNS censorship. When Turkey took down twitter.com, people literally spray painted 1.1.1.1 on walls since you could use it to get around the censorship. OpenDNS got a lot of growth outside the US this way as well. In both the case of Cloudflare and OpenDNS, they can’t promote the censorship-resistant use case as strongly because they have a single IP. Handshake doesn’t face the same restriction.
Eventually, the goal is to get browsers to adopt Handshake in order to reach the late majority who don’t care either way, but that would only happen after significant bottoms up adoption. At a certain point it’d make sense for Opera and Brave to integrate Handshake, and then Firefox, Edge, and all the other browsers as well.
It’s true that a single static IP address is easy to block, but what is stopping an oppressive regime from building tech specifically designed to block Handshake? Correct me if I’m wrong, but Handshake still functions over IP and as such a government could potentially block all IPs associated with Handshake via similar mechanisms that are used to block a single IP. If there exists some kind of public list of all Handshake resolvers, as, from my understanding, there would have to be, they could very easily continue censoring content deemed inappropriate. I don’t see anything built into the core of this that will solve this problem. Oppressive regimes will adapt.
And DNS as it stands is fairly seizure resistant as long as you use secure passwords and the customer services folks don’t get tricked into resetting your account or something.
The vision is grand. I’m excited to see where this project goes and will definitely be following along. Best of luck.
As far as I can see, I could run a Handshake recursive resolver myself, either for my own internal network, or I could publicise it.
It's not clear to me how a third party could verify that my resolver was returning answers based on blockchain data, though. I suppose the blockchain could be contrived to return DNSSEC signatures, which could in turn be sent by the resolver; so if you trust the blockchain root's DNSSEC signature, then you can trust an arbitrary resolver. But the article didn't mention DNSSEC, or how you establish trust in an arbitrary resolver.
> what is stopping an oppressive regime from building tech specifically designed to block Handshake?
It runs over https so it would be difficult to distinguish between a legitimate https packet and a handshake one, you would need to do deep packet inspection which is difficult.
Being distributed it uses multiple ips lots, these ips change lots, this is called churn and keeping track of it is a problem for distributed systems. The swarm is segmented and the segments are usually randomised to the individual for better distribution this is supposed to make it difficult to get all the ips to ban them all but easy to get at least one unbanned ip.
> Oppressive regimes will adapt.
Yes they will but they will have to publicly invest significant money and years of time into a project that can only be used for censorship.
> And DNS as it stands is fairly seizure resistant as long as -sic- the customer services folks don’t get tricked into resetting your account or something.
This happens constantly, its probably the biggest security issue that faces dns, just phone up some level 1 tech and grab yourself a new domain.
>Handshake still functions over IP and as such a government could potentially block all IPs associated with Handshake via similar mechanisms that are used to block a single IP
Blockchains are decentralized. Sometimes a fixed set of bootstrapping nodes is used to improve user experience (rapid connection to the network when opening the app), but if these nodes are blocked it is quite easy to rotate them (and even to make it less easy for an attacker to know the identities of all nodes). A legitimate website that cannot be blocked because it has an unrelated focus can even be used as a shield (some sort of partnership).
>And DNS as it stands is fairly seizure resistant as long as you use secure passwords and the customer services folks don’t get tricked into resetting your account or something.
You do not know what you are talking about I'm afraid. The internet is censored like hell, and I am not talking about living in China or other authoritative regimes. Activists not agreeing with what you are saying try to censor you like hell these days and registrars bow under the pressure. This is not about right-wing hate speech. Just try to start a political platform about a sensitive topic and see how it goes.
Do you want to advocate to allow the marriage of young children and start a democratic discussion about it? Or do you want to host a community of consenting adults believing in a family arrangements in which the man is the lead of the woman and providing practical life advice including how to spank your wife? You'll spend your life wondering when your registrar will take your website down. And these topics really are just examples.
I have seen countless websites disappear (and forums where activists organize themselves to pressure registrars). If you confront them and put them in a corner, they admit that they are censoring just because they do not agree, but they invoke the notion of "higher social interest", and "the ends justify the means", and in essence "this is a holy war, they will be collateral damages but we need to prevent irresponsible speech" (which really is the new way to justify intolerance - a very sickening rhetoric).
For example with the example of wife spanking among consenting adults (there is not even a knowledge asymmetry between the woman and the man in these communities, the methods and psychology behind this arrangement is discussed openly, and they actually choose this lifestyle because they want the psychological outcomes - they want to program themselves at a subconscious level so to speak. This is totally consensual), I know that many people here think that only a vulnerable and exploited woman could agree with that. And I could point you to women advocating for this, and even animating YouTube channels about it - that may be taken down anytime. And this was only to provide a graphic example, but this not limited to this category of topic.
My point is that every majority begins with a minority, and like-minded people, not hating anyone and not propagating hate should be free to live freely even if they lifestyle and values are sickening for some people.
Not so long we tries to look for a registrar who not having vague TOS allowing to them to take down your website if their disagree with the content. Wording providing them large flexibility to censor. After over 1 week of research, we have only found one. But even this was actually based in a country where a legal action can easily be taken to force them to terminate service. Ironically, we then looked into Russia and we found that hosting there would be our best option if the situation gets heated, because of the politics between them and the West. When it gets to that point, you know something is wrong.
The reality is the internet is very censored. Extremely censored nowadays, but there is a lot of propaganda going on to justify this environment. People enjoy censorship until they are the ones being censored. It is like religion, people love seeing they opinion win and others be destroyed. 90% of people happily close their eyes if they opinion and interests are the ones being unfairly and oppressively favored. Handshake is solving a real and serious problem much deeper than what you and most people understand. Handshake is absolutely needed and the problem they solve is REAL, very real and very serious.
If you live a normal life, you always think that there is no problem about anything. But if you try to drive change in the world and be a thought leader, then you see things differently and you are confronted to the problems and frictions that prevented your innovation from emerging naturally without your help.
The problem faced by democracies these days is that laws are made for those voting from their sofas and "having nothing to hide". However, if there is one thing we should have learned by now (but that nobody seems to have learned) it is that laws and society can only be sound if they are focused on creating the environment that those who create democratic value, intellectual value and economic value need. Not the one that those who want to feel safe, and have everything while doing as little effort as possible want. Giving power to this type of people will always screw a society. But ignoring and oppressing them flat out as was done in the past is not good either. So we started of on the extreme right (monarchy), we moved to the extreme left (populism), so now is the time to find a middle ground. We need to have a conversation about limiting the political influence of most passive "citizens", who maybe should not be considered citizens, until they up their intellectual game. Intellectual-meritocracy-like citizenship system, that would need to be appropriately designed not to elevate one school of thought, philosophical premise or opinion as the only acceptable starting point. But this getting out of topic.
If you are interested in this conversation and want in hearing more about these ideas, and even to contribute and share your thoughts, there is a fast-growing international political movement. The mailing list is not public yet but drop me a line and I'll ask them to add you: samuel233[---at---]protonmail.com.
Just make a fun website that is only accessible through the system.
Businesses can own a cryptographic asset (their domain name) that can accrue value based on services provided.
Potentially people may try to use their domains as collateral or experiment in collective ownership of public services through multisig or DAO like constructions.
Hopefully it helps push forward innovation on the chain of trust, opening it up to be something more configurable and dynamic.
I never imagined someone would write a recursive DNS sever in javascript. Have they explained why they chose javascript? It can't perform well nor scale and they even sort of admit that:
Basically, only the root record parsing is done in JS and then passed to unbound for resolution. Though it is possible to run a pure JS resolver, it's not really recommended.
Right, thanks. And I hope my question does not sound too critical. I was just genuinely curious why JS was used.
I think JS is fine for small to mid-sized tasks, prototyping and testing ideas. However, for real DNS servers, used by a lot of clients, I believe C, C++, Go or Rust would be an absolute requirement.
The JS implemention is a fork of bcoin, the JS Bitcoin full node and production backend.
It binds to libunbound but you are right that you would want a lower level language for it to be more scalable. There is a rust implemention work in progress here:
https://github.com/UrkelLabs/rsd
This is separate from the DNS resolver being written in JS, but the team behind Handshake also created bcoin, which is the only javascript fullnode (and non-core fullnode IIRC) that has mined a Bitcoin block.
"Blockchain-based alternative to CAs" has been discussed before there even was the word blockchain (it was called sovereign keys, at least it's pretty close to a blockchain).
I'd expect someone trying at least discussing why that didn't make it. Also I'm really annoyed by the "there was a problem with CAs in 2011, this system is really bad"-tune ignoring what has been changed since then. (E.g. the "You don’t know who all these CA intermediates are" may be true, but that's your problem, because you very well could know, the information is there.)
Author of the post here. My aim was to keep this post focused and cover the differences between Handshake and previous blockchain DNS attempts in a separate post. The keyword here is attempts: previous projects like Namecoin and ENS haven't really taken off. I think the reason has to do with the underlying technology and the go-to-market strategy (or lack thereof) of the projects.
On the technology front, Handshake is the only naming blockchain that's launching with a light client that can resolve names. This may seem like a small thing but it's actually a critical input to success — without a light client, users would either need to run fullnodes (which no one does bc of the terrible ux) or rely on third party services. Third party services provide good ux but reduce the benefit of using the decentralized system in the first place.
On the go-to-market front, the initial distribution of names is really important. It's much more important than the initial distribution of something like Bitcoin because names are non-fungible. They're digital real estate so if a whale is able to bid up all the good names before adoption, there will be no incentive for new participants to invest in the ecosystem (this happened to the previous projects).
Handshake created a few GTM mechanics to prevent that outcome:
* The Alexa top 100k domains have been pre-registered, so that only those domain owners can register their names on Handshake
* Names are released for bidding over a 52 week period. If you hear about Handshake 8 months into launch there will still be a lot of good names available
* Auctions last two weeks and require locking up your coins, making it difficult to bid and win on a lot of names at once.
* Most importantly imo, Handshake coins are being distributed to developers, not investors. 70% of the initial Handshake coins are being airdropped to ~250k open-source developers. Basically, if you have a GitHub account with over 15 followers and an SSH key, you can anonymously claim Handshake coins. This is a no-strings attached giveaway so it will hopefully give developers a reason to check out the project, and it also makes it difficult for whales to buy up a lot of coins early on to outbid everyone.
I haven't looked into this yet, but one question I always ask for new blockchains is: Why use your own blockchain? Security is expensive, and it's trivial to 51% attack new chains with minimal hash power. This would make sense if you were using a shared security model (i.e. building on Ethereum). That being said, what kind of consensus algorithm are you using?
It's actually pretty difficult to enumerate all trusted CAs (or even just what organizations are running CAs). Certificate Transparency certainly helps there, but it's not fully required, and doesn't solve all problems.
The DigiNotar attack (from 2011) was mainly chosen because it's well known and easy to convey. It wasn't even that technically effectively because Chrome had Google's keys pinned, so it was immediately blocked and reported (like you would get with CT today). But, only in Chrome.
More recent examples of mississuance, like tricking Comodo's OCR-based validation [0] or spoofing DNS to hijack Let's Encrypt issuance [1].
CA's are always going to be vulnerable to these sorts of attacks, and they have such a broad attack surface and so much systemic trust (i.e power) that can cause unbounded damages with any error.
Author of the post here. If you have any questions I'll be online for a while to respond to them. We're serious about attempting to improve the security of the internet, so criticisms are welcome too.
Previous attempts at blockchain naming have basically failed, and there are a few reasons why. I go more in-depth into why Handshake is different/may succeed this time around in my comment here: https://news.ycombinator.com/item?id=21001806
We've spoken with people involved with the ICANN and I think that'd be unlikely. In a sense, ICANN is the incumbent that Handshake is trying to unseat, so it's not surprising that they don't like it. There have also been numerous alternative root projects in the past that all failed, so when ICANN people see that aspect of Handshake they quickly dismiss it. Interestingly, we've had conversations with Vint Cerf who invented TCP/IP and he actually liked the properties that Handshake provides (wasn't a fan of the blockchain implementation though). Vint proposed a system with similar properties in the past as well: https://cacm.acm.org/magazines/2018/12/232883-self-authentic...
I'm not a blockchain expert (or DNS, for that matter), but my reckoning is that alternatives to public-key infrastructure involving such things as identity-based and attribute-based encryption are a more promising way to get rid of CAs. Tackle it at the level of the trapdoor function, as this is, at least, mathematically robust. The mathematics of networks is less so.
The Innovators Dilemma provides a good framework for thinking through how it’s possible for new technologies to unseat incumbent network effects. Basically, the new technology needs to outperform the existing technology along a dimension that a new user demographic cares about, but that most existing users don’t care about. That’s how Instagram was able to gain traction in spite of Facebook, and Snapchat was able to gain traction in spite of Instagram. For Handshake, it can beat existing DNS along the dimensions of security and censorship resistance, which I think might be enough to give it a foothold to grow. But we shall see...
Author of the post here. The r/netsec community brings up good points. One thing that's come up frequently is the question of trademark disputes. Handshake does have mechanisms in place to protect a good number of existing trademarks (only the domain owners of the top 100k Alexa domains can register their names as TLDs), and it also has mechanisms to prevent early squatting through the 52 week period for name rollouts.
These mechanics protect trademarks in the short term, but in the long term anyone can bid on an unregistered name in the open auction system that Handshake created. My perspective on this is that there isn't an inherent reason why a naming system needs to deal with trademark issues — there are pros and cons to names being registered in an open auction, just like there are pros and cons to Bitcoin being a store of value that's difficult to censor and seize.
There are very good public safety reasons to allow lifting domains from their current owners. Like if someone owns Microsift and puts a phishing page on it.
This doesn't completely solve the problem, but the top 100k domains on Alexa will be reserved for those domain owners (ex microsoft.com can claim microsoft, google.com Google, etc).
No company in its right mind is going to trust its brand to this.
Megacorps want an administrative solution--a clear target they can throw money and lawyers at if something goes south--rather than blockchain, where a disgruntled employee can run off with the private key and hose the domains for perpetuity.
Author of the post here. I agree with you on this, at least in the early days. I don't expect any major company to switch to Handshake or even adopt Handshake. Realistically, adoption will happy in a bottoms-up fashion, starting with people in the jurisdictions that need it most. For instance, Spain shut down IPFS gateways when Catalonians used it to advertise the Catalan independence referendum. If the IPFS gateway was on Handshake, it would have been much more difficult to take down the gateways.
I find this trend of applications packing their own resolver concerning. If nothing else, it widens greatly the attack surface to name resolution. I also foresee mayhem with perimeter firewalls and stuff. It should be possible to block this at the OS level.
Mainstream OSs are slow to evolve. While I agree that embedded DNS resolvers in browsers and the like should have an off switch, I think embedding in widely adopted software is the only solution to push adoption of these new privacy-focused protocols.
Pushing updates to ever-green browsers is the key to change how millions of people use their computer - since browsing the web is almost all they do!
But how does this solve the problem of Trust on First Use?
Blockchains can safeguard the integrity of the data, but how do we know that painting in the real world corresponds to the token that purports to represent it? How do we know that business on Google really is that business and not a guy in their basement? How does Google or anyone really verify it, whether they are a top-down corporation or a blockchain or a decentralized project like OpenStreetMap?
Proof of Work solves that by preventing Sybil attacks - it's costly to mine (which is equivalent to signing off on, because it wouldn't make sense to sign an invalid block, you would get rewarded). It's the only signature scheme known to be dynamic and allow for an arbitrary participant size. The point is that you can trust the chain with the most proof of work. As long as you maintain a diverse set of peers and validate blocks, you can know the state of the network.
It doesn’t solve this problem at all. The site says:
How do you know that Google's public key is actually Google's public key? When you make that first request to Google, an intermediate network may have intercepted your request and returned a fake public key for Google. CAs attempt to solve this problem. CAs are trusted third parties that verify the authenticity of public keys for websites.
How does proof of work ensure that google.com really goes to Google and not someone who paid $2,000 to mine something?
A miner wouldn’t be able to do that. Only the private key owner of Google could do that. At most a miner could do a double spend attack (would cost a lot more than $2000), but that wouldn’t change the DNS record for Google.
The question is how do you know that the owner of the private key is the “owner of GOOGLE”. That’s what CA’s solve. Blockchain doesn’t solve this problem.
There is no way to do that via the blockchain itself. Theoretically, the community could hard fork Handshake to exclude certain names, but that’s unlikely as it’s antithetical to why the community would use Handshake in the first place. It’d be like if the Bitcoin community hardforked out certain addresses in Bitcoin...
In order to comply with US laws we need to verify people’s identity before they can buy/sell HNS, but fortunately it will be possible to register names without identify verification.
Blockchain solutions in real world work because of people's ability to form legally binding consortium made up of real business entities that have decided to cooperate with each other.
Crypto backed distributed trust that blockchain brings into such consortiums has no value other than superficial optics and hype novelty as of today. It doesn't solve any real problems that isn't already solved by legal mechanisms. To prove this, if you take away the legal mechanisms upon which the consortium is built, the consortium will fail and blockchain won't be able to hold it together.
For example, Bitcoin has value because masses trust they can convert it back to fiat currency via a coin exchange. Coin exchanges are real business legal entities that are subject to laws and regulations as they deal with fiat currency. For the masses, these laws and regulations are what confer that trust on those exchanges, not crypto.
It is best to think of bitcoin as a technical protocol but with very interesting properties, technical properties, and that has certain implications in real world – specifically w.r.t tampering and double spending or theft fraud. But this by itself has no real world value without the legal system backing its conversion to fiat currency. Without this relation to fiat currency, the technical properties are worthless on their own.
Similarly, handshake blockchain has no real world value unless a legally recognized consortium emerges to add value to it in real world.
Using bitcoin metaphor, instead of real world fiat currency it is real world names, trademarks that gets "converted" to digital names on this handshake blockchain that gives this blockchain any value. Once you have a trademark/realname "converted" on this blockchain, your ownership cannot be "stolen or double-spent" etc. That's the intrinsic crypto property of the blockchain which has some real-world value.
But this name "conversion" has to be done by "exchanges" which are real-world business entities to which laws can be applied.
Without this being baked into the system, this is dead on arrival.
Handshake is a blockchain protocol that aims to solve the issue of trusting hundreds of CAs. It's a protocol that's similar to Bitcoin, except instead of using coins as money, you use Handshake coins to register names on the Handshake blockchain. These names are top-level domains (TLDs) like .com, .org, .net. Handshake decentralizes the root zone file, which is the ICANN-controlled file that determines who owns what TLD. Anyone can register their own TLD on the Handshake blockchain.
We need some form of DNS decentralization not only for security but also to improve availability.
Sorry! I'd rather trust Mozilla than some craptocurrency/bullchain company trying to make money out of everything. I don't want to be dealing with speculators and people after the get-rich-quick scheme masqueraded as a "change everything and solve all your problems" solution!
Could certainly happen, but there's a couple mechanisms that mitigate this:
1) The network will only allow you to bid on a name if it has been at least `hash(name) % 52` weeks after mainnet launch. Squatters cannot purchase all of the good names on day 1.
2) The network limits the total number of domain renewals that can occur each block. Eventually this will lead to fee pressure and make renewing 10,000s of domains expensive for squatters.
3) It's possible to atomically trade names for coins on-chain, so squatters that self-custody will likely do this to make selling their names easier. The names will end up with someone that actually uses it
isn't dns already decentralised? (apart form everyone basically using the same server(s) / google ?) you can just set up your own dns if you want to have your own mappings of ip->dn and vice versa. just set your dns to the server you prefer?
A non-profit (ICANN) is the administrator of the DNS root zone. ICANN's model uses a multi-stakeholder model, so registrars, ccTLD holders (i.e. governments) all can contribute, but ICANN claims their board has ultimate decision.
The actual zonefile is hosted by a group of volunteer organizations. The variety, and the use of anycast means that the root zone is fairly stable and as reliable as any other distributed system (i.e. cloud). You can even download the root zone and run it locally if you want.
Handshake is interesting, but it conflates DNS and the CA ecosystem. They are different and used for different things. Most of the big issues around DNS isn't about the protocol, but the policies and legal issues around domain names and their ownership.
this does not stop one from having their own dns server and resolving what they like. the protocol itself has no owner, just a specified way of functioning. one can choose what dns server to use, and how to configure that to respond.
building some sort of overlay network on top of the internet has been done before (.onion anyone?).
How would this improve upon such a scheme for example? I really don't think it adds anything but the word 'blockchain' to the equation, and i honestly don't think that adds anything in the way of security.
additionally, to revoke ones domain name to say, resolve to another host, changing hosting provider for example, would seem impossible in an immutable blockchain. Would that result in forks or in namespace pollution?
Handshake is currently in testnet and the auctions last a few days, but on mainnet the auctions last ~2 weeks. Names are open for bidding for the first 5 days, and then the next 10 days are for bids to be revealed.
Imagine IPv6, but if it was somehow designed to squat on top of the IPv4 namespace, so that switching to IPv6 would cause existing addresses to start pointing somewhere else. That's pretty much the situation Handshake has chosen to be in.
Not to mention that allocating TLDs
- confuses non-technical users ("what do you mean, there's no dot in the address?")
- conflicts with the choice of most browsers to unify the address and search bar (if I type refrigerators and press enter, I want a search results page, not the homepage of whoever registered the TLD 'refrigerators')
- may conflict with other non-standard domain name systems, including special-purpose TLDs like .onion – though they've at least reserved the existing ones, so it would only be a problem for not-yet-developed systems
It's strange, because I want to support decentralized name systems, and Handshake seems better designed than some of the previous attempts, but that one decision makes it seemingly guaranteed to fail.