path: root/88/b1214fa2b33ba3f39fbac83ae2b6f8753b1aab

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 98E27C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 19:12:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 94DDB4EBB7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 19:12:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.25
X-Spam-Level: 
X-Spam-Status: No, score=0.25 tagged_above=-999 required=5
 tests=[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 N8QvUT8OJnnz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 19:12:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com
 [IPv6:2607:f8b0:4864:20::62d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 53A554D107
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 19:12:54 +0000 (UTC)
Received: by mail-pl1-x62d.google.com with SMTP id d8so6279217plg.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 04 Mar 2021 11:12:54 -0800 (PST)
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=a//42yBi6WI3kn5SYuVOrmX5G7LEhVF72WfkswjsQMM=;
 b=VJiMJGJht+4HwG94iaO5vOGepnudhfZTGc04i0vEl0lxYGbvhF13CFTIWN5dsM+rF/
 C5UkTGRLVQNcUGpuyAnDwCu5IaobxG2qdywzt8+3gL/3Lf79wJQvP9StQFGValvtuDHQ
 M3p6/A6XURTVuuO/56Terf5GzVM1cdgw/MgIr/VhnJghPykfmn6ZZWgbDlaDMoEBmpJj
 sSJ3eO9c9alnvsNAjARl1QnF2135ktoXMIDET3XtI+sikPwFPYaTgMksnZhLgCn3bbWm
 vT59upPxbpJAfhsMAV+ugT1JzQf11vYqugi7TcLRzRaGh+UgLfaBlD2oQ2rH2mm6gZ5t
 6YLg==
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=a//42yBi6WI3kn5SYuVOrmX5G7LEhVF72WfkswjsQMM=;
 b=CMiBHh9LwdQ6eMvTewqWYW6CyCM+xRyKpnkbpnOqAxnlM2heRNAmdt7i3iDh7MJazS
 qrI56AwkIu7DDjdMl94owib+99PKRPkOB+AECWCnn44jHnRLADDIw4zY90wY5XgjDrqy
 xliYUtgNFty5bqKdOI2k3yDLBFz0AsMbZSHemsr20kOBtRAF696PrOWqSkr3iQxOHxKw
 +2Xo3T5I8NjsMoVvzX/mtTDPW46VKqegJGqKp9Yjy7cXac4dpd4MgYUmIb4r89jOI+59
 kIE3gQHNk6m/lXgzHpIxWCrcLE3BH0L4Zzj66cWIk0FRCJLdeoYhzC7sRr4vgJobLWM3
 lx8A==
X-Gm-Message-State: AOAM531YeFYMQ02wgN0Qy47v+BvrwV28dBRv4iTMoE6EbVA8UbYZVajb
 KKb037pbFvnND8mtETP5Cl/j0CAIAGsgRjkbK71+dkqxbQjp0BY=
X-Google-Smtp-Source: ABdhPJzfZ8QJa5uMT8azzfRe7VZ5MSVoTeaUJLjLgnyZzY4UvR7SK31Wl5txAM8V2u89OMCfqLx2YYMa6xVKgoNJ9nA=
X-Received: by 2002:a62:38c8:0:b029:1ef:21ba:aba3 with SMTP id
 f191-20020a6238c80000b02901ef21baaba3mr3363493pfa.24.1614883229433; Thu, 04
 Mar 2021 10:40:29 -0800 (PST)
MIME-Version: 1.0
References: <CAJXtxWmwtmGSA5zG0bWmNi0=ZRMZ=kZKr3SpzBr_dQcDrRhsqA@mail.gmail.com>
In-Reply-To: <CAJXtxWmwtmGSA5zG0bWmNi0=ZRMZ=kZKr3SpzBr_dQcDrRhsqA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 4 Mar 2021 13:40:18 -0500
Message-ID: <CAJowKg+Bs7HyrOH8ANs3nXxQ5mtmRnfHrHoRNL=hfOm+JTSuQA@mail.gmail.com>
To: John Rand <johnqrand@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: Thu, 04 Mar 2021 19:31:22 +0000
Subject: Re: [bitcoin-dev] MASF=true + LOT=informational
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: Thu, 04 Mar 2021 19:12:55 -0000

And of course:

1) MASF=3Dtrue + LOT=3Deventually true

Using a declining activation threshold over time gives miners control
only over the timing of activation, not the eventuality.   This is
essentially the same as LOT=3Dtrue, however, it has a greater chance of
activation without requiring intervening releases or changes to the
code.

On Thu, Mar 4, 2021 at 1:15 PM John Rand via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> With reference to considerations https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2021-March/018555.html and motivation to find consensus on =
incrementally improving Bitcoin soft-fork activation mechanisms.  (TL;DR Co=
nsensus is important for the activation mechanism as there are more soft-fo=
rks that Bitcoin will need.  We need to incrementally improve activation me=
chanisms.  It could become critical that Bitcoin prevails in achieving a fu=
ture upgrade even against powerful interests.)
>
> These activation configurations have been discussed with rationales.
>
> 1) MASF=3Dtrue + LOT=3Dfalse
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
380.html
>
> Try LOT=3Dfalse first, with a potential to change to LOT=3Dtrue if pools =
and miners were to unreasonably delay MASF activation.  (By later deploying=
 a revised activation mechanism with LOT=3Dtrue or other.)
