Why was this block hardcoded in the source-code?
What happened with the Monero blockchain in the block 202612?
Monero Stack Exchange is a question and answer site for developers and users of the secure, private and untraceable cryptocurrency Monero. It only takes a minute to sign up.Sign up to join this community
In short, someone managed to exploit a bug in the code, which produced a block that couldn't be validated by the nodes, there's a full analysis of the attack here, https://lab.getmonero.org/pubs/MRL-0002.pdf
Fluffy explained it well, so I'll just paste his abbreviated comment from here: https://www.reddit.com/r/Monero/comments/30jp2n/alright_devs_own_up_whats_the_deal_with_magic/cpte8lk:
The long and the short of it is: the tree-hash.c code that is responsible for transaction hashes within a block had a bug in it whereby any hashes for more than 512 transactions would be computed using uninitialised memory (ie. with garbage). So the attacker slowly built up the dynamic block size limit until they were able to create a 72kb block with 514 transactions in it. Because the hash on transaction 513 and 514 in that block was computed using some random bits of memory on the mining pool's node at the time, a fork occurred. The network eventually chose one of the forks.
We could have patched the bug and carried on, as the network resolved the fork and was fine within 30 minutes of it occurring, but there was a problem with that: nodes stuck on the old fork still existed (in fact I spotted one still around the other day, and this attack occurred in September, 2014). When syncing up and receiving blocks from peers these "stuck" nodes are fine, until you get to block 202612, when suddenly it sends you a block that you cannot verify. We also found that there were some instances of nodes on the correct fork, but their transaction hashes for transactions 513/514 on block 202612 disagreed. This opened up the possibility for the attacker to spend those funds later on (or even for them to be used in a ring signature) which would cause another explosion.
Thus we had to add in a checkpoint for 202612, except that the block hash is over the block header only (ie. disregarding the actual transaction hashes), so we created an exception that uses a blob hash (ie. based on the raw block). We're actually busy refactoring that out into a more general purpose blob hash checkpoint system, partly for legibility, but also so we can use it in future if there is ever a need.
Someone found a bug in a tree hash function, and managed to exploit it, resulting in an unresolvable fork in the chain.
There is a full explanation from Tacotime: https://bitcointalk.org/index.php?topic=583449.msg8677607#msg8677607