2
I am running a full node on the Bitcoin network. Sometimes, I find that it takes a while until I get the newest block.
I checked the source code, and found that every node can at most connect to eight peers. Would it help to increase the number of connections, to reduce the time until I receive the newest block?
2
Up until the latest release (v0.9.3), more peers actually means slower synchronization typically, because we only really fetched from a single peer.
The upcoming release (v0.10.0) has a completely rewritten block fetching/validation mechanism, which first validates headers, and then fetches the blocks from all peers in parallel. The result should be much faster synchronization.
2
Yes, more peers may reduce the time it takes for you to receive the most recently mined block.
When a new block is mined, the miner (or the pool) sends an inv message to all of its peers announcing the new block. Those peers all send a getdata message to the miner requesting the block. The miner replies with a block message sending the block to each of the peers which requested it. (This part can be optimized to not send an entire block.)
Then the peers each validate the block. Once validated, they send an inv message to all of their peers announcing the new block. Any of those peers which haven't received the block yet send a getdata message requesting the block. The block message follows, and the cycle repeats until all peers on the network have the block. (Or, in the case of SPV clients, just the parts of the block they need.)
The more peers you have, the greater the chance you'll be connected to the miner when he makes his initial announcement with an inv message, allowing you to be one of the first to request the block with the getdata message.
However, if the peer you send the getdata message to is bogged down in data transfer, it may take you longer to finish downloading the block than if you had started downloading from a different peer, so having more connections isn't a guarantee that you'll be able to download recently-mined blocks faster. In short, there's an element of luck involved.
Thank you, David. your description gave me a clear blueprint. – Eleven – 2014-11-20T01:38:34.627
IF the upcoming version is in parallel to fetching blocks, do you think change the max outbound bigger will be better? – Eleven – 2014-11-20T01:41:40.767
1Yes, but the advantage will be less significant in absolute terms. For example: if peer A is connected to the miner and peer B is connected to peer A, it might take 5 seconds for peer A to download and verify the block from the miner and then 5 more seconds for peer B to download and verify the block from peer A (10 seconds total). If an improvement allows the block to be downloaded and verified in 4 seconds, peer A will still get the block in half as much time, but the total time peer B has to wait is only 8 seconds. – David A. Harding – 2014-11-20T02:02:06.580
Hi, Pieter . First Thank your answer very much. I don't know what doses the parallel exactly mean. I checked the source code and found every peer can fetch at most 16 blocks and then fetch from another. Is the parallel processing as you said? Or am I wrong. Thank you. – Eleven – 2014-11-20T01:33:54.393
Wait, I assumed your question was about synchronization from scratch to the latest block. If you're talking about just receiving the latest block when you're already caught up there is little to do but being connected to good peers. – Pieter Wuille – 2014-11-20T09:35:27.243