0

What I know so far is that when the node starts for the first time or after some time, the Initial Block Download (IBD) begins. The node chooses one peer (the header sync peer) from 8 outgoing connections. Initially, it sends a getheader message only to this peer and receives headers from it. As the timestamp of receiving headers approach current timestamp, the node starts sending getheader requests to the remaining peers. Headers received from other peers can differ and even create two chains starting from the genesis block.

What I'm interested in is at what point does node start requesting for blocks? Is it during IBD or does it first download headers from all peers, create a complete header tree and only then start downloading blocks for the chain with the most cumulative power and move the active chain tip?

By the way, if checkpoints are applied to header sync, if I get from these other peers in IBD some chain (headers) that starts before checkpoint, how will my node accept it? In case my sync peer gave me wrong chain, I will stay forever blocked from getting the best chain.

3
  • 1
    Whenever there are headers in our header tree, and peers which we know to have blocks in that header tree that we don't have, we start asking them for those blocks. Commented Jan 8 at 3:49
  • @PieterWuille Ok, thanks. What do you think about this what I wrote for checkpoints? If my node choose bad peer, we would remain permanently blocked in that kind of attack.
    – Cosmos
    Commented Jan 8 at 3:55
  • There are various timeouts, at some point other peers get asked too. If a node gives us invalid blocks/headers, the network code may disconnect the peer too, etc. Commented Jan 8 at 4:05

1 Answer 1

1

What I'm interested in is at what point does node start requesting for blocks? Is it during IBD or does it first download headers from all peers, create a complete header tree and only then start downloading blocks for the chain with the most cumulative power and move the active chain tip?

There are two different processes.

The first is IBD. It is divided in two phases (caused by header pre-sync). In first we select one peer as the sync peer and send him one by one getheaders requests. As the timestamp of received headers begins to approach the current timestamp, we start sending getheaders messages to other peers as well. Peer responses with corresponding headers, we validate them and store their tiny identifiers (nothing is stored in block header tree at this moment).

Only after the peers send us all the headers they have (all header messages with less than 2000 objects) we move to the second phase.

In the second phase, we send getheaders messages only for headers that are part of the chain that has enough cumulative work. There are two conditions: that cumulative work must be within one day of the current active chain tip and greater than a certain predefined value. Since the first condition at the very first moment is a genesis block (and some low difficulty blocks), it will be easily bypassed by malicious peer, however, the second condition will not. At this phase, it does not matter which peer you are requesting (whether it is sync peer or some other), it is only important that we ask some peer for which we know it has given header.

More to read about header pre-synchronization you can find in this post.

The second process works, something like, on events. Whenever a new header is added to the tree (event) this process is triggered. If various necessary conditions are met, a request for the block will be sent to one of the peers that is considered to have it.

When a node is just started, since in initial synchronization we only "talk" to one peer, then as sync peer sends us headers, we validate them and put in the tree, getdata requests for these blocks will be sent to that sync peer immediately.

Therefore, no! We do not store all headers first, create complete tree and then download blocks. Everything is done simultaneously. However, we do download all headers in the tree for pre-sync first, before doing anything else.

For this and much more other information check this post.

18
  • The pre-syncing process will prevent low-difficulty headers from being accepted, and without headers, no blocks will be downloaded/accepted either. Commented Jan 8 at 5:07
  • @PieterWuille Fine, but pre-sync at the begin is on genesis block. Low difficulty chain that we get from malicious peer will have cumulative work that is bigger than genesis, so it will be accepted?
    – Cosmos
    Commented Jan 8 at 5:12
  • No, there is a minimum amount of accumulated chain work hardcoded in the client, updated at every release. No headers chain below that value is accepted. See bitcoin.stackexchange.com/questions/76018/…: "(which means: enough to within one day of the active chain tip, and more than the preconfigured minimum chain work)". Commented Jan 8 at 5:17
  • @PieterWuille Thanks, I've edited the answer. Is it okay now?
    – Cosmos
    Commented Jan 8 at 5:52
  • We do not wait for the headers sync to complete before requesting blocks (but pre-sync does need to complete, because no headers are added to the block header tree during presync). Commented Jan 8 at 13:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.