Bitcoin Cash Contentious Forks Outcome: Deficient User Experience And Double-Spend Attempts

If you were not hibernating in Antartica the past month, you surely know by now that the Bitcoin Cash community is divided among the updates to the consensus rules to activate starting November, 15th on BCH blockchain.

We are reading a lot of discussions about hash wars that are in my opinion completely irrelevant to the situation we will all have to face in a month and half.

Earlier this month, we at eminent.ly (a business social network based on BCH) released an API to try to protect our/your business from the potential consequences of this fork: chopsticks.cash.

In fact, application developers need to ensure that their business and services will continue operating smoothly and consistently during the fork period, before one of the contentious forks will be globally supported by the community.

I would want in this article to give some thoughts about the contentious forks and project some of the impacts it could have on our beloved chain of blocks.

This article will be an occasion for the community to openly discuss these impacts within a clear framework. We need to keep in mind that our own decisions will have an impact on Bitcoin Cash future.

I believe that we all are responsible of what will be the outcome, on-chain. So let’s think things through right now, because November 15th… it will be too late.

The intent of this article is not to be exhaustive, but to contribute to/continue the discussion, so don’t hesitate to comment below if I missed something important here, I will then update this analysis.

Contentious consensus rules overview

Here is a quick overview of the different updates to the consensus rules that are pushed by Bitcoin ABC and Bitcoin SV protocol developers, compared to the current chain that nay-sayers want to keep as-is:

As you surely know, the main changes are related to the introduction of new Script opcodes and to the transactions ordering within a block set by the miners.

Considering the current volume of transactions, the default size of a block does not matter that much here, unless some bad actors intend to spam the network on purpose in order to overflow the 32Mb block size limit.

The stress test showed that it was costly and difficult to organize a spam attack in order to break the 32Mb barrier, but not impossible for sure.

Let’s define a model that will help us think things through and simulate what could happen to the network if the status-quo prevails:

• y: time of transaction discovered on the network (which cannot be precisely measured in a distributed system, let’s just assume it exists and there’s a natural order of transactions )
• Tya: a transaction compatible with all forks, e.g, a transaction compatible with the pre-fork version of BCH that does not use post-fork features (new opcodes, byte size), “a” the lexical order (“a” preceedes “b”).
• Cya: a transaction compatible with Bitcoin ABC 18.2 features
• Sya: a transaction compatible within Bitcoin SV features
• XBCx: a Bitcoin ABC CTOR block, “x” the block height in that chain
• XBSx: a Bitcoin SV NTOR block, “x” the block height in that chain
• XBNx: a Bitcoin NayBC/etc. NTOR block, “x” the block height in that chain
• h: block hash/signature. Red indicates a different hash, green an identical hash.
• u: utxo. Green indicates UTXO spendable on all chains, orange indicates that some UTXO are spendable on all chains, and some are not.

Now, let’s take an example to analyze what could happen post-fork on-chain.

The following table presents 7 consecutive transactions of different nature and 2 blocks generated on each chains:

Obviously in this simulation the post-fork chains end up being incompatible.

XBC chain cannot be validated by a XBS or XBN node, XBS chain cannot be validated by XBS or XBN, etc.

In fact, blocks will have different signatures as soon as CTOR will activate or as soon as a transaction will be rejected by some of the nodes because it is using incompatible opcodes.

I think we can call this upcoming contentious fork, a melted fork. In fact, transactions with the same hash will be inserted into different blocks with different hashes across the contentious forks.

These forks will be sharing some of the transactions and some transactions will end up only existing on a particular chain.

In other words, the forks will share chunks of the same history, but ending up having a different global history.

Transactions will be absent from some chains/history as long as they will use new opcodes, or pass the limit of number of opcodes within a transaction.

We will see numerous double spends, intended or not, it will be as simple as using the contentious opcodes.

Let’s imagine Bob wanting to spend a UTXO three times:

1. Bob creates a transaction with this UTXO as input and use checkdataverify within his script and signs it;
2. Bob creates a second transaction with the same UTXO as input and use op_mul within his script and signs it;
3. Bob creates a third with the same UTXO without any new opcodes within his script and signs it;
4. Bob sends the transactions to the XBC, XBS and XBN;
5. XBC will accept 1 and refuse 2&3, XBS will accept 2 and refuse 1&3, XBN will accept 3 and refuse 1&2;
6. Bob will have spent the same UTXO 3 times and ends up with 3 new UTXOs that he will be able to spend on each chain respectively;
7. depending on who will listen to what network, Bob could pay and transact with different services and users on the different chains with the same original UTXO.

Does it sound like a mess? It is to me!

Imagine the user experience resulting from these partially split chains… what will happen for the users wanting to interact on-chain while their respective application providers will be running different nodes?

“ Yes you can use this UTXO, but not this one! “

Always keep in mind that it is the User Experience that matters the most.

I think that if protocol developers cannot agree on the updates to bring to BCH, they should add hashing-based replay protection ASAP, like ABC did for the original BCH fork last year.

As an application developer, I don’t want to have to chose a fork in this mess.

But, what I absolutely don’t want is my users to experience issues and inconsistencies.

So at eminent.ly , we will push our transactions to all chains via chopsticks.cash, without using any of the new features proposed by the forks, and no-one will be able to censor our transactions because we are using this or that type of node.

But one day, we may be forced to use a particular opcode to build a particular service. I consider opcodes to be equivalent to replay protection as of now.

Unless being able to form a consensus, protocol developers should decide to use different hashing method and creates different coins November 15th, instead of creating a messy situation which is pretty much equivalent to hard fork.

The conclusion is that there will not be any hash war, because the hash power will be split by chains and will not collide:

- XBC miners/nodes will mine/validate XBC chain;

- XBS miners/nodes will mine/validate XBS chain,

- and XBN miners/nodes will mine/validate XBN.

However, a lot of confusion for the users will happen at the application level. In particular for the users of wallets and exchanges. In fact, the application developers will end-up having to choose a particular chain to provide a consistent experience to their customers.

Double spends attempts will occur and interoperability between services will suffer.

People will slowly lose trust in the history of the chain itself.

Don’t forget that Blockchain technologies ensure a trustworthy decentralized history, so without ensuring trust the system is broken and useless.

Last year, we had a blocksize issue with BTC, we don’t have it anymore thanks to BCH. This year we will have a consensus issue with BCH, that’s not better…

My team and I are prepared for the worst case with chopsticks.cash.

But I am calling here every wallets and exchanges developers to prepare their system to be ready to face the most critical situation.

People will get angry and we all must ensure consistency at the application level, even if there are perturbations at the protocol level.

I believe that we still have a chance to avoid this situation, if people are not putting their ego first, but taking in account the community interest first.

What do you think about this situation?

Originally published at yours.org.