Historical Review: Catching One of Bitcoin’s Major Vulnerabilities

Published in

Qtum

7 min readFeb 20, 2020

Background

Since the launch of Bitcoin’s mainnet in 2009, it has been “secure” for 11 years, and “very few” major security breaches have occurred. This is also the value of Bitcoin. However, “security” is always a relative concept. After all, Bitcoin is a set of software, and software will have problems.

The Qtum development team had independently discovered in 2018 and reported to the Bitcoin security team an additional issue that could have destroyed Bitcoin: CVE-2018–17144. This vulnerability is one of the most significant security holes in Bitcoin history. This article will introduce the impact of this vulnerability and some technical details, and review the Qtum team’s independent discovery of the vulnerability.

Bitcoin CVE-2018–17144 Vulnerability

The Bitcoin CVE-2018–17144 vulnerability can crash some older versions of Bitcoin nodes, in a DoS (Denial of Service) attack CVE (Common Vulnerabilities and Exposures) is the international listing of publicly known cybersecurity vulnerabilities and is used for reporting problems with all types of software). Even more frightening is that this vulnerability can be used to issue additional Bitcoins. This means that if this vulnerability was exploited, the 21 million bitcoin cap will be broken and attackers can “create” out of nothing new bitcoin. There would also be an unlimited number of Bitcoin inflows into the market, which would undoubtedly cause a devastating blow to the Bitcoin ecosystem.

The vulnerability was introduced from Bitcoin 0.14.x version in 2017, and was not repaired until the 0.16.3 version of September 2018 and was fully disclosed on September 20. Fortunately, no one has exploited this loophole during this time, otherwise, the history of Bitcoin may be completely different today.

Sequence

According to the information disclosed in [1], the Bitcoin Core development team received a DoS vulnerability report from anonymous developers on September 17, 2018, and Bitcoin Core developers discovered that there was an additional issue. The DoS issue was less severe, while the additional issue was a critical problem because it could be used to attack Bitcoin. Therefore, the Bitcoin Core development team fixed this issue on September 18 and concealed the fact that additional vulnerabilities were discovered. They told the community that this was just a DoS vulnerability fix and contacted major mining pools to upgrade. Until September 20, David Jaenson, a Qtum developer, independently discovered and reported the details of additional vulnerability [4], and the Bitcoin Core team had to fully disclose all the information about the vulnerabilities.

The actions of the vulnerability disclosure process are also sufficient to prove its severity. Only for problems that threaten the entire Bitcoin ecosystem will the Bitcoin core team choose to temporarily conceal.

Introduction to the Vulnerability

The Bitcoin Core development team has disclosed the details of the CVE-2018–17144 vulnerability in detail [1], and many community developers have also conducted detailed technical analysis after the event [2] [3], interested readers can refer to the references for more details. Here is a brief introduction to its principle.

“Double spending” is the core problem that all digital currencies need to solve. The so-called “double spend” means that the same money is used twice, which is equivalent to “making money out of nothing”, which is unacceptable for digital currencies. The bottom layer of Bitcoin uses the UTXO model (Unspent Transaction Output), which can prevent “double spending” with extremely simple logic. The same UTXO cannot be used twice. In the more familiar account model, the logic for dealing with such problems is much more complicated and has nothing to do with this article, so it will not be introduced.

The CVE-2018–17144 vulnerability involves a relatively uncommon “double-spend” attack: miners can use this vulnerability to include illegal “double-spend” transactions in the blocks they mine. This transaction is repeatedly used with the same UTXO as an input to “issue” additional bitcoins.

This attack is certainly not easy, and earlier versions of Bitcoin have rigorously checked this situation. However, as a software, Bitcoin is also constantly updating and iterating. Developers have restructured and optimized these checks in a lot of logic and efficiency. It is during the multiple optimization processes that there is a problem with the above-mentioned “double-spend” verification was introduced.

Vulnerability Introduction Process

The process of introducing the vulnerability is roughly as follows [4]:

In the Bitcoin version released in 2012, the development team introduced a redundancy check, which repeated the above-mentioned “double-spend” check in two different pieces of code. Of course, this is not a problem in itself, it just wastes some time.

Since then, a developer has optimized the logic of the redundant second-level check and changed the logic of rejecting transactions when encountering the above “double-spend” to exit the node because the first-level check had already verified the check. So, it would not possible to appear again in the second inspection.

