
Handshake: An experimental peer-to-peer root DNS - noeatnosleep
https://handshake.org
======
gruez
Technical merits aside...

Why was this done as an alternate root project rather than an alternate tld? I
get it makes the project more useful (ability to register .johnsmith rather
than johnsmith.bit), but it's going to severely increase complications when
interoperating with the ICANN dns root.

what happens if you register .foobar on handshake, and then a few years later,
ICANN delegates .foorbar? If you let the ICANN registration take precedence,
all the .foobar domain owners on handshake side will lose their registrations.
The threat of that will keep most people from using tlds registered on
handshake. Why buy a domain on .foobar (handshake root) rather than .foobaz
(ICANN root)? It might cost a few bucks more, but honestly I'd be willing to
pay a few dollars/year more knowing my domain is secure.

Of course, it's possible that operator of the ICANN tld would give an
opportunity for the domain owners on the handshake side to migrate over, but
then they'd miss out on all the revenue on those premium domains. why allow
the old owners of pizza.foobar keep their domain when you can resell it for
$$$?

The project mentions that they have pre-reserved certain TLDs, but all that
does is delay the inevitable. The first conflicts are going to be with yet-to-
be-delegated gTLDs, since they're not in the current root (obviously), and
they're not in the alexa 100k (while they're some sites with generic words as
domains, most of them are squatted, which means they're probably not in the
alexa 100k).

The only hope of this project surviving is if they gain critical mass and
overtake ICANN as the most popular root. The network effect is insane with DNS
(maybe even higher than with social networks), so unless there's a good reason
for _everyone_ to use this, I think this project will stay very niche.

~~~
nine_k
This is a great objection. I nevertheless fail to see why making it a TLD
would help any.

A particular TLD (.bit) would clash with ICANN the same, unless someone would
keep shelling $185k/y for keeping it up. This does not look very realistic.
Registering a TLD is the only official way to interact with ICANN in this
area, and I don't see ICANN making any concessions to an outright competitor.
Even if registered, such a domain would make little sense: now every Handshake
user would depend on ICANN again, hoping it will not hand the TLD to some
other registrar (e.g. due to a failure to pay the yearly $185k). This sort of
defeats one of the purposes of the project.

Not having a single traditional TLD at the end does have upsides. Any name
with a long TLD immediately stands out as a Handshake name. Any reasonable
person would register a domain very unlikely to clash with ICANN's TLDs. The
lack of need to belong to a handful of TLDs allows to e.g. use dashes instead
of dots, lowering the chance of a conflict: not joe.crypto.exchange but joe-
crypto-exchange. (Of course people who want to squat short common words likely
to be made TLDs by ICANN may do it at their own peril.)

Explicitly being at odds with ICANN forces the project to handle this
outright, add a conflict-resolution policy applied at the client side: on a
conflict, prefer which source at which domain? How to indicate a conflict
anyway? There are no one-size-fits-all solutions here, but reasonable
solutions should exist.

In general, I think the technical merits outweigh the risk of name clashes
significantly for almost any reasonable user. (Unreasonable users will always
exist; they should not be paid too much attention.)

~~~
tialaramex
Tor doesn't pay ICANN $185k per year for .onion

A single TLD could reasonably be added to IANA's registry of special suffixes,
since it wouldn't be part of the DNS hierarchy that ICANN is responsible for
they'd have no claim on $185k or any other amount of money.

But a parallel hierarchy is never going to get that, so basically this choice
ensures an up-hill battle, presumably mostly so that like other parallel
hierarchies its proponents can make hollow claims about "owning" names that
actually are meaningless, it's like buying land claims on Mars.

------
BluSyn
Compared to other crypto projects, what really excites me is there is already
a fully functioning testnet, SPV resolver, and C bindings available on day of
announcement!

Main-net launch only 1 month away.

Other crypto projects should take note. This is how to prove you're serious.

~~~
crypt1d
This argument could have been valid 2 years ago, but now there are plenty
crypto projects in both testnet and mainnet phases.

~~~
wmf
On a percentage basis, I would bet fewer crypto projects have working code now
than two years ago. There are plenty of legit projects... and a huge flood of
other stuff.

------
prepend
This seems like a neat idea but the economics are that of a for profit
business, and I think we learned that handing domains to a for profit
(NetworkSolutions) was a bad idea.

7% going to contributors and 7% going to financial backers is a pretty big
incentive. [0]

I’d rather see this set up as a non profit foundation or a community driven
trust and run in an OSS way for the financial elements. As it is, I don’t
think we should create a decentralized network with such significant financial
incentives.

