path: root/17/6d2e4864b6d59ba7f8f42f1434bcbf8f234e0e

Return-Path: <arielluaces@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 75BEBC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 23:39:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4E3EB4ED79
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 23:39:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5
 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
 DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.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 VUCK0fq4nMbq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 23:39:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [IPv6:2a00:1450:4864:20::134])
 by smtp4.osuosl.org (Postfix) with ESMTPS id B1E754ED78
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 23:39:23 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id b1so6650962lfb.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 05 Mar 2021 15:39:23 -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=UoFRvesiU/icZKorH5riFXrUPJrOb6Ub4AHr/WOPosk=;
 b=gjGk6GnFwlcxxljLVgYGa/vMAuEkNsnDmy4RyG5X3UIABCNEoA17XYnvH8O6PShw/i
 NvWhce8UINPz7ufhcGN7E5oz9Pui/3+n2rKUWAxJOTvnTSwFeZNs9sGkgPpYl31EKw9f
 XgEuiqR9PvVmekui6vPXpnJWrF0js5f1QBkWDkxLnSZimOvwOlXpQrch9K3spRApssbT
 0gT0oAugra7EC+kvdc2J4IfJyj/ZeDkqaxv4BuJqpcj185s+Ynde/TikdpeExIIxRXQR
 eo7uWcif99aCmM57GY+0PXOMCMGbEKut/r1uHzyndnN/yfXGpx7cU14SepyRerJkz1Pm
 hlPg==
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=UoFRvesiU/icZKorH5riFXrUPJrOb6Ub4AHr/WOPosk=;
 b=cqu2hcqZH+h7bPdUr/UJtuGsGYX+58GL8tljopG4iLSjd2WdXc4QAOJatK7ctU16rd
 yvpR4kiX1837puFzURDT/wxT2kYhLXrfivURU4seV9HggYGWqVGKm4U3rXoX6wqHV0mO
 0VyuaKFxvJRulyoaah5qrI8CJnwh04WEFpHPU377QBoeZU3K3ESdpZ0Od2ssj7zTTunM
 3sL1bWrIsWg7j8day6K8MiMF31yXGG/b6XnkHEuG0bjT45sKxkCwMkOrTowmBh16ohnh
 /jW4d+Ix04K+TDD4axT7hLJJ5teEvddtqMVQR/gvw9wh8igqRWM+uhaDoUnSUn9wqsdR
 oQnA==
X-Gm-Message-State: AOAM533kK7MWfXOEGp4OWISbXLzHsdTOcZ43tpUL/RXKVb6RngWm+0SW
 vBSDGW0vF/lthmmrqz9IiwVv2dksz85F/pMdo/oTFEHYvvg=
X-Google-Smtp-Source: ABdhPJxhe0oJ2vf3wZ0Wr57WY4BNu1Z4XyKfEBuri/hemzsrgZY7N76KnuZiDnM29qIunv/v5BZtTzW8Tq+9LK2hjO4=
X-Received: by 2002:ac2:5e6a:: with SMTP id a10mr7062324lfr.181.1614987560823; 
 Fri, 05 Mar 2021 15:39:20 -0800 (PST)
MIME-Version: 1.0
From: Ariel Luaces <arielluaces@gmail.com>
Date: Fri, 5 Mar 2021 15:39:24 -0800
Message-ID: <CAOv1TniX-tkGQuLvHB23QcUSJ+VwzzopTnEgchVYDDGuLbB92w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Sat, 06 Mar 2021 08:58:05 +0000
Subject: [bitcoin-dev] Supermajority then simple majority Taproot 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: Fri, 05 Mar 2021 23:39:26 -0000

I found a hint of common ground in reddit that I absolutely loves and
just had to share here on the ML to discuss


Luke's suggestion: To minimise the signal from 90% to 50%+1 during the
MUST_SIGNAL phase.
https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpkbdcg/


