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
- [Ilc] Clarifications and thoughts purpose of ILC … dm-list-ietf-ilc
- Re: [Ilc] Clarifications and thoughts purpose of … Tao Effect
- Re: [Ilc] Clarifications and thoughts purpose of … Tony Arcieri
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … Ben Laurie
- Re: [Ilc] Clarifications and thoughts purpose of … Tony Arcieri
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … Tony Arcieri
- Re: [Ilc] Clarifications and thoughts purpose of … dm-list-ietf-ilc
- Re: [Ilc] Clarifications and thoughts purpose of … Ben Laurie
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … Ben Laurie
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … Ben Laurie