Bitcoin Forum

Question 1:
Assume some node is offline for a long time. After it reconnects to block chain, how does it know what is latest block? As his peer nodes maybe "wake up just now". From their view of chain, maybe the current tip is not the really Latest block.

Question 2:
I am confused how "IsInitialBlockDownload" function works. What is role of this function? It require a node to download a fixed number of block("nChainWork" must more than "nMinimumChainWork").

Question 3:
I run the a new node and read its debug.log file. I find Node got many inv tx info. But it does not sync all the block data(blk***.dat). And it does not "Requesting tx data of tx hash". why ?

"2020-02-10T12:21:14Z got inv: tx 04ef3414b55e45555ebfad775b6164827a020a25836e6a4db87eeb9ebee462d9  new peer=4
"

Question 5:
Why it named 'tip', I think 'top' is more obviously understand. "Top block" :)


Thank you

5. It's probably better to assume it's more of a hint.

1. The peers.dat is designed to store up to a thousand peers and the other peers will be able to help the new client find the most up to date one. There's probably the initial major/trusted peers that take up the first 10 in thst spot (I assume) in order to limit such an event from occurring.

3. That data is stored into memory, the debug log doesn't include io writes because it'd probably be very similar every time and io writes to disk take a long time... (a few milliseconds afaik).

Initialblockdownload is adopted by the client to download a large number of blocks at a faster rate. Currently, Bitcoin Core downloads the block headers first to allow it to request blocks simultaneously from all the peers that it is connected to.

To answer your question, the client will not download blocks from its peers unless the work in the chain that the peers have is higher than the one defined in the chain which is currently located here [1] as of now. It helps to prevent sybil attacks (to a certain extent) which tricks your client into downloading blockchains that has too little work (ie. Chains that are shorter difficulty wise).

[1] https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L87

A node will connect to many peers in a way that is unlikely to have many peers that are also behind. The reason for this is twofold. Firstly, a node will store a database of peers and some information about those peers. When it starts up, it chooses peers from that database and chooses them based on some "goodness" information it stores. Secondly, if that database is too small or has a lot of offline nodes, then it will use the DNS seeders. The DNS seeders will filter for nodes which are up for a long time so new nodes will be connected to seed nodes that know many peers. Those nodes will return additional nodes for new nodes to connect to based on node uptime and other characteristics. So peer discovery itself will select for nodes that have been up for a while and thus are likely to have the latest block.

But even if all of the peers are just coming online, they too will be connected to other nodes and syncing their own blockchain. As they receive new blocks and block headers, they will be able to serve them to their peers. So if you are only connected to nodes that are still syncing, you will still sync from them as they sync their blockchain from their other peers.

It is a bunch of heuristic tests that just check for whether the node is likely to be not synced. It is used to disable certain functionality that is dependent on a recent blockchain (IsIBD will return true before being fully synced).

Other nodes will just send invs to all of their peers regardless of sync state and other status. It is up to the receiver of those invs to do something with them. Because your node is still syncing, it won't request those transactions as it might not be able to validate them yet.