John Rand [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-03-03 to 2021-03-04
💬 Posted a total of 2 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:30:04

- reply

📅 Original date posted:2021-03-04
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210304/0bf18cf7/attachment-0001.html>

2023-06-07 18:30:03

- reply

📅 Original date posted:2021-03-03
📝 Original message:Consensus is important for both taproot and separately for the activation
mechanism. There are more soft-forks that Bitcoin will need, so it is
important to achieve positive progress on the activation topic also, not
get impatient and rush something ill-considered. Not all future soft-forks
maybe as widely supported as taproot, and yet it could become existentially
critical that Bitcoin prevails in achieving a future upgrade in dramatic
circumstances, even against powerful interests counter to Bitcoin user and
investors interests. We should treat the activation topic in a considered
way and with decorum, provide tight non-emotive reasoning devoid of
frustration and impatience. This is a low drama and convenient time to
incrementally improve activation. People have varied views about the
deciding factor, or even which factors resulted in segwit activating after
BIP 141 failed using BIP 9. We do not have to solve everything in one
step, incremental improvement is good, for complex unintuitive topics, to
learn as we go - and it should not be hard to do less badly than what
transpired leading up to BIP 148 and BIP 91. Failure to upgrade if
permanent, or demoralizing to protocol researchers could be a systemic risk
in itself as there are more upgrades Bitcoin will need. We are not Ents
but we should use our collective ingenuity to find an incremental
improvement for activation.
John R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210303/fb745775/attachment.html>

2023-06-07 18:30:03

- reply