pinhead26

Ah hello 2015, my old friend.

DNSSEC is a Government-Controlled PKI -> Not if the root of trust is secured by a proof-of-work blockchain

DNSSEC is Cryptographically Weak -> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605

DNSSEC is Unsafe -> NSEC3 is mentioned by the article itself

DNSSEC is Expensive To Deploy -> We can make tools for this, so much has gotten easier already

DNSSEC is Incomplete -> Agreed, we need browser adoption

The Goosig (extra blinding crpyto) is also optional. With the --bare flag, its just a signature.

You don't have to, it works by signing a message with your PGP or SSH key. All GitHub users' public keys are already available from their API, that's how the airdrop works.

There is currently no such thing as a decentralized side chain. No one wants all this data on Bitcoin.

It doesn't address BGP, just DNS. You are correct about the signature scheme though. In fact, names are owned by unspent transaction outputs, exactly like Bitcoin. Meaning you can own a name with whatever weird script you want (2 of 3 before a certain date, 4 of 5 after...) you can even add scripts that allow certain keys to update a DNS resource, but a different key to transfer the name.

I'd say it extends more than overlap: If a name is not found on the Handshake chain, the resolver "falls back" to legacy ICANN DNS. Since all current gTLDs are reserved as well as the top 100k, there won't be any overlap for a while.

The project raised $10M and then gave 100% of it away to open source projects. They receive some HNS tokens in return. There is a massive airdrop of coins to hundreds of thousands of guthub users, spreading out the money supply to people who might be the most interested in using the system. In other words, this is the least ICO-y new blockchain in a decade.

Names roll out over 52 weeks: HashName(name) % 52 = week number that a name is available. So that should attenuate squatting. Also bidding on names locks up coins for something like 2 weeks, so it's hard to bid on too many names.

Well at least you don't have to worry about package management, all the dependencies are built by the organization either from scratch or with vendored code.

Re: JavaScript, you should take a look at the code in repo, it's excellent. There is a such thing as great Javascript code and bcoin/hsd are prime examples.

Not really, the DNS data is stored in a new data structure called an "Urkel Tree" that offers small proofs and fast lookup times. Full nodes (that archive and process the entire blockchain) can serve these proofs to light clients that use the data to recursively resolve DNS.

Well you don't need to mine the coin to use the DNS system. You can obtain tokens some other way (an exchange) and buy a name on chain.

- 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