[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 [127.0.0.1]) 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-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 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 [127.0.0.1]) 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 governance. 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... 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