path: root/92/f869159a660cf5099242e3b0d6b2a5bfd5801b

Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CC991C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 23:50:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id A389C612C8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 23:50:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MONEY_NOHTML=1.533,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_MONEY_PERCENT=0.01,
 UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fXOgxy91ukRh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 23:50:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 10847612C3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 23:50:00 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1nWoGA-0006pv-52; Wed, 23 Mar 2022 09:49:58 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Wed, 23 Mar 2022 09:49:51 +1000
Date: Wed, 23 Mar 2022 09:49:51 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@jtimon.cc>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220322234951.GB11179@erisian.com.au>
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
 <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
 <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
 <CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
 <20220315154549.GA7580@erisian.com.au>
 <CABm2gDpK8eRx3ATbxkF5ic1usUdT4vKiPJyjmPVc-HEOGkxm-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABm2gDpK8eRx3ATbxkF5ic1usUdT4vKiPJyjmPVc-HEOGkxm-g@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Speedy Trial
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: Tue, 22 Mar 2022 23:50:03 -0000

On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <aj@erisian.com.au> wrote:
> > On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> > People opposed to having taproot transactions in their chain had over
> > three years to do that coordination before an activation method was merged
> > [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
> >
> > [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> >     trial activation parameters for mainnet and testnet were merged.
> > [1] 2021-11-14
> People may be opposed only to the final version, but not the initial
> one or the fundamental concept.
> Please, try to think of worse case scenarios.

I mean, I've already spent a lot of time thinking through these worst
cast scenarios, including the ones you bring up. Maybe I've come up with
wrong or suboptimal conclusions about it, and I'm happy to discuss that,
but it's a bit hard to avoid taking offense at the suggestion that I
haven't even thought about it.

In the case of taproot, the final substantive update to the BIP was PR#982
merged on 2020-08-27 -- so even if you'd only been opposed to the changes
in the final version (32B pubkeys perhaps?) you'd have had 1.5 months to
raise those concerns before the code implementing taproot was merged,
and 6 months to raise those concerns before activation parameters were
set. If you'd been following the discussion outside of the code and BIP
text, in the case of 32B pubkeys, you'd have had an additional 15 months
from the time the idea was proposed on 2019-05-22 (or 2019-05-29 if you
only follow optech's summaries) until it was included in the BIP.

> Perhaps there's no opposition until after activation code has been
> released and miners are already starting to signal.
> Perhaps at that moment a reviewer comes and points out a fatal flaw.

Perhaps there's no opposition until the change has been deployed and in
wide use for 30 years. Aborting activation isn't the be-all and end-all
of addressing problems with a proposal, and it's not going to be able to
deal with every problem. For any problems that can be found before the
change is deployed and in use, you want to find them while the proposal
is being discussed.



More broadly, what I don't think you're getting is that *any* method you
can use to abort/veto/revert an activation that's occuring via BIP8 (with
or without mandatory activation), can also be used to abort/veto/revert
a speedy trial activation.

Speedy trial simply changes two things: it allows a minority (~10%)
of hashpower to abort the activation; and it guarantees a "yes" or "no"
answer within three months, while with BIP343 you initially don't know
when within a ~1 year period activation will occur.

If you're part of an (apparent) minority trying to abort/veto/reject
activation, this gives you an additional option: if you can get support
from ~10% of hashpower, you can force an initial "no" answer within
three months, at which point many of the people who were ignoring your
arguments up until then may be willing to reconsider them.

For example, I think Mark Friedenbach's concerns about unhashed pubkeys
and quantum resistance don't make sense, and (therefore) aren't widely
held; but if 10% of blocks during taproot's speedy trial had included a
tagline indicating otherwise and prevented activation, that would have
been pretty clear objective evidence that the concern was more widely
held than I thought, and might be worth reconsidering. Likewise, there
could have somehow been other problems that somehow were being ignored,
that could have similarly been reprioritised in the same way.

That's not the way that you *want* things to work -- ideally people
should be raising the concerns beforehand, and they should be taken
seriously and fixed or addressed beforehand. That did happen with Mark's
concerns -- heck, I raised it as a question ~6 hours after Greg's original
taproot proposal -- and it's directly addressed in the rationale section
of BIP341.

But in the worst case; maybe that doesn't happen. Maybe bitcoin-dev and
other places are somehow being censored, or sensible critics are being
demonised and ignored. The advantage of a hashrate veto here is that it's
hard to fake and hard to censor -- whereas with mailing list messages and
the like, it's both easy to fake (setup sockpuppets and pay troll farms)
and easy to censor (ban/moderate people for spamming say). So as a last
ditch "we've been censored, please take us seriously" method of protest,
it seems worthwhile to have to me.

(Of course, a 90% majority might *still* choose to not take the concerns
of the 10% minority seriously, and just continue to ignore the concern
and followup with an immediate mandatory activation. But if that's what
happening, you can't stop it; you can't only choose whether you want to
be a part of it, or leave)

Another example: if we'd had a 3-month speedy trial for segwit, that would
presumably have run from 2016-11-15 to 2017-02-15, and been successfully
blocked by people objecting to segwit activation. That would have left a
clean slate for either a simple and safe BIP149 style UASF activation of
segwit (shaolinfry introduced the concept of "user activated softfork
activation" in a post on 2017-02-25), or redesigning segwit to be
compatible with covert ASICBoost (which Greg Maxwell revealed publicly
on 2017-04-05, after apparently realising the potential interaction
with segwit a month earlier) and retrying segwit activation with that
approach via a new speedy trial later in the year.

> > For comparison, the UASF activation attempt for segwit took between 4
> > to 6 months to coordinate, assuming you start counting from either the
> > "user activated soft fork" concept being raised on bitcoin-dev or the
> > final params for BIP 148 being merged into the bips repo, and stop
> > counting when segwit locked in.
> That was extremely risky and could have been a disaster. 

The question that comment was addressing wasn't whether BIP148 was a
good idea, it was how quickly users can coordinate a software update to
respond to consensus rules heading in a direction they find unacceptable.

All the risk and potential for disaster was due to the goals of BIP148:
to get segwit locked in prior to its activation timeout in Nov 2017,
even if only supported by a minority of hashrate.

> >  2) If that somehow doesn't work, and people are pushing ahead with a
> >     consensus change despite significant reasonable opposition; the next
> >     thing to do would be to establish if either side is a paper tiger
> >     and setup a futures market. That has the extra benefit of giving
> >     miners some information about which (combination of) rules will be
> >     most profitable to mine for.
> >
> >     Once that's setup and price discovery happens, one side or the other
> >     will probably throw in the towel -- there's not much point have a
> >     money that other people aren't interested in using. (And that more
> >     or less is what happened with 2X)
> Future markets can be manipulated.

Futures markets measure people's beliefs weighted by wealth and
confidence; and unlike with hashrate signalling there's a real cost to
lying/being wrong. They're certainly not perfect, but nothing is.

> Regarding 2x, that's not how I remember it. If I remember correctly,
> "discovered" a price in btc for bcash that was
> orders of magnitude higher than what it is today.

2x and BCH were two different things.

For BCH, the only futures market was run by viabtc (one of the main
advocates of BCH), was only available a week before the split, and was
(I think?) only available to Chinese investors (at least, it was only
traded against CNY). Nevertheless, the price stabilised at around
$300USD equivalent (0.1 BTC) prior to the split, and that was fairly
in line with the spot price after the split had occurred. That price
dropped during the next two weeks to ~0.07 BTC, then rose to ~0.2 BTC,
and has since dropped to ~0.008 BTC. Coincidentally that's about $300USD
in today's market, so if you're pricing things in USD, the futures market
was actually weirdly accurate.

Viabtc also launched a market for BIP148, though in addition to the
problems with its BCH market, it was pretty unusable in that if the
BIP148-valid chain was the most-work chain, the BIP148 token wouldn't
be redeemed.

But the 2x market I was thinking of was bitfinex's; afaik bitfinex is
reasonably unbiased, the market was fairly accessible and could be traded
against the USD, and it was open for a month before the question of 2x
was definitevely resolved. The discovered price was about 0.2 BTC up
until it was announced that 2x was being abandoned at which point it
dropped to something like 0.02 BTC, representing holding costs until
the market was finalised about 2 months later.

> >     If a futures market like that is going to be setup, I think it's
> >     best if it happens before signalling for the soft fork starts --
> >     the information miners will get from it is useful for figuring out
> >     how much resources to invest in signalling, eg. I think it might even
> >     be feasible to set something up even before activation parameters are
> >     finalised; you need something more than just one-on-one twitter bets
> >     to get meaningful price discovery, but I think you could probably
> >     build something based on a reasonably unbiassed oracle declaring an
> >     outcome, without precisely defined parameters fixed in a BIP.
> Whatever miners signal, until there are two chains and their real
> rewards can be traded, it's hard to know what they will mine
> afterwards.

I don't agree. The BCH futures market accurately predicted the rewards
(and hence hashrate) for mining BCH in the first couple of weeks after
the split.

On the same basis, the 2x futures market predicted that mining the 2x
chain would be massively unprofitable: immediately after the split,
both the 2x chain and the original-rules chain would have the same
difficulty and hence have the same expected cost to mine a block; but
the 2x chain would only have 25% of the reward (0.2 vs 0.8 valuation per
the futures market). Without someone subsidising the first 2016 blocks on
the 2x chain to the tune of about ~15,000 pre-split bitcoin (or ~75,000
post-split 2x coins; or between $80M-$150M USD), either directly, or by
mining at an economic loss, the 2x chain could only collapse.

BCH avoided that fate by having a new difficulty adjustment algorithm
that allowed the difficulty to drop immediately, rather than only on
the next 2016 block boundary.

> They could signal a change with 100% and then after it is activated on
> one chain and resisted on another, they 95% of them may switch to the
> old chain simply because its rewards are 20 times more valuable. This
> may happen 3 days after activation or 3 months, or more.

If it's an either-or choice, it's likely that 99.9% of hashrate will
switch even if the rewards are only 0.1 times more valuable (or 1.1
times as valuable if you prefer). That's why you run a futures market,
to figure out which will be more valuable and by how much.

We saw the either-or case happen with BCH vs BTC; the difficulty of BCH
would drop quickly due to the "EDA", but only rise slowly, making BCH
mining more profitable for an extended period so that opportunistic miners
would switch to BCH for a while until it got expensive again then switch
back to BTC, causing both chains' hashrate to be unstable. 

But if you don't hard fork to a different difficulty adjustment algorithm
the way BCH did on day one, then it doesn't matter how long miners
don't mine on your chain, your chain's difficulty won't adjust, and so
you'll need to instead wait until BTC's difficulty doubles or more,
or its reward halves or more, or some combination of the two. That's
likely much more than 3 months away. I can't imagine why anyone would
still care about your proposed chain months or years later.

So hardforking in merge-mining (so it's not an either-or question) or
a new difficulty adjustment algorithm (so you don't have to wait months
or years) seems a much more realistic approach.

> >     So if acting like reasonable people and talking it through doesn't
> >     work, this seems like the next step to me.
> Not to me, but you're free to create your future markets or trade in them.
> I wouldn't do any of them, and I would advice against it.

*shrug* Do what you like (and I mean, I don't trade in futures markets
either) but I think you'd be missing out on very useful information,
and losing a chance for people who aren't devs to offer tangible and
objective support for your cause.

> >     I think the speedy trial approach here is ideal for a last ditch
> >     "everyone stays on the same chain while avoiding this horrible change"
> >     attempt. The reason being that it allows everyone to agree to not
> >     adopt the new rules with only very little cost: all you need is for
> >     10% of hashpower to not signal over a three month period.
> No, 10% of hashpower is not "very little cost", that's very expensive.

If we're talking about consensus changes, the target is 100% of hashpower,
and also something approaching 100% of nodes. By comparison 10% of
hashpower is *much* cheaper, especially when the 100% have to actively
upgrade in order to support, while the 10% just have to not do anything
in order to oppose.

To be clear: You don't have to setup the 10% of hashpower yourself,
you just have to convince the existing owners of 10% of hashpower to
not actively support the change.

> >     That's cheaper than bip9 (5% over 12 months requires 2x the
> >     cumulative hashpower), and much cheaper than bip8 which requires
> >     users to update their software
> Updating software is not expensive. the code for bip8 could have been
> merged long before taproot was even initially proposed.
> It could be merged now before another proposal.

The BIP8 spec we have today is very different to the BIP8 spec when
taproot was merged, let alone before it was even proposed. As it was,
it had serious problems that hadn't been addressed, and the version we
have today likewise has significant problems that haven't been addressed,
which is why it wasn't and shouldn't be merged.

> Updating software is certainly not more expensive than getting 10% of
> the hashrate.

Updating software (or not updating software) is precisely *how* to get
10% of hashrate. It's not more or less expensive -- it *is* the expense.

> >  4) At this point, if you were able to prevent activation, hopefully
> >     that's enough of a power move that people will take your concerns
> >     seriously, and you get a second chance at step (1). If that still
> >     results in an impasse, I'd expect there to be a second, non-speedy
> >     activation of the soft fork, that either cannot be blocked at all, or
> >     cannot be blocked without having control of at least 60% of hashpower.
> And if you never got 10% hashpower, we move to the next step, I guess.

