path: root/a1/de0e483d36d647fea76f859b39dcedf0900555

Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 822C1C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Apr 2021 22:37:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 59D4240EAC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Apr 2021 22:37:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level: 
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ig-80ZqNbZBC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Apr 2021 22:37:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com
 [IPv6:2607:f8b0:4864:20::52c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0D56440EA5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Apr 2021 22:37:00 +0000 (UTC)
Received: by mail-pg1-x52c.google.com with SMTP id z16so1610597pga.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Apr 2021 15:37:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :content-transfer-encoding;
 bh=xXXN0BFbYlZwKfIDriikjG/YR6pVy+dgILQLVgXUXfE=;
 b=XX8Ta+T8M7dOAx7ObzBbDsG+h/vEaJSCpJ9vu61MvkU7lsBdSs5xrXJe62RpDKDbu3
 LUAvX6mpW193NmQCQOBHGd6stecl1co1X9c3+tzX1kIJrb9mBns/zGdgS6dGYAFZZLmk
 HAUsm/gwFPaDxhVo7GC9wuw7nB1RVtT7Etk1d09mlQuekp+z0Vg3F6o/fYCiMCi4FREp
 t8rlTSm6VPY0I1IfIcTKnaKHntQNXzPEwRItE0XKPnnPkPOnHoxzGyLtviOerQn5TwT9
 BV1aKUUa/ej26eXHl5wWTZDT1R0J+OYikn28G0C75G4BN1rFeVEDu6yEu8tqicBh59a4
 lZ+A==
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:content-transfer-encoding;
 bh=xXXN0BFbYlZwKfIDriikjG/YR6pVy+dgILQLVgXUXfE=;
 b=QcOrnSw3PJWaX61UyMu+baBz98bdYoLokfNSP9c2Ws16wCMwcyVQBJWyBsRGl7LXsa
 fj5ZzCJDCfaEphgjUneLvy0EOOpxxseymJZFCHjiUg+aJVRfXZdBvKMVgufBlj3577Ec
 VcTly3AQp+lYdaf6qZpzQdMgtB9hVatyyHw4TjgCsZpsUMIFYx6aX1q71+hqqwy8VTXm
 KmTI0FQYZFyamfauAnQf+KJ1Ie7Y7NRTcY6mAK/1DXTJFM4cH1ShBt4tmhudifeeN1MO
 OjC+RZ9/89lfwOjvifYPGxb/2HmeD7nksHZxIkJVYFJN4TO0O4YvWcZzxH5WXiGW04C5
 7U5g==
X-Gm-Message-State: AOAM533SwB/OmBHlW6fH17XYPXa8jw+jec9o+ZoeMMFpytQLTCgeweaP
 12D5e36s1sfl2j/JUsv1bxq3f4mavAMzheytzif8g28=
X-Google-Smtp-Source: ABdhPJwjOKIq5sOcc6XjHMt7PAeVLEORPEs647OX4WDGJT1rQhapkWkd5jfkENoI07HxxbN3x2piEq6Y64MC11Z2N5U=
X-Received: by 2002:a63:144e:: with SMTP id 14mr3152969pgu.53.1617662220130;
 Mon, 05 Apr 2021 15:37:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAFvNmHSO1qBv2Lm4uHq82oEx5nxayKRsyP3Vx6BNfHJiOaztPQ@mail.gmail.com>
In-Reply-To: <CAFvNmHSO1qBv2Lm4uHq82oEx5nxayKRsyP3Vx6BNfHJiOaztPQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 5 Apr 2021 18:36:48 -0400
Message-ID: <CAJowKgJS4UY_FVf7i18WFRYVHR0+EhJ066UwHFngvz8dxuoYaQ@mail.gmail.com>
To: Michael Folkson <michaelfolkson@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 05 Apr 2021 23:07:36 +0000
Subject: Re: [bitcoin-dev] Announcing a new standard for soft fork activation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Apr 2021 22:37:02 -0000

this satire points out the "bikeshedding" problem, or the "law of trivialit=
y".
a problem is discussed in proportion to the number of people who feel
qualified to talk about them.
few users are experts at the cryptography, and even fewer are experts
at c++, cryptography and possibly game theory
therefore the number of people who feel qualified to analyze or
discuss the proposed changes are few  (schorr sigs are hopefully the
least controversial)
whereas the mechanism for activation is relatively easy to understand

schnorr:  improved signature scheme, can reduce tx size (ACK)
mast: reduces tx size and improve privacy of of complex contracts (ACK)
taproot: mast... but it looks like p2pkh (ACK)
activation:   bikeshedding not necessary now.

On Thu, Apr 1, 2021 at 11:15 AM Michael Folkson via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There have been a vast number of proposals for soft fork activation in re=
cent months and it is important that all these important ideas don=E2=80=99=
t go to waste. Hence I propose a new standard for soft fork activation inco=
rporating all the ideas into one standard. I appreciate this standard has c=
ome too late for Taproot activation but it should be ready for any future s=
oft forks. It is a multi phase, multi year standard. No soft fork can activ=
ate unless and until it has successfully passed through all of the differen=
t 14 phases. This will demonstrate Bitcoin=E2=80=99s ultimate conservatism.
>
> Phase 1) Let=E2=80=99s See What Happens - BIP 8 (false, 0.25 years). The =
shortest phase just to whet appetites.
>
> Phase 2) Start now, improve later - BIP 8(false, 1 year) A confusing name=
, it starts but it doesn't improve later
>
> Phase 3) BIP 9 equivalent - BIP 8(false, 1 year)
>
> Phase 4) Gently discourage apathy - BIP 8(true, 1 year) Forced signaling =
at the end of this phase but obviously there are still many phases before t=
he soft fork can actually activate.
>
> Phase 5) BIP 91 (1 year). As a nod to our SegWit history we have a BIP 91=
 activation phase.
