Re: [Ietf-hub-boston] proof of work and consensus protocols

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 07 November 2019 16:14 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf-hub-boston@ietfa.amsl.com
Delivered-To: ietf-hub-boston@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE601208F8 for <ietf-hub-boston@ietfa.amsl.com>; Thu, 7 Nov 2019 08:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.563
X-Spam-Level:
X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 RHmNtRhHTuSS for <ietf-hub-boston@ietfa.amsl.com>; Thu, 7 Nov 2019 08:14:11 -0800 (PST)
Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (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 0AB371200B3 for <ietf-hub-boston@ietf.org>; Thu, 7 Nov 2019 08:14:11 -0800 (PST)
Received: by mail-ot1-f42.google.com with SMTP id v24so2494480otp.5 for <ietf-hub-boston@ietf.org>; Thu, 07 Nov 2019 08:14:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YqokTOq8J5ZmgCWpjaDjtzxnSfOP1CRqi1dbO5xKe8g=; b=YwESWAGGP7ODTmgQ5DVt5JzyOpBNj1qbUpqnsfM5ibZ0eNn15a7QGVKCncxvhIoNLx gDWQIds6+NEHtenH15aLLdqFrqnzeYPJsEoyrjKrL47jRaeJLIr/W7As0tsVmwv+B3cb 0f41jMfgFXuOKIBZ4bDuAcS9jpul2xtpFkn5GbGZkJyktbf0NKbpR5UtmD+mixkJkSIx EYTIJzOvWMrzJ7iiHSqJMdKgBJEjAE9tQNxZfEMcuTK31SwOfKQvnx52QBV1MKrib84x V58FSWQNf07r38//Uq4m2TzSZU9zvpf9UNymMWsSkoXPsfQahMlkgtwIhy8baeK0I5yu 3IPg==
X-Gm-Message-State: APjAAAWNtRwH8EdBJ4M4lrQBoyHHVtTSNn0UgTOWQVETBznKp524F3Yz BkjmVS2XoQ1sKtY69GnweGR9U/qEUr/T53LdAhU=
X-Google-Smtp-Source: APXvYqwa4/k7h99RcelaAopxLfXtUpRLNjzll29lvbkR7tbH+Dg8AidKycAYwgerNRxbGUWfdQpFm1w1LoJ4ox/OhQM=
X-Received: by 2002:a05:6830:15c8:: with SMTP id j8mr3510792otr.112.1573143250149; Thu, 07 Nov 2019 08:14:10 -0800 (PST)
MIME-Version: 1.0
References: <840D094E-3A27-43AD-9FE7-D5BB05200DC5@akamai.com>
In-Reply-To: <840D094E-3A27-43AD-9FE7-D5BB05200DC5@akamai.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 07 Nov 2019 11:13:59 -0500
Message-ID: <CAMm+LwgaP+x8xQZuq5iKY-HZzXtJXKt-00nb+eO+HrKQhRr9XQ@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: "ietf-hub-boston@ietf.org" <ietf-hub-boston@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009b299a0596c3f498"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-hub-boston/5uyIx3eULtDdxu0MqN_1ph9uces>
Subject: Re: [Ietf-hub-boston] proof of work and consensus protocols
X-BeenThere: ietf-hub-boston@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "For IETFers in the Boston area." <ietf-hub-boston.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-hub-boston>, <mailto:ietf-hub-boston-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-hub-boston/>
List-Post: <mailto:ietf-hub-boston@ietf.org>
List-Help: <mailto:ietf-hub-boston-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-hub-boston>, <mailto:ietf-hub-boston-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 16:14:12 -0000

On Thu, Nov 7, 2019 at 10:12 AM Salz, Rich <rsalz@akamai.com> wrote:

> This came up during Phillip’s presentation, there’s apparently a new paper
> out:
>
>     https://twitter.com/IACR_News/status/1192387232855973889?s=19
>

Thanks.

I think I have come across a solution that actually solves the problems
raised at the hub meeting and it folds back on the central axiom I have
that each user should ultimately be their own root of trust.

So alice has a Mesh account which means that she has a DARE Catalog that
tracks her set of devices. That catalog is authenticated by means of a
Merkle Tree. So she creates an attestation at regular intervals and submits
it to her Mesh service which will include it in the service notary log and
ultimately mesh it in the internotary. And she will periodically accept the
attestation of her Mesh service and include it in her own chain.

So Alice will be her own ultimate root of trust.

Now we do have a Descartes daemon type situation. What if her Mesh service
defects?

But the whole point of this infrastructure is to allow Alice to
communicate. So can we somehow make it a condition of Alice being able to
communicate with Bob that they are going to discover a possible defection
by their respective Mesh services?


I think we can *provided that* the diameter of the inter-notarization graph
of the Mesh services is sufficiently bounded. Which is almost certainly
going to be the case as there will be at least one company offering an open
notarization service.