Live data from Hacker News

Decentralized Naming and Certificate Authority

handshake.org

31–40 of 128 posts

Re: Decentralized Naming and Certificate Authority

#31
post #7

They've somehow managed to make the two least optimal choices of language possible. The full node daemon, hsd, is written in Javascript. A non type safe language with poor package management for consensus critical code. We also have a light client, hnsd, which is written in C A non memory safe and error prone language for client code people would run on their systems as root.

[deleted]

Re: Decentralized Naming and Certificate Authority

#32
Great, what the world really needs is a hideously inefficient set of distributed DNS servers that are permanently eating 100% CPU to do their proof-of-work blockchain mining crap. The page hand-waves this away by claiming (with no good reason) that it will all be renewable energy. Just like bitcoin in China, right?

Re: Decentralized Naming and Certificate Authority

#33

I know the handshake devs/maintainers are active on here. I've heard explanations from y'all about how handshake tries to solve the squatter problem. As far as I understand those explanations: - Names are released at a trickle, meaning no one can buy all of them in one go. - Names have to be constantly renewed (it's not a buy-once-keep-forever scheme), and (correct me if I'm wrong), you can't buy 10 years out in adva…

> 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

Re: Decentralized Naming and Certificate Authority

#34
post #17

Does putting self-signed certs on a blockchain really solve the problem?

Everyone can put self-signed cert on a blockchain. You need to prove that you control the domain. Easiest way to prove that is to ask your registrar. And if your registrar will sign this fact you don't even need to ask him. So you naturally will come to DNS and DNSSec. And all standards are already here: deploy DNSSec, put TLSA record and it's done. It's a solved problem, just not widely supported.

"prove that you control the domain"? isn't that the rub? sounds a bit circular to me at least. there doesn't seem to be any solid replacement for the existing centralized trust authorities. what am i missing?

Re: Decentralized Naming and Certificate Authority

#35
post #7

They've somehow managed to make the two least optimal choices of language possible. The full node daemon, hsd, is written in Javascript. A non type safe language with poor package management for consensus critical code. We also have a light client, hnsd, which is written in C A non memory safe and error prone language for client code people would run on their systems as root.

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.

Better the cannot open shared object file: No such file or directory you know than the left-pad you don't.

Re: Decentralized Naming and Certificate Authority

#36
I am actually curious because I don't fully understand how Handshake works... I believe it allows you to setup a K of N threshold signature scheme for changing DNS, which, is kinda cool, but I don't understand if this would help BGP route hijacking.

Edit: I guess this is a replacement for ICANN not the inter-carrier routing protocols, which is, interesting. Is the point here that if DNS authorities switch to Handshake for authoritative DNS it will be harder to hijack routes? I would love an explanation, sorry it I'm being dense!!

Re: Decentralized Naming and Certificate Authority

#37
Decentralized systems generally have pretty complicated governance models and technology to support them, making it easy to get lost in the details. I've found when trying to assess things like this it's best to find a critical question and find out the details of the answer. For the case of decentralized naming, one interesting question tends to be "What happens when someone registers cocacola.com?"

Usually the answer to that question reveals whether the system is A) not in fact decentralized, or B) not compatible with laws in most jurisdictions.

Anyway, not necessarily a specific critique of this system since I don't know the answer to the question in this case. More just a useful framework I've found to assess distributed systems without getting mired in execution details.

Re: Decentralized Naming and Certificate Authority

#38

I am actually curious because I don't fully understand how Handshake works... I believe it allows you to setup a K of N threshold signature scheme for changing DNS, which, is kinda cool, but I don't understand if this would help BGP route hijacking. Edit: I guess this is a replacement for ICANN not the inter-carrier routing protocols, which is, interesting. Is the point here that if DNS authorities switch to Handshak…

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.

Re: Decentralized Naming and Certificate Authority

#39

I know the handshake devs/maintainers are active on here. I've heard explanations from y'all about how handshake tries to solve the squatter problem. As far as I understand those explanations: - Names are released at a trickle, meaning no one can buy all of them in one go. - Names have to be constantly renewed (it's not a buy-once-keep-forever scheme), and (correct me if I'm wrong), you can't buy 10 years out in adva…

- Names are released over the course of 52 weeks. Determined by hash(name) % 52. So at worst the name you want to register will not be available until ~51 weeks from now (Handshake launched last week!). - Names have to be renewed bi-annually. You don't need to pay a fee, you just need to submit a transaction to prove you still have access to the private key. I don't think this will be any different than the existing…

If I'm understanding you, the 52 week release is a one time thing, not a continual thing? So it's not that names will be continually trickle-released it's that for the next 52 (51) weeks, they'll be trickle-released, and then everything will be out there and this will work just like normal domain registration? I was under the impression that the trickle release was just how registration would work in general.

That doesn't seem to me at first glance like it's going to be that much of an improvement over squatting, but again, I get that there are multiple goals here worth accomplishing. And it is a much simpler system than needing to go into a queue to register a domain.

Just to make sure I understand -- am I correct in saying that Handshake is not designed to solve domain name scarcity, more to decentralize it so that an organization like ICANN can't rent-seek on top of that scarcity?

Re: Decentralized Naming and Certificate Authority

#40

Decentralized systems generally have pretty complicated governance models and technology to support them, making it easy to get lost in the details. I've found when trying to assess things like this it's best to find a critical question and find out the details of the answer. For the case of decentralized naming, one interesting question tends to be "What happens when someone registers cocacola.com?" Usually the answ…

All the existing TLDs like .com and .net are blacklisted so that only the TLD owners can register them. The claiming process for blacklisted TLDs uses DNSSEC so there are no third parties involved in the process. In addition, the top 100k Alexa domains are pre-registered so that only the domain owners can register those domains as TLDs (only google.com can register .google). That is done through DNSSEC as well.
Post reply on HN