<p><strong>Scenarios that don't pose a concern</strong></p>
<p>Scenario: A valid or invalid Taproot spend makes it into a mined block before activation (block 709632). It is just treated as anyone can spend as no one on the network is enforcing the Taproot rules until block 709632. This has <a href="https://b10c.me/blog/007-spending-p2tr-pre-activation/" rel="nofollow noreferrer">already happened</a> (executed by 0xB10C).</p>
<p><strong>Bad case scenarios (unlikely to occur)</strong></p>
<p>Scenario: A majority of miners (although previously signaling readiness months previous) don't upgrade to a full node version that enforces Taproot rules by the time of activation. An invalid Taproot spend makes it into a mined block post activation and creates a large re-org when it is re-orged out.</p>
<p>Monitor: It may not be clear what full node version mining pools are running. But if they include a valid Taproot spend in a block (with no invalid Taproot spends) that they mine post activation this suggests they are enforcing the Taproot rules correctly.</p>
<p>Scenario: Second layer protocols encounter unforeseen issues due to the Taproot upgrade and need fixing. Laolu Osuntokun recently discussed a Taproot related <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019589.html" rel="nofollow noreferrer">problem</a> with the Neutrino light client protocol observed on testnet on the bitcoin-dev mailing list.</p>
<p>Monitor: It really depends on the issue re what to monitor but any problems will likely be discussed on the bitcoin-dev and lightning-dev mailing lists.</p>
<p><strong>Worst case scenarios (highly unlikely to occur)</strong></p>
<p>There is a bug found in the Taproot implementation code and we need a hard fork to either fix the bug or reverse the soft fork change.</p>
<p><strong>What bad scenarios have occurred in the past with previous soft fork activations?</strong></p>
<p>Bitcoin Optech goes through the history of soft fork activations <a href="https://bitcoinops.org/en/topics/soft-fork-activation/" rel="nofollow noreferrer">here</a>. There have been a number of emergency activations of consensus changes to address bugs though these weren't pre-planned soft forks like Taproot. And of course although the SegWit soft fork eventually activated smoothly in 2017 the months running up to that activation were anything but smooth (You can read about the months preceding the SegWit activation in <a href="https://blog.bitmex.com/the-blocksize-war/" rel="nofollow noreferrer">The Blocksize War</a> by Jonathan Bier). The only pre-planned soft fork activation that encountered problems at activation time was the BIP 66 soft fork in 2015. As Optech states:</p>
<blockquote>
<p>The 75% threshold was reached at block height 359,753. On 4 July 2015,
the 95% threshold was reached at block 363,725 and all nodes running
Bitcoin Core version 0.10.0 or later (or a compatible implementation)
began enforcing the new rules. However, at block height 363,731, a
non-upgraded miner produced a block that didn’t contain the correct
block version and so was not valid under the new ISM activation rules.
Other miners built on top of this invalid block, ultimately producing
a chain with six invalid blocks. This meant non-upgraded nodes and
many lightweight clients treated the 96 transactions in the first
invalid block as having six confirmations even though they hadn’t, at
that time, been confirmed even once in a valid block. Eventually
developers were able to contact pool operators and get them to
manually reset their software to return to the valid chain. A second
event of this type occurred the next day, giving transactions three
false confirmations. Happily, all regular transactions from both the
six-block and three-block invalid chains were later confirmed in valid
blocks, meaning that no regular users lost money.</p>
</blockquote>

CC BY-SA 4.0
2021-11-04T17:20:06.287Z
@Prayank: Why? What do you think could happen to them?
Michael Folkson
CC BY-SA 4.0
2021-11-04T14:06:30.190Z
2021-12-15T12:11:14.927Z
2021-12-15T12:11:14.927Z
Michael Folkson
<p>According to <a href="https://taproot.watch/" rel="nofollow noreferrer">taproot.watch</a> Taproot activates in approximately 10 days (block 709632) at the time of writing (November 4th 2021). What could go wrong with regards to bad case or worst case scenarios? Is there anything that miners or users could do at this late stage to reduce the probability of these things happening or to merely protect themselves in the case that one of these things happen?</p>
<p>What bad scenarios have occurred in the past with previous soft fork activations?</p>
<p>What should we watch out for around the time of activation (or in the blocks following activation) to check that the activation has gone smoothly?</p>

