7 ms·

The article and Namebase faq go into some details, but just so I understand, what are the practical effects of this beyond decentralization? - If I buy a TLD,

The article and Namebase faq go into some details, but just so I understand, what are the practical effects of this beyond decentralization? - If I buy a TLD, will I own it in perpetuity, even after I die? - If we're encouraging people to register their own TLDs, won't we run into the same limited-name/squatter problems as normal domains? I get that names are being released at a trickle, but that seems like it would just put off the problem a bit. - Is this going to have the same environmental problems as Bitcoin, or will having fewer transactions mean that's less of an issue? - Is Brave the only browser looking into this, or are we also seeing buy-in from browsers like Firefox and Chrome? I'll read through whitepaper and learn the details, but if possible I'd like to know if it's worth my time to do so. I'm not necessarily feeling great about the idea of having separate TLDs for every site, but I'll admit there is something attractive about being able to register 1 TLD as a namespace, one time, and then using subdomains for every other site I ever make. It's just not clear to me how that system would scale.

crediblewitness 7y ago
> - 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>
pinhead26 7y ago
- 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 https://github.com/handshake-org/hnsd
- oauea 7y ago
  > 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?
  - tynes 7y ago
    Yes but you risk keeping keys online
  - troquerre 7y ago
    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.
troquerre 7y ago
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.
- ishanjain28 7y ago
  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.
theamk 7y ago
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?
- tynes 7y ago
  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.
- troquerre 7y ago
  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.

crediblewitness 7y ago

> - 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>

pinhead26 7y ago

- 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 https://github.com/handshake-org/hnsd

oauea 7y ago
> 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?
- tynes 7y ago
  Yes but you risk keeping keys online
- troquerre 7y ago
  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.

troquerre 7y ago

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.

ishanjain28 7y ago
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.

theamk 7y ago

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?

tynes 7y ago
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.
troquerre 7y ago
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.