Note: Original article written by Francisco Marcos, translated and published with permission.
In previous articles I have commented the battle we are involved in on Bitcoin Cash, with two sides that I will call "BCH IFP" and "BCH no-IFP". The hashpower part of the battle will take place in November 15th of 2020.
Most likely all miners producing blocks on the "BCH IFP" side will do so using Bitcoin ABC node software, while those on the "BCH no-IFP" side will run BCHN's client; although the latter have more options I will simplify the problem to facilitate understanding of my approach.
In addition to a battle between developer groups there is another very important one being fought on social media, riddled with tricks to discredit one's opponents. I'd like to focus specifically on the comment from BCHN supporters who say their node will always follow the most work chain. This assertion has advantages and disadvantages, as most things in life:
The advantage is the good press it provides, since to the eyes of those who can only see the tip of the iceberg this 'Good attitude' makes them gain adepts to their cause.
The downside is the risk that any blocks found by "BCH no-IFP" miners are eventually orphaned, due to possible chain reorganizations in case the "BCH IFP" side accumulates more work during an approximate 100 minutes period.
The reorganizations are impossible, currently the no-IFP side is signaling a majority of hashpower. Or are they?
If we consult the only current source of what miners will do on D-day (November 15th of 2020), the situation looks like this:
This value is in continuous evolution, at the time of the writing of this article about 53,2% of the signaling is in favor of BCHN ("BCH no-IFP"). There is no signaling in favor of ABC.
Therefore, it seems very clear that majority hashpower is in support of the "BCH no-IFP side". However, the devil is in the details.
Signaling in favor of BCHN in a block's coinbase string has no cost or inconvenience until D-day.
Mining with BCHN from D-day (and H-hour which is 12:00 AM UTC) onwards does have a cost in the form of risk that the blocks you find will later be orphaned.
There may be miners who currently signal one thing, and finally do something else entirely in an attempt to deceive their competitors (Sybil attack). The lack of Sybil protection is the Achilles heel of this and other signaling-based systems as consensus-reaching mechanisms, such as the BMP (Bitcoin Mining Parliament). The situation is much worse if we take into account that BCH is a minority chain, with currently little over 2.2% of total SHA256 hashpower.
The incentive system once cards are facing up (IFP is a soft fork, and once we know the intentions of each miner), allows for gaming in a way that advantages miners who follow the "BCH IFP" side, over the "BCH no-IFP" ones.
How can this risk be mitigated?
I see three alternatives:
Manually force the split by coordinating with all nodes in order to execute an InvalidateBlock "000....xxx" command.
Algorithmically force the split before the fact by implementing replay protection.
Force the split after the fact.
The first solution has the advantage that it can be treated as an "Ace up one's sleeve", that is, to be used only if necessary. On the other hand, it comes with the problem of coordinating manually executing a command that has to be input in each and every node in a very short time. This option could also cost the 'good press' obtained by the previous commitment to 'following the most work chain', although I believe this would go unnoticed by most observers.
The second solution has technical drawbacks. Implementing replay protection involves updating each and every one of the software that explicitly want to follow said blockchain, but in return, the risk of orphaning for your miners' blocks disappears completely. Additionally, and this is the factor I consider the most important, they can again direct the machinery of simple public opinion to see this side as the one who took measures most favorable to the interests of the majority, when in the quite distinct reality, they reduced the risk of being defeated on H-hour of D-day, and consequently having no "BCH no-IFP" chain at all.
The third option has the inconvenience of facing the ecosystem from a position of "loser" of the now settled battle, even if it will be a perfectly valid option.
For these reasons, I believe that the "BCH non-IFP" side may soon announce the implementation of a replay protection mechanism, again under the guise of being the movie's good guys.
I wont lie. I love watching bcash nerds ripping each other apart. 😘
I agree with you on this article from my limited understanding.
May you conquer thy censoring coinspice enemies marco