Re: [Ilc] Clarifications and thoughts purpose of ILC list

David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> Wed, 22 February 2017 18:25 UTC

Return-Path: <dm-list-ietf-ilc@scs.stanford.edu>
X-Original-To: ilc@ietfa.amsl.com
Delivered-To: ilc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C891129973 for <ilc@ietfa.amsl.com>; Wed, 22 Feb 2017 10:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eOOYHtFrP_HV for <ilc@ietfa.amsl.com>; Wed, 22 Feb 2017 10:25:13 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD7B12967C for <ilc@ietf.org>; Wed, 22 Feb 2017 10:25:13 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v1MIPBL8099284; Wed, 22 Feb 2017 10:25:11 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1MIPBb6075971; Wed, 22 Feb 2017 10:25:11 -0800 (PST)
From: David Mazieres <dm-list-ietf-ilc@scs.stanford.edu>
To: Tony Arcieri <bascule@gmail.com>
In-Reply-To: <CAHOTMV+qx_a44MNAaFN-M7YzA-rkmtRCRS_nNGeSibgNHUshrA@mail.gmail.com>
References: <87bmu194rx.fsf@ta.scs.stanford.edu> <CAHOTMV+qx_a44MNAaFN-M7YzA-rkmtRCRS_nNGeSibgNHUshrA@mail.gmail.com>
Date: Wed, 22 Feb 2017 10:25:10 -0800
Message-ID: <87poiaf5h5.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/zg0g0ByVDEILkuQ13BGJzflQf5Y>
Cc: ilc@ietf.org
Subject: Re: [Ilc] Clarifications and thoughts purpose of ILC list
X-BeenThere: ilc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-05-23 PDT <mazieres-fchkzc5a6hir7my83mgvu3njdw@temporary-address.scs.stanford.edu>
List-Id: "Discussion of mechanisms and applications for Internet-level consensus." <ilc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ilc>, <mailto:ilc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ilc/>
List-Post: <mailto:ilc@ietf.org>
List-Help: <mailto:ilc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ilc>, <mailto:ilc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2017 18:25:14 -0000

Tony Arcieri <bascule@gmail.com> writes:

> While I think that would be interesting, the existing solutions in this
> space, namely Bitcoin-style proof-of-work chains, corrupt data under
> network partitions (so-called "blockchain forks", see also eclipse attacks)
> meaning they are not partition tolerant and therefore have neither CP nor
> AP semantics under CAP theorem (although CP semantics would be desirable),
> and have formally been demonstrated not to have the properties of byzantine
> fault tolerance[1] (BFT) or byzantine fault detection (BFD), which I would
> consider necessary in any sort of federated consensus system.
>
> Though the notion of "Satoshi consensus" has garnered a bit of attention
> due to Bitcoin, I hope any effort in this space is held to higher and more
> traditional standards of what "consensus" actually means in traditional
> distributed systems contexts, which includes not corrupting data in the
> presence of network partitions, and ideally possessing BFT or BFD
> semantics. So far, I am not aware of any feature-complete/deployed
> "permissionless" system that provides these properties. That's not saying
> they're impossible, but there's much groundwork that still needs to be done.

Well, there are a bunch of different variants of Satoshi consensus.
Some of them, like peercoin and tendermint, look more like traditional
BFT, only where participants are elected based on some other criterion
such as stake in a cryptocurrency.

> Though I don't speak for Stellar (but have observed they appear to behind
> this BoF), I think they have been doing interesting work in this space with
> SCP, even if it compromises on the so-called "permissionless" aspect. That
> said, the Internet itself is a "permissioned" system (ASes can't peer willy
> nilly) as are many of the core protocols the Internet has been built on,
> and so far the sky hasn't fallen like certain chicken littles would tell
> you it will.
>
> ...
>
> At the end of the day systems need operators, and the operators will always
> be able to exert some degree of control.

I suppose one way of looking at the issue is that *all* consensus
systems start to misbehave when owners of more then some fraction of
some resource start misbehaving.  Bitcoin breaks once about 1/3 of
hashing power is controlled by someone with incentive to undermine the
system.  BFT breaks when 1/3 of nodes are malicious.  Proof of stake
breaks once too many coins elect Byzantine nodes.  So maybe the question
shouldn't be whether a system is permissioned or permissionless, but
rather along what axis the permission lies.  Another related question is
how to balance safety (meaning agreement and validity, or roughly "CP
semantics") against liveness (or "AP semantics" in CAP parlance)--as you
can trade one off for the other--and how does that trade-off get
decided.

For better or for worse, the "currency" driving Internet change seems to
be market clout.  This is soft of a simplification of the point made by
Clark et al. in "Tussle in Cyberspace," but basically change can happen
because millions of end users adopt some protocol, or because
systemically important ISPs unilaterally implement some change.  The
Stellar consensus protocol, SCP, was inspired by this model.  It relies
on something akin to market clout for consensus--individual nodes make
their own trust decisions, and so "transitive trust" is really the
resource that could allow someone to undermine the system.

Not all aspects of the Internet are as robust as the ideal market-driven
"tussle space."  For example, TLS certificates have a disjunctive
property, where a single CA can cause headaches for entities with much
greater market clout.  Moreover, it is difficult for individuals to
adopt a CA for a particular purpose (like some set of websites) without
it bleeding over into other purposes.  Obviously the trans working group
is improving the situation.  Similarly, once you choose an email
provider, your privacy is at the whim of that email provider even if, in
aggregate, email providers would like to provide greater privacy.
Finally, some things like payments between participants with no
preexisting relationship just don't work today.  This is one of the
reasons Stellar developed SCP, and why I personally believe that some
sort of standard Internet-level consensus would spur innovation that
promotes financial inclusion.

David