<p>It is unnecessary to recalculate block headers regularly. Whenever a new block is announced, the block header’s hash must meet the difficulty requirement to be acceptable. The combination of committing to the preceding block’s hash and the new block’s hash meeting the difficulty requirement, translates to an inductive commitment to all prior blocks in the best chain, as well as a proof of work. After this cheap check, the block is also tested to adhere to all other consensus requirements.</p>
<p>When a new block arrives, it checks whether this block extends its best chain or it constitutes an alternative chaintip with more work. If so, the node extends its best chain, or reorganizes to the new best chain’s tip.</p>
<p>If instead a block is published, that &quot;changes a predecessor of the best chain tip&quot;, this would produce a distinct block header from the original, and the new block would constitute an alternative chaintip at a lower height than the best chaintip. (And the attacker would have to spend the same amount of proof of work to make the changed block pass the difficulty requirement.) As the successor of the original block commits to the hash of the best chain, and all further successors each inductively commit to the original block by committing to a successor of the original block, the best chaintip would have more work than the alternative chaintip, <em>unless the attacker builds more blocks on top of their alternative block to outpace the prior best chaintip</em>.</p>
<p>Anyway, we only need to check each block once, and then simply keep the block header chain in memory and extend from there, and it is unnecessary to revalidate blocks later, because we already know that anything that is part of our best chain has been checked before and cannot be changed without changing the header’s hash.</p>

CC BY-SA 4.0
2024-08-22T18:16:30.220Z
2024-08-22T18:16:30.220Z
Murch
<p>Receiving nodes <a href="https://bitcoin.stackexchange.com/a/49440/34190">independently maintain</a> a copy of the <a href="https://bitcoin.stackexchange.com/a/60984/34190">UTXO set</a>. This is the set of <a href="https://bitcoin.stackexchange.com/questions/4301/what-is-an-unspent-output">unspent transaction outputs</a> that the node has checked previously. It is used to check fresh transactions.</p>
<p>When a new block is successfully found, its header and transactions are broadcast.</p>
<p>When a node receives the transactions, it:</p>
<ol>
<li>Re-constructs the merkle tree from the transactions and checks the header is valid.</li>
<li>For each transaction, it checks that there is a matching output in the UTXO set, and checks that the spend is valid.</li>
<li>It removes spent TXOs and adds new unspent TXOs from the new transactions.
Note that for every block, at least one new output is added for the coinbase transaction<sup>1</sup>.</li>
</ol>
<p>On full nodes, it is the UTXO set that is &quot;recalculated regularly.&quot;</p>
<hr />
<p><sup>1: It's possible that a coinbase could have no spendable outputs, but it's unlikely! </sup></p>
<p><sup> Note, in implementation, <a href="https://bitcoin.stackexchange.com/a/99827/34190">the UTXO set is spread over multiple separate structures</a>, but can be imagined as a single entity for explanatory purposes. </sup></p>

CC BY-SA 4.0
2024-04-27T14:16:59.783Z
2024-04-27T14:41:56.110Z
2024-04-27T14:41:56.110Z
Lee
<p>As that answer says,</p>
<blockquote>
<p>the nodes verify the transactions upon receiving a new block</p>
</blockquote>
<p>So each node only needs to check once and it can then make a note of the block-id. A node never needs to refetch a block it has already seen. It would fetch a block at the same height with a different id in which case that block gets validated</p>
<p>There is no real need for a node to periodically revalidate data it already received. Bitcoin core does recheck it's stored Blockchain data at startup though. This guards against local interference not against other nodes trying to transmit tampered blocks.</p>

CC BY-SA 4.0
2024-04-27T14:06:13.360Z
2024-04-27T14:06:13.360Z
RedGrittyBrick
<p>I am aware that, in Bitcoin, blocks are immutable because of the Merkle tree structure, which ensures that every block contains the (Merkle root) hash of the previous block.</p>
<p>Thanks to the properties of cryptographic hashes, even a 1 bit change in a previous block leads to a different hash, which <em>can be</em> used to detect tampering if you compare the hash of block (N-1) to the hash included in the next block N.</p>
<p>My question is: when is this check actually carried out?</p>
<p><a href="https://bitcoin.stackexchange.com/a/92684/151280">Some claim that</a></p>
<blockquote>
<p>yes, the blocks get recalculated regularly</p>
</blockquote>
<p>but I haven't found any source on this claim.</p>

