[messaging] Namecoin

Trevor Perrin trevp at trevp.net
Fri Aug 22 01:25:20 PDT 2014

On Thu, Aug 21, 2014 at 11:37 AM, Joseph Bonneau <jbonneau at gmail.com> wrote:
> I would say most in the Bitcoin
> community are skeptical of any consensus mechanism that *doesn't* involve
> proof-of-work as none have been convincingly shown to work under fire,

Maybe that's true for cryptocurrency, but it's less clear how much
proof-of-work consensus helps other use cases.

A blockchain can be monitored for correctness (wrt double-spending
rules, name-registration rules, etc).  Observed-correct blocks can be
published widely.  In that case the party choosing the blocks only has
denial-of-service power (omitting transactions, or refusing to issue a

In a timestamping case (for example) that's not a big deal.  There
could be multiple timestamping authorities and you can send your
document hash to all of them.  If one of the TSAs behaves weirdly in
the future you don't care, you've already got your timestamp.

Cryptocurrency seems very diferent (though using the same data structure):
 * The double-spending rule means you want to track everything in one log.
 * The value of money is being able to use it in the future, so it's
important that the block selection process remains robust and outside
anyone's control.
 * Proof-of-work is being used for mining, so it's lying around.

So having a "decentralized" proof-of-work process choose the next
block makes sense.  But that means you need a massive community of
miners, which is hard to arrange so means fewer block chains, and thus
a more "centralized" system overall.

Anyways, in a "transparency for public keys in a centralized service"
case, the service is already capable of DoS'ing its users.  So the
service might as well publish its own log, proof-of-work consensus
isn't needed.

What about a Namecoin-like "register a name for your public-key" case?
 If you weren't able to update the mapping, I think this would clearly
be more like timestamping than cryptocurrency (once you've registered,
you don't care what happens later).

How important is it to update the mapping?  I guess at a minimum it
would be nice to reclaim names after giving the user a 1-year notice
or something.  Is that enough "power" for the naming authority that
you'd want proof-of-work consensus, given the real tradeoffs in cost /
complexity / centralization that come with it?

> 1) Namecoin doesn't support efficient proofs of freshness. Knowing the most
> recent mapping requires storing the entire block chain, or trusting somebody
> else to do so for you. You can do an "SPV"-style proof that a name->key
> mapping existed at some point to anybody tracking the current head of the
> blockchain, but that doesn't prove that this wasn't overwritten later. This
> is fixable with a re-design by including the current Merkle tree of mappings
> in every block . This has been proposed for Bitcoin itself
> (https://en.bitcoin.it/wiki/Thin_Client_Security#Unused_Output_Tree_in_the_Block_chain_.28UOT.29,
> https://bitcointalk.org/index.php?topic=88208.0) and could certainly be
> built into a new system, potentially alongside a skip-list to enable compact
> SPV proofs.

Good point.  If there's a real use case for Namecoin semantics, it
seems like there should be a better data structure.

> 2) Namecoin didn't find a good balance between low cost to register a new
> name and resistance to squatters and such a balance may not exist.

Good point also.

Stepping back, if proof-of-work isn't needed for block selection,
doesn't lead to good name allocation, and couples things to a
complicated mining system so that it's hard to evolve and hard to
deploy different namespaces, that seems like a good argument for
abandoning it (for the name-your-public-key use case).


More information about the Messaging mailing list