Yes; you then move to the next step knowing that what level of
interest/support you actually have.

> >  5) If you weren't able to prevent activation (whether or not you
> >     prevented speedy trial from working), then you should have a lot
> >     of information:
> >
> >       - you weren't able to convince people there was a problem
> >
> >       - you either weren't in the economic majority and people don't
> >         think your concept of bitcoin is more valuable (perhaps they
> >         don't even think it's valuable enough to setup a futures market
> >         for you)
> >
> >       - you can't get control of even 10% of hashpower for a few months
> >
> >     and your only option is to accept defeat or create a new chain.
> What if it's still the other people who are lacking information?

If it's other people that lack information, there's two options. One,
you might be able to explain things to them, so that they learn and gain
the information. The other is that for whatever reason they're not willing
to listen to the truth and will remain ignorant. If it's the first case,
you'd have succeeded in an earlier step. If it's the latter, then it's
not something you can change, and it doesn't really matter in how you
decide what to do next.

> It wouldn't be a new chain, it would be the old chain without the new
> evil change, until you manage to show the other people that the change
> was indeed evil.
> Remember, in this example, the new change being evil is not a
> possibility, but an assumption.

It's extremely unhelpful to call things "evil" if what you want is a
reasonable discussion. And if reasonable discussion isn't what you want,
you're in the wrong place.