In 2017, in the Bitcoin 0.14 version, another developer performed a performance optimization on the redundant first-layer check, because this check will check the input of each transaction one by one, and the developer felt that this efficiency was very low, so the check was skipped by default.

In the 0.15–0.16 version, the database structure of the Bitcoin node had undergone a relatively large adjustment. In the process, the above-mentioned second-level redundancy check was entirely deleted. At this point, the original two-level redundancy check was completely “removed”.

Consequences

As a result, the “double-spend” attack initiated by the miner described above become possible:

For 0.14.x nodes, this attack can directly cause the node to crash in a so-called DoS attack;

For the later versions of 0.15.x-0.16.2, this “double-spend” attack will be directly recognized as a legal transaction to realize the “additional issuance” of Bitcoin.

It is worth noting that only miners can launch the above-mentioned attacks because “double-spend” transactions initiated by ordinary users will soon be found to be illegal once they are broadcast, while miners can directly write transactions into blocks. Therefore, the cost of this attack is also very high, and it needs sufficient computing power to support it.

But even if you do not launch an attack directly, you only need to publicly disclose this vulnerability and attack method, you can easily “short” Bitcoin, and thus obtain huge benefits in the secondary market.

At that time, most of the nodes in the Bitcoin network were affected versions 0.14–0.16. If the vulnerability was exploited, it would be enough to destroy all the consensus established by Bitcoin in the past ten years. The Qtum team was the first to independently discover this additional issue, and theoretically had enough time to launch an attack. However, the Qtum team did not choose to launch an attack or disclose it through public channels but instead used responsible disclosure to confidentially report to the Bitcoin security team as soon as possible.

Qtum and Bitcoin

Why can the Qtum team discover Bitcoin security holes?

Qtum is the first public chain project to successfully support smart contracts on top of the Bitcoin UTXO model. The UTXO-based solution proposed by Qtum can also be implemented on Bitcoin, but it is difficult for a conservative Bitcoin core development team to promote such a large improvement. At the same time, Qtum is also the only open source project that always follows the latest Bitcoin code. Every iteration of Bitcoin is introduced into Qtum. Not only that, Qtum contains both the underlying UTXO model code of Bitcoin and the EVM of Ethereum. It also uses the PoS consensus mechanism, so the security issues to be considered are more complicated than Bitcoin. It can be said that to become a Qtum developer, you must first become an expert in Bitcoin and Ethereum.

The time back on September 18, 2018, when the Bitcoin Core team pushed the new version to the community to fix the “DoS vulnerability”, which concealed the fact that it added additional vulnerabilities. The Qtum team followed up on this upgrade, but during the testing process, Qtum developer David Jaenson quickly discovered that there was an additional issue. With a cautious approach, David investigated Qtum’s UTXO code, EVM code, and PoS code in detail, and finally determined that it was an additional issue of the Bitcoin code itself. After discussions with the team, Qtum reported the vulnerability to the Bitcoin development team and submitted a complete attack test case. The Bitcoin team subsequently made full disclosure of the vulnerability and specifically thanked Qtum developer David Jaenson for his contribution [1].

Invited to Satoshi Nakamoto Roundtable

There are many Bitcoin code contributors among Qtum developers, and it is one of the technical teams most familiar with Bitcoin and Ethereum code. It is precisely because of Qtum’s technical team’s long-term support for the Bitcoin technology community that Qtum co-founder Patrick Dai was invited to participate in the confidential closed-door meeting of the Bitcoin circle in 2020: Satoshi Roundtable [5]. This closed-door meeting is also known as the “Bilderberg Meeting” of the Bitcoin circle.

Conclusion

In the future, the Qtum technical team will continue to be active in open source projects such as Bitcoin and Ethereum, and work with the open-source community to ensure the underlying security mechanism of the blockchain. At the same time, Qtum will continue to make breakthroughs in blockchain privacy computing, improved consensus mechanisms, and more advanced virtual machines. We believe that more Qtum technology solutions will be adopted by other open-source projects such as Bitcoin in the future to jointly create a more complete underlying infrastructure of the blockchain.

References

Original article: https://medium.com/@chain.info1/fcoin-cold-wallet-keeping-secrets-ed961cbb7e90