This past weekend, bitcoin miners lost up to US$50,000 as the Bitcoin network was affected by the generation of invalid blocks due to the appearance of two separate versions of the blockchain or a “fork.” This fork continued to exist for six blocks and later, three more invalid blocks were generated as the issue repeated the following day.
This article will look at the reason for this problem, possible solutions and blockchain alternatives.
Under the hood
A signature must be generated in order to conduct a Bitcoin transaction. The signature generated with cryptographic algorithm ESCDA includes transaction data, private key and some random data.
Actually, the signature is two integers: r and s. It is generated by OpenSSL library and encoded using strict DER (Distinguished Encoding Rules) encoding. DER encoding is an ASN.1 (Abstract Syntax Notation One) presentation format. Different versions of OpenSSL library might encode the signature in various ways.
Due to this fact, in case network users utilize clients with different versions of the libraries (e.g. when people compile binaries on their own; in such situation version of the OpenSSL depends on OS), network might face issues when nodes reject the chain, as they cannot correctly verify the signature, leading to forks.
Therefore, Bitcoin had depended on signatures parsing from OpenSSL library for a long time. In winter of 2015, an issue of OpenSSL 1.0.0p / 1.0.1k incompatibility rose. As a result of OpenSSL's change for CVE-2014-8275, many clients rejected any signature which was not encoded in a strict manner.
Then Core Bitcoin team came to a conclusion that using the software, which was not designed or distributed for consensus use (in particular OpenSSL) for the purposes of consensus-normative behavior was incorrect, and measures had to be implemented.
Bitcoin Core Developer Gregory Maxwell wrote:
"While for most applications it is generally acceptable to eagerly reject some signatures, Bitcoin is a consensus system where all participants must generally agree on the exact validity or invalidity of the input data. In a sense, consistency is more important than ‘correctness.’"
Maxwell proposed a solution when the signature should have been decoded and then re-encoded before verification to ensure that it was properly consumed. BIP66 created in January of 2015 proposed to transfer the signature validation control to the core Bitcoin code to make Bitcoin independent of OpenSSL.
- Gregory Maxwell
What happened?
In order to implement this feature, Bitcoin needed a “hardfork,” which was supposed to be performed in two stages. Before the start of voting, all Bitcoin blocks were v.2. New rules were to be introduced when at least 750 blocks out of 1000 generated would have been v.3. Then, as soon as 950 out of 1000 generated blocks would have been v.3, all v.2 blocks were supposed to become invalid, and all the next blocks would have enforced the new rules.
First, the voting took place, and everyone voted for the new signature format, i.e. 750 of 1000 blocks generated were v.3. After passing the second threshold, v.2 blocks should not have been accepted by the network.
The network kept generating them, quite logically, as not all clients were updated. The strange part, however, was that instead of declining these blocks, the network kept accepting them.
They were accepted by 50% of the network, because these 50% were SPV (Simplified Payment Verification) clients, which do not verify everything in the block, but instead rely on either connecting to a trusted node, or high difficulty as a proxy for proof of validity. As a result, 50% of the network accepted blocks while the other 50% did not. The network was split.
Why did it happen?
If we look at the list of invalid block hashes on the Bitcoin Wiki, we can see that invalid blocks were generated by 4 pools and (maximum) two big miners. We can assume that they had an older version of Bitcoin, with a few changes from the following version introduced manually. The pools might very well have their own patched Bitcoin code.
Solution
According to the announcement on the Bitcoin.org website, everyone should upgrade to get only the correct chain. Miners should upgrade their software not to lose their money. Any non-upgraded miners will lose their money. After the situation is solved, all v.2 blocks will be recognized as invalid. It will happen sooner or later, but it is inevitable.
Sellers should increase the required number of transaction confirmations, since there is a possibility of a long branches not being accepted by the network, as the orphans generate 50% of the network. However, these chains would not likely be longer than 30 blocks, so 30 checks would suffice.
What’s ahead?
There is nothing to fear, as the problem will finally be solved. However, miners will lose quite a lot. Currently it is announced that several large miners have lost over US$50,000 dollars’ worth of mining income. Merchants, on the other hand will probably not be affected. The hardfork is a very complicated process. Bitcoin had a few months to realize that 50% miners do not verify the blocks as they should, but this did not happen.
It may be possible that light clients (SPV mining / SPV wallets) are not reliable enough. At least, it is not enough to simply listen to a single node. Some alert mechanism should be used to notify the users that something wrong is going on in the network.
Altcoin alternatives
Bitcoin-based currencies
All cryptocurrencies, which have Bitcoin codebase in its core, have the same issue with transaction signature verification by OpenSSL libraries. That means that potentially every altcoin network might have problems with block rejection due to different signature encoding by different clients.
Nowadays, a hardfork for the implementation of BIP66 recommendations is the best solution for solving the problem in Bitcoin-based currencies. Meanwhile, for every cryptocurrency developer team it is very important to utilize this experience of Bitcoin’s hardfork planning pitfalls and light clients’ unreliability for future hardforks.
CryptoNote currencies
Bytecoin and other CryptoNote currencies are different because they do not rely on OpenSSL and have their own cryptography and codebase. Roughly speaking, CryptoNote team accounted for everything that was described in BIP66, among other improvements when the network was only designed.
NXT & Ethereum
NXT utilizes bouncycastle.crypto, a lightweight cryptography API for Java and C#. Ethereum relies on Crypto++, also known as CryptoPP. Both of them are external libraries as well as OpenSSL. We cannot be confident that changes in the libraries would not affect these cryptocurrencies’ network consensus.
Full disclosure: The author of this article Joseph Lin is a Bytecoin developer.