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

David Mazieres <> Thu, 23 February 2017 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E1F21296B4 for <>; Thu, 23 Feb 2017 11:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kkn8glCHz0NZ for <>; Thu, 23 Feb 2017 11:25:44 -0800 (PST)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 211FB129982 for <>; Thu, 23 Feb 2017 11:25:44 -0800 (PST)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id v1NJPhxD015528; Thu, 23 Feb 2017 11:25:43 -0800 (PST)
Received: (from dm@localhost) by (8.15.2/8.15.2/Submit) id v1NJPhxm036962; Thu, 23 Feb 2017 11:25:43 -0800 (PST)
From: David Mazieres <>
To: Tony Arcieri <>
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 23 Feb 2017 11:25:43 -0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [Ilc] Clarifications and thoughts purpose of ILC list
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-05-24 PDT <>
List-Id: "Discussion of mechanisms and applications for Internet-level consensus." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2017 19:25:45 -0000

Tony Arcieri <> writes:

> Like many things in this space, "Satoshi consensus" is an ill-defined
> buzzword. In part I think it means incorporating programs into the
> consensus decision, which seems like fairly novel and interesting work to
> me (and somewhat similar to e.g. Trillian's "personalities"). In this
> space, yes incorporating consensus programs into (P)BFT-like schemes such
> as Tendermint is interesting.

Okay, then by that definition, "Satoshi consensus" is only one possible
approach among several to realizing Internet-level consensus.

> However, above I was using it specifically to refer to the proof-of-work
> scheme for consensus. "CP" versus "AP" of course both assume "P", a
> property Bitcoin (and systems using a similar proof-of-work consensus
> model) do not have. Under a network partition in Bitcoin, the system will
> both make progress and be available for reading (where CP systems will fail
> closed if they can't reach a quorum). When the partition is healed,
> acknowledge writes are lost and data is clobbered. Systems which truly
> uphold "CP" or "AP" semantics do not clobber data this way.

I agree about CP, but not AP.  AP systems are not safe, and hence will
clobber data.

Perhaps CAP is not the best way to categorize these systems, though.  It
may be better just to assume an asynchronous communication model (which
subsumes temporary partitions as equivalent to slow nodes).  Then we can
just talk about safety (agreement + validity), liveness (termination),
and fault tolerance.

> This sort of split-brain behavior can be exploited by attackers who are
> able to arbitrarily create network partitions. Eclipse attacks are a common
> example.

Right, so basically you are saying any Internet-level consensus
mechanism should guarantee safety even in an asynchronous communication
model where you can't distinguish slow from failed nodes.  I agree,
personally.  However, reasonable people might push for greater
availability.  It would be interesting to see if list members have
"rough consensus" (non-technical meaning) on this point, or
alternatively if makes sense to layer a less safe but more available
"short-term" system on top of one that guarantees safety for long-term
events (e.g., for certificates issued over a week ago).  We may want to
revisit this question down the line after discussing more applications.