Cory Fields, a Bitcoin Core developer who joined the project around 2013 through MIT’s Digital Currency Initiative, anonymously revealed in April a critical bug in one of the main Bitcoin Cash clients which could have split the currency.
In a follow up statement, Bitcoin ABC explained the bug as allowing an attacker to create in incompatible transaction which when mined in a block would have led to a fork. They say:
“An attacker may construct a malicious transaction which would be accepted by Bitcoin-ABC 0.17.0 and mined into a block.
This block would be rejected by all other versions of Bitcoin Cash compliant implementations. The malicious transaction would contain the bitflag of 0x20 set in the signature hash type.”
This bug would have most certainly led to mining loses as well as a potential reversal of history had it been exploited.
That’s because an unintentional chain-split, like an intentional chain-split, effectively creates two currencies. But while when such split is intentional they can continue living side by side, when it is unintentional the split is temporary as you eventually want to get them back into one currency.
That means one chain would have to be discarded in such situation as has happened in Bitcoin Core at least twice in 2015 and 2013, something which can lead to some confirmed transactions becoming unconfirmed.
As such, and needless to say, this sort of situation should be avoided in all circumstances. Something Cory Fields managed to do in this case.
In a lessons learned statement, Fields describes the disclosure process of the bug. He wanted to do so anonymously to not attracted blame if someone else exploited the bug in the meantime, but he found the process to be somewhat difficult.
“There were no keys listed for any of the lead developers on the public PGP key servers where they would usually be found, and there were none present in their code repository either,” he says.
Fields thus was forced to make a post on github asking for a PGP key, with PGP keys being an encryption method that hides the contents of a statement.
Such key was provided and the bug was eventually fixed, but some are now suggesting Amaury Sechét, lead dev at Bitcoin ABC, should start signing the repositories.
Fields further highlights the lack of robust scrutiny of code changes in Bitcoin ABC by describing how this bug came about as follows:
“While looking through Bitcoin ABC’s change-logs earlier this year, I noticed that one of the most critical pieces of transaction validation had been refactored.
The changes jumped out at me immediately because they seemed so unnecessary. Curious about the reasoning behind them, I took a look at the public review the changes had undergone.
There was no justification other than “encapsulation,” it had only two reviewers, and review only lasted a week before the code was accepted.
Large refactors are very common and often good practice in typical software development. But it is extremely risky to modify validation code for cryptocurrencies, due to the ever-looming threat of inadvertently introducing a chain-splitting bug.”
It is unclear now whether Bitcoin ABC will take on board the lessons learned. Bitcoin Core, for example, has an exclusive security related mailing list. But they do say in their statement:
“Bitcoin ABC will be taking several actions in order to prevent such an event from occuring again, as well as reduce the overall response time in the case of emergent issues in the future.”
Thus perhaps there may be a happy ending for once, with Fields’ approach clearly showing there are plenty of neutral devs who just like to code and fix things.