A scheduled upgrade of the Bitcoin Cash network happened today. Post-upgrade Bitcoin Cash users may have been surprised that their transaction did not confirm promptly. A bug in Bitcoin ABC did not recognize transactions as valid as the count of the number of operations did not correctly flag a transaction as valid.
As a result, ABC nodes did not properly relay transactions, and miners running the ABC software did not confirm any transactions. As a result, no transaction was processed by the Bitcoin Cash network for over an hour. Such an event marks a second Bitcoin Cash upgrade that was not smooth, as the previous upgrade resulted in a chain split.
Why Bitcoin Cash’s upgrade procedure is responsible
After such an event it is helpful to reflect on what processes can be improved to avoid such a snafu. Let us compare a Bitcoin Cash upgrade to a Dash upgrade.
The Bitcoin Cash network announces the date that an upgrade will occur in advance. This puts pressures on developers to release software before it might be ready. Consistent with this change, Bitcoin Cash uses the median time passed (MTP) to signal an upgrade. This means nodes will enforce new rules even if other nodes on the network are not ready. For comparison, Dash upgrades using the method outlined in Dash Improvement Proposal 001. This is based on Bitcoin Improvement Proposal 009. A Dash upgrade requires miners to signal that they are ready to accept the upgrade in blocks. Bitcoin Cash’s MTP method will upgrade even if nodes are not ready.
Dash’s much more careful approach
Because Dash does not announce network upgrades way in advance, they are afforded the time required to be very deliberate and through of their testing. Currently Dash is on release candidate 5 for the planned 0.14 upgrade. For comparison, Dash’s 0.13 release had 11 release candidates before it was released to the network. A global payment network can handle a delayed update. That is a small price to pay for security and reliability.