Let's say someone creates a blockchain fork starting from the genesis block, when the difficulty was absurdly low compared to today; then he starts mining new blocks from there up to the current block index.

Normally, this would require such an amount of time to make it completely impossibile to catch up with the real blockchain; even if he used today's powerful mining hardware, the difficulty increase would compensate for it quickly. But, here's the catch: he customizes his mining software to not ever increase the difficulty, even if it's mining hundreds of blocks per second; block timestamps are simply faked in order to make it seem they were generated at ~10 minutes interval.

When the fake blockchain is longer then the real one (currently ~300000 blocks), he starts broadcasting it; it appears to conform to all rules, and it's longer than the current one, thus all clients and miners treat this as a winning fork and switch to working on it. Of course, difficulty increases abruptly as soon as the full network hashing power is thrown at it, and after some time block generation resumes normal levels.

But now the creator of the fake blockchain owns all Bitcoins that have been generated from the genesis block to when he released it.

Is this scenario actually possible? If not, why? How would Bitcoin nodes reacts to a 300000-blocks-long fork? Is there a limit on how long a fork can be?

  • 2
    "he customizes his mining software to not ever increase the difficulty" This would make the blocks incompatible with standard Bitcoin clients. – Tim S. May 7 '14 at 16:31
  • 1
    Not if the blocks have fake timestamps which make it seem like they were generated about every 10 minutes; that generation rate would not trigger a difficulty increase. When the full fake blockchain is released, it would seem like it was generated by a constant amount of hashing power which never required increasing the difficulty. – Massimo May 7 '14 at 18:09
  • 2
    Hm, I suppose you're right, with one big catch: in order to get 300,000 blocks generated every 10 minutes with constant (low) difficulty and forged timestamps, you'd need the total time period to be longer than the real blockchain's time period. This causes problems, but as Nate points out, it's the difficulty that's the real criteria, not the length, so it's irrelevant. – Tim S. May 7 '14 at 18:49

There are two problems with this:

  • The "longest" block chain is selected not by total number of blocks, but by total difficulty. A chain with a large number of low-difficulty blocks would not win.

  • The Bitcoin reference client hard-codes the hashes of a relatively recent block as a "checkpoint" and will reject any chain not containing that block at the correct height. So any chain that diverges before the checkpoint will be ignored.

  • Great, exactly the answer I was looking for :) – Massimo May 7 '14 at 14:55
  • "The Bitcoin reference client hard-codes the hashes of a relatively recent block as a "checkpoint" and will reject any chain not containing that block at the correct height" this hasn't been true since block 295000 in 2014. – G. Maxwell Jul 23 '18 at 1:22
  • Yep, and you might like to look at the date of my answer... :-) – Nate Eldredge Jul 23 '18 at 6:04

Nate gave a good answer on the modern meaning of "longest chain"-- as a historical curiosity, the originally released Bitcoin software behaved like you were expecting and that attack would actually work! It was later changed to determine "longest" in terms of work. This seems like a pretty big mistake, but for Bitcoin's first year the difficulty was constantly at the minimum. Longest by-count and by-work give the same result if the blocks all have the same difficulty.

Even if you did eventually match the total work of the 'real' chain somehow your fork would get ignored by current implementations because they hardcode the identities of some of the early blocks (up to 2014, but not more recently). There were several historical weaknesses that motivated this, but almost all of them are long since resolved. The reason the residual pinning exists is because with the advent of modern mining ASICs it has become so cheap to make diff=1 blocks that it would be plausible to run a node out of memory with low diff blocks while it was busy trying to figure out if they would eventually add up to enough work in total. There are several known ways of mitigating this remaining attack, but they are all a lot more complicated to implement than the simple expedient of fixing the old chain.

There is an interesting theoretical attack related to this subject-- if we assume that hashrate increases exponentially forever due to advances in computing power and we assume an attacker has a constant arbitrarily small fraction of mining power (because he also benefits from tech improvements) and he attempts to mine a fork starting arbitrarily far back and adjusts his timestamps to get the highest difficulty he can get then eventually he will end up with more apparent work than the actual chain with probability 1! This is because his high difficulty results in high variance, and eventually he gets arbitrarily lucky and jumps ahead. The assumed exponential growth means that his lack of luck in the past needs only a constant relative amount of luck in the present to overcome it, no matter how far he fell behind in the past. The attack is only theoretical because if you plug in realistic numbers the success rates for this sort of attack only become non-negligible after numbers of years that we don't have words for. :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.