path: root/92/155d5a7d0bb4ccb9c689fd4165602f3fb94b0e

Return-Path: <johnqrand@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 80883C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 17:54:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6346843282
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 17:54:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.877
X-Spam-Level: 
X-Spam-Status: No, score=0.877 tagged_above=-999 required=5
 tests=[DATE_IN_PAST_03_06=1.076, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id e7GT1eQtAx9c
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 17:54:32 +0000 (UTC)
X-Greylist: delayed 03:03:12 by SQLgrey-1.8.0
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [IPv6:2a00:1450:4864:20::52b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 158AF4326E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 17:54:31 +0000 (UTC)
Received: by mail-ed1-x52b.google.com with SMTP id h10so35988796edl.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 04 Mar 2021 09:54:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=zukLdD4KJ89ix0owHGjlti1Z7OdewzKWe9zBu/fa7wQ=;
 b=jvbSdK3itfNwDyAXlorKv4lPNkxmN37abCCcDstK7de0Df/AqjZjsSXX6Np2QQfbgm
 o6Z4l4JZUhKj6T1I24m58lofFovGocL6WrkmWsmdtj5cF8cIdKDlLFGYicr3JEKNKc6T
 fuCFR2rXfpruhYiZDcBcm+MYSO2dgEYQdPiKKOM39vttyOyxgoCFLvUo0UT6xFgOp6Vf
 VehDjrV33OwmbxJqkiEI901d0P4xdkARxwnsJh0o8WJ6uGWZ1U3T4HP9w7vfIwG8r89S
 A6hXCpfheWmSDmXCfqQD93sXQ/jJTHgNlGTeLX7Tm8jLK2eo1wQhFhH8w5Fy42Vn6G6s
 c8aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=zukLdD4KJ89ix0owHGjlti1Z7OdewzKWe9zBu/fa7wQ=;
 b=GDIqCYcV8OevecLIJaLWdtdROYZ3VJjuBSJysc86u7UFCeZmjsVlrkz565Cwuhd/6t
 XxGTPObJl/5Dj72YYLahnldwiL0iGVfW0Ctqr9rA2Gxq54gzMrR9Aj+dUu8kZveZ28sm
 PDPZoanT2xXb0yX0+Fp6L1/eBtyofHeFexWmCuhhnv9U2XqNTM9Pmro1rl5+tD9jQrGk
 vSLtsxnhrQoAwNWdLUEL76TUB4y9tI2Ba0VZMJWyeyqzVKkfqqeGa9A28CO/pgIgQeXg
 laV35WaIwZ7BccFlmj9fOjj/uRBJd3zZ5qhhn1EiaAJFp8+DS4wuN19vMrSE4dmMQBi8
 8l2A==
X-Gm-Message-State: AOAM531+3Vk4KGanDyEhVmxT/dkdHkaqUOjFTmGacfIWzy0fmmxMj0no
 RzKwNiXEh/8aUTfme3YN7USlMnjJJk0WUqpCQx1w8vJAcFw3Uw==
X-Google-Smtp-Source: ABdhPJzV7aelSbHh6ZU3uwgNh+gzEhNBGJ6N7qD0BtpUgmiIwJSpb2YVMJhcbax7l9YP4WMwtCsyZTT0TdA+fzqD6Kk=
X-Received: by 2002:a2e:b043:: with SMTP id d3mr2472753ljl.280.1614867953450; 
 Thu, 04 Mar 2021 06:25:53 -0800 (PST)
MIME-Version: 1.0
From: John Rand <johnqrand@gmail.com>
Date: Thu, 4 Mar 2021 14:25:41 +0000
Message-ID: <CAJXtxWmwtmGSA5zG0bWmNi0=ZRMZ=kZKr3SpzBr_dQcDrRhsqA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000b9809905bcb6be51"
X-Mailman-Approved-At: Thu, 04 Mar 2021 18:15:21 +0000
Subject: [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 17:54:33 -0000

--000000000000b9809905bcb6be51
Content-Type: text/plain; charset="UTF-8"

With reference to considerations
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018555.html
and motivation to find consensus on incrementally improving Bitcoin
soft-fork activation mechanisms.  (TL;DR Consensus is important for the
activation mechanism as there are more soft-forks that Bitcoin will need.
We need to incrementally improve activation mechanisms.  It could become
critical that Bitcoin prevails in achieving a future upgrade even against
powerful interests.)

These activation configurations have been discussed with rationales.

1) MASF=true + LOT=false

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html

Try LOT=false first, with a potential to change to LOT=true if pools and
miners were to unreasonably delay MASF activation.  (By later deploying a
revised activation mechanism with LOT=true or other.)

Arguments against have included a major concern about perpetuating the risk
demonstrated by the BIP 141 / BIP 9 with potential for misuse and
misunderstanding 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 about
developer control, and being considered and incremental in starting with a
safe conservative approach
https://old.reddit.com/r/Bitcoin/comments/lcjhl6/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
configuration, changes the risk calculation for LOT=false.  So that
LOT=false may not be safer in practice, and does not wash reference client
developers hands of contributing to the combined risk.

2) MASF=true + LOT=true

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018545.html

Arguments in favor, inverse of above.  But if LOT=true is a hidden flag in
bitcoin reference code, or released by another project, then
misinterpretation 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=true gains
traction?  With explicit communication of this intent and reason for
initial non-inclusion.

There were also concerns about offending miners.  This concern seems
dubious to many, given pools indicated ~90% support
https://taprootactivation.com/ 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 category 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
dramatic and the signaling direction against should be reserved for the low
probability outcome.

3) MASF=false + LOT=informational

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018495.html

