Now the Bitcoin Cash community knows where it stands.

In the last weeks, many major pools mining BCH vowed to defend Bitcoin Cash against the attempted hostile takeover of its community by Bitcoin ABC developer Amaury Séchet by switching over to the mining software BCHN or other alternatives.

Today, ViaBTC announced that they would "stay neutral" in the upcoming November 15th battle between BCH and the new Bitcoin ABC coin. However, upon further inquiry they admitted that they would let their customers choose if they want to mine using BCHN or Bitcoin ABC, with Bitcoin ABC being the default. That's not really being neutral...

Together with their sister company, Antpool, they represent around 30% of the BCH hashrate today. That is a minory but their implementation will make it very easy for BTC miners to temporariy use their hashrate against the BCH community. They would be acting against their own interests because they would effectively pay money to Bitcoin ABC forever if the IFP remains, but they might just do so out of spite.

To prevent a contentious November 15th fork, the community should now prepare its defense strategy. In this article I will propose some methods for discussion in the community.

1. Encourage miners to migrate from ViaBTC to other pools

We should make BTC and BCH miners aware that supporting ViaBTC (and maybe Antpool) means risking that their future profits will be reduced by the amount syphoned towards Bitcoin ABC. Staying on the ABC coin chain will also mean that they will likely lose all their mining profits by the time they can sell them in case the ABC chain loses.

ASICseer already showed how effective this can be. They issued a public user alert that resulted in their customer's hash power for ViaBTC fell from 50 petahash to 39 petahash within only 12 hours.

2. Educate businesses that a 70% majority of hashrate will move away from Bitcoin ABC

We need to educate businesses using Bitcoin Cash that they should replace Bitcoin ABC with BCHN in preparation for the upcoming upgrade. This will ensure that they stay on the majority chain.

3. Hold a coin vote

When the IFP was originally proposed, Bitcoin ABC claimed that it was requested by chinese miners. Once the community showed its universal disapproval, the chinese miners that presumably put the idea on the table quickly backed down from it and the proposal gained a 0% approval rate in the block vote.

This shows that the chinese miners care what the BCH community thinks about a proposal. Therefore, I propose that we should hold a coin vote regarding the future we want to see for Bitcoin Cash (IFP or Non-IFP). Every BCH gets one vote, results are tallied on a given day.

This would send a clear picture to them that the IFP is universally unpopular amongst coin holders.

While I do not have the skillset required to detail how such a vote would best be held, I believe it could be an important tool to judge community support for technical proposals, now and in the future.

4. Translate articles to chinese

As explained in the paragraph before, the chinese miners care about what the rest of the community thinks. But language can be a barrier. So we need to find a way to reach them better, for example by translating articles like this one to chinese.

5. Block other mining nodes from building upon Bitcoin ABC blocks

Currently, BCHN and other nodes would happily continue building upon blocks mined by Bitcoin ABC (including the 8% IFP fee). In the other direction, Bitcoin ABC would reject all blocks that do not send them money. This creates an unequal playing field.

To level the playing field, some community members (not developers) have suggested to outright blacklist the hardcoded Bitcoin ABC wallet address and rejecting transactions sending money to it or from it. This would however be problematic because it would demonstrate that Bitcoin Cash can blacklist addresses, a mechanism many governments and companies would be very interested in.

Others have pointed out that miners who disagree with developers stealing from the coinbase would likely manually reject any blocks that were mined using Bitcoin ABC. My proposal is to coordinate such an effort without forcing anyone to use it. Here is how it would work: all node developers would add the ability to load a list of "bad" blocks from a user chosen URL. If a block is on the list, the software would refuse to build upon it.

These lists would only be used in the event of an attack on the network. Miners would be free to use such a list or not, but it BCH is getting attacked, they may very well chose to. It could be a list maintained locally by their admin or some other entity that identifies hostile blocks.

This would allow nodes with shared interests to reject hostile attacks without touching the source code or manually rejecting blocks on every instance. This mechanism could not be used to enforce a transaction blacklist because there is no central authority maintaining these lists and it would not be economic for a miner to reject blocks based on some government blacklist.

Other ideas?

If you have more ideas on how we can have an easy transition in November, please let me know in the comments. I am also very curious to hear what you think about my suggestions.