[0] [https://handshake.org/how-it-works](https://handshake.org/how-it-works)

~~~
glitch003
Interesting. I suppose it's only a matter of time until someone forks it and
changes or lowers those incentives?

But they will have to re-build the user base and since handshake.org is
literally giving away $10m to build it's user base, it might be difficult.

~~~
prepend
I think registries like this are hard to fork because there is so much buy-in
required from a critical mass of users for any change.

I think we are better off with some sort of community consensus protocol and
the only benefit of giving away “$10m” is to gain even more money for the
developers. Standards should be open or driven by a commodity cost model, not
a “inventor gets rich” model. Their plan accounts for plans when the chain
value is over $50B. That is unlikely, but it means there’s a model in the
developers plans where $7B in value is held by the developers and investors.

DNS and other Internet standards never would have succeeded using compensation
models like this. I can’t think of any RFCs that would have such payouts for
the main contributors.

------
bloopernova
This definitely looks interesting!

(I hope a project contributor is reading/commenting)

Q: Let's say I'm a representative of a company that wants to buy their name
"example.com" to be resolved via Handshake. Assuming things are live and
running well, what's the process by which we'd get www.example.com resolving
to 123.123.123.123? (keeping it simple, not worrying about mx and srv records
yet) How stable and safe is our record, assuming we owned the trademark for
example.com?

~~~
BluSyn
This provides a replacement for the root zone and not does not directly
include subdomains. In DNS terms this is like registering a TLD. So if you own
"companyx.com" domain, you could register "companyx" on handshake. Once you
own this domain you can use your private key associated to set your name
servers / other DNS settings, so subdomains could fallback to using existing
DNS resolution, or this could resolve directly to a website.

With your private key you can also do interesting things like verify your
subdomains with signatures ala DNSSEC or verify your own SSL certs without
CAs.

The paper also mentions future improvements that could see each TLD using a
side-chain (like plasma) to manage and possibly sell their own subdomains.
This could also give each TLD owner more control over their own "consensus
rules" for their particular TLD.

There are a lot more possibilities here, some are covered in the paper, many
more are still to be explored.

Super excited for this project!

~~~
iforgotpassword
I'm curious how this would work out at scale. Would everyone just get a long
descriptive TLD and then use that directly? While that would technically work
I imagine it would confuse people who are used to treat the address bar of the
browser primarily as the search box. So I'd enter "flowers" and expect a
Google search for flowers, but since the TLD flowers exists and resolves to
something you end up on some dude's blog. The alternative would be to use the
www subdomain, but apart from looking odd (www.flowers? Something my mom could
accidentally come up with, forgetting the .com - so maybe not that bad after
all...) since we're not used to that now, it also reverses the current trend
of dropping the www.

So of looks like this could also mean some changes in how we actually use the
web, not just how DNS is managed.

~~~
lugg
Chrome already handles this: if you want the domain enter in the protocol -
[https://](https://)

If you want to search leave it off.

On top of that Chrome already has the ability to redirect you straight to the
domain if it is well defined. I can't imagine it difficult to move that logic
to google redirects instead.

e.g. "test.vm" goes to a google search despite being url format. "test.dev"
goes to domain.

~~~
iforgotpassword
The point is not whether there is a technical solution to that or not.

"I'll prefix the domain with [https://](https://) so I will directly establish
a secure connection because leaving it out implicitly means plain http, which
makes me vulnerable to mitm attacks" \- nobody outside tech, ever

And it wouldn't be any different here. Over the last decade we've been so
focused on dumbing down tech enough so that it's accessible to pretty much
anyone on the planet. It will be very hard to reverse this trend. Even just
adding a trailing slash is cumbersome. I can only imagine how many million man
hours we'd have to waste worldwide to explain that to the average Joe and
their mom. Just remembering how many times I've seen people type a backslash
instead of a slash in URLs, this will be fun.

------
sdf43543t345
This is really cool! Rather than make the same mistake every other DNS tries,
they include the ICANN domains already. I ran the client and started resolving
hostnames against it immediately.

Its also mined, so give it a try!

~~~
_eht
Just mining testnet coins though right? I imaging you won't be able to use
what you mine now when they go live.

------
bribroder
How do you get coins if you're not an open source project? Is the idea that,
when the mainnet launches, private individuals and the for-profit sector will
buy coins from open source projects?

~~~
BluSyn
or you could mine your own

~~~
cryptobeanbaby
what happens when one of these large mining operations in China/South
pacific/etc target this network and begin accumulating all the handshake
"coins".

How would someone 3 years from now have access to generate coins/tokens after
the protocol increases the difficulty and stops generating coins so easily?

Wouldn't it be cheaper just to run a normal DNS server? What's the use case?

~~~
koolba
Even better, what happens when a mining operation decides to mount a 51%
attack and take over a root resolver? If I’m understanding the point of this
correctly (big if...), then they’d be able to route any TLD anywhere they’d
like. Combined with DNS caching for extended chaos.

~~~
jancsika
They wouldn't be able to _immediately_ route _any_ TLD anywhere they'd like,
but they could certainly screw with the network.

They would have to expend hashing power solving a previously solved block
puzzle while continuing to build the blockchain off their new branch and
ensure that its total difficulty is greater than any competing chain.

So suppose you immediately buy up TLD "foo", get a single confirmation on it,
and publish it to your fanbase. The 51% attacker would be able to a) use their
hashing power to publish their different solution to the block where your TLD
got included, b) include their own purchase of "foo" in their alternate block,
and c) continue building on their alternate chain to make it the canonical
state of the transaction db. So your fanbase would look for "foo" and get the
attacker's zone.