I think this proposal is a natural evolution:
From the creation of BIP9 to enable soft fork activations with low
risk under widespread miner support
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
To miner aggression against segwit, resulting in shaolinfry's
releasing the BIP148 and BIP91 proposals and a UASF client, resulting
in the Bitcoin civil war, resulting in settlement through economic
pressure.
To shaolinfry's creation of BIP8 to force a soft fork when
encountering minority miner apathy/malice and a desire for the majoity
of users to deploy
https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki
To Greg Maxwell's suggestion of two round activation with BIP9
followed by a flag-day activation (couldn't find the link, it's
mention in Matt's Modern Soft Fork Activation proposal)
To Matt Corallo's suggestion to do a BIP9 deployment followed by a
BIP8 deployment with a six month waiting period in between (Modern
Soft Fork Activation)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
To Luke Dashjr's addition of lockinontimeout to BIP8 to consolidate
the functionality of BIP8 and BIP9
https://github.com/bitcoin/bips/pull/550
To AJ Towns' suggestion of a gradually decreasing activation threshold
and a user configurable option between conditional activation and
guaranteed activation at the end
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018043.html
To Gregorio Guidi's suggestion of decreasing the threshold to 1.2% as
the locked in date approaches, allowing for activation failure and
removing of the LOT flag
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018476.html
To Ariel Lorenzo-Luaces' (me)  suggestion of switching the final
threshold to 50% to pose a reorg threat to non-upgraded miners instead
of risking a minority fork
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018529.html
To Luke Dashjr's suggestion of switching thresholds to 51% during the
MUST_SIGNAL phase instead of a gradualy decreasing threshold
https://old.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpkejqt/
(I hope I'm not missing anything)
To Matt Corallo seemingly liking the idea? It's hard to tell.


I think Luke's proposal fixes a lot of concerns on both sides of the
LOT discussion.
I went through all the Taproot activation discussion I could find, as
well as some old segwit activation discussions, and here I summarize
points that will hopefully convince all supporters from all sides of
the Taproot activation discussion.
Some points are repeated but framed differently based on the reader's
predisposition (LOT=true or LOT=false or flag day).
Something to note is that this is not a compromise, I mention it at the bottom.


The case for this new proposal for supporters of LOT=true first:
1. no veto bug) Miners wouldn't have veto power. If 51% of miners are
signaling during MUST_SIGNAL phase Taproot activates. This proposal
follows the will of the community. (point 5 on Matt's Modern Soft Fork
Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
2. signaling used for coordination instead of voting) The requirement
for a 95% supermajority vote disappears since those, what would have
previously been seen as, votes are irrelevant during the MUST_SIGNAL
phase. The 51% threshold is also seen as a coordination mechanism for
users to gauge miner support to automatically split from an unupgraded
miner minority.
4. low threshold UASF) It's much much easier to do a UASF marketing
blitz since only 51% of mining power needs to enforce the new rules
and the supermajority is not required. Mining power (51% of it needed)
will probably be convinced if exchanges, wallet software, and a
moderate number of users are on the Taproot activation side
(significant economic activity). This was a major problem in 2017
because it was uncertain whether signaling miners were running BIP9 or
UASF.
5. no UASF minority chain) If LOT=true is released and it never
achieves 50% signaling then there would be a fork and the UASF chain
will be exposed to attacks or destabilization due to miners switching
between chains. This proposal avoids that situation because it
guarantees that a majority of mining power is supporting Taproot so
the chain can't be attacked. You never really wanted to fork off from
your friends right?
3. nodes stay in consensus) If Taproot does not achieve a
supermajority but does achieve a simple majority (>51% PoW) at the end
of activation then upgraded users, upgraded miners, and non-upgraded
will all follow the taproot-active ruleset, leaving a minority of
miners to be exposed to reorgs if they don't enforce the new Taproot
rules. At this point the economic majority will very clearly be in the
taproot-activated chain so this creates strong pressure for the
minority of miners to capitulate or hard/soft fork off. (I imagine
they will capitulate... unless they want to have fun being poor)
6. no double spends) No need to stress about writing code to prevent
double spends the chain will stay together.
7. no PoW change) No need to stress about changing the PoW unless the
miner majority doesn't signal. In that case a flag day is needed with
a PoW change so the forked chain is safe. It's too risky to have to
re-upgrade, in the middle of Taproot deployment, to a new client to
deploy a PoW change in the event that the majority mining power is not
on board.
7. minority miners forced to comply or fork off) Zealous miners
against the proposed feature are forced to hard fork with an
anti-Taproot fork if signaling is greater than 51%. The hard fork will
have 49% in the worst case, probably much less if we assume humans are
greedy. The miner minority may attack if they are confident they will
succeed. But their success is unlikely due Nakamoto consensus.
8. no early adopter dilema) There is no reluctance of upgrading
because it's more likely the new version will be on the chain with the
most PoW. This fixes the early adopter dilemma.
9. no late adopter stress) Since the result of activation keeps all
users together and minority miners are forced off, late adopters don't
need to worry about upgrading their client to not risk being reorged.
They will be on the taproot activated chain.
10. majority attracts the undecided) At 51% of mining power and an
economic majority I would say Greg Maxwell's "opposed unless there is
clear consensus on LOT=true" is very well satisfied. (paraphrase
provided by michaelfolkson
http://gnusha.org/taproot-activation/2021-02-16.log)
11. discovered bugs can back out deployment) With forced activation
there is no way to back out activation unless all users revert to
using a previous version or upgrade to using a new fixed version. But
it's not guaranteed that all users will revert or upgrade. This
proposal allows a cancelation if we force the majority of miners to
not signal.
12. no alt-nodes) A UASF media blitz can achieve activation with 51%
miner support and can be executed with a client released by core
instead of an alt-node.
13. no dev+miner forced changes) Users maintain sovereignty in future
soft forks by maintaining the option of creating anti-feature hard
fork or soft fork movements as long as they have enough mining power
to maintain a safe chain. Miners and devs don't have ultimate power.
(unless a supermajority of both groups agree to an anti-user feature
but I find that unthinkable right now since the economic majority
wouldn't comply easily, may happen in the future, who knows)
14. no dev forced changes) Avoid a power grab from core developers and
a minority of users. They can't force a feature change because miners
and an economic majority together can veto. At minimum the forced
feature requires 51% mining power and zero user support, even in that
case majority users still have options. (point 10)
15. less miner polling pre-deployment) One of the rationales to lower
the activation threshold from 95% to 90% is due to 89% verbal miner
support https://taprootactivation.com/ . I saw some people wanted to
go as low as 85% or 80%, hell someone on the ##uasf channel wanted to
drop threshold to 65% to incentivize non-upgraded nodes to join the
UASF alt-node http://gnusha.org/uasf/2021-03-04.log . With this
proposal it doesn't matter if miners don't overwhelmingly support the
feature so their verbal input is less significant. Deployment can
happen as soon as 51% of mining power express verbal support, unlike
what's happening right now where miner apathy is delaying deployment
because no one is sure whether a supermajority is achievable.
16. new status quo) I'm not sure I understand when Luke says LOT=true
is status quo but this proposal probably fixes that too? This proposal
kind of acts like a flag day with the protection of a majority PoW.


