I read what an attacker with 51% of hash power can do in here and here.

However, I want to know whether an attacker with 51% of hash power can change old blocks? For example, assume the attacker has been the dominant node from today for a period of one week. Can she remove a transaction from a block which was confirmed yesterday? What about transactions confirmed one week or one month ago?

  • possible duplicate of bitcoin.stackexchange.com/questions/32212/…
    – morsecoder
    Jun 23, 2015 at 15:18
  • @ StephenM347: That question is similar to my question but from different point of view. I know that the solved block depends on every byte of transaction data and changing (or removing) a transaction of an old block requires changing the nonce and recomputing the hash. However, I want to know that a dominant attacker can change old blocks (using his 51% hash power)? How old? Jun 23, 2015 at 15:52

1 Answer 1


An attacker has a hard time changing the past

An attacker has very limited influence to change old blocks, because he has to replace all blocks that confirm the event he wants to change and keep up with the new ones that the network is still creating.

Say, Eve achieved to control 51% of the hash rate and wants to unconfirm a transaction from 6 blocks in the past.

To succeed, she has to provide 6 + X + 1 blocks, while the rest of the network finds X blocks.

With a hash rate distribution of 51:49 solving for X:

enter image description here

Eve would have to sustain control of 51% of the network's hashrate for an average of 172 blocks in order to unconfirm a transaction confirmed by six blocks.

That would be approximately 28 hours and 40 minutes. My calculation is simplifying the process by expecting a fixed block interval, as in reality, mining is a random process, it could take much longer or shorter.

Change a week of history?

For a week back, X would solve to 24,720 blocks, i.e. roughly 171 days.

How much could be changed with a week of 51% hash power?

With a week of 51% hash power, one would be able to catch up roughly 40 blocks, i.e. about 6 hours and 40 minutes.

But really?

Well, 50% of the hashing power doesn't just drop off the grid for long times without anyone noticing. If suddenly all blocks took twice as long people would start to catch on, after a few hours. I'm not sure everyone would just accept a rewrite of a significant portion of the history. As when both chain forks are public, it is easy to find out what was changed in the history, there might be broad support for declaring the attacking fork invalid, or at least somebody might be able to find out who got conned, and sue in meatspace.

  • Thanks for your comprehensive answer. But I think not accepting "a previously unknown chain that came in to replace a significant portion of the history" is not specified in bitcoin protocol. Could you provide some references for me. Jun 23, 2015 at 18:19
  • @TailofGodzilla: It is not in the protocoll, but in Bitcoin Core. I think I found it here: main.h: CheckForkWarningConditions. AFAIU When Bitcoin Core detects a chain fork of 7 length within the 72 blocks of the tip, there is a warning emitted, saying "Warning: Large valid fork found [...] Chain state database corruption likely.". Natural forks should never go on longer than a few blocks, and both forks would be known to the client. Publishing a longer, previously unknown chain should trigger the warning.
    – Murch
    Jun 23, 2015 at 20:57
  • I.e. the only circumstances this would occur in, would be malicious intent, which would probably not gain much support.
    – Murch
    Jun 23, 2015 at 22:01
  • I am going from the bits and pieces I've remembered from an old conversation, reading something about this months ago, and skimming the code. If you're interested in more information, perhaps you should ask another question about this specifically, and hope that someone more knowledgeable like a core dev took note. ;)
    – Murch
    Jun 24, 2015 at 7:37
  • Actually, I've asked a question myself: bitcoin.stackexchange.com/q/38237/5406
    – Murch
    Jun 24, 2015 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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