At this point in the hypothetical you're in a small minority, and have
been unable to convince people of your point of view. Calling the people
you disagree with "evil" (and saying they support something that's evil
is exactly that) isn't going to improve your situation, and doing it in
a hypothetical sure feels like bad faith.

> What you're arguing is "if you haven't been able to stop the evil
> change, then perhaps it wasn't evil all along and the people trying to
> resist it were wrong and don't know it".

If it's an evil change, then good people will oppose it. You've tried
convincing devs in the "discuss the proposal" stage, whales in the
"futures market" stage, and miners in the "hashpower signalling" phase,
and failed each time because the good people in each of those groups
haven't opposed it. So yes, I think the most likely explanation is that
you're wrong in thinking it's evil.

But hey what about the worst case: what if everyone else in bitcoin
is evil and supports doing evil things. And maybe that's not even
implausible: maybe it's not an "evil" thing per se, perhaps it's simply
equally "misguided" as the things that central banks or wall street or
similar are doing today. Perhaps bitcoin becomes the world currency,
and in 100 or 200 years time, whether through complacency and forgetting
the lessons of the past, or too much adherence to dogma that no longer
matches reality, or just hitting some new problem that's never been seen
before and an inability to perfectly predict the future, and as a result
most of the world opts into some change that will cause bitcoin to fail.