The case for this new proposal for supporters of LOT=false first:
1. discovered bugs can back out deployment) The activation can be
canceled and the chain will remain united if any problem is found.
(point 1 on Matt's Modern Soft Fork Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
2. miner minority can't cancel) Only 51% of mining power can cancel if
a bug is found so a minority of miners can't abuse the threat of
canceling for political reasons.
3. no need for miner promises) In the back of the minds of LOT=false
supporters there is always the doubt of "what if we really can't trust
miners?". We can ask them and make them promise that they will support
the upgrade but we can never really know. With this proposal we don't
need to worry about a miner minority promising to signal and then
breaking the promise.
4. no UASF aggression at the start) Miners aren't antagonized because
they are still part of the signaling process and they keep their right
to run any client they want without the threat of a UASF. Though they
will eventually mine orphan blocks if they don't upgrade, which is
probably true for a handful of miners even today.
5. UASF is optional) If miners seem to be stalling or not signaling
users have the option of running a media blitz without having to
coordinate the release of a new UASF client. This removes the
complications of multiple client releases interacting to activate the
same feature.
6. UASF is reactive) Forcing miners to upgrade with a media blitz and
a threat to create a hard fork later will be after miners are shown to
be apathetic or malicious. Users have time to gather information while
the MUST_SIGNAL period approaches.
7. no user forced changes) Removes the precedent of users forcing
changes on miners because they must attain 51% miner support. If users
have less than 51% miner support they must hard fork instead.
8. safe supermajority activation) The threshold will remain in
supermajority territory 95% before the MUST_SIGNAL phase. When a
supermajority is achieved there will be minimal disruption and minimal
detriment to Bitcoin's security. (point 3 on Matt's Modern Soft Fork
Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
9. users have time to upgrade) Users will have an appropriate amount
of time to upgrade. (whatever time it takes to achieve supermajority)
(point 2 on Matt's Modern Soft Fork Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
10. no long deployments) In case of miners not reaching a
supermajority due to apathy we won't have to wait six months and then
another release and another long deployment.
11. no UASF minority chain) Users won't be reorged because if at the
end of activation support is below 51% taproot wont activate and users
will stay together.
12. no big reorgs) If more than 51% of miners support Taproot then
upgraded users, non-upgraded users, and minority miners will stay on
the same chain. Some non-upgraded users and miners will be at risk of
creating and following orphan blocks. But the likelihood is that the
miner minority will upgrade if we assume that they are self-interested
and don't want to mine orphan blocks. This results in a small risk of
chain split and small risk of big reorgs. (point 4 on Matt's Modern
Soft Fork Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
13. no late adopter stress) If mining power majority is not achieved
during activation then all miners stay on the same chain and late
adopters don't need to worry about the risk of some UASF chain
overtaking theirs.
14. no divergent consensus rules) The chain can stay together and our
friends won't fork off because we will all be running the same client
and the client will be backwards compatible.
15. no need for redeployment) If activation fails it's clear that it
happened due to a lack of a majority of clients supporting the change
and a lack of a strong enough economic group to force miners to
upgrade. So if activation fails we can be sure that we won't be
releasing the feature again or the feature must be released as a hard
fork if a group of users really really want it.
16. no co-optable deployment) No more LOT flag so code can't be easily
modified to create divergent consensus from a core release.
17. no incentive to force signaling) A big reason for users to force
signaling is for reorg protection in case they are in a minority
chain. With this proposal the UASF chain is protected from reorgs by a
miner majority so no need to force signaling.
18. no configurable consensus) No more LOT flag so no need for a
parameter/config value to force users to pick a side on upgrade.
Forcing the choice on users guarantees there will be users running a
UASF but at the same time reduces the likelihood of a successful UASF
due to other users running LOT=false.
19. no alt-nodes) If this proposal gains consensus and it can be
released in core then we will avoid the issue of fracturing groups of
core forks jockeying for user support.
20. miners can test features before deployment) If changes can be
written to core without contention or risk of divergent consensus.
Core can release RCs for miners and users to test the feature. I think
it would have helped to know the segwit-ASIC boost conflict before
segwit signaling even though there is no guarantee that it would have
been disclosed. But maybe having this ability will be useful for other
features.
21. no false flagging interference) No need for two activation periods
so no need to worry about buggy miner signaling software (false
flagging) that may continue to signal for the prior deployment. This
is a potential issue for modern soft fork activation. (this issue is
mentioned by AJ Towns in the decreasing threshold proposal
https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki)
22. no dev vilification) Core developers can't be portrayed as having
ultimate power because they at least require 51% miner support.
23. safe supermajority threshold) Since the threshold will drop to 51%
during MUST_SIGNAL we could take the luxury of raising the
supermajority threshold back to 95% instead of 90%. This increases the
risk of miner stalling but that's the worst that could happen, which
is pretty good IMO.
24. no flag day) Avoids the pressure of devs pulling the trigger on a
flag day because this proposal removes (reduces?) the likelihood that
there will be a future chain split. This takes a lot of pressure off
of devs releasing this deployment.
25. no Taproot death) If we go with LOT=false first and it fails,
there is no getting around the fact that one group will want LOT=true
and the other group will want to drop Taproot altogether. I think devs
will still have a hard time deploying LOT=true after LOT=false.
26. no procrastinating) Since the deployment period doesn't need to be
too long for a safe LOT=true (after a failed LOT=false signaling
period) then there isn't a risk of users and miners procrastinating
upgrades until the last 3 or so months before the flag day.
27. another activation failure does not kill the MASF method) If
LOT=false fails again it was likely we would have never used it again.
That would be the death of quick MASF. But with this proposal the only
way to fail is if a majority of miners are against the feature and
have been unconvinced by an economic minority media blitz. In which
case the feature is contentious but the activation method remains
intact.


