Pathological BIP91/UASF Scenarios

The Bitcoin community is feeling great about BIP91 locking in. Amid the celebration, however, are voices of doubt asking about some extreme scenarios. In this article, I’m going to lay out the various crazy scenarios that may happen now that BIP91 is locked in.

Scenario 1: Cautious Miners

We really have no idea what software anyone on the network is running. Miners may mine blocks that say “NYA” in the coinbase and signal bit 4 (BIP91), but that can be done with almost any software. They could be running Core, they could be running Segwit2x, they could even be running bcoin or some other alternate implementation. But there is no way to know without auditing their servers.

It has been speculated that perhaps the miners are not running Segwit2x. In this scenario, more than 50% of miners choose to not run Segwit2x (aka btc1) or James Hilliard’s Segsignal (this is the Core client + BIP91). This would mean not enough miners enforce BIP91 and would cause a chain split.

Here’s what would happen:

• 2017 July 23 08:00 GMT — BIP91 is activated all blocks should signal BIP141.
• Shortly after — A block that doesn’t signal BIP141/Segwit is introduced to the network. We’ll call this the “forking block”.
• More than 50% of miners build on that block (one that doesn’t signal for Segwit) and that becomes the dominant chain. This chain may have some blocks that don’t signal BIP141/segwit. Segwit2x/Segsignal clients don’t view this chain as valid so we have two chains.
• 2017 August 1 00:00 GMT — BIP148 UASF now actually does something. As there are two chains already, they will need to choose. Most likely, the chain that’s signaling BIP141 is the one they’d choose as it’s in alignment with their goals.

We have a potential chain split in this scenario.

Here’s what would need to happen in order for this scenario to come to pass:

• Majority of miners would have to run something other than Segsignal/Segwit2x (basically clients with BIP91 enforcement logic)
• A miner would have to create a non-BIP141 block (presumably someone that doesn’t like Segwit and wants BU only)

Note this incurs significant risk to the forking block creator. First, if a majority of miners are on Segsignal/Segwit2x, then their blocks get orphaned and they’re out about $38000 as of this writing. Second, if a majority of miners are not on Segsignal/Segwit2x, their block will create a fork. Both outcomes seem to be pretty terrible for the miner, so it’s hard to see what the motivation would be for a miner to act this way.

That said, this could happen if enough miners are too cautious to upgrade to Segsignal or Segwit2x. However, this scenario seems doubtful if these CEOs are to be taken at their word:

• Save

• Save

In other words, as long as the miners run the code they agreed to run (that is, Segwit2x as per the New York Agreement) or a subset (Segsignal), we should be good here.

Scenario 2: Malicious Miners

In this scenario, a majority of miners decide to betray the New York Agreement and not signal for BIP141 after BIP91 activation. This would essentially rock the Bitcoin world to its core and would be a stunning betrayal not normally seen outside of soap operas. Here’s how that would go down:

• 2017 July 23 08:00 GMT — BIP91 is active on the network, but a Group of Malicious Miners (GoMM for short) decide to not signal for BIP141.
• Shortly after — A GoMM Miner introduces a block that doesn’t signal BIP141. Honest miners that are running BIP91 reject this block as invalid, so we have a fork.
• 2017 August 1 00:00 GMT — UASF BIP148 occurs and builds on top of the BIP91 miners. They have compatible code so they continue building on their own chain.

It’s hard to think of a good motivation for why a GoMM would exist. Even if they succeed, they end up with a fork and if they wanted to go down this route, it would have been much easier to not activate BIP91 as that would have given less hash power to the UASF.

The only way this could happen is if there were something that’s seen as an egregious violation of the New York Agreement among miners and a group of them split off publicly with a majority of the hash power in the next week or so. In other words, as long as the miners don’t get pissed off at each other, we should be good here.

Scenario 3: Segsignal/BIP91 Bug

It’s possible that core developer James Hilliard’s BIP91 implementation (say, in Segsignal) has some unforeseen bug in it and that could cause a network fork. This would likely be unintentional and given that, most likely the community would come together to rectify the situation in a reasonable and fair way.

That said, trust may be low enough that something unintentional like this could lead to a full blown permanent fork if enough people are irrationally angry at each other.

Scenario 4: Segwit2x Bug

As about half the code changes in Segwit2x are almost exactly the same as that in Segsignal, a bug from Segwit2x that doesn’t apply to Segsignal and is consensus critical would only be in the 2x part (BIP102) of the code. That code, however, doesn’t execute until 3 months after Segwit activation, so until Segwit activation, this isn’t a concern.

There still is a possibility that there’s a short-term consensus critical bug, but this seems very unlikely as there just isn’t much code affecting the short term that’s different from Segsignal.

Conclusion

We look to be headed toward Segwit activation in late August (around 21–24) and though there are scenarios where Segwit doesn’t happen, they can all be fairly characterized as low-probability events. There isn’t economic or political gain to be had by any actors in the ecosystem to catalyze these scenarios.

That said, if you are prone to worry, start thinking about November’s Segwit2x hard fork instead.

Want to get curated Technical Bitcoin News? Sign up for the Bitcoin Tech Talk newsletter!