a Responsible message about the vulnerabilities in the era of cryptocurrency
25 APR 2018 I anonymously privately reported critical vulnerability of Bitcoin Cash, one of the most expensive cryptocurrency in the world, which should not be confused with Bitcoin. The successful abuse of this vulnerability could be so devastating that secure transactions Bitcoin Cash would no longer be possible, which completely destroyed the usefulness (and therefore value) of the currency. But the vulnerability was fixed without incident and made public may 7, 2018
Cash Bitcoin is a cryptocurrency different from Bitcoin and is not compatible with it. It is so named because of its origin from Bitcoin. Fixed at the moment the bug, described below, was only Bitcoin Cash; the only connection with the Bitcoin – like name.
As for me and my motives, I work as part of an Initiative by digital currency (Digital Currency Initiative), the Media laboratory Massachusetts Institute of technology (MIT Media Lab), which, as the name implies, is a group dedicated to the research and development of cryptocurrencies. In particular, I help develop and maintain Bitcoin Core, the original software implementation of Bitcoin. In connection with this work, I am often asked at conferences and seminars what I think is the greatest challenge for Bitcoin in the future. My answer is always the same: to avoid catastrophic software bugs.
The identification of this bug, which could definitely lead to disaster, confirmed my belief that the threat of software bugs in the crypto world is greatly underestimated. I submit a detailed report about this incident not as an attack against Bitcoin Cash, but as a real example of how much more work is required to achieve a sophisticated technological level necessary for the cryptocurrency, and as a warning to companies who are not adequately prepared for such scenarios.
In short, it was rewritten some of the code for verification of signatures in the transaction, but in the new code was missing a critical check some particular bit in the type signature. In his message, I called this bit SIGHASH_BUG. This omission allowed a specially crafted transaction to fork the blockchain Bitcoin Cash in two incompatible chains. The next section describes the significance of this split. A detailed description of the bug and the solution, see the text of my message.
What is special about the bugs, splitting the blockchain?
The majority of cryptocurrencies, including Bitcoin and Bitcoin Cash, operate by spreading a registry of all transactions to all participants. To spend coins, the sender must first create a transaction in accordance with all the rules of the system. Most of the rules are obvious and straightforward, for example, “you can’t spend more than you have”, but there are much more sophisticated and technical, especially those which describes the format of digital signatures. But if the cryptocurrency is decentralized, who sets these so-called validation rules?
The validation rule set all together!
The rules of the system are what see them all and to monitor their compliance – task software. If a participant tries to cheat and create a transaction spending money he doesn’t have, other participants simply reject such transaction. Therefore, the transaction has been accepted, it must follow even the most pedantic rules.
ON that monitor compliance with the validation rules, needs time to develop. Constant changes to improve performance, add new options, better security, etc. But it is critical that all versions of the compliance was carried out in the same way.
What happens when an accidental software bug in a new version, the transaction is considered valid, whereas all previous versions of the software rejected it as invalid? The result is a “split chain” and that means that some of the participants who updated their software, will accept this transaction. And so as transactions and blocks are chained together, two groups of participants differ in their opinion about of all future transactions. Without quick action on the part of developers and campaign to group all participants on one side of the fork two camps of participants and will not be able to reach agreement. Then, the currency will actually split into two incompatible currency – a return to the status quo impossible.
When weighing the potential consequences of such bugs is crucial timeliness. If the blockchain is split so that on one side 99% of the participants, and the other only 1%, then an obvious solution is for everyone to join the majority. But if about 50% upgraded to the new version, the easy way out does not exist.
It is this bug, splitting the blockchain, I found the new version of the most popular implementation of Bitcoin Cash, but only after it was updated almost half of the network.
As a starting point for the new cryptocurrency Bitcoin Core is often used, as it is free open source software. In addition to benefits in previous years of improvement, the use of open source means that not related to each other cryptocurrencies can benefit from future enhancements each other. Source software implementation of the Cash Bitcoin, called the Bitcoin ABC (which, again, introduces confusion), is just one of those that is based on Bitcoin Core.
Because large chunks of shared code, such derivatives often have similar bugs, and hence similar solutions to these bugs. However, it is not realistic to expect that the developers working on a single currency, will actively share their improvements with developers working on other currencies, even to keep up with one project – not an easy task. So I developed a habit every few months to see the changes some of these projects in finding solutions to bugs that may be relevant to Bitcoin Core.
Looking at the beginning of this year, the change log Bitcoin ABC, I noticed that one of the most critical parts of the validation transaction has been refactored. Change it immediately caught my eye because they seemed unnecessary. Intrigued by their reason, I decided to see what he thinks about the changes the community. The only argument was “encapsulation”, the reviews were only from two people and a code review was just one week before its adoption.
A thorough refactoring is very common and often is a good practice in regular programming. However, it is risky to modify the code validation of crypto-currencies because of the ever-present threat with irreversible consequences when the blockchain splitting.
Seeing how few reviews got changes and how many rows were changed, I felt it was likely he could sneak a bug, and so I started to search. To find SIGHASH_BUG, took less than 10 minutes.
Above I mentioned that my message about the bug was anonymous. I would like to explain the reasons, as the anonymity has played in an important role.
Making sure the bug can be easily abused, I decided to notify the developers of Bitcoin ABC – but quickly realized that there is a big problem. It was a bug in a public, open, and it was able to detect anyone else. Nothing prevented anyone to make the same discovery and used it before the error can be eliminated.
What could happen in worst case? Let’s say I reported the bug privately, using my name and someone would have found it independently and the next day anonymous took it. So I used in the message your name, there will be convincing proof that I had the necessary knowledge and tools to attack the network. I would not be able to prove that the attacker is not me. Imagine that the attack was in total lost billions of dollars. People have killed for much less. So anonymity was not just important, but I considered it necessary for its own security.
Trying to figure out whether it is possible completely anonymous message, I began to ask myself whether or not to get involved. In the end, I was not obliged to say anything. But if someone found the same bug in Bitcoin Core, I would have hoped that it would draw him to our attention with maximum prudence and safety. So I decided to do: create a message that I would like to read it, and deliver it in a way I would prefer it to.
The first step was obvious – I needed to know about the politics of the Bitcoin ABC for the responsible reporting of any vulnerabilities. Policy for dealing with such matters in our day – a common occurrence and is a must for any project where safety is critical. Unfortunately, I cannot find this policy on the website or code repository. The closest thing I could find is the screen when sending a message in the bug tracker on GitHub:
Not the same. Then I started trying to find public encryption keys for communication with the “people” known as the developers of Bitcoin ABC. The encryption of the message guarantees that no one else can see it, and therefore I would be less worried about how to deliver the message. I would not be able to verify the identity of the key holders, but such an approach still would be a reasonably safe and much better than no encryption.
But I again stalled. No public servers PGP keys where they usually should look for, no code repository no keys for communication with the main developers was not. Then I had no other option but to anonymously request the keys through various online channels, using Tor to best disguise his identity.
First, I created a throwaway account on GitHub and on 25 April reached out to several developers of Bitcoin ABC:
Fortunately, it worked! After about 5 hours I got the key and quickly used it, having written in response a detailed description of the problem. But when I went the next day to see if you have got the answer, GitHub has blocked my burner account, perhaps due to the use of Tor. So further contact in this way was impossible. I had to assume that the message has not been received.
Having the encryption key, I decided to try the last method of communication and sent an encrypted message through the bug tracker Bitcoin ABC, also using Tor and one-time account. Six hours later, having received no reply, I wrote on the bug tracker last desperate appeal:
On April 27, when I waited for answer to your message in about 48 hours, opened a request about inclusion of changes to quietly fix the problem in the Bitcoin ABC. Obviously, the message was received. Success!
I found a vulnerability in Bitcoin Cash was successfully reported and resolved and in the end not provided for free noticeable effects. But it would be wrong not to give the ecosystem the ability to perform this significant omission.
The developers of cryptocurrency should reflect and reconsider the tools available, and we use policies and procedures. Even if we can’t eliminate the risk of similar bugs, but I can learn that in the future it is better to be prepared.