The case for this proposal for supporters of a straight flag-day:
1. no divergent consensus rules) all nodes will be compatible and
backwards compatible so they will all stay with the same consensus
rules.
2. discovered bugs can back out deployment) A flag day can't be
canceled. With this proposal if we find a bug it's easy for miners to
revert to an old version to get signaling below 51%.
3. signaling is available) With signaling we can all see the progress
of the activation. We will know if it's near a supermajority, we will
know if it's near the 51% milestone. Without signaling we might fail
to gather adoption and not even know which miners were actually
running the new version.
4. majority hash power will stay together) All users and the majority
mining power will stay on the same chain. It's possible that a
minority of mining power will fall out of consensus if they don't
enforce Taproot rules but if we assume they will act in their best
interest then they will upgrade once the simple majority of mining
power is signaling. Minority miners that are staunchly against
upgrading or are just really really really lazy and maybe take mining
as a hobby will fork off. But It's not possible to force those
minority miners anyway. For example there could be a minority of
miners running pre-segwit software today.
5. no redeploy to move the date) With a 95% threshold and a 51% at the
end we can be certain that the change will or won't activate. So no
need to scramble to move dates or potentially release a LOT=false
client earler than the flag day. Any of that scrambing is gone because
we just wait. The worst that could happen is a 6% miner minority can
delay the change until the MUST_SIGNAL period.
6. it's clear who wins under contention) Flag day activations need as
much economic adoption as any other method. With a flag day, any
contention in the feature will lead to entrenched groups and a split
is inevitable. With this proposal the economic majority decides by
forcing miners to signal one way or another by threatening a hard
fork. But with this proposal it's clear that who wins the debate is
who wins 51% miner support so the economic majority (if it's very
small will likely reconsider not forking off). With a flag day, who
wins the debate is only clear years after the flag day based on market
capitalization.
7. can start building early) Developers will have high assurance that
the change will activate after the 51% threshold is reached so they
can start building after 51% and don't need to wait until the
supermajority.
8. MASF is available) Activation can happen very early with a
supermajority since Taproot is not contentious. (still the most likely
outcome, by far!)
9. no dev forced changes) Avoid a power grab from core developers to
rush a flag day that doesn't have enough economic majority. Once the
client is released the chain split is nearly guaranteed. With this
proposal devs would need a miner majority and a supporting economic
majority or an apathetic economy supermajority.


