<p>Yes a full node downloads and verifies all blocks starting from the genesis block. Not on every startup though, the state is efficiently stored and read back into memory on startup (with some rechecking of the last X blocks as a sanity check against corruption).
For finding the right chain, it starts with downloading the headers first, with which it can determine the most-work chain, so it doesn't need to download all forks along the way (unless it encounters an invalid block).
Yes, this can take a while, but it's at the core of how bitcoin achieves being trustless: validate everything yourself.</p>

CC BY-SA 4.0
2019-08-09T18:46:42.523Z
2019-08-09T18:46:42.523Z
Jannes
<p>When a new node joins the network, it will look up nodes from the DNS seeds. It'll reach out to multiple nodes it hears about and ask them for more peers in turn.
The new node asks each of their peers for their best chaintip and then starts sychronizing the headers of the best chaintip it hears about first. A block header is only 80 bytes (tiny in comparison to complete blocks) but already allows checking that all the blocks on that chain are connected and that the blocks are meeting the difficulty criteria.</p>

<p>From then on, the node verifies each block in order to validate that the consensus rules were followed. If the best chaintip they were following is found to be injuring any consensus rules, the first block to be invalid is discarded and the peers that follow this chain disconnected. The best chaintip from that point on is found instead is found by querying the remaining (rule-compliant) peers. Finally, the node will discover the valid chain with the most accumulated difficulty.  </p>

<p>Each release of Bitcoin Core sets a default value for the <code>assumevalid</code> parameter to a block that recently preceded the release. When synchronizing up to that block, nodes using <code>assumevalid</code> will assume that the history up to that block is valid. They will still calculate all the UTXO set transitions and check difficulty everywhere, but will not check signatures on transactions up to that block.</p>

CC BY-SA 4.0
2019-08-09T19:12:04.270Z
So, when a user (Alice) connects to the network and communicates with others peers (Bob and Charlie), Alice only asks for the header of the top block of their active chain, and not for their whole blockchain state (forks included)? Then from this information Alice works her way backwards to the genesis block.. if some block in the sequence is not found by Alice, she asks that same user for the lost block. If Alice eventually has the whole blockchain sequence to the genesis block, and the chain is deemed valid, then from all the valid chains Alice picks the one with most work?
E. Kruminis
CC BY-SA 4.0
2019-08-09T20:45:02.933Z
Kinda. 1. Alice asks each peer to tell them their best height. Then she asks the peer with the highest accumulated difficulty to provide her with the full chain of headers from her current block to their chaintip. After validating the header chain, Alice's node builds up from the genesis block towards the chaintip. Only if she learns about a better chaintip or finds an invalid block does she change the chaintip she's working towards. The sync happens from genesis block to chaintip.
Murch
CC BY-SA 4.0
2019-08-09T18:51:06.150Z
2019-08-09T18:58:54.107Z
2019-08-09T18:58:54.107Z
Murch
<p>Let's say a user joins the Bitcoin network and downloads the latest state of the blockchain (all blocks, which includes the forks/uncles). How does this user find/determine the active blockchain on which they should build upon? I'm not asking about difficulty levels or the amount of work that gets put into the chain, but as to how this one user finds that longest chain and is sure that there are no more longer chains.</p>

<p>I imagine the simple (and only?) way to do this would be to check every single block the user has, and then start building upon the one which has the most work put into it. However, since nodes also store the numerous forks, evaluating every single block and its "path" throughout Bitcoin's existence is likely to take a while (and continue to take longer as time goes on).</p>

<p>A potential 'shortcut' would be to simply look up recent blocks, eg. search for blocks that were submitted in the last 48 hours, and then just take the longest valid chain from there, but then how would one decide on a particular timeframe? (24h? 48? last week? last month?) It would still in theory be possible that the current longest chain has been published a long time ago and other nodes are acting maliciously by trying to ignore it, so this approach doesn't seem valid in my opinion.</p>

<p>I know Bitcoin uses LevelDB to store metadata about blocks for quick look up, which would help speed up the evaluation of all the blocks, but is there are more pragmatic approach that Bitcoin's code takes?</p>

<p>Also, is this evaluation done from scratch (ie. from the genesis block) each time the user boots up, or is the information about the longest chain stored somewhere on disk for quick future retrieval when the user rejoins?</p>