No miner activation.  This is interesting in using the non-standardness
part of schnorr to activate at a flag height without normative signaling in
version bits.  But the combined removal in this proposal of (normative
signaled) 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=true) in protest.  It is true that schnorr
requires wallet work, but that overlooks the philosophical nature of the
rejection of unneeded delay and empirical evidence shows rather
conclusively that ecosystem players are predominantly selectively lazy and
only work on Bitcoin infrastructure upgrades after the fact.

Subsequent posts on the thread with this proposal discuss that
informational 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 to argue against: more information is better.

4) MASF=true + LOT=informational

From the above it would be interesting to see discussion of a combination
of MASF=true (same mechanism as 1 or 2) with LOT=informational (mechanism
from 3).  Where, again, informational means signaling is provided but in an
optional and informational sense, that is not normative for consensus code,
but to inform the ecosystem about a hashrate verified opt-in assertion of
readiness from pools.  In some way that could be more reliable in signaling
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 event
that activation were unreasonably delayed, forced miner signaling from 2)
could be argued to be less reliable as the mechanism for signaling on pools
has no automated link to fullnode software version.  In the MASF delay
eventuality, where the flag height is relied upon, users and services would
be 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

--000000000000b9809905bcb6be51
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>With reference to considerations <a href=3D"https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018555.html">http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018555.html<=
/a> and motivation to find consensus on incrementally improving Bitcoin sof=
t-fork activation mechanisms.=C2=A0 (TL;DR Consensus is important for the a=
ctivation mechanism as there are more soft-forks that Bitcoin will need.=C2=
=A0 We need to incrementally improve activation mechanisms.=C2=A0 It could =
become critical that Bitcoin prevails in achieving a future upgrade even ag=
ainst powerful interests.)</div><div><br></div><div>These activation config=
urations have been discussed with rationales.</div><div><br></div><div>1) M=
ASF=3Dtrue + LOT=3Dfalse</div><div><br></div><div><a href=3D"https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html">https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html=
</a><br></div><div><br></div><div>Try LOT=3Dfalse first, with a potential t=
o change to LOT=3Dtrue if pools and miners were to unreasonably delay MASF =
activation.=C2=A0 (By later deploying a revised activation mechanism with L=
OT=3Dtrue or other.)</div><div><br></div><div>Arguments against have includ=
ed a major concern about perpetuating the risk demonstrated by the BIP 141 =
/ BIP 9 with potential for misuse and misunderstanding of a normative mecha=
nism as a political veto.=C2=A0 Such veto can be overridden by the market, =
but the forced need to do so increases drama and risk.</div><div><br></div>=
<div>Arguments in favor include being defensive to avoid misinterpretation =
about developer control, and being considered and incremental in starting w=
ith a safe conservative approach=C2=A0<a href=3D"https://old.reddit.com/r/B=
itcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02=
w/" style=3D"white-space:pre-wrap">https://old.reddit.com/r/Bitcoin/comment=
s/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/</a>=C2=A0=
=C2=A0</div><div><br></div><div>Though it should be acknowledged and taken =
into account that disagreement and potential for partly incompatible client=
s with different activation configuration, changes the risk calculation for=
 LOT=3Dfalse.=C2=A0 So that LOT=3Dfalse may not be safer in practice, and d=