In that scenario, I think a hard fork is the best choice: split out a new
coin that will survive the upcoming crash, adjust the mining/difficulty
algorithm so it works from day one, and set it up so that you can
maintain it along with the people who support your vision, rather than
having to constantly deal with well-meaning attacks from "bitcoiners"
who don't see the risks and have lost the plot.

Basically: do what Satoshi did and create a better system, and let
everyone else join you as the problems with the old one eventually become
unavoidably obvious.

> But that contradicts the premise: an evil change being deployed using
> speedy trial.

Again: any change that could be avoided if it were deployed via BIP8,
can also be avoided *by the exact same techniques* if it were deployed
via speedy trial or a similar approach.

> >     Since your new chain won't have a hashpower majority, you'll likely
> >     have significant problems if you don't hard fork in a change to
> >     how proof-of-work works; my guess is you'd either want to switch
> >     to a different proof-of-work algorithm, or make your chain able
> >     to be merge-mined against bitcoin, though just following BCH/BSV's
> >     example and tweaking the difficulty adjustment to be more dynamic
> >     could work too.
> No, I disagree. You'll just get the hashpower you pay for with subsidy and fees.

The value of the subsidy is something you can directly figure out from
running a futures market; and unless you're deliberately subsidising fees,
they'll almost certainly be ~0.

> >     (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
> >     BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
> >     merge-mining, are apparently at 68%, 42% and 17% respectively)
> Google tells me 0.0073BTC.

I think you're reading too much precision into those numbers? When
I looked again the other day, I got a figure of 0.66%; today I get
0.75%. I'm sure I rounded whatever figure I saw to one significant figure,
so it might have been 0.75% then too.

https://bitinfocharts.com/comparison/bitcoin-hashrate.html#3y
https://bitinfocharts.com/comparison/bitcoin%20cash-hashrate.html#3y

> In perfect competition and leaving fees aside (in which probably
> bitcoin wins too), BCH should have approximately 0.0073% the hashrate
> bitcoin hash.

Oh, or you're just getting the percentage conversion wrong -- 0.0073
BTC is 0.73% of a BTC, and thus it would be expected to have about 0.73%
of the hashrate.

