[Ilc] Clarifications and thoughts purpose of ILC list

dm-list-ietf-ilc@scs.stanford.edu Thu, 16 February 2017 21:58 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 970781296FA for <ilc@ietfa.amsl.com>; Thu, 16 Feb 2017 13:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Pl9uVIbOTZUl for <ilc@ietfa.amsl.com>; Thu, 16 Feb 2017 13:58:44 -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 95CB31296F9 for <ilc@ietf.org>; Thu, 16 Feb 2017 13:58:44 -0800 (PST)
Received: from market.scs.stanford.edu (localhost []) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v1GLwhtn019484 for <ilc@ietf.org>; Thu, 16 Feb 2017 13:58:43 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1GLwh7S054797; Thu, 16 Feb 2017 13:58:43 -0800 (PST)
From: dm-list-ietf-ilc@scs.stanford.edu
To: ilc@ietf.org
Date: Thu, 16 Feb 2017 13:58:42 -0800
Message-ID: <87bmu194rx.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/AKRUCLh_AYPSqgBd9F8f1NdZrQ8>
Subject: [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-17 PDT <mazieres-mz25ifj75g4n88b2gifq6ry7pn@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: Thu, 16 Feb 2017 21:58:45 -0000

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).  This is not to be
confused with other meanings of the word, as in "rough consensus and
running code," or consensus in any kind of a governance context.

Many kinds of distributed system leverage some a consensus mechanism.
At a high level, one of the things we might want to discuss in this list
is whether it could be beneficial for the IETF to standardize some kind
of consensus protocol or service.  Such an effort could provide a useful
building block for new or enhanced applications such as Internet
payments, auditable software packages, end-to-end email encryption, and
probably more things I haven't thought of yet.  The goal of this list is
certainly not to replace existing protocols or to change Internet

While obviously consensus mechanisms have been around for decades, one
recent development has been the advent of so-called permissionless
consensus mechanisms with open membership.  These mechanisms allow new
types of system, for instance ones in which mutually distrustful parties
with no pre-existing relationship can execute atomic transactions
together.  If we abstract the Internet slightly (maybe pretending some
centralized IANA-controled identifiers are public keys anyone could have
unilaterally allocated), the Internet, too, starts to look like a
permissionless system.  That's where this idea of "Internet-level"
consensus originates.  Does it make sense to leverage the permissionless
aspects of the Internet to implement some sort of permissionless
consensus mechanism?  Should the IETF be undertaking efforts along these
lines?  Could such efforts benefit existing IETF efforts or solve
existing challenges?  If the answer to any of these questions is yes,
then this mailing list is the place to start throwing out ideas...