I work at Namebase.The other comments address most of your questions, but just to add on: the 52 week rollout will help significantly with preventing squatters. Handshake has designed some other mechanisms that prevent squatting. The first is that the Alexa top 100k domains have been pre-registered (only facebook.com can register .facebook on Handshake). This ensures that existing domain stakeholders can transition to Handshake without worrying about their name being squatted on.

Second, Handshake is airdropping 70% of the mainnet coins to open-source developers. If you have over 15 followers on GitHub, you can claim around $400-800 of Handshake coins (HNS) with no strings attached. Not only will this give developers an incentive to check Handshake out, but also this ensures that the bidding power is spread out at launch. Without this mechanism, a whale could spend $10mm on HNS at launch and outbid everyone.

Is there a way to be included if we have fewer than 15 followers? I've open sourced some personal projects, and I'm interested in claiming my domain (already did this on ENS), but after visiting handshake.org I did not see a way to participate without being included in the automated airdrop. Thanks!

> If you have over 15 followers on GitHub, you can claim around $400-800 of Handshake coins (HNS) with no strings attached.

How will one go about this? I'm interested, if only for the purpose of claiming a few domains that I have a personal interest in.

Go to https://handshake.org/ and click the top link under Developer Airdrop.

You can use https://github.com/handshake-org/hs-airdrop to claim your coins on the testnet. You’ll have to repeat the process once the mainnet launches.

If you want an easier way to claim and use your coins I can also add you to our private beta for Namebase.io. Just ping me at tieshun at namebase.io.

There was a post on HN about a year ago announcing Handshake, with an option to signup for the airdrop with your github account, irc account, etc.

Do you know if these users will still receive the tokens they signed up for? Should these tokens show up on testnet?

You should have received a seed phrase as part of that airdrop. You'll be able to use that seed phrase to claim your tokens on the testnet and mainnet. Ping me at tieshun at namebase.io if you want to try things out on testnet — I'm happy to walk you through it.

Hey! So, I thought this was cool and wanted to try it out.

Compiled hnsd and tried to run it on local machine and an ec2 spot instance but it keeps failing to connect to it's (hardcoded?) peers.

I keep seeing this,

peer 354 (172.104.177.177:13038): failed connecting: connection refused peer 354 (172.104.177.177:13038): closing peer peer 354 (172.104.177.177:13038): closed peer peer 355 (139.162.183.168:13038): failed connecting: connection refused peer 355 (139.162.183.168:13038): closing peer peer 355 (139.162.183.168:13038): closed peer peer 353 (172.104.214.189:13038): failed connecting: connection refused peer 353 (172.104.214.189:13038): closing peer peer 353 (172.104.214.189:13038): closed peer peer 352 (173.255.209.126:13038): failed connecting: connection refused peer 352 (173.255.209.126:13038): closing peer peer 352 (173.255.209.126:13038): closed peer peer 357 (172.104.177.177:13038): failed connecting: connection refused peer 357 (172.104.177.177:13038): closing peer peer 357 (172.104.177.177:13038): closed peer peer 359 (139.162.183.168:13038): failed connecting: connection refused peer 359 (139.162.183.168:13038): closing peer peer 359 (139.162.183.168:13038): closed peer peer 358 (172.104.214.189:13038): failed connecting: connection refused peer 358 (172.104.214.189:13038): closing peer peer 358 (172.104.214.189:13038): closed peer peer 356 (173.255.209.126:13038): failed connecting: connection refused peer 356 (173.255.209.126:13038): closing peer peer 356 (173.255.209.126:13038): closed peer peer 363 (172.104.177.177:13038): failed connecting: connection refused peer 363 (172.104.177.177:13038): closing peer peer 363 (172.104.177.177:13038): closed peer peer 361 (139.162.183.168:13038): failed connecting: connection refused peer 361 (139.162.183.168:13038): closing peer peer 361 (139.162.183.168:13038): closed peer peer 362 (172.104.214.189:13038): failed connecting: connection refused peer 362 (172.104.214.189:13038): closing peer peer 362 (172.104.214.189:13038): closed peer peer 360 (173.255.209.126:13038): failed connecting: connection refused peer 360 (173.255.209.126:13038): closing peer peer 360 (173.255.209.126:13038): closed peer

Also, These IP address are either blocking ICMP ping messages or outright unreachable because ping fails to talk to them.

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

https://hnscan.com/peers

502 Bad Gateway

I tried it right after he suggested doing that.

Try this command, It contains a list of peers that were working few hours back. Maybe they are still online.

  ./hnsd -r 127.0.0.1:53  -s ajgkxfe47u6wwyvyh7qixbdddvjxcqbs2oxwr5attq45yj72s5pcs@54.201.46.33:13038,akudgzg2wntfjucsodyvz44h76qae7xrtuix6wc6fc22cx5jll6fe@165.227.52.206:13038,ajaqq7jwqrwixmvl64tzi3qfi7ynj3hmmtzmkyubtrljh4mwmh7ie@165.22.151.242:13038,ap77bve4acntajehkvqc33bvlsi27ka6l2xte4fhn2ghuwx44fsxc@18.236.58.201:13038

- Handshake TLDs need to be renewed every two years or the names go back up for auction. Renewals must include a recent block hash to prove that the name owner is still active and has _recently_ signed the renewal transaction.

- Yes, names are rolled out over 52 weeks based on the hash of the name (modulo 52), which was designed to prevent squatting. The auction & renewals processes should help as well.

- Yes, Handshake uses proof-of-work. It's a different algorithm (Blake2b keyed with KMAC256) than Bitcoin but still essentially relies on energy consumption for security.

- I'm not aware of any other major integrations. But it is easy for users to run their OWN local light client and use it as the DNS resolver for their OS: https://github.com/handshake-org/hnsd

> Handshake TLDs need to be renewed every two years or the names go back up for auction. Renewals must include a recent block hash to prove that the name owner is still active and has _recently_ signed the renewal transaction.

Can't this just be automated?

Yes! Another comment mentioned that you’ll need to keep keys online to do this, which is not completely true. You can also create a key that can only be used renew your names that’s separate from your master key.

Yes but you risk keeping keys online

> - If I buy a TLD, will I own it in perpetuity, even after I die?

No, if you don't send a renewal transaction, the name goes up for auction again.

> - Is this going to have the same environmental problems as Bitcoin, or will having fewer transactions mean that's less of an issue?

Yes, it's proof of work

> I'm not necessarily feeling great about the idea of having separate TLDs for every site

TLD owners manage the namespace as they see fit. that includes issuing/selling/giving away sub-domains. <subdomain>.<TLD namespace>

I have only skimmed the whitepaper, but I did not notice any mention of handling of the loss of the private key.

Sooner or later, any servers get hacked, and attackers can get the private data stored there. If this happens, is there any way to recover the TLD? Or are we going to end up with a network where many names point to ransomware pages?

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.

There’s a mechanism that prevents this. If your key is stolen you can submit a transaction that opens your key for public auction again, so an attacker would have to outbid you in the auction to win the name. This will prevent most ransom attacks.