<blockchain><security><merkleblock>
Do nodes periodically check block hashes?
A. Darwin
# Do nodes periodically check block hashes?

(Asked by: username_0 on 2024-04-27)

I am aware that, in Bitcoin, blocks are immutable because of the Merkle tree structure, which ensures that every block contains the (Merkle root) hash of the previous block.

Thanks to the properties of cryptographic hashes, even a 1 bit change in a previous block leads to a different hash, which *can be* used to detect tampering if you compare the hash of block (N-1) to the hash included in the next block N.

My question is: when is this check actually carried out?

[Some claim that](https://bitcoin.stackexchange.com/a/92684/151280)

> yes, the blocks get recalculated regularly

but I haven't found any source on this claim.

**Tags:** blockchain, security, merkleblock


---

## 3 answers

### Answer by username_1 on 2024-08-22. Score: 1

It is unnecessary to recalculate block headers regularly. Whenever a new block is announced, the block header’s hash must meet the difficulty requirement to be acceptable. The combination of committing to the preceding block’s hash and the new block’s hash meeting the difficulty requirement, translates to an inductive commitment to all prior blocks in the best chain, as well as a proof of work. After this cheap check, the block is also tested to adhere to all other consensus requirements.

When a new block arrives, it checks whether this block extends its best chain or it constitutes an alternative chaintip with more work. If so, the node extends its best chain, or reorganizes to the new best chain’s tip.

If instead a block is published, that "changes a predecessor of the best chain tip", this would produce a distinct block header from the original, and the new block would constitute an alternative chaintip at a lower height than the best chaintip. (And the attacker would have to spend the same amount of proof of work to make the changed block pass the difficulty requirement.) As the successor of the original block commits to the hash of the best chain, and all further successors each inductively commit to the original block by committing to a successor of the original block, the best chaintip would have more work than the alternative chaintip, *unless the attacker builds more blocks on top of their alternative block to outpace the prior best chaintip*.

Anyway, we only need to check each block once, and then simply keep the block header chain in memory and extend from there, and it is unnecessary to revalidate blocks later, because we already know that anything that is part of our best chain has been checked before and cannot be changed without changing the header’s hash.


---

### Answer by username_2 on 2024-04-27. Score: 0

Receiving nodes [independently maintain](https://bitcoin.stackexchange.com/a/49440/34190) a copy of the [UTXO set](https://bitcoin.stackexchange.com/a/60984/34190). This is the set of [unspent transaction outputs](https://bitcoin.stackexchange.com/questions/4301/what-is-an-unspent-output) that the node has checked previously. It is used to check fresh transactions.

When a new block is successfully found, its header and transactions are broadcast.

When a node receives the transactions, it:

1. Re-constructs the merkle tree from the transactions and checks the header is valid.
2. For each transaction, it checks that there is a matching output in the UTXO set, and checks that the spend is valid.
3. It removes spent TXOs and adds new unspent TXOs from the new transactions.
   Note that for every block, at least one new output is added for the coinbase transaction1.

On full nodes, it is the UTXO set that is "recalculated regularly."

---

1: It's possible that a coinbase could have no spendable outputs, but it's unlikely!

Note, in implementation, [the UTXO set is spread over multiple separate structures](https://bitcoin.stackexchange.com/a/99827/34190), but can be imagined as a single entity for explanatory purposes.


---

### Answer by username_3 on 2024-04-27. Score: 0

As that answer says,

> the nodes verify the transactions upon receiving a new block

So each node only needs to check once and it can then make a note of the block-id. A node never needs to refetch a block it has already seen. It would fetch a block at the same height with a different id in which case that block gets validated

There is no real need for a node to periodically revalidate data it already received. Bitcoin core does recheck it's stored Blockchain data at startup though. This guards against local interference not against other nodes trying to transmit tampered blocks.


---

