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

Tony Arcieri <bascule@gmail.com> Thu, 23 February 2017 17:36 UTC

Return-Path: <bascule@gmail.com>
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 06BB112A202 for <ilc@ietfa.amsl.com>; Thu, 23 Feb 2017 09:36:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VFMeaRMI44NP for <ilc@ietfa.amsl.com>; Thu, 23 Feb 2017 09:36:11 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FD9129A6A for <ilc@ietf.org>; Thu, 23 Feb 2017 09:36:10 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id h10so174030707ith.1 for <ilc@ietf.org>; Thu, 23 Feb 2017 09:36:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XNA4VO5h6ebzMry7lhQZdYNtEWS7WEgX8B66zGJbmS4=; b=MvN1c4jPB0v8vY7DEPkACSPDolQwh2eExmzp2MXrbdtaVMpmcZLyLtPyAflQP7/Rva BgUPmbnmq2OjdeB4cYHUGkqL+3Au0qULr1SQfSii8LARkfsMFEGueqOWplN0uPPb+tRb TkfgeeEgiO7mH8LDPVLDTdhY7B/ulGHgmeRHjMf95+ivG6sZlD9edzT6YMiQIkidFA0Q tyMKPe5SfO35CEM1KUmaio2TjPYig4rL69meuKIniyl5mnzl9IYtfSfLq+Sjc1Go8Qd3 G4mTHzOO0aV41NhhOzgTTWWQCeLMenB3Kkg1oD3fpXc4ObAir/+Jx3jkC+umTOZTBYEv zlKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XNA4VO5h6ebzMry7lhQZdYNtEWS7WEgX8B66zGJbmS4=; b=IzDKPs07kAKxsP4GMnJMbHIeoFBhaMIxO4UT5In8topdlI5FTDjmqXXQZYNPAcSRtl 1PdKbAYFxq1v3OUXGVTn9j7xyWITVGVGkIM/uQP7hhh9nZFt+Czgu8Gffvh3q9X298bq uELMTdiSBF5VzcKFP5teUaLLq3FlxmVaiiZAsrNY7ZJcyU4bkg2eH1NL80svxHCXYVip wGzu9v/0hUHamcnU6ZEVEsJTu72vpNHsIZe7q7ohl09X/WywkR14nLcQGHzbFn0wbjlk RyWtlfigY4f/YhPnYKdVH+9r105wduLCex6yasGOW7PF4WXRTg3JTy2TL3EnvNI6npxN R9xQ==
X-Gm-Message-State: AMke39kkb5o5DteU8T3J/VFbyJDsiXw61kSUc7/MQJ34/V/czfUhzrG2N4lusitdJMlFhktPd3zJXYaE26HgRA==
X-Received: by 10.36.127.73 with SMTP id r70mr3855044itc.11.1487871370184; Thu, 23 Feb 2017 09:36:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.5.21 with HTTP; Thu, 23 Feb 2017 09:35:49 -0800 (PST)
In-Reply-To: <87poiaf5h5.fsf@ta.scs.stanford.edu>
References: <87bmu194rx.fsf@ta.scs.stanford.edu> <CAHOTMV+qx_a44MNAaFN-M7YzA-rkmtRCRS_nNGeSibgNHUshrA@mail.gmail.com> <87poiaf5h5.fsf@ta.scs.stanford.edu>
From: Tony Arcieri <bascule@gmail.com>
Date: Thu, 23 Feb 2017 09:35:49 -0800
Message-ID: <CAHOTMV+_4E-Cf=7aKPiKpfT_dievyiABVMbkD=U81MJePttD4A@mail.gmail.com>
To: David Mazieres expires 2017-05-23 PDT <mazieres-fchkzc5a6hir7my83mgvu3njdw@temporary-address.scs.stanford.edu>
Content-Type: multipart/alternative; boundary=001a1147c5ae7ddda00549360ca0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/pD421tyuEr7q3Yn3s4t3IoGGM1I>
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
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: Thu, 23 Feb 2017 17:36:12 -0000

On Wed, Feb 22, 2017 at 10:25 AM, David Mazieres <
dm-list-ietf-ilc@scs.stanford.edu> wrote:

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


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.

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.

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.

-- 
Tony Arcieri