tynes

Solving #1 is interesting because it would also be useful if you didn't care to use a Handshake name and also didn't want to depend on the traditional CA system. It could save the need to for companies to ever install a certificate on their employee's machines along with coordination around updating the certificate.

Handshake is very different than Namecoin. Its possible to come to this conclusion by doing any amount of research. Please consider thinking before speaking in tribalism. There is no good trustless sidechain technology. Sovereign names can exist in parallel to sovereign money and both can benefit from each other.

Also HNS is a coin, not a token.

In blockchains, there is a difference between consensus and policy. The way that the Handshake recursive resolver works is not based on consensus. This means that people can insert rules for delegating a particular request to ICANN or to the Handshake authoritative resolver. It currently checks the Handshake authoritative resolver first, then falls back to ICANN.

If this behavior is easily configurable/shared and open source, then people can opt into whatever configuration that best suites their needs.

I think ENS is queried more often in a different context than DNS, since many people access it via JSON RPC over HTTP. The interface is an Ethereum contract, although records could be cached in a DNS server if the server can hit an Ethereum node upstream. The two projects feel pretty different for that reason. Handshake could be accessed over DoH potentially.

> If names have to be renewed on a year-by-year basis, is there any mechanism for archival? Won't this be strictly worse for link rot?

Blockchains are good for timestamping. The records on chain can be tracked over time but this doesn't solve the problem of when the blockchain authoritative name server delegates to the tld's authoritative name server. Maybe the tld nameserver could index the records in a git like data structure and be able to serve queries with a time parameter

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.

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.

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

There is also a C light client here: https://github.com/handshake-org/hnsd

For the consensus, there are C bindings for the cryptography and a workerpool that really speeds things up.

It could also be possible to dump the Handshake zone into a zone file and serve from behind unbound.

Yes but you risk keeping keys online

Handshake is for top level domains. You can do quick updates using traditional DNS infrastructure at a domain underneath a Handshake top level domain. The benefit is that you have a cryptographic asset representing the top level domain, the root of trust comes from you, value can accrue in the asset itself, its tradable with non interactive atomic swaps and is censorship resistant.

To update DNS records, you need to submit a valid transaction to the network. People generally do not keep their keys connected to the internet to prevent this type of problem. It is possible to use Bitcoin Script to describe policies regarding updating the DNS records, ie a 2 of 3 multisig to update.

Unfortunately the seeder peers aren't up right now, see here for a fresh peers list

https://hnscan.com/peers

The way the the ENS integration would work is the DNS request for vitalik.eth would end up at a Handshake Authoritative Name Server and then there are certain blacklisted top level domains (.onion, .tor, .i2p, .bit and a few others) where a client for that protocol is instantiated and then a request is sent out to the appropriate system and then the response would be formatted into a DNS query by the Handshake Name Server and sent back to the client.

Not implemented yet, but this is where one would implement it https://github.com/handshake-org/hsd/blob/master/lib/dns/ser... https://github.com/handshake-org/hnsd/blob/master/src/ns.c#L...

Satoshi Labs should consider a donation :) Since Trezor devices now support many coins, I'm sure that there is a much higher demand for the devices. If you are a purist, please update trezor-connect so that it doesn't rely on a Bitcore instance that you manage

If you have any interest in participating in the community, please visit https://handshake.community

Human intervention is important to the proper functioning of blockchain protocols. It's a myth that blockchains can just operate in a completely objective way without people. The point is to minimize the amount that people need to interject, so that people can instead focus on a higher abstraction

User experience around key management is poor. I agree that it needs to be improved, Handshake supports the industry standard HD Key Derivation following bip44 and has Ledger Nano support. The keys can be derived deterministically from a mnemonic, so it's up to the org to not lose that mnemonic. Eventually (if blockchain actually works) there will be an easy to use protocol for breaking the mnemonic up into shares and allowing recovery of the mnemonic using m of n shares.

In the case where keys are lost, there are 2 options

1) Let the domain expire after 1 year, there is a protocol rule in which the domain must be updated and without the private key it would be impossible to update it, and then rebuy it

or

2) Gain support from the community and fork the protocol such that the domain is reassigned to a different private key

There is a process for trademark dispute resolution, it's been going on for awhile now. The Alexa Top 100k domains are reserved and can be claimed using a DNSSEC Proof, so dot google on Handshake can be claimed by the owner of google dot com

The root of trust comes from the accumulated proof of work instead of an organization. This is interesting because self signed certificates can be trustworthy if they are signed with the private key of the Handshake top level domain holder. I believe it will open up the chain of trust for devs to innovate on and experiment with novel cryptography

Handshake (handshake.org) provides an SPV Proof that the DNS records held in it's zone are authentic. This means if an attacker wanted to spoof records, they would have to:

1) Eclipse attack the client, meaning that the client is on a partitioned network with an alternative chain tip. This grows more expensive as the records were written further in the past

or

2) Steal the top level domain owners private key and update the database

I wish IBM could turn itself around

I know of multiple bootcamp grads that currently work at Google. It is a thing