> >     At the point that you're doing a hard fork, making a clean split is
> >     straightforward: schedule the hard fork for around the same time as
> >     the start of enforcement of the soft fork you oppose, work out how
> >     to make sure you're on your own p2p network, and figure out how
> >     exchanges and lightning channels and everything else are going to
> >     cope with the coin split.
> You shouldn't need to do a hardfork to resist a consensus change you don't like.

Of course; that's why option (1) is to talk to people about why it's a
bad idea so it doesn't get proposed in the first place.

But if you want to resist a consensus change that is overwhelmingly
supported by the rest of the bitcoin economy, and for which your reasons
aren't even considered particularly logical by everyone else, then yeah,
if you really want to go off on your own because everyone else is wrong,
you *should* do a hardfork.

If a change doesn't have overwhelming support, then hopefully the costs
to get 90% of hashrate signalling is a significant impediment. If you do
have overwhelming support, then the cost to get 90% of hashrate signalling
(or even apparently 99.8%, see getdeploymentinfo on block 693503) --
doesn't seem to be too bad.

> "around the same time", with bip8 and the resistance mechanism
> proposed by luke, it doesn't need to be "around the same time
> according to some expert who will tell you what to put in your
> software", but "exactly at the same time, and you only need to know
> which pproposal version bit you're opposing".

(Arguing semantics: You can't do the split at exactly the same time,
because the split starts with each chain finding a new block, and blocks
are found probabilistically depending on hashrate, so they won't be found
at the same time. Or, alternatively, the split happens whenever either
client considers the other chain invalid, and always happens at the
"same" time)

If you want to do things at exactly the same height, you can do that if
the soft fork is activated by speedy trial as well.

I'd say the same height approach works better on speedy trial than
with BIP8/BIP343, since with speedy trial signalling is only for a
short period, and hence you know well in advance if and when you'll be
splitting, whereas with an extended signalling period that goes for a
year past the minimum activation height, you may find yourself splitting
at any point in that year with as little as two week's notice.

If I were doing a hardfork coin split to avoid following some new soft
forked rules that I think were horrible, I think I'd prefer to do the
split in advance of the softfork -- that way exchanges/wallets/lightning
channels/etc that have to do work to deal with the coinsplit aren't
distracted by simultaneously having to pay attention to the new softfork.
YMMV of course.

> Yeah, great example. It doesn't have to be an "evil change" as such,
> it can just be a "deeply wrong change" or something.
> Or if we were using BIP8 and had the resistance mechanism proposed by
> luke, all we would need to do is change one line and recompile:
> I don't remember his enumeration constants but, something like...
> - bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;
> + bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;
> Say we discover it 3 days before forced activation.
> Well, that would still be much less rushed that the berkeleyDB thing,
> wouldn't it?

No, exactly the opposite.

In order to abort a BIP8 activation, 100% of hashpower and 100% of
node software needs to downgrade from anything that specifies BIP8 with
mandatory activation.

The "berkelyDB thing" was an accidental hard fork due to the updated
software with leveldb being able to accept larger blocks than the old
bdb-based bitcoind could. 

The result was two chains: one with a large block in it, that could
only be validated by the newer software, and a less work chain with only
smaller chains, that could be validated by both versions of the software;
the problem was ~60% of hashpower was on the larger-block chain, but
many nodes including those with ~40% hashpower. The problem was quickly
mitigated by encouraging a majority of hashpower to downgrade to the
old software, resulting in them rejecting the larger-block chain,
at which point a majority of hashpower was mining the smaller-block
chain, and the smaller-block chain eventually having more work than
the larger-block chain. At that point any newer nodes reorged to the
more-work, smaller-block chain, and everyone was following the same chain.

What that means is that the operators of *two* pools downgraded their
software, and everything was fixed. That's a *lot* less work than
everyone who upgraded their node having to downgrade/re-update, and
it was done that way to *avoid* having to rush to get everyone to do
an emergency update of their node software to be compatible with the
larger-block chain.

See https://bitcoin.org/en/alert/2013-03-11-chain-fork
and https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

On the other hand, that approach only works because it takes advantage
of a lot of hashrate being centralised around a few pools; if we succeed
in making block construction more decentralised, solutions here will
only become harder.

> If there's only opposition after it is deployed, whatever the
> activation mechanism, in that particular case, would be irrelevant.

Once you've released software with a softfork activated via BIP8 with
mandatory activation (ie, lot=true), and it has achieved any significant
adoption, the soft fork is already deployed and you need to treat it as
such. If you want to have an easier way of undoing the softfork than
you would have for one that's already active on the network, you need
a different activation method than BIP8/lot=true.

Cheers,
aj