[messaging] Namecoin

[Tao Effect]

On Aug 22, 2014, at 3:31 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> 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.

Speaking of unsupported assertions, that "the merits of proof-of-work [are] debatable" needs to be substantiated with something, especially if you are comparing it to pre-PoW concepts.

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

Isn't it self-evident that to have the correct public key for the mapping you need the mapping to be updatable in case it is compromised, lost, changed, etc.?

> I'm using the term normally enough.  Namecoin is a single namespace

Namecoin has two officially recognized namespaces, and far more unofficial namespaces. It supports an almost arbitrary number of namespaces.

https://wiki.namecoin.info/index.php?title=Welcome

> 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.


To declare the whole of Bitcoin or Namecoin as being centralized—based on the number of namespaces or the number of blockchains they "have"—seems disingenuous at best, and ad hominem at worst.

To illustrate the difference in stark terms between TSAs and Blockchains:

- In CT, it is possible for a *single* entity (MITM) can provide false answers to *all* queries that a user makes.
- In blockchains protected by PoW, it is nearly impossible for any single entity to provide false answers to the vast majority of queries a user makes, even when the chain is under 51% attack.

Dismissing this difference as "belaboring terminology" makes it sound (to me at least) as though you aren't interested in having an honest discussion.

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

I read your post and the Nakamoto paper. If there's a reason for me to read your references that's relevant to this discussion please let me know, otherwise I politely decline as there are other matters that I must devote my time to.

> and the idea they could be linked
> together and published without burning hundreds of millions of dollars
> in computation seems like apostasy.

There are various consensus algorithms out there that do not rely on PoW. There are also PoW algorithms that don't waste computation (see Vitalik's blog posts and talks).

What interests me are not so much Merkle Trees on their own, but how they are used by blockchains and consensus algorithms. Merkle Trees on their own aren't enough to address the issues that you expressed concerned about in previous emails (secure & efficient key distribution, name to key mappings, e2e messaging, etc.).

>> 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.

Yes. Everything I've researched indicates they are necessary to secure the blockchain itself. I have no seen a single valid counter-argument to this point.

> 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.

I showed in previous emails why CT doesn't deliver on its promise and therefore cannot be used for this purpose. You're welcome to respond to that if you would like.

Cheers,
Greg


--
Please do not email me anything that you are not comfortable also sharing with the NSA.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140822/c73b4358/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140822/c73b4358/attachment.sig>