>
> Arguments against have included a major concern about perpetuating the ri=
sk demonstrated by the BIP 141 / BIP 9 with potential for misuse and misund=
erstanding of a normative mechanism as a political veto.  Such veto can be =
overridden by the market, but the forced need to do so increases drama and =
risk.
>
> Arguments in favor include being defensive to avoid misinterpretation abo=
ut developer control, and being considered and incremental in starting with=
 a safe conservative approach https://old.reddit.com/r/Bitcoin/comments/lcj=
hl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
>
> Though it should be acknowledged and taken into account that disagreement=
 and potential for partly incompatible clients with different activation co=
nfiguration, changes the risk calculation for LOT=3Dfalse.  So that LOT=3Df=
alse may not be safer in practice, and does not wash reference client devel=
opers hands of contributing to the combined risk.
>
> 2) MASF=3Dtrue + LOT=3Dtrue
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018545=
.html
>
> Arguments in favor, inverse of above.  But if LOT=3Dtrue is a hidden flag=
 in bitcoin reference code, or released by another project, then misinterpr=
etation of developer control is avoided.
>
> Would there be consensus for the reference implementation doing nothing, =
and signal intent to follow the market if a non-contentious LOT=3Dtrue gain=
s traction?  With explicit communication of this intent and reason for init=
ial non-inclusion.
>
> There were also concerns about offending miners.  This concern seems dubi=
ous to many, given pools indicated ~90% support https://taprootactivation.c=
om/ and are less detail oriented.  But also BIP 148/ BIP 91 sequence events=
 was enormously dangerous and worth minor social cohesion to avoid as a cat=
egory of risk.
>
> Against the realism of developer control, if there were a market need to =
reject a soft-fork, that can also be done with a UASF.  But UASF is dramati=
c and the signaling direction against should be reserved for the low probab=
ility outcome.
>
> 3) MASF=3Dfalse + LOT=3Dinformational
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
495.html
>
> No miner activation.  This is interesting in using the non-standardness p=
art of schnorr to activate at a flag height without normative signaling in =
version bits.  But the combined removal in this proposal of (normative sign=
aled) MASF is problematic for the needless delay it creates.
>
> It seems probable that the delay itself would motivate users to switch to=
 clients with MASF+UASF (LOT=3Dtrue) in protest.  It is true that schnorr r=
equires wallet work, but that overlooks the philosophical nature of the rej=
ection of unneeded delay and empirical evidence shows rather conclusively t=
hat ecosystem players are predominantly selectively lazy and only work on B=
itcoin infrastructure upgrades after the fact.
>
> Subsequent posts on the thread with this proposal discuss that informatio=
nal signaling be substituted so that users and the market can benefit from =
the information about miner intent.  As it is non-normative it seems hard t=
o argue against: more information is better.
>
> 4) MASF=3Dtrue + LOT=3Dinformational
>
> From the above it would be interesting to see discussion of a combination=
 of MASF=3Dtrue (same mechanism as 1 or 2) with LOT=3Dinformational (mechan=
ism from 3).  Where, again, informational means signaling is provided but i=
n an optional and informational sense, that is not normative for consensus =
code, but to inform the ecosystem about a hashrate verified opt-in assertio=
n of readiness from pools.  In some way that could be more reliable in sign=
aling a willing readiness rather than a UASF under duress mandatory signal.
>
> Consider also with 2 or 4) alike (or 1 after switching to 2), in the even=
t that activation were unreasonably delayed, forced miner signaling from 2)=
 could be argued to be less reliable as the mechanism for signaling on pool=
s has no automated link to fullnode software version.  In the MASF delay ev=
entuality, where the flag height is relied upon, users and services would b=
e well advised to ensure they are running schnorr validating fullnodes, and=
 for SPV users to verify their wallet relies on schnorr upgraded fullnodes.
>
> John R
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev