A scheduled upgrade of the Cash network happened today. Post-upgrade Cash users may have been surprised that their transaction did not confirm promptly. A bug in 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 Cash network for over an hour. Such an event marks a second Cash upgrade that was not smooth, as the previous upgrade resulted in a chain split.
Why 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 Cash upgrade to a Dash upgrade.
The 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, 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 . This is based on Improvement Proposal 009. A Dash upgrade requires miners to signal that they are ready to accept the upgrade in blocks. 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.
Published at Wed, 15 May 2019 18:08:28 +0000