<taproot><soft-fork><activation-mechanism>
Taproot activates within the next 2 weeks. What could go wrong and what could be done to reduce probability of any of these bad case scenarios?
Michael Folkson
# Taproot activates within the next 2 weeks. What could go wrong and what could be done to reduce probability of any of these bad case scenarios?

(Asked by: username_0 on 2021-11-04)

According to [taproot.watch](https://taproot.watch/) Taproot activates in approximately 10 days (block 709632) at the time of writing (November 4th 2021). What could go wrong with regards to bad case or worst case scenarios? Is there anything that miners or users could do at this late stage to reduce the probability of these things happening or to merely protect themselves in the case that one of these things happen?

What bad scenarios have occurred in the past with previous soft fork activations?

What should we watch out for around the time of activation (or in the blocks following activation) to check that the activation has gone smoothly?

**Tags:** taproot, soft-fork, activation-mechanism


---

## 1 answers

### Answer by username_0 on 2021-11-04. Score: 2 | Accepted answer

**Scenarios that don't pose a concern**

Scenario: A valid or invalid Taproot spend makes it into a mined block before activation (block 709632). It is just treated as anyone can spend as no one on the network is enforcing the Taproot rules until block 709632. This has [already happened](https://b10c.me/blog/007-spending-p2tr-pre-activation/) (executed by 0xB10C).

**Bad case scenarios (unlikely to occur)**

Scenario: A majority of miners (although previously signaling readiness months previous) don't upgrade to a full node version that enforces Taproot rules by the time of activation. An invalid Taproot spend makes it into a mined block post activation and creates a large re-org when it is re-orged out.

Monitor: It may not be clear what full node version mining pools are running. But if they include a valid Taproot spend in a block (with no invalid Taproot spends) that they mine post activation this suggests they are enforcing the Taproot rules correctly.

Scenario: Second layer protocols encounter unforeseen issues due to the Taproot upgrade and need fixing. Laolu Osuntokun recently discussed a Taproot related [problem](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019589.html) with the Neutrino light client protocol observed on testnet on the bitcoin-dev mailing list.

Monitor: It really depends on the issue re what to monitor but any problems will likely be discussed on the bitcoin-dev and lightning-dev mailing lists.

**Worst case scenarios (highly unlikely to occur)**

There is a bug found in the Taproot implementation code and we need a hard fork to either fix the bug or reverse the soft fork change.

**What bad scenarios have occurred in the past with previous soft fork activations?**

Bitcoin Optech goes through the history of soft fork activations [here](https://bitcoinops.org/en/topics/soft-fork-activation/). There have been a number of emergency activations of consensus changes to address bugs though these weren't pre-planned soft forks like Taproot. And of course although the SegWit soft fork eventually activated smoothly in 2017 the months running up to that activation were anything but smooth (You can read about the months preceding the SegWit activation in [The Blocksize War](https://blog.bitmex.com/the-blocksize-war/) by Jonathan Bier). The only pre-planned soft fork activation that encountered problems at activation time was the BIP 66 soft fork in 2015. As Optech states:

> The 75% threshold was reached at block height 359,753. On 4 July 2015,
> the 95% threshold was reached at block 363,725 and all nodes running
> Bitcoin Core version 0.10.0 or later (or a compatible implementation)
> began enforcing the new rules. However, at block height 363,731, a
> non-upgraded miner produced a block that didn’t contain the correct
> block version and so was not valid under the new ISM activation rules.
> Other miners built on top of this invalid block, ultimately producing
> a chain with six invalid blocks. This meant non-upgraded nodes and
> many lightweight clients treated the 96 transactions in the first
> invalid block as having six confirmations even though they hadn’t, at
> that time, been confirmed even once in a valid block. Eventually
> developers were able to contact pool operators and get them to
> manually reset their software to return to the valid chain. A second
> event of this type occurred the next day, giving transactions three
> false confirmations. Happily, all regular transactions from both the
> six-block and three-block invalid chains were later confirmed in valid
> blocks, meaning that no regular users lost money.

> **Comments:**
> **username_0**: @Prayank: Why? What do you think could happen to them?  

---