However, if we're five years into Handshake's existence and you hold one of
the very first TLDs published in their blockchain, the attacker cannot
immediately take over your TLD. They'd have to go back to the block where you
made your purchase (or I guess when you renewed) and solve puzzles all the way
up until the total difficulty of their chain exceeds the current canonical
chain. Which they can do with 51% given enough time.

Also note that an attacker can begin/develop a 51% attack without publishing
anything at all to the network.

~~~
tialaramex
> They wouldn't be able to immediately route any TLD anywhere they'd like

It seems to me that this can only be true if it's also impossible for the
legitimate owner to change this. If it can be changed, then the 51% attacker
can change it.

The actual DNS contains names with hugely long cache lifetimes and very little
practical agility, and it also contains "fast flux" names whose RRs change
constantly. If this experiment is only interested in the former it should
highlight that, as a shortcoming.

~~~
dboreham
I don't think anyone has a short TTL for a record in the root zone.

~~~
tialaramex
24 hours seems to be common for the TLDs I looked at. That seems fairly short
compared to this idea that a 51% attacker would need sustained capability to
do real damage.

------
hschoenburg
Whoah they have a fully functioning stub resolver that queries their testnet

------
mynewtb
How does this compare to namecoin?

~~~
imglorp
And how to avoid squatting?

People started buying up tons of obvious namecoin names while they were cheap,
as speculators.

~~~
_eht
Why is squatting a problem that needs to be solved? Serious question.

~~~
zrm
Because names are scarce and squatting produces inefficiency. Someone who
wants to make productive use of the name has to pay a middle man in order to
do it, which reduces their resources available to do the useful thing and
unjustly enriches the middle man who has provided nothing of value to anyone
compared to the situation where nobody registers the name until they have a
use for it. (Or, if multiple legitimate users want the same name at the
outset, compared to having an auction where money goes somewhere meritorious
like paying the cost of maintaining the naming system instead of to the jerk
with the fastest computer.)

Although one of the best ways to discourage squatting is to reduce scarcity.
Have hundreds of TLDs (.cars, .bank, .farm, .repair, .plumber, .housing,
etc.), or if you're not ICANN and don't want to pollute the global namespace
with multiple TLDs then second level domains (.cars.bit, bank.bit, etc.)

Then a squatter has to register hundreds of times as many names and each name
has hundreds of times fewer prospective buyers. Combine this with some nominal
cost ($10/year) to holding a name, irrelevant to normal users but prohibitive
to someone who wants to hold trillions of names hostage. And which you want to
have regardless to be able to reclaim names that have been abandoned.

------
xjia
How does it bootstrap its own P2P network? Resolve a name with a DNS to find
seed servers?

------
aw3c2
Why is money (coins) necessary for this?

~~~
cryptobeanbaby
Why is a Proof-of-Waste blockchain necessary for this?

We already have
[https://www.eff.org/observatory](https://www.eff.org/observatory), and anyone
can run a DNS server for free.

~~~
dboreham
"anyone" can not run a root zone server.

------
bogomipz
This project is really exciting.

If I could make a suggestion to the maintainers - I think it would be helpful
to put the "project paper" in an additional format besides just the text file.

The handksahake.org site is really easy on the eyes but I found reading
through a text file of this length quite a slog.

------
josh2600
This looks like a really cool premise. Decentralized signatures for certs
seems like a no-brainer solution to cert/DNS hijacking (maybe I'm missing
something?).

~~~
petra
Cool technical premise. Not the first implementation of the idea. My guess?
Business is hard.

~~~
bogomipz
What are the other implementation of the idea?

------
delphi86
Awesome project! Check out the website for more information.
[https://handshake.org/](https://handshake.org/)

------
kylegalbraith
This looks very interesting indeed. I would be interested in contributing, so
time to go read up on how I do that.

------
pandasun
They should partner with Let's Encrypt! This is great.

------
Avamander
Sounds interesting - how can I actually use it?

~~~
delphi86
You can use Handshake as your DNS resolver now: [https://handshake-
org.github.io/guides/mac-install.html](https://handshake-
org.github.io/guides/mac-install.html)

------
ebikelaw
Unclear in what way existing DNS and certificate attestation is not peer-to-
peer. DNS authority lies wherever you want it to lie, and root certificates
are yours to honor or ignore. I don't see what real material benefit this has.

------
jalcine
About damn time.

------
dang
We changed the url changed from [https://github.com/handshake-
org](https://github.com/handshake-org), to the project page, which points to
this and also provides more of an overview.

------
cryptobeanbaby
It looks like the dev team has already anticipated a SHA3 based ASIC design as
a threat to monopolize control over the Handshake protocol.

Guessing an insider on is hoping to exploit this for financial gain and
control of this isolated DNS pool.

and why would users want to participate in a protocol which inherently
relinquishes centralized accountability and responsibility, in favor of a
security model that allows any of these mining warehouse operations run by
anonymous robber barrons with enough excess capital to fill up an entire
building with random number generating electricity wasting heaters?

Who thinks this is seriously a good idea for anything other then exploiting
greater fools to sell digital beanie babies to?