oes not wash reference client developers hands of contributing to the combi=
ned risk.</div><div><br></div><div>2) MASF=3Dtrue=C2=A0+ LOT=3Dtrue</div><d=
iv><br></div><div><a href=3D"https://lists.linuxfoundation.org/pipermail/bi=
tcoin-dev/2021-March/018545.html">https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2021-March/018545.html</a><br></div><div><br></div><div>Argu=
ments in favor, inverse of above.=C2=A0 But if LOT=3Dtrue is a hidden flag =
in bitcoin reference code, or released by another project, then misinterpre=
tation of developer control is avoided.</div><div><br></div><div>Would ther=
e be consensus for the reference implementation doing nothing, and signal i=
ntent to follow the market if a non-contentious LOT=3Dtrue gains traction?=
=C2=A0 With explicit communication of this intent and reason for initial no=
n-inclusion.</div><div><br></div><div>There were also concerns about offend=
ing miners.=C2=A0 This concern seems dubious to many, given pools indicated=
 ~90% support <a href=3D"https://taprootactivation.com/">https://taprootact=
ivation.com/</a> and are less detail oriented.=C2=A0 But also BIP 148/ BIP =
91 sequence events was enormously dangerous and worth minor social cohesion=
 to avoid as a category of risk.</div><div><br></div><div>Against the reali=
sm of developer control, if there were a market need to reject a soft-fork,=
 that can also be done with a UASF.=C2=A0 But UASF is dramatic and the sign=
aling direction against should be reserved for the low probability outcome.=
</div><div><br></div><div>3) MASF=3Dfalse + LOT=3Dinformational</div><div><=
br></div><div><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoi=
n-dev/2021-February/018495.html">https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2021-February/018495.html</a><br></div><div><br></div><div>No=
 miner activation.=C2=A0 This is interesting in using the non-standardness =
part of schnorr to activate at a flag height without normative signaling in=
 version bits.=C2=A0 But the combined removal in this proposal of (normativ=
e signaled) MASF is problematic for the needless delay it creates.=C2=A0=C2=
=A0</div><div><br></div><div>It seems probable that the delay itself would =
motivate users to switch to clients with MASF+UASF (LOT=3Dtrue) in protest.=
=C2=A0 It is true that schnorr requires wallet work, but that overlooks the=
 philosophical nature of the rejection of unneeded delay and empirical evid=
ence shows rather conclusively that ecosystem players are predominantly sel=
ectively lazy and only work on Bitcoin infrastructure upgrades after the fa=
ct.</div><div><br></div><div>Subsequent posts on the thread with this propo=
sal discuss that informational signaling be substituted so that users and t=
he market can benefit from the information about miner intent.=C2=A0 As it =
is non-normative it seems hard to argue against: more information is better=
.</div><div><br></div><div>4) MASF=3Dtrue=C2=A0+ LOT=3Dinformational<br><br=
></div><div>From the above it would be interesting to see discussion of a c=
ombination of MASF=3Dtrue (same mechanism as 1 or 2) with LOT=3Dinformation=
al (mechanism from 3).=C2=A0 Where, again, informational means signaling is=
 provided but in an optional and informational sense, that is not normative=
 for consensus code, but to inform the ecosystem about a hashrate verified =
opt-in assertion of readiness from pools.=C2=A0 In some way that could be m=
ore reliable in signaling a willing readiness rather than a UASF under dure=
ss mandatory signal.</div><div><br></div><div>Consider also with 2 or 4) al=
ike (or 1 after switching to 2), in the event that activation were unreason=
ably delayed, forced miner signaling from 2) could be argued to be less rel=
iable as the mechanism for signaling on pools has no automated link to full=
node software version.=C2=A0 In the MASF delay eventuality, where the flag =
height is relied upon, users and services would be well advised to ensure t=
hey are running schnorr validating fullnodes, and for SPV users to verify t=
heir wallet relies on schnorr upgraded fullnodes.<br></div><div><br></div><=
div>John R</div><div></div></div>

--000000000000b9809905bcb6be51--