<p>Every soft fork or consensus change involves a (very small) non-zero risk of a network split. That risk is considerably lower for a soft fork than say a hard fork (where all nodes need to upgrade). That's why soft forks aren't attempted every month or year. All you can do is minimize that risk.</p>
<p>Aaron lays out some scenarios that are theoretically possible. Any incompatibility between &quot;Bitcoin Core&quot; and &quot;Bitcoin Taproot&quot; during the Speedy Trial deployment is in my view highly unlikely. If Speedy Trial fails to activate and we reach November 2022 (please note 2022 not 2021) without miners activating then we are in a similar scenario to the UASF in 2017 where it depends on what the economic majority is running. I can't predict what the economic majority would be running in November 2022 but I highly suspect the delaying of Taproot activation would be at the top of everyone's minds.</p>
<p>Andrew Chow adds in the comments that false signaling in the period after Speedy Trial has failed to activate (Bitcoin Core has no activation mechanism in this period though this could obviously change in the future whilst Bitcoin Taproot is running a BIP 8 deployment) could cause a chain split.</p>
<blockquote>
<p>Furthermore, a malicious miner could take advantage of these competing activation rules and false signaling in order to induce a chain split which leaves the UASF nodes stuck on an orphan chain. This is in contrast to the typical chain split caused by false signaling which can be resolved by the majority of hash rate building on the chain enforcing the new rules.</p>
</blockquote>
<p>You do have to weigh up these risks of a network split with miners deliberately blocking Taproot activation potentially forever. If we were to say no more UASFs ever again because we don't want to take any network split risk that would be handing miners a permanent veto to block the activations of soft forks that have community consensus. So you have to weigh up the risk of the latter which would be just as concerning (if not more concerning) to people.</p>
<p>So in summary these are subtle trade-offs. A number of developers have worked hard to minimize the risk of a network split. But it doesn't get to zero unless you literally never try a soft fork again. And that would mean that Bitcoin would never seriously improve again.</p>

CC BY-SA 4.0
2021-04-20T01:22:40.267Z
The UASF is not the only way that a chain split can occur. False signaling can (and has) cause a chain split after activation. Furthermore, a malicious miner could take advantage of these competing activation rules and false signaling in order to induce a chain split which leaves the UASF nodes stuck on an orphan chain. This is in contrast to the typical chain split caused by false signaling which can be resolved by the majority of hashrate building on the chain enforcing the new rules.
Ava Chow
CC BY-SA 4.0
2021-04-20T09:11:29.373Z
Thanks for this Andrew. Will update answer.
Michael Folkson
CC BY-SA 4.0
2021-04-19T19:44:37.930Z
2021-04-20T09:18:40.953Z
2021-04-20T09:18:40.953Z
Michael Folkson
<p>No. With a softfork, a network split is only possible if miners create invalid blocks. This is something they can do with or without a softfork, so it is not an issue specific to softforks.</p>
<p>It is important for the economy to use their own full nodes to avoid the risk of being led off by a miner attack in the form of invalid blocks. This remains true with softforks, where upgrading is necessary to retain full node security.</p>

CC BY-SA 4.0
2021-05-01T14:51:06.560Z
2021-05-01T14:51:06.560Z
Luke Dashjr
<p>In this <a href="https://bitcoinmagazine.com/technical/there-are-now-two-taproot-activation-clients-heres-why" rel="nofollow noreferrer">article</a> from Aaron van Wirdum he states there is a risk of a network split with two releases (Bitcoin Core and Bitcoin Taproot) not following exactly the same activation mechanism(s)? Is this true?</p>
<p>This question was asked by Andrew Asmakov and has been paraphrased.</p>

<soft-fork><taproot><activation-mechanism><bip9-version-bits><bip8-version-bits>
Is there network split risk for Taproot activation with two releases (Bitcoin Core and Bitcoin Taproot)?
Michael Folkson
# Is there network split risk for Taproot activation with two releases (Bitcoin Core and Bitcoin Taproot)?

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

In this [article](https://bitcoinmagazine.com/technical/there-are-now-two-taproot-activation-clients-heres-why) from Aaron van Wirdum he states there is a risk of a network split with two releases (Bitcoin Core and Bitcoin Taproot) not following exactly the same activation mechanism(s)? Is this true?

This question was asked by Andrew Asmakov and has been paraphrased.

**Tags:** soft-fork, taproot, activation-mechanism, bip9-version-bits, bip8-version-bits


---

## 2 answers

### Answer by username_0 on 2021-04-19. Score: -1 | Accepted answer

Every soft fork or consensus change involves a (very small) non-zero risk of a network split. That risk is considerably lower for a soft fork than say a hard fork (where all nodes need to upgrade). That's why soft forks aren't attempted every month or year. All you can do is minimize that risk.

Aaron lays out some scenarios that are theoretically possible. Any incompatibility between "Bitcoin Core" and "Bitcoin Taproot" during the Speedy Trial deployment is in my view highly unlikely. If Speedy Trial fails to activate and we reach November 2022 (please note 2022 not 2021) without miners activating then we are in a similar scenario to the UASF in 2017 where it depends on what the economic majority is running. I can't predict what the economic majority would be running in November 2022 but I highly suspect the delaying of Taproot activation would be at the top of everyone's minds.

Andrew username_1 adds in the comments that false signaling in the period after Speedy Trial has failed to activate (Bitcoin Core has no activation mechanism in this period though this could obviously change in the future whilst Bitcoin Taproot is running a BIP 8 deployment) could cause a chain split.

> Furthermore, a malicious miner could take advantage of these competing activation rules and false signaling in order to induce a chain split which leaves the UASF nodes stuck on an orphan chain. This is in contrast to the typical chain split caused by false signaling which can be resolved by the majority of hash rate building on the chain enforcing the new rules.

You do have to weigh up these risks of a network split with miners deliberately blocking Taproot activation potentially forever. If we were to say no more UASFs ever again because we don't want to take any network split risk that would be handing miners a permanent veto to block the activations of soft forks that have community consensus. So you have to weigh up the risk of the latter which would be just as concerning (if not more concerning) to people.

So in summary these are subtle trade-offs. A number of developers have worked hard to minimize the risk of a network split. But it doesn't get to zero unless you literally never try a soft fork again. And that would mean that Bitcoin would never seriously improve again.

> **Comments:**
> **username_1**: The UASF is not the only way that a chain split can occur. False signaling can (and has) cause a chain split after activation. Furthermore, a malicious miner could take advantage of these competing activation rules and false signaling in order to induce a chain split which leaves the UASF nodes stuck on an orphan chain. This is in contrast to the typical chain split caused by false signaling which can be resolved by the majority of hashrate building on the chain enforcing the new rules.  
> **username_0**: Thanks for this Andrew. Will update answer.  

---

### Answer by username_2 on 2021-05-01. Score: 0

No. With a softfork, a network split is only possible if miners create invalid blocks. This is something they can do with or without a softfork, so it is not an issue specific to softforks.

It is important for the economy to use their own full nodes to avoid the risk of being led off by a miner attack in the form of invalid blocks. This remains true with softforks, where upgrading is necessary to retain full node security.


---

