I agreed (in the end) that the "good faith gesture" opening move of deploying Speedy Trial was the best option to start off BIP340-2 activation.
I'm kind of taking the same view on luke's alternative activation client; he thinks giving miners any mechanism to delay activation is a mistake. I'm sympathetic, but disagree.
Not going to get into a discussion about this though, as we've already got people attempting to create hype around it.
There are two major possibilities:
Activate a rule without hashpower enforcement which may create a second incompatible forkcoin blockchain with fair probability, causing millions of dollars cumulative cost to the part of the industry that handles third party bitcoins (exchanges, etc) when they may be forced to allow withdraws of the fork (or sued when they don't), with high probability creates long reorgs (>6 blocks) that will be visible to a portion of users, potentially allowing double spending theft. Notably none of these costs are costs to miners (other than indirectly through dropping the Bitcoin price), and an additional fork gives miners the potential for greater profit (because more total coins are issued but difficulty is split).
Or have a system that waits until a super-majority hashpower will enforce the rule, so that a second competing chain cannot persist. A consequence of this is that miners can delay activation.
Those are the choices. The details of the parameters can influence the severity of the negative effects-- e.g. longer to upgrade can make fewer users effected by reorgs, or a shorter activation period can reduce the maximum delay miners can cause, but that fundamental issue remains.
If you make a non-hashpower enforcement take *years* to activate then ubiquitous enforcement by users might eliminate the forks/reorgs/etc. But in that case you've created *years* of delay instead of months of delay, so the goal of not being delayed fails. "YOU CANT DELAY US IF WE DELAY OURSELVES!!!"
Checkout the
HN taproot thread and the long discussion I had with someone who was *convinced* that taproot was going to create a spinoff chain. The only reason it almost certainly won't is miner activation.
Now, if miners are legit blocking a deployment against the communities will, then the significant costs and risks of a forced activation may be well worth it. Or if it's already blocked, making the forced activation happen years out wont be any more delay. Or if the change is a non-urgent fixup, then delaying it years to begin with may not be a problem.
But if there is no particular reason to think they are going to block something, why the heck would we either add huge activation delays or the risk of splitting the chain (requiring preparatory costs, even if it doesn't happen!) just in case they might? If they do it can be dealt with then, with the full benefit of information about how the obstruction went, how widely and quickly the users deployed the update, etc.
To give a concrete example, say we learned that 20% hashpower obstructed for no good reason and users upgraded about as fast as they normally do during an initial attempt. Then it mike make sense to deploy with a 70% activation threshold and a flag day that activates regardless after 3 years, This way it'll probably activate quickly with minimal disruption but users still have adequate time to upgrade before a disruptive hard cut if the blocking miners grow. Or maybe we learn that user uptake was extremely fast for this upgrade, in which case cutting the 3 years to 2 might make sense.
So yeah, sure miners being able to delay stuff isn't good. But you can't just wish it away, it comes with a phenomenal benefit-- one that is a competitive advantage against constantly hardforking scamcoins-- and one that allows us to activate new consensus rules much *faster*. If we find miners actually blocking something, then the benefit may not be worth it. Considering that plenty of users don't anticipate using any specific new feature-- so it has no benefit to them-- a potentially disruptive activation means that some otherwise desirable features would be legitimately opposed by users: why should they take cost and risk for some feature that won't benefit them?
Skipping over the miner activation only looks attractive if you ignore the costs of not using it-- Significant risk of spiting and/or destabilizing the network, years of additional delays, or both.
If you don't like delays you should prefer hashpower triggered activation, except when hashpower wont activate something quickly. If delay isn't an issue, simply having a flag height set a few years out is probably best.
The right way to think about this is that a consensus rule upgrade naturally takes 2-5 years to do so with low risks. Using hashpower signaling we can safely bring that down to months, but hashpower might not bother to (or active choose not to) cooperate and then we're stuck with riskier or slower approaches.
Besides, I proposed taproot in January 2018, assuming it activates at the earliest opportunity via hashpower it'll be almost
four years since I proposed it. These folks that are now so worried about the risk of a few months of delay by miners... Where were you all these years? Or is delay only something you care about to the extent of angrily retweeting some
hashtag and not enough to bother helping with the work to make something real?
) makes such transactions appear the same as a regular [1 (or more) inputs -> 2 outputs] tx, because there is only 1 aggregated signature (because additive signatures, despite 2 parties signing the tx). Currently, spending outputs from that kind of transaction reveals it to be a 2 of 2 multisig that had alternate script paths, not so with the same tx script using Taproot/schnorr.