>
> Phase 6) BIP 148 (1 year). Some people disagree that BIP 91 activated Seg=
Wit so we do a BIP 148 activation phase to keep those people happy. Again f=
orced signaling doesn=E2=80=99t actually mean activation. There are still m=
any more phases to pass through.
>
> Phase 7) Speedy Trial (using block height, 0.5 years) on mainnet
>
> Phase 8) Speedy Trial (using MTP, 0.5 years) on mainnet
>
> Phase 9) Speedy Trial on the default signet (0.5 years)
>
> Phase 10) Speedy Trial on a combination of three different custom signets=
 in parallel (0.5 years)
>
> Phase 11) Speedy Trial on testnet and a custom signet in parallel (0.5 ye=
ars)
>
> Phase 12) Modern Soft Fork Activation (3.5 years) This is the longest pha=
se of the soft fork activation standard. It is itself multi phase and multi=
 year so this can be considered a nested activation phase within this stand=
ard.
>
> Phase 13) UASF BIP 8 (LOT=3Dtrue, 1 year). Forced miner signaling at the =
end of this phase but ultimately the soft fork doesn=E2=80=99t yet activate=
 as there is one final additional phase the activation must pass through. T=
his gives Samson the opportunity to sell some hats. We are close now. The n=
atives are getting restless.
>
> Phase 14) Second flag day (1 year) We don=E2=80=99t want those pesky user=
s actually activating a soft fork on their own so an additional flag day is=
 added just so we can tell users that we prevented a chain split.
>
> Assuming a soft fork activation has successfully passed through all these=
 14 phases it should activate. It will take a minimum of 13 years. However,=
 if it fails during any one of these phases it has to start from Phase 1 ag=
ain. We should take Bitcoin=E2=80=99s conservatism very seriously. If a sof=
t fork activation can=E2=80=99t pass successfully through all these phases =
it shouldn=E2=80=99t activate. Ultimately we don=E2=80=99t really mind what=
 is in the soft fork (any idiot can design consensus changes and write secu=
re bug free C++ code) that is very much secondary in importance to *how* th=
e soft fork is activated. The activation design absolutely must be conserva=
tive.
>
> I expect this rigorous standard for soft fork activation will get a BIP n=
umber. If you are going to propose a future soft fork I recommend you plan =
for activation in approximately 13 years from the point the soft fork code =
is merged into Core.
>
> I am happy to settle the soft fork activation question once and for all f=
or the community. I expect in time my contribution will be recognized in th=
e annals of history with Satoshi Nakamoto and Hal Finney.
>
> Addendum: Although all future soft forks will ultimately use this standar=
d, this standard is copyrighted. Every time it is used royalties must be pa=
id into this quantum secure Bitcoin vanity address 1quantumsecureaddress
>
>
> --
> Michael Folkson
> Email: michaelfolkson@gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev