Re: [Ilc] [saag] Distributed ledgers and control

David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> Wed, 29 March 2017 11:43 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 F25651296AE; Wed, 29 Mar 2017 04:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LbuxME4BK_04; Wed, 29 Mar 2017 04:43:10 -0700 (PDT)
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 56CA51296AD; Wed, 29 Mar 2017 04:43:09 -0700 (PDT)
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 v2TBh8A2061932; Wed, 29 Mar 2017 04:43:08 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v2TBh8Jb029362; Wed, 29 Mar 2017 04:43:08 -0700 (PDT)
From: David Mazieres <dm-list-ietf-ilc@scs.stanford.edu>
To: Paul Hoffman <paul.hoffman@vpnc.org>, "saag@ietf.org" <saag@ietf.org>
Cc: ilc@ietf.org
In-Reply-To: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org>
References: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org>
Reply-To: David Mazieres expires 2017-06-27 PDT <mazieres-7kjfd7jny6nqhpqvs8psccye9s@temporary-address.scs.stanford.edu>
Date: Wed, 29 Mar 2017 04:43:08 -0700
Message-ID: <87inmsxq9f.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/zluP7wdzgmHDQBOIwhoQtYHnfVc>
Subject: Re: [Ilc] [saag] Distributed ledgers and control
X-BeenThere: ilc@ietf.org
X-Mailman-Version: 2.1.22
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, 29 Mar 2017 11:43:12 -0000

Paul Hoffman <paul.hoffman@vpnc.org> writes:

> Greetings. A few folks have recently been discussing which ledger and 
> ledger-esque protocols should be used with upcoming IETF protocols. It 
> is easy to conflate the governance of the ledger with its uses. A good 
> article that helps make the distinction is:
>
> https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-distributed-ledger-technologies-may-do-little-to-transform-the-economy/

First, a plug for the IETF Internet-level consensus (ILC) mailing list
(CCed), which is a good place to discuss these issues:

        https://www.ietf.org/mailman/listinfo/ilc

as well as a reminder of the talk I'll be giving at the Thursday saag
meeting:

        https://www.ietf.org/mail-archive/web/saag/current/msg07651.html

The article you forwarded seems like a reaction to the notion that
blockchain technologies can somehow supplant or circumvent regulation.
That's a common view within the cryptocurrency community, but a highly
controversial one outside.  Nonetheless, there are different
applications for some of the consensus technologies underlying
blockchain systems that don't undermine governance and may be of
interest to the IETF.

In particular, given a mechanism for Internet-level consensus, it
becomes possible to execute atomic transactions across parties that
don't know or trust one another.  Far from undermining regulation, this
actually makes it practical to bridge various regulatory jurisdictions
(e.g., create a total order across all certificates issued by all CAs,
or atomically perform two funds transfers in two different countries).

Furthermore, the notion of a blockchain-esque public log can be
leveraged for various forms of transparency.  For instance, last year
there was a controversy in which Apple claimed to refuse an FBI request
to sign a special compromised iPhone bootloader.  Unfortunately, for all
we know, Apple may have signed the software after all while claiming not
to for the PR benefit.  That they probably didn't yields the worst of
both worlds--angering the FBI and still spooking potential customers.
Requiring firmware updates to be published in a public log would allow
the public to verify whether or not such activity is happening.

David