Re: [admin-discuss] Next steps towards a net zero IETF

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 23 March 2023 01:58 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE98C14CE3B; Wed, 22 Mar 2023 18:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pwb8SKa1Iakb; Wed, 22 Mar 2023 18:58:15 -0700 (PDT)
Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750F7C14CE25; Wed, 22 Mar 2023 18:58:15 -0700 (PDT)
Received: by mail-oi1-f173.google.com with SMTP id bk5so5866612oib.6; Wed, 22 Mar 2023 18:58:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679536694; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+QFGIsnUxDpYfuXFmzspREf6CNS6E3MMztm4N+SVfUc=; b=eBxy9uM45npvHU8CwSFt90kXyzBBfUTpEZoaTm2MDJhpISFpIuU/B1nbNQANpB7JGf t6dcuAEN03YAtu++a5qITDbWSh7sgUuqFqbHTD3+gNJr6LI58UCw/k7iqlzlCqKKNBdq jKnv7Phl591zSB/yaeyX6vWbPto5ApKXOxREiFWk5B2xiGeTOhbCTxo70su4GAmCovrI Oq4XRWYOYVbxLyCMTv4FbrgxhpkSvYCM+rEdWVvpn07GczS7AM2rPwZiPhQe34vdDyuZ pdC2gNCQZNMr6lnLDsNcdatO32ZUpWyQREdYyjBX/k66p5lbgp4xJdpo2oJuGiAtERdi 8iUA==
X-Gm-Message-State: AO0yUKUnOEznIC4KQyEbO/F6ipD0wviMumTlXtZrZ2YmKpSsB5tcGpNv MLfxnFJOa1i9FE+hF0dSTrwuGlVP0yqrezrZVC97DW4kwCc=
X-Google-Smtp-Source: AK7set8L6JMgcvjpkHw+qhKz6VpfeA0wdSiP4qUaVMR7jL0yKK0qizn1txhbInaNdbOZR1wUXi9YBt09O91u8Kma9uI=
X-Received: by 2002:a05:6808:b38:b0:386:b6a7:c093 with SMTP id t24-20020a0568080b3800b00386b6a7c093mr1561663oij.6.1679536694550; Wed, 22 Mar 2023 18:58:14 -0700 (PDT)
MIME-Version: 1.0
References: <20230321210158.6uelg47rosiswjxq@crankycanuck.ca> <20230321220809.1E3DAB43AB7D@ary.qy> <CAMm+LwjCXPmQGd+KMdmGb=sGa45LegFoJc4=6=X0HJqEKSkOPg@mail.gmail.com> <BYAPR13MB2582BF53A407A4259C6A816EF4879@BYAPR13MB2582.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB2582BF53A407A4259C6A816EF4879@BYAPR13MB2582.namprd13.prod.outlook.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 22 Mar 2023 21:58:03 -0400
Message-ID: <CAMm+LwhE_LeUaF5YeqXRJbcrbzSQsDp=tqLf2fLYRZ1Epm=ENg@mail.gmail.com>
Subject: Re: [admin-discuss] Next steps towards a net zero IETF
To: Michael McBride <michael.mcbride@futurewei.com>
Cc: "admin-discuss@ietf.org" <admin-discuss@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000010e7c405f7879c7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wrmXjvo-gTQ0f4CJxTMDZKMF4S0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2023 01:58:17 -0000

Proof of Stake is what has enabled all these crypto-Ponzi schemes, it
introduced the notion of getting paid 'interest' on your crypto. Yes, I
know that Etheruem only started POS recently but the idea that it 'might
happen' was enough for the FTX fraud.

There is no need to create a fake currency to prevent rollback attacks on a
digest chain. Don't need proof of work or proof of stake or any fake
currency. All you need is to mesh all the chains together so that 1) nobody
can defect without the defection being visible and 2) everyone becomes
their own ground truth for evaluating notarized signatures - provided they
were running their own notary log at the time.


On Wed, Mar 22, 2023 at 9:05 PM Michael McBride <
michael.mcbride@futurewei.com> wrote:

> > Best thing we could do for the planet would be to develop a technology
> that kills TTTSNBN dead
>
>
>
> Let’s do it. PoS already uses 99.95% less energy than PoW. Perhaps we can
> do better.
>
>
>
> mike
>
>
>
> *From:* ietf <ietf-bounces@ietf.org> *On Behalf Of * Phillip Hallam-Baker
> *Sent:* Wednesday, March 22, 2023 4:07 PM
> *To:* admin-discuss@ietf.org
> *Cc:* ietf@ietf.org
> *Subject:* Re: [admin-discuss] Next steps towards a net zero IETF
>
>
>
> OK, I am going to say something that is going to make a lot of people
> annoyed. But hold on.
>
>
>
> This issue of carbon credits being bogus is actually one of the incredibly
> rate problems for which TTTSNBN[*] could actually be used for. Of course,
> there is the fact that TTTSNBN is  absolutely the most stupid and wasteful
> technology on the planet but some form of cryptographically authenticated,
> append only log technology is actually something that could be used to
> provide transparency in a carbon credit scheme.
>
>
>
> OK so what can IETF participants do?
>
>
>
> Best thing we could do for the planet would be to develop a technology
> that kills TTTSNBN dead. That instantly saves 0.5% of emissions from
> electricity generation.
>
>
>
> Next best thing we could do is to fix carbon credits so that they are more
> transparent.
>
>
>
> Finally, IETF can meet less often in plenary session. Meeting three times
> a year is a very poor application of time and resources. I understand the
> reasons, I do not find them persuasive.
>
>
>
>
>
> Now before folk get started, note that I said 'IETF participants' not
> IETF. I am pretty sure that there are many here with the skills. Is this
> the right venue? Probably not.
>
>
>
> I do have something of a scheme though. If folk look at my Mesh
> technology, they will see that the latest version makes use of cross
> notarized Merkle-tree indexed logs as a basic primitive. So every Mesh user
> generates their own notary log which is their ground truth. Users
> periodically cross notarize with their Mesh Service Provider which in turn
> cross notarizes with the Mesh callsign service. Thus every personal Mesh
> notary log is meshed to every other.
>
>
>
> What this gives is a better, more robust notary log than TTTSNBN without
> any proof of waste whatsoever.
>
>
>
> Another interesting feature of the next release is that the Mesh Messaging
> client allows every Mesh user to be their own Messaging service provider.
> Which might have some interesting implications with respect to some
> legislation being proposed in my native country.
>
>
>
>
>
> [*] The Technology That Shall Not Be Named.
>