[messaging] Namecoin

[Trevor Perrin]

On Fri, Aug 22, 2014 at 7:48 AM, Tao Effect <contact at taoeffect.com> wrote:
> On Aug 22, 2014, at 3:25 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
>> How important is it to update the mapping?
>
> It depends on what the mapping is used for.
>
> If it's being used for mapping names to public keys, or for the other
> purposes that Namecoin is being used, it's critically important.

I was hoping for more analysis of the "register a name for your
public-key" case.

This use case is NOT a "cryptocurrency" use case.  It's closer to
older ideas such as [1] which build on a timestamping /
blockchain-like data structure, but don't rely on cryptocurrency
mechanisms like proof-of-work mining or proof-of-work block selection.

So the merits of proof-of-work here are debateable.  It would be good
to explore the requirements of this use case, and the pros and cons of
such a mechanism.

Unsupported assertions like "critically important" don't advance the discussion.


>> 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?
>
> It's unclear to me what you're asking here, could you clarify?

See above.


> Also, throughout your writing, it's clear to me that you are using a very
> different definition of "centralization" than the definition that is being
> used by the blockchain community.

I'm using the term normally enough.  Namecoin is a single namespace
backed by a single blockchain with a single set of rules.

I consider that "centralized".  I understand the proof-of-work process
attempts to decentralize the selection of new blocks (but of course,
see mining pools).

We're smart enough to handle these distinctions, let's not belabor terminology.


> 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).
>
>
> A distinction should be made between abandoning proof-of-work (PoW) and
> abandoning blockchains altogether.

I'm making that distinction.


> In your email, you've referred to some type of timestamping authority (TSA),
> but you did not make clear what you were referring to; whether it was a
> reference to CT or some other system of your own devising.

You should read my post and its references (and the Nakamoto paper):

https://moderncrypto.org/mail-archive/messaging/2014/000668.html

The famous Bitcoin "blockchain" is an old data structure, first
proposed in the context of timestamping, and discussed in many other
contexts besides cryptocurrency.

Patents made this area problematic for a long time, and cryptocurrency
is more exciting than timestamping and cert revocation and forensic
snapshots and CA transparency and so on.   So I guess Bitcoin is the
first you've heard of Merkle Trees, and the idea they could be linked
together and published without burning hundreds of millions of dollars
in computation seems like apostasy.

But there's a history here you should read up on, if you're so
enthusiastic about this.


> On the otherhand, if you are expressing a preference for alternative
> consensus protocols, please be specific about which ones you prefer.

The immediate question I was raising is whether block selection
benefits from a consensus protocol, in the
"register-a-name-for-your-public-key" case.

There are examples where blockchain-type data structures are useful
when a single entity chooses the successive blocks (timestamping;
transparency for a centralized service; a Certificate Transparency
log).

It's unclear to me whether "register-a-name-for-your-public-key" is
more like those cases, or more like cryptocurrency.


Trevor