[HN Gopher] Decentralized Naming and Certificate Authority
___________________________________________________________________
Decentralized Naming and Certificate Authority
Author : LinuxBender
Score : 183 points
Date : 2020-02-12 17:15 UTC (5 hours ago)
(HTM) web link (handshake.org)
(TXT) w3m dump (handshake.org)
| jspaetzel wrote:
| First impression: Great another ICO.
|
| Second impression: Not a wildly outlandish idea but im not sure
| if it's a good idea either. Decentralized and automated registrar
| with a concept of renewals. Nifty.
|
| I'm not really sure how the economics here work out.. Could I
| scoop up a few million names early on and then hold them forever?
| Has that already happened? Could this enable anonymous
| registration? Would these things make users trust these names
| more or less?
| pinhead26 wrote:
| 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.
| troquerre wrote:
| Handshake didn't do an ICO. They raised $10.2m from
| institutional investors like A16Z, Sequoia, Greylock, and
| Founders Fund, and then donated all the money they raised to
| non-profits and open-source projects. Here's a notice from the
| free software foundation when they received $1m from Handshake
| https://www.fsf.org/news/free-software-foundation-receives-1...
| jlgaddis wrote:
| Another:
|
| > _Handshake donates $300,000 USD to Debian_ [0]
|
| [0]: https://www.debian.org/News/2019/20190329
| Foxboron wrote:
| Arch Linux also received 300k USD. We didn't publish any
| news about this as this was a "no-strings attached"
| donation.
|
| You can however see it as part of the monthly SPI reports;
|
| http://spi-inc.org/treasurer/reports/201808/#index3h4
| rasengan wrote:
| Anyone participating in the GooSig airdrop [1] can technically
| register names anonymously as their keys will not be exposed in
| terms of having received the coins.
|
| Additionally, anyone who can obtain HNS anonymously can thus
| register anonymously.
|
| [1] https://github.com/handshake-org/goosig
| troquerre wrote:
| If you're trying to claim the airdrop, we created this
| resource to make it easy https://namebase.io/airdrop. It
| walks you through using https://github.com/handshake-org/hs-
| airdrop under the hood but it generates a wallet address for
| you automatically.
| RL_Quine wrote:
| 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.
| pinhead26 wrote:
| 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.
| RL_Quine wrote:
| I'm very aware of bcoin.
|
| https://npm.anvaka.com/#/view/2d/bcoin
|
| Many steps of indirection away we find things like this
| include.
|
| https://github.com/juliangruber/isarray/blob/master/index.js
| module.exports = Array.isArray || function (arr) {
| return toString.call(arr) == '[object Array]'; };
|
| Javascript is an absolute joke of a language.
| judge2020 wrote:
| Don't forget https://github.com/sindresorhus/number-is-
| nan/blob/master/in...
| chirss wrote:
| For real, it can't even work with regular expressions
| decently.
| Ajedi32 wrote:
| I don't really see the problem. On any remotely modern
| version of Node that's just a noop. On ancient versions of
| Node its a very useful polyfill.
| heartbeats wrote:
| Better the _cannot open shared object file: No such file or
| directory_ you know than the _left-pad_ you don 't.
| skilgarriff wrote:
| We have a Rust implementation in the works:
| https://github.com/UrkelLabs/rsd
|
| It's not a full node implementation _yet_ , but will be there
| soon!
| [deleted]
| lifty wrote:
| I hope more implementations will become available. It's a
| decent start, since the C based light client doesn't expose any
| services.
| RL_Quine wrote:
| You can't say that a C daemon interacting with a network has
| no attack surface, especially as the thing runs as root.
|
| It promiscuously makes outgoing TCP connections to an
| unauthenticated P2P network, so given enough time you'll
| eventually interact with an attacker if there is one.
| troquerre wrote:
| PSA if you had over 15 followers on GitHub by August 2018 you
| were likely included in the Handshake airdrop. Basically they
| developed a way to give each dev in the airdrop 4662 coins each
| (worth a lot since current market price is $0.50[1]). These
| instructions walk through what the claiming process is like,
| which can only be done after block 2016 in a day or so
| https://namebase.io/airdrop.
|
| [1] https://namebase.io
| the_snooze wrote:
| Looks like this is similar to Namecoin?
|
| https://www.cs.princeton.edu/~arvindn/publications/namespace...
| dang wrote:
| A thread from 2018: https://news.ycombinator.com/item?id=17673922
| jimmysong wrote:
| This has been tried. It's called Namecoin and it failed to get
| much traction.
|
| I suspect that using Bitcoin instead would improve adoption
| dramatically instead of creating yet another token. This can be
| done using sidechains or something similar.
| sdtsui wrote:
| Hey Jimmy - I hope the bitcoiners that eventually read this
| thread can get both sides, as many project teams have received
| some version of the "do it on bitcoin with
| sidechains/lightning/liquid/rsk" refrain. I think in practice
| it's more complicated than that.
|
| First - I tend to think an idea with clear similarities being
| tried before and failing is default a non-negative (sometimes
| good) sign: shows us what didn't work, and deepens everyone's
| understanding/validation of the problem space.
|
| I would also say that it's more similar to Bitcoin than most
| people would think. Looking at the software, I think it's
| pretty cool that handshake's first implementation is a fork of
| a bitcoin implementation that has seen production usage for
| years (bcoin), one important change is the addition of opcodes
| to support covenants, so that blinded vickery name auctions can
| be done fully on-chain.
|
| Basically, Handshake can build on top of the security and
| reliability that Bitcoin-like systems have validated for us
| over the last few years: namely, UTXO systems, proof of work,
| user knowledge/habits around self-custody.
|
| I think Bitcoiners could consider looking at Handshake from
| this perspective: there is a lot of core technology,
| architecture decisions, and spirit that is similar. Perhaps if
| you believe in the potential of public blockchains like many
| early Bitcoiners do, the solution might not be things like
| sidechains (which are mentioned as a potential scaling option
| in the design notes), but extending the core technology in a
| minimal, single-purpose way (to support auctions)?
|
| Perhaps it is possible that Handshake goes down as one of the
| best examples of an ambitious new project actually "using
| Bitcoin" (albeit in a way most Bitcoiners would not immediately
| agree with) instead of creating "yet another token"?
|
| ----
|
| p.s. I've been a fan of yours for years and your content was
| some of the first I ran into when I was entering crypto full-
| time. I guess at the end of the day I'm simply curious what you
| thought of the other projects so far (including Namecoin and
| ENS) - do you own any names on other decentralized naming
| systems?
|
| What do you think prevented Namecoin from getting sufficient
| traction from your perspective?
| rglullis wrote:
| ENS is running on top of ethereum just fine
| [deleted]
| tynes wrote:
| I think ENS is queried more often in a different context than
| DNS, since many people access it via JSON RPC over HTTP. The
| interface is an Ethereum contract, although records could be
| cached in a DNS server if the server can hit an Ethereum node
| upstream. The two projects feel pretty different for that
| reason. Handshake could be accessed over DoH potentially.
| pinhead26 wrote:
| There is currently no such thing as a decentralized side chain.
| No one wants all this data on Bitcoin.
| tynes wrote:
| Handshake is very different than Namecoin. Its possible to come
| to this conclusion by doing any amount of research. Please
| consider thinking before speaking in tribalism. There is no
| good trustless sidechain technology. Sovereign names can exist
| in parallel to sovereign money and both can benefit from each
| other.
|
| Also HNS is a coin, not a token.
| verdverm wrote:
| It is not the same as Namecoin.
|
| Handshake at it's core is a decentralized root zone of trust,
| the equivalent of ICANN. It's up to people building on it to
| create the registrars and such.
|
| Previous experiments were for one TLD like .bit or .eth
|
| With Handshake, every possible TLD is released over 52 weeks
|
| Even more so, it works with existing DNS infrastructure and
| tools. All it is doing is allowing for all TLDs and resolving
| them (with preference for ICANN / HNS) where the overlap
| occurs. It was built from the start to exist along side today's
| systems.
| heartbeats wrote:
| Namecoin will get added to Tor soon. I would definitely call
| that traction.
| michaelbuckbee wrote:
| Yeah, domain registration seemed like one of the few problems
| that potentially (lots and lots of handwaving around the
| details here) could actually have been a good fit for a
| blockchain solution.
|
| - It's all public - It doesn't change that often - It is a data
| storage issue (as compared to processing) - On a per record
| basis it's pretty small (as compared to trying to store PNGs in
| the blockchain)
| troquerre wrote:
| One of the issues with Namecoin is the issuance. You can
| register any name for a set price. This leads to easy squatting
| behavior and allows whales to buy up all the good names.
| Handshake built in mechanisms to improve the issuance of names
| (detailed in danShumway's comment) which is critical when
| you're working with the issuance of scarce, non-fungible
| assets. It's like drawing a comparison to bitcoin and bit gold.
| Both had the same idea, but the specifics matter.
| heartbeats wrote:
| It doesn't matter how you start with it. As per the Coase
| theorem[0], the following two are equivalent:
|
| 1. give names out by an arbitrary schedule (e.g. first-come-
| first-serve), then sell them to the highest bidder
|
| 2. give money out by an arbitrary schedule, and give the
| names to the highest bidder directly
|
| The only thing the distribution scheme can change is where
| the money ends up, as well as some fringe cases of
| economically irrational actors. In all likelihood, the
| distribution of the names will eventually be Pareto-optimal
| or close enough anyway.
|
| [0]: https://en.wikipedia.org/wiki/Coase_theorem
| mankyd wrote:
| > mail became Gmail, usenet became reddit, blog replies became
| facebook and Medium, pingbacks became twitter, squid became
| Cloudflare, even gnutella became The Pirate Bay. Centralization
| exists because there is a need to manage spam, griefing, and
| sockpuppet/sybil attacks.
|
| No, centralization exists because users don't care about the
| protocol. Users care about the brand.
|
| It's way easier to use FB than it is to say "choose your hosting
| provider. Each one has a slightly different set of features. Then
| link with other people you care about, all of whom may be using
| different providers that you need to pay special attention to."
| With FB, I click "send a friend request" and then move on with my
| day. And that's just one example.
| iamnothere wrote:
| > No, centralization exists because users don't care about the
| protocol. Users care about the brand.
|
| Brand is a proxy for the level of functionality delivered by
| that brand.
|
| People didn't switch to GMail because it was a "cool" brand,
| they switched because the spam filtering worked, Google gives
| you a ton of free space (a problem at the time), and it didn't
| have obtrusive banner ads. This was passed on by word of mouth,
| and now GMail is popular.
|
| > It's way easier to use FB than it is to say "choose your
| hosting provider. Each one has a slightly different set of
| features. Then link with other people you care about, all of
| whom may be using different providers that you need to pay
| special attention to." With FB, I click "send a friend request"
| and then move on with my day. And that's just one example.
|
| Exactly my point, the UX is better and the network effect
| ensures that many/most of your friends are already there. It's
| not about branding, it's about ease of use.
| mankyd wrote:
| > Brand is a proxy for the level of functionality delivered
| by that brand.
|
| 100% agreed.
|
| > People didn't switch to GMail because it was a "cool"
| brand,
|
| Less agreed on this. Brand is also a proxy for PR, marketing,
| and the general image of the company. Gmail had an awesome
| feature set - better than its competitors at the time, but
| also spread wildly by word of mouth. At that time, Google was
| an exciting company for most people (it still is by and
| large, but that's another discussion). Gmail's "invite-only"
| onboarding was done well and made it exclusive. FB did the
| same thing when they rolled out to one school at a time.
|
| Ultimately, I think we're on the same page. People want good
| UX; they want a product/company that their friends recommend;
| they want something that just works.
| unlinked_dll wrote:
| > People didn't switch to GMail because it was a "cool" brand
|
| In the early days of gmail when you needed an invite code, it
| _definitely_ was a status symbol to have that @gmail.com on
| your email address.
|
| And at the time, the actual functionality of gmail was far
| less significant than the fact it was free and decoupled from
| your internet provider, although you're right the storage
| capacity on a free email was unheard of at the time.
| viraptor wrote:
| Gmail invites were at some point a joke. Everyone had them
| and I wouldn't be able to give them out quickly enough.
| Maybe at the very beginning they were exclusive a bit, but
| soon anyone interested could post online and get an invite
| in minutes.
| Sohcahtoa82 wrote:
| > And at the time, the actual functionality of gmail was
| far less significant than the fact it was free and
| decoupled from your internet provider
|
| If that was the real draw, then people would have just
| stuck with Hotmail, Yahoo, and the dozen other e-mail
| providers.
| dependenttypes wrote:
| I really do not see the point. Naming not only is not important
| but it also causes issues with trust. I think that the solution
| that tor/i2p went with is much better.
| danShumway wrote:
| 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 advance.
|
| - A large portion of the initial names are reserved for Open
| Source developers, under the assumption that squatting won't be
| so much of a problem if they get first pick.
|
| It's still not clear to me how this solves resource scarcity.
|
| - If names are released at a trickle, does this mean I might want
| to register a domain for a project and there literally won't be
| any able available for me to choose from?
|
| - 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?
|
| - If names are released at a trickle, doesn't this create an even
| greater incentive for both good and bad actors to grab them as
| soon as they become available?
|
| I'm mildly interested in Handshake because based on very limited
| research it seems in general to be an improvement over what we
| have. I get that perfect is the enemy of the good, I would take
| almost any improvement over the existing system. But at the same
| time, I still just don't understand how this helps solve the
| squatter problem -- every once and a while I ask and get an
| explanation, and then think about it for a while and end up
| having more questions.
|
| My perspective is, we want everyone to be online. We want
| everyone to have their own blog, we want people to be able to
| create websites on impulse. And we want resilient, long-term
| links that can serve as permanent addresses for content. The idea
| of combating squatters is based on the assumption that domain
| names will continue to be a scarce resource. But you
| fundamentally _can 't_ have domains be a limited resource that
| are difficult to hoard if you also want random/poor elementary
| school kids to be able to buy them.
|
| Handshake talks about solving Zooko's triangle: human-meaningful,
| decentralized, or secure. But the way I originally heard Zooko's
| triangle explained to me (which may have been wrong) was: human-
| meaningful, secure, high-availability. Am I correct in assuming
| that in the second version, Handshake is optimized for human-
| meaningful and secure at the expense of high-availability? That
| domains will continue to be a limited, scarce resource that are
| susceptible to hoarding by people with lots of money? Or are
| there other mechanisms here that I don't understand?
| tynes wrote:
| > 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
| troquerre wrote:
| - 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 DNS in terms of
| link rot. - I think the main thing names being released over
| time does is it allows for more people to find out about
| Handshake and start competing for the good names before they're
| gone. In an ideal world, everyone would know about Handshake at
| the same time, and so any name that is registered has the
| maximum competition for it. That world is not feasible but we
| can get closer to it by releasing names over time. - I've only
| heard Zooko's triangle described in the first way, which
| matches the wikipedia article on it
| https://en.wikipedia.org/wiki/Zooko%27s_triangle
|
| Disclaimer: I'm the ceo of Namebase.io, we built a registrar
| for Handshake domains and exchange for Handshake coins (HNS),
| so I'm pretty bullish on Handshake.
| wtmt wrote:
| > 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.
|
| When talking about email alternatives here, I see a lot of
| comments strongly suggesting owning a custom domain and using
| it. If the domain cannot be renewed and kept alive in advance
| for a few years, the bus factor of being the only technical
| person in the family could mean that they lose their emails
| very soon (worst case scenario where something bad happens to
| the technical person towards the end of the bi-annual period
| just before the renewal).
|
| "You need to submit a transaction to prove you still have
| access to the private key" -- "transaction"? "prove"?
| "private key"? There's no way this is going to last if people
| use these domains for emails and mailboxes for their
| families. At least with the conventional system, it's easy to
| note down simple instructions to go to a site, pay and renew.
| This system seems better suited for institutions that may be
| able to handle it (though it could be argued that even large
| companies fail in trivial ways, like it happened with a
| certificate expiry with Microsoft recently).
| danShumway wrote:
| I'm not affiliated with Handshake in any way.
|
| But my assumption is that there would still be registrars
| that can handle this sort of thing for you, in the same way
| that a service like Netlify can handle setting up a static
| site server and renewing LetsEncrypt certificates. It's
| just that if you wanted to do it manually, you could.
| troquerre wrote:
| Exactly. We built a registrar for Handshake
| (https://namebase.io) and our service will automatically
| handle renewal transactions. That said, anyone can still
| manage their keys and submit renewal transactions on
| their own if they want to do that, similar to how you can
| use Coinbase vs a desktop wallet for Bitcoin.
| xoa wrote:
| > _- 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!)._
|
| Can you clarify on what "names" means here? Common names,
| dictionary, every single name that exists in current DNS? If
| someone has a unique non-word domain right now do they have
| to submit that? Wait a year?
|
| > _- 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 DNS in terms of link rot._
|
| That sounds decent on the face of it but it depends on how
| automated that can be made, what the window is like, etc.
| Right now I can renew every 10 years, or do so for 10 years
| and add on more time every year so that if I ever forget or
| have trouble once I still have a huge window, and have
| automated billing/warnings etc. Not free, but pretty
| reliable. If namebase.io or the like are needed to handle
| this by most users I also don't see how decentralized that
| can actually end up being though I guess the infrastructure
| can help. How are transfers to different registrars handled?
| [deleted]
| troquerre wrote:
| Any name up to 63 characters (normal domain name
| characters, unicode gets converted to punycode) can be
| registered. The difference with Handshake is that users get
| to choose how they store their names. There's a spectrum of
| convenience and self-sovereignty. In traditional DNS the
| existing system makes that choice for you, whereas
| Handshake is creating a system where individuals get to
| choose based on their preferences. I place a lot of value
| on that freedom to choose.
| xoa wrote:
| > _Any name up to 63 characters (normal domain name
| characters, unicode gets converted to punycode) can be
| registered._
|
| But how does that square with the 52-week staggered
| release bit? If I wish to go register my domain right
| now, what happens? I don't see anything on namebase that
| would simply allow entry of an arbitrary domain, instead
| the "bid soon" seems to just be a bunch of dictionary
| words. There is an invitation to enter your handle or
| whatever, but does that mean all such handles and
| existing domains have been auto scanned already for
| entry? Or if I do a search, do you then take that and put
| it up for auction like so many typical registrars? This
| is a really basic thing and it's not clear.
|
| > _There 's a spectrum of convenience and self-
| sovereignty. In traditional DNS the existing system makes
| that choice for you, whereas Handshake is creating a
| system where individuals get to choose based on their
| preferences. I place a lot of value on that freedom to
| choose._
|
| No offense but this reads as boilerplate PR mush, it
| doesn't actually answer anything. Choose _what_? High
| level values are all well and good but they 're not a
| substitute for nuts-and-bolts implementation specifics
| either.
| danShumway wrote:
| 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?
| rasengan wrote:
| Additionally to combat squatting, to register a name, one
| needs to go thru a Vickrey auction and bid on a name after
| it is released. Bidding continues for about 5 days
| thereafter and there are 10 days to reveal the bids.
|
| The winner pays the second highest bid.
| danShumway wrote:
| Wait, what?
|
| That seems like it could have a _lot_ of unintended
| consequences, to the point of invalidating all of the
| benefits from having tons and tons of new names. I have a
| lot of follow questions about the potential for abuse.
|
| From the squatter/troll angle: if I'm a troll or I'm
| trying to steal good names before anyone else can get
| them, what stops me from monitoring the current auctions
| and stealing domains by bidding above the statistically
| most likely market price for that domain? Users have to
| _guess_ in advance how much a domain will cost?
|
| From the decentralized, anti-corporate angle: if I'm
| Comcast, what stops me from monitoring the current
| auctions, and blocking anyone who tries to register any
| variant of `comcastsucks`? With the current system,
| that's prohibitively expensive since there are tons of
| variations that I'd need to preemptively register. With
| the system you're describing, it costs me nothing until
| someone tries to register a domain that triggers my
| Regex, and then I just outbid them and block any domain
| that criticizes me, because as a company I'll always be
| able to trivially and safely outbid any single person.
|
| From a general user angle: does this mean I have to wait
| 5 days to register a new domain? With the current system,
| I can set up a brand new website in a single evening, and
| all I need to do is find a name that isn't taken yet -- I
| don't have to worry someone else will see what I'm doing
| and snipe my purchase. With the system you're describing,
| I have to wait 5 days to discover whether or not I'm
| actually going to be able to buy the domain I want at
| all, and if I don't get it, then I need to repeat the
| entire process?
|
| I have so many questions about this system now. There
| _has_ to be something you 're leaving out here. I can't
| imagine using a DNS registrar that made me wait 5 days to
| discover whether or not I got to have the domain, or that
| made me guess how much it would cost at the risk of
| losing the entire domain. If there aren't other details
| you're leaving out, that's a strictly worse system than
| what we have right now.
| troquerre wrote:
| The auctions are semi-blind. You bid, and can optionally
| add a blind to your bid. The network sees your combined
| total bid + blind, but won't know your true bid value
| until the reveal period. So if you want to guarantee you
| win an auction, just make sure your bid is greater than
| the highest existing total.
| danShumway wrote:
| > if you want to guarantee you win an auction, just make
| sure your bid is greater than the highest existing total.
|
| How do I do that if other people's bids can contain
| blinds? How do I know what the highest existing total is
| -- I still have to guess everyone else's total, right?
|
| And even if the auction wasn't partially sealed, even if
| it was completely public -- I don't see how my concerns
| above would go away. Isn't it still possible for
| companies who can trivially outspend anyone else to do
| regex matches on all of the current auctions and dominate
| the entire domain space? Don't I still need to wait 5
| days to do something that I can do today in less than an
| hour?
|
| Learning about auctions pretty much entirely, just by
| itself, took me from thinking, "it's not perfect, but it
| still seems almost universally better than what we have"
| to, "no, this would be a massive downgrade from our
| current system." I thought the point was to stop rent-
| seeking, not to implicitly allow every fortune 500
| company and government to personally vet/block every
| single domain transaction.
|
| The auction system being described here doesn't just
| focus on other problems other than name scarcity, it
| makes the name scarcity problem _way worse_. If I 'm
| China and I want to censor this system, what stops me
| from monitoring the auctions and throwing a measly $2000
| at any domain name that sounds critical of me in any way?
| What's the point of having a distributed or decentralized
| protocol in that scenario?
| troquerre wrote:
| You are correct in that Handshake is trying to decentralize
| DNS more so than solve the scarcity nature of naming. That
| said, Handshake will increase the supply of TLDs by
| multiple orders of magnitude so the names do become less
| scarce overall.
| sdtsui wrote:
| > That domains will continue to be a limited, scarce resource
| that are susceptible to hoarding by people with lots of money?
|
| I don't think so - note that these are for tlds, so a lot of
| existing internet infrastructure can be used for Handshake
| names.
|
| Someone who wants elementary school kids to be able to buy them
| would allow for the purchase (at low, no, or negative cost) of
| subdomains (traditional domains) - it may allow for a
| proliferation of hundreds of little self-sovereign registrars
| with different policies.
|
| `${name}.namesforschoolkids`
| joosters wrote:
| 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?
| verdverm wrote:
| You missed what HS does. It does not run the DNS system, it
| extends what ICANN does. The same DNS tools and infra are still
| used
| ruyden1000 wrote:
| This is golden, it reminds the time when Let's encrypt started.
| Something that is challenging and can change a lot the direction
| of the internet.
| RL_Quine wrote:
| Nice astroturfing.
| dang wrote:
| Please read and follow the site guidelines.
|
| https://news.ycombinator.com/newsguidelines.html
| layoutIfNeeded wrote:
| >Created: 40 min ago
| dang wrote:
| Please don't shame users for creating new accounts. I
| appreciate that you're trying to protect HN, but we
| definitely don't want to attack people for joining the site.
| The damage that does in the case where someone is being
| genuine is much worse than the benefit it provides in the
| inauthentic case.
|
| https://news.ycombinator.com/newsguidelines.html
| omani wrote:
| lol you really think we fall for your comment?
| dang wrote:
| Please read and follow the site guidelines when posting here.
|
| https://news.ycombinator.com/newsguidelines.html
| xoa wrote:
| :\
|
| As has been the pattern with all these decentralized DNS schemes,
| the FAQ doesn't cover the most utterly basic question: "I
| currently have one or more domains that I use extensively for my
| own life/work. How do I transfer those to try this new scheme?
| How much actual dollars/euros/yen/yuan/... does it cost, not
| mystery blockchain-whatevers but predictable real money? Does
| this new scheme harm me?"
|
| Shouldn't an experimental system in particular want regular tech
| people with personal domains trying it out? We'd probably be more
| willing to give it a whirl (with fallbacks) since it's more for
| our own private use. But instead it's all about trademark holders
| and the Alexa 100k and so on, which is important too but it seems
| like most such domain holders would be a lot more conservative.
| And I've had a growing suspicion that the last part of the
| question doesn't get answered clearly because the answer is "you
| may get screwed, we are ideologues who think that people should
| be able to take your domain if you're not rich enough to defend
| it."
|
| I mean, right now I don't in fact see the current DNS system as
| _horrible_. Cloudflare and others are pretty reliable registrars
| and companies to deal with. A .com is about $8, .net and .org
| both about $10. A known amount of $200 or so and I 'm set for 10
| years, and I consider that a good thing. I've had my domains for
| nearly 20 years now, they're core to my online identity and
| personal infrastructure. Same for most businesses, DNS sits at
| the center of everything. My concerns are about ICANN allowed
| price increases due to monopoly, and whether bad actors could
| somehow try to claim my domain and how I'd fight that as an
| individual. But I don't see answers in the FAQ to how this would
| help answer those. My personal domains aren't in Alexa top-
| whatever so it sounds like handshake will auction them off. There
| is a "renewal fee" after that but it's handwave-y:
|
| > _Renewals for names are annual and cost a standard network fee_
|
| A standard network fee of _what_? $1? $10? $100? It can vary by
| thousands of percent at random like so many cryptocurrencies? How
| long is the renewal window? Can it be paid upfront? What happens
| if it gets missed? Is any of this _predictable_?
|
| I simply don't see any brass tacks implementation stuff here.
| It's a bunch of high level hoohah about the evils of
| centralization without any acknowledgement of how centralization
| can be useful and efficient too and how they deal with that. The
| word "federation" does not appear at all, which is another
| important approach/aspect. It sounds worryingly like a common
| "religious" approach where people take a tool (like
| decentralization) and turn it into a goal in and of itself.
| troquerre wrote:
| There's an airdrop that gives developers on github claims.
| Basically if you had over 15 followers on GitHub by August 2018
| you likely got 4662 coins (worth a lot since current market
| price is $0.50[1]). These instructions walk through how to
| claim the airdrop https://namebase.io/airdrop. This way you can
| easily register names to try Handshake out even if you already
| have websites in traditional DNS.
|
| [1] https://namebase.io
| uberdru wrote:
| Does putting self-signed certs on a blockchain really solve the
| problem?
| vbezhenar wrote:
| 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.
| uberdru wrote:
| "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?
| vbezhenar wrote:
| As long as we're talking about conventional DNS, it's
| centralized by design. And if you want to build a better
| DNS, you can just use onion: domain is public key and you
| can even mine good domains (facebookcorewwwi.onion).
| josh2600 wrote:
| 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!!
| pinhead26 wrote:
| 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.
| sfusato wrote:
| Went through the FAQ's, but still didn't understood much about
| how this is supposed to work alongside ICANN/current DNS system.
| Well, I didn't got Bitcoin the first 2 times either.
|
| 1. "Browsing the web with human readable names is what Internet
| users have gotten acclimated to." => give me an example of a
| "handshake" domain name in this case
|
| 2. I have some domains/sites not so popular (not in the first
| 100k Alexa domains). I will only hear about "Handshake" in 5
| years time when Handshake completely replaced what we are using
| today, by which time, someone else might have "registered my
| domain names". What do I do? Obviously I can prove I own my
| .com/.net.
|
| To site failed to answer some basic questions/concerns or give
| some real world use case scenarios.
| sfusato wrote:
| Own answer to 2: So all existing TLDs are by default "pre-
| reserved".
|
| Secondly, the 100k top Alexa sites refers to the inability to
| register a ".whatever" if that "whatever.some_tld" is in top
| 100k Alexa. So, basically this is "pre-reserving" "gTLD".
|
| In my first impression, these 2 things were somehow correlated.
| xur17 wrote:
| > I have some domains/sites not so popular (not in the first
| 100k Alexa domains). I will only hear about "Handshake" in 5
| years time when Handshake completely replaced what we are using
| today, by which time, someone else might have "registered my
| domain names". What do I do? Obviously I can prove I own my
| .com/.net.
|
| This is one part that Handshake does not explain very well. The
| existing domains and tlds that icann owns will continue to work
| moving forward. The top 100k Alexa domains bit works like this:
|
| For the top 100k alexa domains, the owner receives the root of
| the domain as a domain in Handshake (ex: the owner of
| `example.com` receives the domain `example` in Handshake). All
| `*.com`, etc domains continue to operate as they have in the
| past.
| aSplash0fDerp wrote:
| Seeing how Internet 1.0 is getting cannibalized by big business
| and governments, I'm hoping to see HS and other orgs start
| working on an offline mesh network and devise a completely new
| system of information distribution.
|
| Humanity appears to be changing the public park infrastructure of
| the Internet into a paid-access theme park, with [them/someone
| else] writing the rules. It doesn't look like the righteous, tech
| illiterates, political manipulators or shareholder driven groups
| are going to relent.
|
| The Internet used to be filled with raw data, but in the age of
| centralized, walled garden curating, the essence of the
| information superhighway has been lost.
|
| It would be cool if they could pioneer a new way to replicate
| data in the age of autonomous vehicles or use the Internet to
| transfer volumes of data for offline nodes to broadcast and
| reimagine DNS and the other fundamental tools to make something
| like that resilient.
|
| If they could remove most/all of the ads, marketing, monetization
| and censorship from the data, we might see another generation
| experience the raw data bliss many of use were raised on in the
| pre-dot.com era.
|
| It was truly something special and felt like the world (of
| knowledge) was at your fingertips (instead of something slimey on
| the other end).
| troquerre wrote:
| Shameless plug - if anyone wants to try using Handshake, we built
| a registrar for Handshake domains and an exchange for Handshake
| coins (HNS) at https://namebase.io. We just launched last week
| but there's already been a lot of usage so it'll be interesting
| to see what people do with their Handshake domains when they
| become available.
| matt2000 wrote:
| 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.
| troquerre wrote:
| 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.
| xoa wrote:
| This is useful info and should really, really be in the FAQ.
| Like, right at the top, because I don't think it's clear
| right now at all what happens to regular domain holders using
| them for email, their own services, intranets and so forth.
| If those in the current registrar system have a _reliable_
| path to transition /try it out at some point that's a good
| start.
|
| Edit to add: your namebase.io FAQ seems a lot more useful
| than the handshake one. For starters it clarifies that there
| is a confusing terminology difference, where I guess the
| handshake people are using "domain" to mean "TLD" and
| "subdomain" to refer to what everyone typically calls a
| domain. So a core offering of this system appears to be a
| blockchain based replacement to the $150k+ (or whatever it is
| these days) "get your own arbitrary TLD" thing ICANN did,
| "anyone" gets to register their own TLD. But that raises more
| questions, like where the actual hardware behind all this
| goes particularly for existing TLDs which are blacklisted.
| LukeBMM wrote:
| > This is useful info and should really, really be in the
| FAQ. Like, right at the top, because I don't think it's
| clear right now at all what happens to regular domain
| holders using them for email, their own services, intranets
| and so forth. If those in the current registrar system have
| a reliable path to transition/try it out at some point
| that's a good start.
|
| Seconding this. I did not pick up on that at all.
| sdtsui wrote:
| I think this is a great question - I'll paraphrase my
| interpretation: "What does enforcement look like when a big
| name / known trademark is registered?" - I'll answer the
| question again in a different way. Will return to this _.
|
| ----
|
| But first - would like to +1 troquerre's answer - the DNSSEC
| proofs provide some degree of long-term primacy and
| compatibility/transferability to Handshake - it'll help
| minimize conflicts/disputes.
|
| Adding to that answer: I think something often left unsaid is
| how Handshake is attempting to create incentives for everyone
| (not just the early devs) to work together and make the
| internet better. The wide distribution to FOSS developers and
| donations have been mentioned by the team in other replies, but
| I'd like to add more:
|
| From the design notes: (source:
| https://handshake.org/files/handshake.txt)
|
| ``` ICANN has been the root namespace for the internet. ICANN
| (CA, US) is allocated 24,480,000 of the initial coin supply by
| the Handshake community.
|
| Cloudflare, Inc. (DE, US) is a corporation doing fundamental
| research for naming, caching, and certificate authorities. They
| are allocated 6,800,000 of the initial token supply.
|
| Namecoin is a decentralized naming blockchain. 10,200,000 of
| the initial supply was allocated to leading current and prior
| Namecoin developers.
|
| Verisign, Inc. (VA, US) is the registrar for .com and .net.
| They are allocated 6,800,000 of the initial token supply. The
| .com and .net TLDs on Handshake will be given to Verisign with
| a DNSSEC proof.
|
| Keybase has been innovating in the naming and certificate
| authority space. Keybase, Inc. (DE, US) are allocated 0.25% of
| the total token supply.
|
| Public Internet Registry (VA, US) maintains the .org namespace.
| They are allocated 3,400,000 of the initial token supply. The
| .org TLD on Handshake will be given to PIR with a DNSSEC proof
| to pir.org.
|
| Afilias plc (IE) has been the service provider for the .org
| namespace. They were allocated 3,400,000 of the initial supply
| to a DNSSEC proof of afilias.info. Note for both PIR and
| Afilias, this allocation was made before the proposed sale of
| the .org namespace. ```
|
| These aren't trivial amounts for typical "ICO project marketing
| buzz / fake partnerships", they add up to percentages of total
| supply claimable by DNSSEC proof.
|
| Because of this attempt to align incentives, I imagine there
| could be a world where community members (FOSS developers and
| wider mainstream 'internet' folks, not just 'crypto' folks) can
| get the best of both worlds, where any conflicts between ICANN
| and Handshake are minimized or the user pain mitigated by
| resolvers/other service providers.
|
| ----
|
| _*returning to the original question on cocacola -- the dnssec
| proof setup helps with .com domains where the holder wants to
| claim and use the Handshake tld there are a lot of situations
| where this is not enough.
|
| What if someone registers cocacolacompany, or
| thecocacolacompany, or coke? It could totally happen:
|
| Source: https://github.com/kyokan/namegrind ```
| cocacolacompany,4032,2,false thecocacolacompany,22176,20,false
| coke,50400,48,false ``` Note: - that output is
| ${name},${blocknumber},${weeknumber},${reserved} - it can be
| generated with this tool https://github.com/kyokan/namegrind
|
| If one puts together the pieces from some of the other posts
| from the team - someone can claim anonymously with GooSig and
| buy the above names, and the multinational that is "The Coca-
| Cola Company" will probably attempt to find and enforce
| trademark protections against the holder -- if they cannot find
| that person, and it is flagged as an infringing name --
| resolvers or some other downstream service providers may have
| to block it. Of course, I am not condoning this - talk to your
| lawyer before you knowingly attempt to buy a name -- just
| pointing out that it is possible. From there, we could
| extrapolate various ways the legal system gets involved, or
| "pretty complicated governance models" attempt to protect The
| Company's claims, or the holder's privacy/control.
|
| So, to answer your question: Handshake is definitely less
| centralized than existing systems (no entity to send a takedown
| request to), but it's also not clear if strictly incompatible
| with laws in most jurisdictions.
|
| I don't think anything of this kind has been done before - my
| intent is to provide a bit of context and spark further
| discussion, but I'm not qualified to do more than speculate on
| how the legal stuff may play out.
|
| That said, for some jurisdictions, "B)" may very well happen.
| Ajedi32 wrote:
| This is a great idea with one easily correctable but nonetheless
| fatal flaw: it's an all-or-nothing preposition. If users choose
| to use Handshake as their DNS roots, they will no longer be able
| to access websites which only exist on ICANN's root zone.
|
| Assuming I'm not mistaken and that really _is_ how Handshake is
| set up (someone please correct me if I 'm wrong), then IMO the
| whole project is essentially dead on arrival. There's no chance
| they're going to be able to convince millions of large websites
| to register on a new DNS root overnight. And even if they did
| somehow managed to convince 80% of websites move to the new
| system, users _still_ wouldn't switch over because doing so would
| effectively break 20% of the internet for them.
|
| It's a real shame, because this problem would be trivially
| avoidable if they simply allowed the existing TLDs use the ICANN
| roots and confined Handshake domains to their own TLD (.handshake
| maybe). That way, adoption could happen slowly over time and
| users could switch over to the Handshake roots with no downsides.
| As-is though this is simply unworkable.
| xur17 wrote:
| > If users choose to use Handshake as their DNS roots, they
| will no longer be able to access websites which only exist on
| ICANN's root zone.
|
| This is not true. You can setup Handshake to be your resolver,
| and it will resolve both domains on handshake, and legacy
| domains from icann.
| Ajedi32 wrote:
| Then what's this paragraph in the FAQ about?
|
| > Existing TLDs and over 100,000 Alexa websites are reserved
| on the Handshake blockchain. Upon removing collisions,
| generic, and exclusions (e.g. 1 or 2 character names),
| approximately 80,000 names remain. Using the root key and
| DNSSEC, domain owners can cryptographically prove ownership
| to the Handshake blockchain to claim names.
|
| Does Handshake control existing (`.com`, `.org`, etc.) domain
| names or don't they? If they do, then what happens when a DNS
| entry in Handshake's roots contradicts what's in the ICANN
| roots? If Handshake wins conflicts, then that breaks the
| internet for existing users.
| xur17 wrote:
| I have a longer answer here [0], but in short, Handshake
| does not control existing domain names. They are giving the
| top 100k existing domain name owners control of a gtld
| based on the domain they own. Ex `example.com` receives
| `example` in Handshake's system.
|
| [0] https://news.ycombinator.com/item?id=22312059
| Ajedi32 wrote:
| Okay, that's much better. Thanks for the clarification. I
| assume "com", "org", "net", "ninja", etc are also
| reserved then?
| xur17 wrote:
| Yes, they are. The list can be found here:
| https://raw.githubusercontent.com/handshake-
| org/hsd/1c2d1036...
| tynes wrote:
| In blockchains, there is a difference between consensus and
| policy. The way that the Handshake recursive resolver works is
| not based on consensus. This means that people can insert rules
| for delegating a particular request to ICANN or to the
| Handshake authoritative resolver. It currently checks the
| Handshake authoritative resolver first, then falls back to
| ICANN.
|
| If this behavior is easily configurable/shared and open source,
| then people can opt into whatever configuration that best
| suites their needs.
| Ajedi32 wrote:
| Awesome, that's good to hear! Sounds like a pretty easy fix
| then. Users just need to configure the recursive DNS resolver
| to delegate existing TLDs to ICANN and that fixes the
| compatibility issue. I might actually give that a try at some
| point.
| djsumdog wrote:
| I don't see information on how names are handled. I know Zeronet
| started the entire .bit (which can be purchased with NameCoin).
| Are there reserved TLDs for handshake?
|
| Has ICANN said anything about .bit or .onion TLDs? I suspect TOR
| is big enough they won't touch .onion, but if they sell .bit,
| you'll then have some name overlap/conflicts.
| lifty wrote:
| The handshake namespace overlaps with the normal domain name
| system, but they reserve the top 100k domains for the current
| owners. My only concern is the long term sync between DNS and
| the old system. But I like the project and I think it's a good
| way forward for replacing the current centralized DNS and PKI
| system
| pinhead26 wrote:
| 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.
| lifty wrote:
| That's great. I didn't know that all the gTLDs are
| blacklisted, I thought they only the first 100k. This
| should make the transition smoother
| RL_Quine wrote:
| That's just an immediate non-starter then. Nobody is
| following all of these esoteric systems in the case that one
| of them gains marketshare, it guarantees that people will be
| phished and defrauded as soon as they use it. We had this
| issue with namecoin already, where people went and registered
| names of prominent people and tried to use that to solicit
| fraudulent donations.
| lifty wrote:
| That's a fair point and I share the same concern. I would
| have allowed anyone that owns a domain and can prove it, to
| get their domain for free in the new system. You could do
| the proof similarly to how Let's Encrypt does it
___________________________________________________________________
(page generated 2020-02-12 23:00 UTC)