[messaging] Namecoin, squatting and decentralized solutions to Zooko's triangle

Natanael natanael.l at gmail.com
Mon Aug 3 04:51:02 PDT 2015


Den 3 aug 2015 08:21 skrev "Joseph Bonneau" <jbonneau at cs.stanford.edu>:
>
> Talking to Trevor today, I realized I never emailed the list to plug a
cool paper at Princeton that I co-authored on squatting in Namecoin that
was published at WEIS last month[1]
>
> The official position from Namecoin is that squatting is a non-issue
(even calling discussion of squatting a case of bike-shedding) [2].
>
> By contrast our paper shows that  Namecoin has almost exclusively been
used by squatters so far [2].There are only a few dozen cases of legitimate
usage to date and over 100,000 names which have been claimed by one of four
major squatters (or re-sellers or whatever you would like to call them).
There is also no evidence of a functional market through which squatters
sell these names-it's all speculative so far.
>
> There are a lot of ideas about how to change incentives to prevent
squatting (including some in the paper) and Namecoin's design can probably
be improved. So one might say a better-designed Namecoin could "solve"
squatting and therefore Zooko's triangle.
>
> But I think a deeper issue is that the human-meaningful/readable/usable
property of names is ill-defined in Zooko's original triangle and has been
described different ways since. If Namecoin worked and was secure but was
subject to excessive squatting, limiting the availability of many desirable
names, would this be a "solution"? Names would be human-readable but
perhaps not human-usable.

[...]

Another of my sketches:
https://roamingaroundatrandom.wordpress.com/2014/09/20/web-of-trust-dns/

You'll note that my solution to squatting is to drop global consistency.
This is in line with Mike's response. Global uniqueness of addresses is
ensured here with public keys as addresses, acting as the equivalent to IP
addresses (assuming no multi-hosting). Then on top you add a *local* name
resolution layer to get human readable names.

My conclusions so far is that to get a globally consistent view you need
one of the following;

* An unquestionable global arbitrator, or a federation of them (requires
gatekeepers)

* A global concensus algorithm that don't need gatekeepers (proof-of-work,
or other purely algorithmic proofs of irrevocably burning scarce resources)

The latter alternative can behave in the following ways:

* First-come first-serve (Namecoin today)

* Chaos

The problem here is that the concensus algorithm has no trusted
non-centralized sources of input data about the outside world. Even if you
managed to create objective metrics (you can't), it isn't possible to
ensure with certainty that the blockchain will accurately represent those
metrics.

The decentralization works in Bitcoin because every user is the authorized
centralized entity that may provide the digitally signed inputs that tell
the world what to do with *his and only his* coins. Same in Namecoin with
domain names. As soon as you try to establish the truth for anything beyond
"the holder of the public key X says Y", you end up with a mess. Letting
the first registration stand is easier than trying to encode and compare
human valuation. Conflict resolution is hard when you have no objective
metrics.

So what exactly can be done, if you want to try it anyway?

* Let the miners decide (the options with the most PoW behind them is
assumed true - a sub-variant of this is the first-come first-serve scheme)

* Try to use incentives to get people to tell the truth - now we enter the
realm of decentralized prediction markets (conceptually not far from
gambling). Here people contribute to the signal instead of adding noise
because they believe others will do so too, and that doing otherwise thus
will be unprofitable (when it is working). Now we just moved into game
theory, good luck proving your system ever will be capable of getting close
to optimal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150803/a1051caa/attachment.html>


More information about the Messaging mailing list