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

Tony Arcieri <bascule@gmail.com> Wed, 22 February 2017 07:10 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 AB315129480 for <ilc@ietfa.amsl.com>; Tue, 21 Feb 2017 23:10:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 CMORRdzxRO5C for <ilc@ietfa.amsl.com>; Tue, 21 Feb 2017 23:10:20 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 EC81E129444 for <ilc@ietf.org>; Tue, 21 Feb 2017 23:10:19 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id j13so3052971iod.3 for <ilc@ietf.org>; Tue, 21 Feb 2017 23:10:19 -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:cc; bh=7tI9rPkp5A8a8div2RijA0ejO9BnW4Ya6yAauKZpZgk=; b=Z2J233ukCYdJ4hx7ibga7zEk3WKw5SmG2Bbr4IvbqagR4zTs6YZw4LRVw5JkxHSxX1 Pai5ShhNNbOcClYXmwhfd0ClyUTWvSRhQPS3I1z5N7f5LwnkzoqdhZp9dSeGMT0zYk/a 1D1i0SzmnCht80PT2OVDblF8z6HKwwgtcEW6NME4EJtwM87/OnpGZk1h2PJ1xDwb7Ew+ ItPFuUZhLfGnUwch+dUIfP1lFWaA2gi0x3Pc/yRtvLy5ff3dJdNv4iPkkwVROdRSevXc ZOhOL8w5F2M+rdWD2NsGnEChf70OpBMpAOuddfUt2Yrltiea6SG9qCXPXgtUoGbyRYbe h0rQ==
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:cc; bh=7tI9rPkp5A8a8div2RijA0ejO9BnW4Ya6yAauKZpZgk=; b=gmaV1cFHiiQn3s0f0Dr6RlpEtKPHwyw01l2yTq0okCV7InlNQcLL8IjPCXtCqvvk6R hG//wCLMzHRcV7gABbymsn7NRzWynlnso3TIu89MbYT9YGkWo/MGzFgmufueoDhsr8MX JRNyaRRGyxSzhw2djJoAClwZz9LD+VMSh5jcP2VgYOCK0n/gHRuOiW6GxsPhQj2HHQnh sYwbf1VaVeWlVH3pdEgJE3bDiEmbhr7DpDYpmMx1M392diJtDRblfoo1CvTGzFyLXv/f EW6R6vcw0ro0BlfuHLu/VAnZI6ahg5t18cKEfj9oz16KpSLY6MBcZxWx5UuuMOsH/Ybl sNfA==
X-Gm-Message-State: AMke39l+CLEa8jqrddvy9ET3ylvPsQdR6LVNGsw8gg5qtCwwS79T2Gk+8PJiMtseFxddrCazTOfwwQlqBem/tA==
X-Received: by 10.107.10.11 with SMTP id u11mr25519952ioi.139.1487747419005; Tue, 21 Feb 2017 23:10:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.5.21 with HTTP; Tue, 21 Feb 2017 23:09:58 -0800 (PST)
In-Reply-To: <87bmu194rx.fsf@ta.scs.stanford.edu>
References: <87bmu194rx.fsf@ta.scs.stanford.edu>
From: Tony Arcieri <bascule@gmail.com>
Date: Tue, 21 Feb 2017 23:09:58 -0800
Message-ID: <CAHOTMV+qx_a44MNAaFN-M7YzA-rkmtRCRS_nNGeSibgNHUshrA@mail.gmail.com>
Cc: ilc@ietf.org
Content-Type: multipart/alternative; boundary="001a113ed60a6ce79605491930b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/qp77jmacVIJjH7hgTWwdAEifY5k>
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: Wed, 22 Feb 2017 07:10:22 -0000

On Thu, Feb 16, 2017 at 1:58 PM, <dm-list-ietf-ilc@scs.stanford.edu> wrote:

> The fact that the term consensus has a colloquial meaning may be
> generating confusion among some members of the list.  As intended in the
> list name, the term consensus refers to a narrow distributed systems
> definition, namely the problem for a group of nodes to pick an input
> value such that there is both agreement (all nodes output the same
> value) and validity (the output equals one of the valid inputs, ruling
> out vacuous solutions like always outputting zero).
>

I strongly agree it's important to look at traditional definitions of
consensus, particularly ideas like byzantine fault tolerance and CAP
theorem/partition tolerance.


> Does it make sense to leverage the permissionless aspects of the Internet
> to

implement some sort of permissionless consensus mechanism?


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.

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.

Meanwhile the only "permissionless" system of note, Bitcoin, is having
system-crippling issues with both scalability and governance, and appears
to largely be under the control of mining cartels, so I'm not sure
"permissionless" systems are necessarily a good idea or if they actually
live up to the ideals of removing control of the system from a central
cabal.

At the end of the day systems need operators, and the operators will always
be able to exert some degree of control.

[1]: https://eprint.iacr.org/2014/765.pdf

-- 
Tony Arcieri