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.
Decentralized Naming and Certificate Authority
31–40 of 128 posts
Re: Decentralized Naming and Certificate Authority
#32Re: Decentralized Naming and Certificate Authority
#33I 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…
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
#34Does 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.
Re: Decentralized Naming and Certificate Authority
#35They'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.
Re: Decentralized Naming and Certificate Authority
#36Edit: 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
#37Usually 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
#38I 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…
Re: Decentralized Naming and Certificate Authority
#39I 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…
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
#40Decentralized 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…