The case for this new proposal for supporters of gradual decreasing
activation threshold:
1. no gaming thresholds) Miners can't suddenly signal at 55% threshold
to force 45% of non-signaling miners to scramble an update.


The case for this new proposal for supporters on all sides:
1. conservative enough for core) If we can fix all the kinks and
achieve some consensus I think this proposal will be safe enough to be
supported by core devs.
2. remove activation contention) If things go well we might get a few
more rounds of soft fork activation without contention.
3. no ambiguity on which chain is bitcoin) If there is a minority
group that forks off then the chain called Bitcoin will be the one
with the most economic support and miner support. With this come the
benefits that 21 million stays 21 million and $1 trillion stays $1
trillion. Unless a majority of mining power is trying to force a soft
fork that antagonizes the economic majority. Tthis miner oppression
would then be considered a 51% attack and maybe a PoW change is in
order.
4. *this is a real solution not a compromise*) I think this solution
fixes so many issues on both sides of the LOT debate that I see it as
better than either solution independently. This is a real solution and
the added benefit is that it's a solution that coincidentally brings
both sides of the debate together.
5. only contentious changes make contentious activation) Contentious
activations will be ones that have near 50/50 miner support. Features
like that will probably never even get to the activation stage and
Taproot is not one of them.
6. no LOT drama) The LOT flag is removed so no more default to argue
over. No more drama. And no cover for social attacks on bitcoin.
7. no mid-deployment changes) Deployment is on complete autopilot so
users don't need to change any configuration in the middle of
deployment period.


Leave it to bitcoiners to turn bitcoin's biggest flaw (51% attacks)
into a feature (51% upgrade pressure). The Bitcoin space is so
fascinating.
I hope there isn't some giant obvious flaw I'm missing. Please tell me
if I am. Or add to the arguments if you'd like.


Cheers
Ariel Lorenzo-Luaces