<p>Changing the previous block hash in all of the subsequent block hashes will change those block's hashes too. They become different blocks and are treated as different blocks by nodes. When other nodes try to verify those other blocks, they will extremely likely compute a block hash which does not meet the Proof of Work requirement, and thus those blocks would fail validation.</p>
<p>The way around this is for the attacker to recompute the Proof of Work, but then that takes a lot of time and computing power and is thus difficult to do.</p>

CC BY-SA 4.0
2020-12-30T21:22:46.397Z
Okay, understood. So the proof of work will fail because it's highly unlikely that the new computed proof of work hash would match the target space required by the proof of work. Therefore it falls to be computably unfeasible to recalculate all the hashes up to the head of the chain. Is that right?
deadlock
CC BY-SA 4.0
2020-12-30T21:36:05.487Z
Just one more question: how many proofs of work have to be verified when a new block is added to the chain? Is this range going from each previous block which includes every last validated transaction to which the new transactions of the minted block are referring to, to the last accepted block?
deadlock
CC BY-SA 4.0
2020-12-30T23:26:57.530Z
@ignacioaranguren to verify the state of the network, every block all the way back to the genesis block needs to be verified. A node only needs to do this once, and then each new block is verified as it is received, and this verification includes checking that previous block hash is included and correct (but the node has already verified that previous block - no need to do it all over again!).
chytrik
CC BY-SA 4.0
2020-12-30T20:37:20.147Z
2020-12-30T20:37:20.147Z
Ava Chow
<p>I'm dealing with some problems to finally understand how implicit consensus works and I've come across with one question. Suppose the following:</p>
<p>A malicious miner proposes the following block to be included somewhere in the middle of the blockchain. If he just copies the value of the previous block's hash pointer in the new block's header, and recalculates the following blocks hash pointers till the end of the chain, by coping the same header in each block in the original chain, wouldn't this blockchain be as valid as the original, considering that the new hash pointers match with the content of each previous block?</p>
<p>A way of trying to clarifying myself and answering to the question was to think of the implicit consensus. Could it be that the other well-behaving nodes will deny this proposing block by storing a copy of the previous state of the blockchain and comparing the old blockchain with a new one?</p>

CC BY-SA 4.0
2021-01-26T22:13:43.023Z
Possible duplicate of https://bitcoin.stackexchange.com/q/69149/5406
Murch
<blockchain><consensus>
How does the blockchain know if its block hashes have been tampered?
deadlock
# How does the blockchain know if its block hashes have been tampered?

(Asked by: username_0 on 2020-12-30)

I'm dealing with some problems to finally understand how implicit consensus works and I've come across with one question. Suppose the following:

A malicious miner proposes the following block to be included somewhere in the middle of the blockchain. If he just copies the value of the previous block's hash pointer in the new block's header, and recalculates the following blocks hash pointers till the end of the chain, by coping the same header in each block in the original chain, wouldn't this blockchain be as valid as the original, considering that the new hash pointers match with the content of each previous block?

A way of trying to clarifying myself and answering to the question was to think of the implicit consensus. Could it be that the other well-behaving nodes will deny this proposing block by storing a copy of the previous state of the blockchain and comparing the old blockchain with a new one?

**Tags:** blockchain, consensus

> **Comments:**
> **username_1**: Possible duplicate of https://bitcoin.stackexchange.com/q/69149/5406  

---

## 1 answers

### Answer by username_2 on 2020-12-30. Score: 2 | Accepted answer

Changing the previous block hash in all of the subsequent block hashes will change those block's hashes too. They become different blocks and are treated as different blocks by nodes. When other nodes try to verify those other blocks, they will extremely likely compute a block hash which does not meet the Proof of Work requirement, and thus those blocks would fail validation.

The way around this is for the attacker to recompute the Proof of Work, but then that takes a lot of time and computing power and is thus difficult to do.

> **Comments:**
> **username_0**: Okay, understood. So the proof of work will fail because it's highly unlikely that the new computed proof of work hash would match the target space required by the proof of work. Therefore it falls to be computably unfeasible to recalculate all the hashes up to the head of the chain. Is that right?  
> **username_0**: Just one more question: how many proofs of work have to be verified when a new block is added to the chain? Is this range going from each previous block which includes every last validated transaction to which the new transactions of the minted block are referring to, to the last accepted block?  
> **username_3**: @ignacioaranguren to verify the state of the network, every block all the way back to the genesis block needs to be verified. A node only needs to do this once, and then each new block is verified as it is received, and this verification includes checking that previous block hash is included and correct (but the node has already verified that previous block - no need to do it all over again!).  

---

