Implement BIP91

Now that btc1 has merged support for accelerated BIP91 activation, we should implement the same. This will allow BIP148 miners to join Segwit2x miners in activating segwit early via bit4 signalling. Locking segwit in before August 1st is the best outcome for everyone, so we want to make sure the 80% bit4 threshold is reached right away.

[kek-coin]

Should be in a separate miner-specific branch because BIP91 is only relevant for miners.

Is there a good reason to maintain two separate branches and two sets of binaries? Running BIP91 shouldn't adversely affect nodes, and has the marginal benefit of rejecting any soon-to-be orphaned blocks.

[kek-coin]

Because enforcing BIP91 offers no benefits to non-mining nodes over enforcing BIP148 and carries a slight risk of being forked off by malicious false-signalling of bit4. BIP91 is mostly a way for miners to coordinate compliance with BIP148 and as such is out-of-scope for a BIP148-enforcing client imho.

[alp-bitcoin]

NACK

In the unlikely case that there's enough false signalling of bit4 to cause BIP91 activation with only minority hash power, wouldn't we want our nodes to follow the BIP91 side? It's likely to still have enough hash power to win and reorg the legacy chain.

[luke-jr]

NACK, agree with @kek-coin

[mkwia]

NACK

Any response to my last point from the nacks?

[luke-jr]

@ChrisAcheson No, I think we would want to follow the BIP148 side.

With an early minority activation, there would be no "BIP148 side". It would be BIP91 vs legacy. If we were to wait until our flag date to start rejecting non-segwit blocks, we'd be in danger of being reorg'ed by the BIP91 chain.

BIP148 nodes will consider the BIP91 chain valid (since it will contain only segwit-signalling blocks). BIP91 nodes will consider the BIP148 chain invalid though, since it will have non-segwit blocks after 80% signalling was reached, but before August 1st.

Since our goal is to get segwit activated, it doesn't make any sense to hold out against an early minority activation just because they're not following our exact specification. If we support them, we'll get the same result as if they had waited and joined the BIP148 fork on August 1st.

[kek-coin]

If there is no seperate BIP148 and BIP91 chain, and therefore it's BIP91 vs. legacy as you stated, BIP148 nodes will already follow the BIP91 chain.

It would be BIP91 vs legacy until August 1st, at which point it becomes BIP91 vs BIP148 vs legacy. The BIP148 chain will start out ahead of the BIP91 chain. If the BIP91 chain catches up to the BIP148 chain (which is likely in this scenario), BIP148 nodes will discard all transactions since the start of the BIP91/legacy split.

[luke-jr]

@ChrisAcheson You might be right iff we could ensure everyone updated to BIP91+BIP148 before BIP91 activated, but we can't.

Minority activation due to false signalling is extremely unlikely. The combined false + true signalling rate needs to reach 80%. If 40% of the global hash rate is false signalling, that leaves another 40% that will actually be mining on the BIP91 side.

If we consider this scenario likely enough to affect our decision here, then that means adding BIP91 support is something that we absolutely must do right now, not just a nice convenience for BIP148 miners. All current BIP148 nodes would be in danger of losing transactions to a reorg, so we need to get as many of them to update to a version with BIP91 support as possible. Not doing so would be negligent.

Fortunately we've got a month left before BIP91 signalling is supposed to start, and BIP148 users are paying attention to any changes in the UASF situation. Or at least, they should be.

[kek-coin]

@luke-jr suggested implementing this as a -bip91 option; if off-by-default I could get behind that.