Software vulnerabilities continue to be a red flag issue in crypto community. Not long ago, the top-five cryptocurrency EOS network experienced a vulnerability right in the dawn of its development. The same thing happened to Ethereum, when a series of Distributed Denial of Service (DDoS) attacks led to a significant delay in the operation of the nodes. And the news about another bug in the code came out yesterday, with the announcement made by Monero developers to patch the vulnerability, which allowed attackers to burn funds. It could seem that such kind of bug can affect any crypto, but not Bitcoin. But what could be worse than the vulnerability of a coin with a daily turnover of $4.5 billion? Perhaps, only ignorance about the existing threat. The recent Bitcoin Core vulnerability is a clear case in point.

“Most catastrophic bug ever”

On Sept. 18, Bitcoin Core developers announced a release of an update to fix a DDoS attack vulnerability. The most shocking discovery was that such an attack could be succeeded by flooding the full node operators with traffic, or by sending them information that could trigger a network crash.

The fix CVE-2018-1744 was initially addressed to several developers who were working on both Bitcoin Core and other cryptocurrency-based projects. The bug was identified by Bitcoin Cash developer Awemany, who concludes in his Medium post that CVE-2018-17144 is “the most catastrophic bug in recent years, and certainly one of the most catastrophic bugs in Bitcoin ever.” Awemany publicly expressed his feedback without hesitating to call Bitcoin Core’s most prominent developer arrogant. The vulnerability is being tracked in the CVE-2018-17144 advisory, which includes the following description:

“Bitcoin Core 0.14.x before 0.14.3, 0.15.x before 0.15.2, and 0.16.x before 0.16.3 and Bitcoin Knots 0.14.x through 0.16.x before 0.16.3 allow a remote denial of service (application crash) exploitable by miners via duplicate input. An attacker can make bitcoind or Bitcoin-Qt crash.”

However, the vulnerability was much more serious, as it could have allowed malicious miners to artificially inflate Bitcoin’s supply via a simple type of double input.

In simple terms, the recent event is related to the consensus code. Miners could crash blocks in case they tried to validate a block containing a transaction that attempts to spend the same input twice, causing the whole Bitcoin infrastructure to crash. Furthermore, providing that those invalid blocks need to be mined anyway, malicious miners willing to disregard block reward of 12.5 BTC (approximately $80,000) could even lead to destruction of the whole ecosystem.

Double-spending bug

A white lie or simple ignorance?

Perhaps, because of the possible catastrophic consequences of the error, the developers decided to keep it a secret, having won the time to fix it and invited both miners and users to update their software aimed at eliminating possible crash.

In the report made two days later, the developers explained that the team made every appropriate action in order to encourage immediate software upgrades, including building awareness for the concerned actors, while delaying publication of the full issue’s disclosure to gain time for systems to upgrade.

According to the statement, the patched vulnerability existed in the Bitcoin Core software without repairment since version 0.14, while version 0.15 introduced the inflation vulnerability.

Nevertheless, Bitcoin Core developers decided to disclose the full extent of the vulnerability after a majority of the BTC hash rate upgraded to the patched software, while full node operators who have not been complied with the guidance should do so as soon as possible.

Bitcoin’s Core statement resumed:

“At this time, we believe over half of the Bitcoin hash rate has upgraded to patched nodes. We are unaware of any attempts to exploit this vulnerability. However, it still remains critical that affected users upgrade and apply the latest patches to ensure no possibility of large reorganizations, mining of invalid blocks or acceptance of invalid transactions occurs.”

Bitcoin Core bugs timeline

Who found the bug?

Among the catalysts to help resolve this critical bug was Bitcoin Core developer Cory Fields, who identified one of the most critical vulnerabilities of Bitcoin Cash earlier this year, which could have been so disruptive that transacting Bitcoin Cash safely would no longer be possible, completely undermining the utility (and thus, the value) of the currency itself, as Cory argues here.

Community’s reaction

The Bitcoin Core development team has been heavily criticized by Bitcoin holders for the manner in which they rolled out the ‘hot’ announcement regarding the bug and the patch.

Indeed, their decision to publish the announcement without consulting members of the altcoin networks has disappointed many industry enthusiasts and contributors.

Among those who have expressed public criticism was the self-named Bitcoin Core’s ‘Secret Agent’ John Carvalho who described in a series of tweets how Bitcoin Core’s team was making decisions when the doors were closed.

The event was another opportunity for ‘crypto Twitter’ and especially the enthusiasts of Bitcoin and Bitcoin Cash to argue. Let’s not forget about plenty of Bitcoin users who have been thankful and have shown appreciation for the hard work of developers to keep Bitcoin’s network safe, without being remunerated and provide their services mostly on a volunteer basis.

Possible consequences

Despite the fact that the bug has been fixed, the question remains: What would have happened if the error had not been detected in time? In particular, some users wondered whether somebody managed to exploit this vulnerability to produce “a bunch of fake Bitcoins.” One of them even discovered that 0.1 BTC was generated in the Bitcoin Testnet as a result of such misuse.

The answers to these questions, along with words of reassurance, have been given by Bitcoin Core team in their latest update:

“Stored funds are not at risk, and never were at risk. Even if the bug had been exploited to its full extent, the theoretical damage to stored funds would have been rolled back, exactly as it was in the value overflow incident. However, there is currently a small risk of a chain split. In a chain split, transactions could be reversed long after they are fully confirmed. Therefore, for the next week or so you should consider there to be a small possibility of any transaction with less than 200 confirmations being reversed.”

Another Bitcoin developer, Pieter Wuille, assured that “if this bug would have been exploited already, it would be noticed by any such new node.”

Later, he added that in case such a bug had been exploited by someone after the update release, “all 0.14.0 version nodes would crash and everyone who upgraded would see warnings about not being on majority chain.”

Well, while all this may sound convincing, one more essential question still remains: What if not all the users managed to patch the upgraded version? More fuel to the fire has been added by CobraBitcoin, lead back-end developer at Openbazaar, who suggested that “80 percent of the network is [still] running vulnerable software.”

The percentage of this network is minimal, according to Emin Gün Sirer’s statement, with a major patch corresponding to economically worthless nodes. If they affected something useful, someone would have bothered to upgrade them.

All’s well that ends well

Bitcoin’s vision of decentralization and transparency seems to be minimized when looking closely the CVR-2018-1744 episode, indicating that major decisions are being taken by a small minority of members of the community. Therefore, the fear of a major loss of billions of dollars, in case of a different decision, seems to be obvious.

The probability of crashing the entire system was high in this saga, as the bug has been variously described as “very scary,” “major,” “catastrophic,” and one of the “top three of four” most severe bugs ever found in Bitcoin’s code.