<p>The great advantage of a new node starting from the genesis block is that the node is able to individually verify every transaction is valid and does not need to trust any other node to know that when done the entire blockchain is valid. The blockchain is verified independently and the integrity of the blockchain is established.</p>

<p>For those not interested in that, it is possible to just run an SPV client which just uses the headers.</p>

CC BY-SA 3.0
2018-01-31T16:16:42.137Z
Can you show an example why would syncing a full node from the middle of the blockchain fail? Would it still fail, if we assume that blocks have new field for the hash of the utxo database it's applied on?
Calmarius
CC BY-SA 3.0
2018-02-01T11:28:39.030Z
I am not assuming that syncing from the middle would fail, only that it would fail to fully validate the blockchain. The hash you suggest does not remove the need to validate that the transaction matches the hash for full validation, otherwise the hash is just a number.
Willtech
CC BY-SA 3.0
2018-01-31T08:51:41.017Z
2018-01-31T08:51:41.017Z
Willtech
<p>Bitcoin's blockchain is very much like a version control. It versions the unspent output database (and some metadata I don't know about) and blocks represent the deltas (commits or patches) to this database.</p>

<p>Now if you want to know the state of the system after 1000 blocks, you need to start from the genesis block, then download, verify and apply 1000 blocks (patches) to it. Now we are beyond 500000 blocks and syncing up new node takes ages.</p>

<p>Version controls solve this problem by inserting a full snapshot instead of deltas after several revisions so one don't have to apply all patches from first to last to get to the latest state. But this is not necessary.</p>

<p>It's enough if patches contain a hash of the state they are patching allowing the verification of the deltas themshelves. So if you have revision 1234 of the state, the patch that upgrades it to revision 1235 contains a hash of it. So the one who applies the patch can verify if they apply it to the correct state (it would be cryptographically very difficult to forge a different state that matches the hash and appear valid). So it's technically possible to design a system that allow syncing from the middle.</p>

<p>In case of the blockchain this would simply mean that instead of storing the hash of the previous block, it would store the hash of the previous state of the utxo database. This would mean that if I could download the utxo database eg. at block 500000, I could start apply the next 6000 blocks to it and reach the correct latest state without having to start from the genesis.</p>

<p>However the current design of blockchain doesn't allow this. You have to start from block 1 and catch up from that.</p>

<p>In 2009 when Bitcoin started version controls were probably well known already. And I think I wasn't the only one who suggested and discussed this. Probably there is a good reason for not allowing to start from the middle. So what's the advantages of having to start syncing from the genesis?</p>

<blockchain>
What's the advantage of making a new node sync from the genesis block?
Calmarius
# What's the advantage of making a new node sync from the genesis block?

(Asked by: username_0 on 2018-01-31)

Bitcoin's blockchain is very much like a version control. It versions the unspent output database (and some metadata I don't know about) and blocks represent the deltas (commits or patches) to this database.

Now if you want to know the state of the system after 1000 blocks, you need to start from the genesis block, then download, verify and apply 1000 blocks (patches) to it. Now we are beyond 500000 blocks and syncing up new node takes ages.

Version controls solve this problem by inserting a full snapshot instead of deltas after several revisions so one don't have to apply all patches from first to last to get to the latest state. But this is not necessary.

It's enough if patches contain a hash of the state they are patching allowing the verification of the deltas themshelves. So if you have revision 1234 of the state, the patch that upgrades it to revision 1235 contains a hash of it. So the one who applies the patch can verify if they apply it to the correct state (it would be cryptographically very difficult to forge a different state that matches the hash and appear valid). So it's technically possible to design a system that allow syncing from the middle.

In case of the blockchain this would simply mean that instead of storing the hash of the previous block, it would store the hash of the previous state of the utxo database. This would mean that if I could download the utxo database eg. at block 500000, I could start apply the next 6000 blocks to it and reach the correct latest state without having to start from the genesis.

However the current design of blockchain doesn't allow this. You have to start from block 1 and catch up from that.

In 2009 when Bitcoin started version controls were probably well known already. And I think I wasn't the only one who suggested and discussed this. Probably there is a good reason for not allowing to start from the middle. So what's the advantages of having to start syncing from the genesis?

**Tags:** blockchain


---

## 1 answers

### Answer by username_1 on 2018-01-31. Score: 3

The great advantage of a new node starting from the genesis block is that the node is able to individually verify every transaction is valid and does not need to trust any other node to know that when done the entire blockchain is valid. The blockchain is verified independently and the integrity of the blockchain is established.

For those not interested in that, it is possible to just run an SPV client which just uses the headers.

> **Comments:**
> **username_0**: Can you show an example why would syncing a full node from the middle of the blockchain fail? Would it still fail, if we assume that blocks have new field for the hash of the utxo database it's applied on?  
> **username_1**: I am not assuming that syncing from the middle would fail, only that it would fail to fully validate the blockchain. The hash you suggest does not remove the need to validate that the transaction matches the hash for full validation, otherwise the hash is just a number.  

---

