Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

Tao Effect <contact@taoeffect.com> Mon, 16 December 2013 21:31 UTC

Return-Path: <contact@taoeffect.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F141A1F00 for <therightkey@ietfa.amsl.com>; Mon, 16 Dec 2013 13:31:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhwz3CYBVXxZ for <therightkey@ietfa.amsl.com>; Mon, 16 Dec 2013 13:31:15 -0800 (PST)
Received: from homiemail-a4.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 974E91AD8EC for <therightkey@ietf.org>; Mon, 16 Dec 2013 13:31:15 -0800 (PST)
Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id F1CE951C063; Mon, 16 Dec 2013 13:31:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=d71yU3XePE8b9+8Vg 0IYAJylNqA=; b=AqJwvuCC3WY9Yg8oSEZ23x/D51wFYgsD1S014gFo+FoY4KySj rSYkZYxdrZ/e03chHSRHp5AO+eHAP/7IpXTVypUN1sO8af3QHGMew8crSW5WH7Hw oyb7175QWEDhmjLSiBQh1Lp/aDxMwulMVmI+ZtL4HYlKYBaEf+hDOt87/I=
Received: from [192.168.2.3] (ip98-180-48-204.ga.at.cox.net [98.180.48.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 2EED351C062; Mon, 16 Dec 2013 13:31:13 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_14C01A26-908E-47E7-B788-05B8325D0EA3"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <CABrd9SQebG0+DpnD0GXD8nOXa2FSSKp8LLbBO+q1PxAEJ6dQcw@mail.gmail.com>
Date: Mon, 16 Dec 2013 16:31:08 -0500
Message-Id: <596BD192-F19E-48A5-8FD7-37D5A2085751@taoeffect.com>
References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com> <CABrd9SQebG0+DpnD0GXD8nOXa2FSSKp8LLbBO+q1PxAEJ6dQcw@mail.gmail.com>
To: Ben Laurie <benl@google.com>
X-Mailer: Apple Mail (2.1822)
Cc: "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 21:31:19 -0000

Hey Ben,

On Dec 14, 2013, at 2:12 PM, Ben Laurie <benl@google.com> wrote:

>> Decentralized: there is no central authority controlling all the names
> 
> If it is based on bitcoin, that is untrue. Or even if not. See
> http://www.links.org/files/decentralised-currencies.pdf.

Thank you for the link to this paper.

I needed to find the time to actually read this and get back to you. I've now done this.

You've posted this reply to a number of lists that we're both subscribed to, so I'm going to send this reply to each one:

My reply can be summarized (mostly) by Vladimir's response to your paper here:

https://bitcointalk.org/index.php?topic=25760.msg372591#msg372591

For the list's sake, here are the salient points Sir Vladimir makes:

Than, first of all, he is trying to solve a non-problem and fails to see that issue he is trying to solve is not a bug but a feature.

This is in reference to your criticism of proof-of-work. Here's the rest of his comment on that particular point:

There is no problem with energy consumption, it is a very low price to
pay for getting rid of all the middlemen leaching a few percent from
every money transfer. Moreover, energy spent by miners on securing the
bloc chain is rather negligible in comparison to energy spent on other
ways to do money, when you consider, for example energy, required to
haul all the cash and gold in armoured trucks, smelting gold bullions,
coining coins, smelting metal for the bank vaults and so on...

Second criticism of your paper is as follows (again, I'll just copy Vlad's comments here):

Second of all, his "efficient solution" is very weak. Essentially, he
is proposing to replace voting weighted by pure computational power
(surely not very energy efficient way) to voting weighted by a number
of clients plugged into the network, without proposing any viable way
(since it is impossible) to ensure that this number of clients is not
faked. Therefore, he is effectively shifting proof-of-work concept
from doing lots of sha-256 calculations to opening lots of ports on
lots of IP's simultaneously. This could solve a problem of quick
propagations and wide distribution of information, but surely not a
problem of "double spending". Total epic fail!

Somehow, you seem to have completely missed the point of Bitcoin's proof-of-work. It's right there in the original paper:

The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.

Vladimir made one final comment (not too important though, but I'll include it anyway):

He also has completely missed economic part of the system where
initial bitcoin inflation serves the purpose of subsidy to enable
quick growth of the network and making it secure from 50% attacks.

However, all of these points made by Vladimir do not destroy the point your paper makes entirely. They just badly bruise it.

IMO, the only legitimate criticism of Bitcoin contained in your paper is the following:

If, for example, 1% of the total power available7 is used to produce Bitcoins at present (in fact, the amount is far less than that), then at any point someone could come along with a further 1.1% of the total power and use this to define their own consensus8 , thus invalidating all the work, and all the money, of the initial group, and instead take possession of the entire currency for themselves.

This is referring to (or at least should be referring to) the idea of an attacker making their own "fake fork" that they control through superior-CPU power.

The strength of your argument (IMO) rests on this one issue: Whether or not there exists an attacker with the computational power necessary to take over the network.

This is a legitimate question, and combined with the observations made by Vladimir, it implies two takeaway points:

1. Your suggestion for an "efficient alternative" to Bitcoin appears to be inferior to Bitcoin because it appears to be based on one-IP-one-vote (rejected in the original paper).

2. Bitcoin's legitimacy and trustworthiness depends on whether or not there exists (or can exist) an entity with more horsepower than all more than 50% of the nodes on the network. This is old news.

The Bitcoin community has been discussing the 51% attack for a while and appears to be working on addressing the issue:

https://en.bitcoin.it/wiki/Proof_of_blockchain_fair_sharing

In case it's of interest to someone, here are two sites about known attacks on Bitcoin:

http://codinginmysleep.com/bitcoin-attacks-in-plain-english/
https://en.bitcoin.it/wiki/Double-spending

Cheers,
Greg

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