The asymmetric advantage thing...againThe asymmetric advantage thing...again

Supporters of BIP 110 have repeatedly made the claim that the rest of the network needs to actively deploy a fork to resist the BIP 110 rules if they don't want to see BIP 110 rules enacted, even if there is less than 50% of the hash rate mining BIP 110 compliant blocks.

This contention rests on the fact that all BIP 110 compliant blocks are also valid by current Bitcoin rules. This means that if a split were to happen and the BIP 110 side of the split ever became the chain with the most work, all non BIP 110 nodes would abandon the chain they were on and switch to the BIP 110 chain.

I don't believe this affords BIP 110 as much of an asymmetric advantage as supporters claim (#1413227). In my mind, they still need to get more than 50% of the hash to mine with their rules if they want to enforce them on the whole chain.

What if a minority of miners are really, really, ridiculously lucky?What if a minority of miners are really, really, ridiculously lucky?

However, in the circumstance where there is something like 40% of hash rate mining on the BIP 110 chain, it is possible that there will be a chaotic period during which the minority of miners could get lucky and make a chain with more work. In this circumstance, people who don't like BIP 110 may find that their side of the split gets reorged by the BIP-110 when the BIP 110 miners have a streak of luck.

In order to demonstrate this, I ran 20 trials on @supertestnet's forkalicious fork simulator (#1442165) where the pro-BIP 110 side of the split having 40% of the hash rate.

While there are some reorgs in the first 10 or 20 blocks, by 50 blocks after a split, 18 of the trial runs had the non BIP 110 side with a significant lead on the BIP 110 side of the split (as we would expect because they have 60% of the hash rate).

Summon the powers of invalidateblock!Summon the powers of invalidateblock!

However, if you are one of the people who doesn't like BIP 110 and you are worried that your chain will get reorganized, you could use a bitcoind command called invalidateblock to target the first BIP 110 block after a split and make it so that your node will never see that block as valid (and will see any block that is build on it as invalid, too).

The wonderful supertestnet has built a prototype to demonstrate this behavior. You can find it here:

https://github.com/supertestnet/URSF-110

Super also made a nice video explaining how it works:

And wrote up this handy little description:

What does this software do, specifically?What does this software do, specifically?

It has two modes: regtest and mainnet. On regtest mode, it does the following things:

• connects to your bitcoin node
• tells you how to signal to your local network that you are running this software
• pretends a BIP110 signaling window is going to begin in the next regtest block
  gives you commands to mine pro-BIP110 blocks and anti-BIP110 blocks using BIP110's signaling mechanism
• checks how many blocks signal that they are pro-BIP110 in the signaling window
• if too many blocks signal that they are pro-BIP110, it starts running bitcoin core's "invalidateblock" command to reject those blocks

There are several dozen BIP110 signaling windows between now and September. BIP110 activates if, during any of them, 55% of blocks signal support for it. BIP110 also "requires" miners to start signaling in favor of BIP110 a few weeks ahead of its activation block. Since BIP110 "requires" 55% of blocks to signal for BIP110 and this software "rejects" blocks if 55% of them signal for BIP110, miners have to choose: either keep the people running BIP110 happy or keep the people running URSF-110 happy. They can't keep both sets happy.

Please note this disclaimer from Super's site:

I do not recommend running the software on mainnet because I am a very bad coder. It probably doesn't even work, and in a potentially-contentious soft fork like this, you could very easily lose money if you run this on a node that backs real money.

Super also has a longer discussion about BIP 110 on this github page and what he thinks of it.