<synchronization><peer-discovery><checkpoints><assume-valid>
How does a node find the active chain?
E. Kruminis
# How does a node find the active chain?

(Asked by: username_0 on 2019-08-09)

Let's say a user joins the Bitcoin network and downloads the latest state of the blockchain (all blocks, which includes the forks/uncles). How does this user find/determine the active blockchain on which they should build upon? I'm not asking about difficulty levels or the amount of work that gets put into the chain, but as to how this one user finds that longest chain and is sure that there are no more longer chains.

I imagine the simple (and only?) way to do this would be to check every single block the user has, and then start building upon the one which has the most work put into it. However, since nodes also store the numerous forks, evaluating every single block and its "path" throughout Bitcoin's existence is likely to take a while (and continue to take longer as time goes on).

A potential 'shortcut' would be to simply look up recent blocks, eg. search for blocks that were submitted in the last 48 hours, and then just take the longest valid chain from there, but then how would one decide on a particular timeframe? (24h? 48? last week? last month?) It would still in theory be possible that the current longest chain has been published a long time ago and other nodes are acting maliciously by trying to ignore it, so this approach doesn't seem valid in my opinion.

I know Bitcoin uses LevelDB to store metadata about blocks for quick look up, which would help speed up the evaluation of all the blocks, but is there are more pragmatic approach that Bitcoin's code takes?

Also, is this evaluation done from scratch (ie. from the genesis block) each time the user boots up, or is the information about the longest chain stored somewhere on disk for quick future retrieval when the user rejoins?

**Tags:** synchronization, peer-discovery, checkpoints, assume-valid


---

## 2 answers

### Answer by username_2 on 2019-08-09. Score: 3 | Accepted answer

When a new node joins the network, it will look up nodes from the DNS seeds. It'll reach out to multiple nodes it hears about and ask them for more peers in turn.
The new node asks each of their peers for their best chaintip and then starts sychronizing the headers of the best chaintip it hears about first. A block header is only 80 bytes (tiny in comparison to complete blocks) but already allows checking that all the blocks on that chain are connected and that the blocks are meeting the difficulty criteria.

From then on, the node verifies each block in order to validate that the consensus rules were followed. If the best chaintip they were following is found to be injuring any consensus rules, the first block to be invalid is discarded and the peers that follow this chain disconnected. The best chaintip from that point on is found instead is found by querying the remaining (rule-compliant) peers. Finally, the node will discover the valid chain with the most accumulated difficulty.

Each release of Bitcoin Core sets a default value for the `assumevalid` parameter to a block that recently preceded the release. When synchronizing up to that block, nodes using `assumevalid` will assume that the history up to that block is valid. They will still calculate all the UTXO set transitions and check difficulty everywhere, but will not check signatures on transactions up to that block.

> **Comments:**
> **username_0**: So, when a user (Alice) connects to the network and communicates with others peers (Bob and Charlie), Alice only asks for the header of the top block of their active chain, and not for their whole blockchain state (forks included)? Then from this information Alice works her way backwards to the genesis block.. if some block in the sequence is not found by Alice, she asks that same user for the lost block. If Alice eventually has the whole blockchain sequence to the genesis block, and the chain is deemed valid, then from all the valid chains Alice picks the one with most work?  
> **username_2**: Kinda. 1. Alice asks each peer to tell them their best height. Then she asks the peer with the highest accumulated difficulty to provide her with the full chain of headers from her current block to their chaintip. After validating the header chain, Alice's node builds up from the genesis block towards the chaintip. Only if she learns about a better chaintip or finds an invalid block does she change the chaintip she's working towards. The sync happens from genesis block to chaintip.  

---

### Answer by username_1 on 2019-08-09. Score: 0

Yes a full node downloads and verifies all blocks starting from the genesis block. Not on every startup though, the state is efficiently stored and read back into memory on startup (with some rechecking of the last X blocks as a sanity check against corruption).
For finding the right chain, it starts with downloading the headers first, with which it can determine the most-work chain, so it doesn't need to download all forks along the way (unless it encounters an invalid block).
Yes, this can take a while, but it's at the core of how bitcoin achieves being trustless: validate everything yourself.


---

