Issue on 2 March 2018: The reason that the Electroneum blockchain has stopped working at block 179840 on 2 March 2018 is due to a bug that slipped in when trying to address the original 202612 bug as described below. The problem is due to an error in the line of code that forces the blockchain to adopt the new version. However, this is a simple fix and a new, updated version should be released within a couple of hours, as pointed out by CEO Richard Ells.
In the past few days there has been a lot of uncertainty in the Electroneum community regarding the Block 202612 bug, as pointed out by a Reddit user, KnifeOfPi2. The bug has been inherited from the Monero code, which Electroneum is based on, and is relatively easy to fix.
In this post, I’ll try to explain what the bug is and how it affects you.
We’ll start with a short summary, and then dive into a detailed explanation of things.
Note: This post is a summary of the writings of KnifeOfPi2 and the Monero Research Lab (publication MRL-0002 in particular), whose writings have enabled me to understand the bug thoroughly. Thank you.
The Short Explanation
According to KnifeofPi2, “on September 4, 2014, somebody exploited a flaw in the Monero code to cause block #202612 to evaluate to an incorrect hash.” This caused the blockchain to split into two (not a so-called hard fork, as you’ll see) at block #202612.
A detailed explanation of this hack can be found in MRL-0002.
The hacker tried to use this opportunity to sell all his coins on one side of the chain while keeping his coins on the other side of the chain. Luckily, most of his selling transactions were caught by exchanges and could be blocked.
However, due to the complexity of the attack (as you can read in the detailed explanation below), cleaning up this mess was no easy task. Block 202612 was already captured in the blockchain and could not be reversed.
So in order to fix this issue, the developers hard-coded a check into the Monero code so that future miners that tried to validate the blockchain would simply accept block 202612 and not try to question its hash.
How Does This Affect Electroneum?
Electroneum is based on the Monero code, meaning it is using a slightly modified version of the Monero codebase. When copying the code, the developers overlooked this hard-coded fix that was introduced by the Monero developers.
When Electroneum reaches block 202612 on its own blockchain, and the bug is not fixed, the Electroneum blockchain will come to a halt and would not be able to process further transactions until the bug is fixed.
Luckily, the inherited bug is a simple two-line fix, according to the Electroneum team, that is relatively easy to do. The developers will release a new version of the code, after which all miners will need to upgrade to that code.
According to KnifeOfPi2, “If the offending pieces of code are removed before March 9, the network will continue operating as normal. Basically, all nodes have to be updated, and anyone who doesn’t update will be kicked off the network.”
Miners that update to the new code will continue without a hitch and carry the Electroneum blockchain by themselves while miners that do not upgrade will essentially be “stuck” on block 202612 until they upgrade. Therefore, no hard fork will occur and there is no reason to panic.
Is my ETN Safe?
Yes, indeed. Miners that upgrade to the new code will be able to carry the network until all the remaining miners have upgraded.
Your coins are in no danger of being stolen or double-spent. There is nothing you need to do at the moment.
But if you want to understand this bug entirely, read on…
The Long, Detailed Explanation
Now, let’s take a look at the long, detailed explanation. I’ll start by explaining what a hash is, how this bug was introduced into the Monero blockchain, how the attacker exploited it, and what it means for Electroneum users.
Origins of the Bug
On September 4, 2014, a hacker exploited an extremely sophisticated bug in the Monero blockchain, causing block 202612 to pass with an incorrect hash, and allowing him/her to split the Monero blockchain in two for a short period of time. This attack was performed at block 202612 in the Monero blockchain (hence the name).
Once again, refer to MRL-0002 for a complete review of this hack.
In order to spot this flaw in the Monero code, the attacker must have been an educated person. According to MRL-0002, “The attacker must have had extensive knowledge of the Monero code, had good knowledge of Merkle Trees, and basic knowledge of cryptographic hash functions.”
So let’s break this apart. First, we need to know what a block hash is.
What is a Block Hash?
A block hash (or hash for short) is basically a fingerprint or a signature of a particular string of text (in this case a block of transactions in text format), often used in various kinds of cryptography. When a block is “hashed”, complex mathematical functions are performed to generate a hash (or signature) of the block.
Hashing the same block of transactions will produce an identical hash everytime it is hashed. But changing even one character in that block will cause the hash to look entirely different, with no similarity whatsoever to the original hash.
This is a powerful tool for keeping information safe.
The process of hashing is special because it is irreversible. There is no known method for a person in possession of a hash to figure out what the original string was from which the hash was computed.
How Block Hashes are Computed in Monero
To keep blockchains safe, transactions in a particular block are combined into one large string and then hashed.
In Monero, a special hashing structure called a Merkle Tree is used.
According to MRL-0002, “…to build a Merkle Tree, we take some blocks of data (transactions), and we hash them. Then we hash those, two at a time. Then we hash those, two at a time. And we repeat this process until we are done. You can think of a Merkle Tree as a football bracket of cryptographic hashes.”
This is illustrated for a block with 8 transactions in the image below:
At some point only a single hash remains, representing all the transactions combined into a Merkle Tree.
It is obvious that a process of this kind would only work if the number of transactions is equal to a power of 2 (such as 22 = 4, 23 = 8, 24 = 16, 25 = 32, etc…).
So what happens if a block has a total number of transactions does not equal a power of 2? It is here where the bug in the Monero code crept in – in the way that these hashes were computed.
According to MRL-0002, “The attacker noticed that a mis-implementation of a commonly used power-of-two rounding algorithm could be exploited while computing the hash of a block in order to generate two distinct blocks with the same hash.”
To summarize the complicated mathematical explanations in MRL-0002, the code was written in such a way that blocks with a number of transactions not equal to a power of 2, would generate the same hash as one with the highest number of transactions that equal a power of 2, below that value.
It is as if only the number of transactions up to a specific power of 2 is considered when generating the hash, and all the remaining ones are left out the hashing process.
For example, relating to our example figure above, any block with 9 – 15 transactions would generate the same hash as a block with only 8 transactions since 8 is the highest power of 2 strictly less than the actual transaction count. In each of these cases, only the first 8 transactions were used to calculate the block hash.
How the Attacker Exploited this Bug
The attacker then published 2 blocks at exactly the same time, but with a different number of transactions. He used the bug above to allow him to pass two blocks with a different number of transactions, under the same block hash.
According to MRL-0002, “Once two blocks with the same hash were published nearly-simultaneously, part of the network had one block and the rest of the network had the other block ” And since the hashes of both blocks were “correctly hashed” according to the faulty code, both blocks were accepted by the community.
However, this now created an irregularity in the transaction list. Half of the miners had one list of transactions, and the other had another list, and so they could not agree with one another. Neither half would accept new blocks from the other half.
As said in MRL-0002, “The two parts of the network refused to accept the legitimacy of the blockchain upon which the other part was operating. It was as if, suddenly, half the Monero network switched to a brand new CryptoNote coin’s blockchain. It still appeared to,
say, currency exchanges or vendors, that they were both one network still working on Monero…
…The attacker had a short window of time during which they could sell ‘counterfeit’ Monero from the new network on an exchange such as Poloniex for Bitcoin and immediately withdraw.”
But his Monero on the other half of the blockchain remained intact, essentially allowing him to double his Monero coins.
Luckily, according to MRL-0002, many of the exchanges involved were quick to pick up on the problem and froze the transactions. Most of the illegal “counterfeit” funds were recovered.
How the Bug was Fixed
The Monero developer community now had to provide a fix that would allow subsequent miners to correctly validate block 202612 on the original blockchain and discard it on the “forked” blockchain.
So to fix this, they hard-coded the hash of block 202612 directly into the Monero code, meaning that they entered the exact hash of block 202612 into the code rather than have the code compute it by itself.
This allowed the Monero blockchain to function normally again.
But it created a few small problems for Electroneum…
How to Bug Affects Electroneum
Electroneum is based on Monero’s codebase. The developers essentially just copied the Monero code and published it with slight modifications under the Electroneum name (perfectly legal, by the way, since Monero is an open-source project).
However, the original bug fix for block 202612 was carelessly left in place and not removed.
So when Electroneum reaches block 202612 somewhere in early March 2018, problems would arise. Instead of computing the correct hash of the block, the code would then try to evaluate the block using the hard-coded hash instead, which would obviously be wrong.
According to KnifeOfPi2, “If the issue is fixed through a soft fork, the network will continue working just fine, and absolutely nothing will happen.”
If the bug fix is not removed, Electroneum miners at that point will become stuck, and won’t be able to progress any further. They’ll be “stuck in limbo”, forever trying to evaluate a block using a hard-coded hash, that will never evaluate correctly.
How to Fix the Bug
The Electroneum team can easily fix the bug by removing the original Monero bug fix from the code and releasing the updated version to the public (this process is often called a soft fork).
Miners that adopt this new code will carry on past block 202612 without a hitch. Miners that don’t adopt the code will become stuck and will be unable to verify any subsequent blocks or transactions until they update to the new code and resync the blockchain.
This will not create a fork since the old miners won’t be able to build new blocks on their side of the blockchain. They will essentially be trapped and stuck until they upgrade to the new code.
Does This Affect Your ETN?
No, in no way, whatsoever.
The Electroneum team has announced that they will release an updated version of the code soon. There’s a lot of publicity regarding this bug, so it can be certain that most miners will upgrade to the new code after the updated version is released.
Your coins will be safe and well and won’t get lost, stolen, or double-spent.
There won’t be a fork and therefore no additional coins will be created either.