<p>Full nodes verify the complete blockchain history on the initial block download (IBD) or on a <code>reindex</code>. As the node is synchronizing with the network, they keep updating the overview of spendable balances, the Unspent Transaction Output Set.</p>

<p>When a node gets disconnected or turned off, they can pick up from their last known state and continue updating the UTXO Set with the changes from the new blocks that have since been published.</p>

<p>The history only needs to be checked once. If another node changes the content of an old block, this will not change the state of any other nodes. Other nodes will only ever discard information that they have already validated when they learn about and reorganize to a heavier chain.</p>

<p>If you change a block in the past, you will still not be able to get your node to accept that new information, unless you additionally manipulate your own node's UTXO Set or the software you're running on your node to accept it.</p>

<p>However, this would be a pointless exercise, as nobody else would accept your changed block unless it is backed by being part of a heavier chaintip.</p>

CC BY-SA 3.0
2018-03-24T21:20:44.130Z
Thanks. 

Does it mean that it's theoretically possible for https://blockchain.info/ to show you incorrect block data if someone internally has modified an old block? It won't change anything for the network of course, but if someline is relying on a service to display the true state of the blockchain, internarl modifications to the old blocks may be left undetected for a while?
Bozho
CC BY-SA 3.0
2018-03-25T00:59:50.793Z
Yes, it would be theoretically possible, if someone had manipulated blockchain.info's database that they would show incorrect information.
Murch
CC BY-SA 3.0
2018-03-24T17:07:17.893Z
2018-03-24T17:07:17.893Z
Murch
<blockquote>
  <p>when are old blocks verified by each full node? </p>
</blockquote>

<p>never unless rescan=1 command-line option passed to</p>

<blockquote>
  <p>From what I've seen, the possible answers include: when it's downloaded and when you do a -rescan.</p>
</blockquote>

<p>yes, on downloading also of course</p>

<p>one of my .dat files is broken (some garbage in contents) but bitcoin-qt works well because it uses UTXO, not blocks themselves</p>

<blockquote>
  <p>if I change the contents of an old block (and thus break the hash chain)</p>
</blockquote>

<p>this depends what do you mean.</p>

CC BY-SA 3.0
2018-03-24T16:36:34.883Z
Rescan doesn't re-validate blocks.
Claris
CC BY-SA 3.0
2018-03-24T17:03:55.310Z
oups. reindex=1
amaclin
CC BY-SA 3.0
2018-03-24T14:15:00.680Z
2018-03-24T14:15:00.680Z
amaclin
<p>You can't change an old block without changing everyred hot chili peppers jorge subsequent block. You would have to mine again and rebroadcast every single block starting with the one you changed.</p>

<p>The nodes would then reject them because the blocks they have saved have more proof-of-work.</p>

<p>I don't know if a full node regularly verify the integrity of the chain from start to finish. But if they doesn't, that is unimportant for the attack you're describing.</p>

CC BY-SA 3.0
2018-03-24T13:21:30.717Z
This is wrong, changing an old block *would* change every subsequent block. Each block’s hash includes the previous block’s hash as input, so changing one will change the hash of every single block following it. Also, if a single block could be changed, that would not affect the total proof of work of the chain (all else held constant). So the nodes would not reject the block for the reason you cited, rather they would reject it because the new block would not have any other valid blocks built on it, and thus not be as long as the honest chain
chytrik
CC BY-SA 3.0
2018-03-24T17:24:41.520Z
It was a typo, I tried to say "can't"
Osias Jota
CC BY-SA 3.0
2018-03-24T12:26:29.583Z
2018-03-24T17:28:52.540Z
2018-03-24T17:28:52.540Z
Osias Jota
<p>I have a question about an implementation detail - when are old blocks verified by each full node? I.e. when will I be "caught" if I change the contents of an old block (and thus break the hash chain)</p>

<p>From what I've seen, the possible answers include: when it's downloaded and when you do a -rescan.</p>

<p>However, does a full node regularly verify the integrity of the chain from start to finish?</p>

<p>(I'm aware that changing the history on my node doesn't do any good, as those verifying my future transactions will have the correct chain and thus refuse any attempts to double spend)</p>

<bitcoin-core><full-node>
Verifying old blocks
Bozho
# Verifying old blocks

(Asked by: username_0 on 2018-03-24)

I have a question about an implementation detail - when are old blocks verified by each full node? I.e. when will I be "caught" if I change the contents of an old block (and thus break the hash chain)

From what I've seen, the possible answers include: when it's downloaded and when you do a -rescan.

However, does a full node regularly verify the integrity of the chain from start to finish?

(I'm aware that changing the history on my node doesn't do any good, as those verifying my future transactions will have the correct chain and thus refuse any attempts to double spend)

**Tags:** bitcoin-core, full-node


---

## 3 answers

### Answer by username_1 on 2018-03-24. Score: 1 | Accepted answer

Full nodes verify the complete blockchain history on the initial block download (IBD) or on a `reindex`. As the node is synchronizing with the network, they keep updating the overview of spendable balances, the Unspent Transaction Output Set.

When a node gets disconnected or turned off, they can pick up from their last known state and continue updating the UTXO Set with the changes from the new blocks that have since been published.

The history only needs to be checked once. If another node changes the content of an old block, this will not change the state of any other nodes. Other nodes will only ever discard information that they have already validated when they learn about and reorganize to a heavier chain.

If you change a block in the past, you will still not be able to get your node to accept that new information, unless you additionally manipulate your own node's UTXO Set or the software you're running on your node to accept it.

However, this would be a pointless exercise, as nobody else would accept your changed block unless it is backed by being part of a heavier chaintip.

> **Comments:**
> **username_0**: Thanks.   Does it mean that it's theoretically possible for https://blockchain.info/ to show you incorrect block data if someone internally has modified an old block? It won't change anything for the network of course, but if someline is relying on a service to display the true state of the blockchain, internarl modifications to the old blocks may be left undetected for a while?  
> **username_1**: Yes, it would be theoretically possible, if someone had manipulated blockchain.info's database that they would show incorrect information.  

---

### Answer by username_2 on 2018-03-24. Score: 1

> when are old blocks verified by each full node?

never unless rescan=1 command-line option passed to

> From what I've seen, the possible answers include: when it's downloaded and when you do a -rescan.

yes, on downloading also of course

one of my .dat files is broken (some garbage in contents) but bitcoin-qt works well because it uses UTXO, not blocks themselves

> if I change the contents of an old block (and thus break the hash chain)

this depends what do you mean.

> **Comments:**
> **username_3**: Rescan doesn't re-validate blocks.  
> **username_2**: oups. reindex=1  

---

### Answer by username_4 on 2018-03-24. Score: 0

You can't change an old block without changing everyred hot chili peppers jorge subsequent block. You would have to mine again and rebroadcast every single block starting with the one you changed.

The nodes would then reject them because the blocks they have saved have more proof-of-work.

I don't know if a full node regularly verify the integrity of the chain from start to finish. But if they doesn't, that is unimportant for the attack you're describing.

> **Comments:**
> **username_5**: This is wrong, changing an old block *would* change every subsequent block. Each block’s hash includes the previous block’s hash as input, so changing one will change the hash of every single block following it. Also, if a single block could be changed, that would not affect the total proof of work of the chain (all else held constant). So the nodes would not reject the block for the reason you cited, rather they would reject it because the new block would not have any other valid blocks built on it, and thus not be as long as the honest chain  
> **username_4**: It was a typo, I tried to say "can't"  

---

