1

It's usually frustrating when my Bitcoin Core full node is syncing, especially just catching up from merely several hours/days ago.

I wonder how does Bitcoin Core manage its peers? Will it disconnect with slower nodes, and then turn to faster ones?

I once heard of the eclipse attack issue. However, as far as I know, Bitcoin Core syncs the block headers first, then it will always download full block data. It doesn't seem to hurt if Bitcoin Core could behave in such way (switching to faster nodes) when it's downloading blocks.

EDIT: According to my rough observation, fast nodes often seemed to be "stuck", as long as slow peers were still not disconnected, in other words, manually disconnecting slow peers often seemed to "accelerate" the syncing process.

Is that merely some sort of illusion, or a real phenomenon? Will manually disconnecting nodes introduce any risk?

Improve this question

1 Answer 1

Reset to default
1

One thing to note is when you're syncing the blockchain, you're both downloading the blockchain and also validating all of the transactions. So that is also a possible bottleneck on your end that could be causing a slow sync.

I wonder how does Bitcoin Core manage its peers? Will it disconnect with slower nodes, and then turn to faster ones?

This question addresses how peers are initially discovered. If you're interested in connecting to a different node you know of, you can use the rpc to disconnectnode and addnode.

Improve this answer
7
  • I'm quite sure that validation is not the bottleneck, since I'm not running Bitcoin Core on a constrained environment like RaspPi. I actually asked about the "role" of peer nodes during different stages. I thought that my node can try its best to reach as many nodes as possible firstly, only to fetch block headers; then it could try to download block data as fast as possible, which doesn't seem to require reaching nodes of broader scope.
    – Chris Chen
    Commented Dec 24, 2019 at 12:34
  • This is incorrect. During IBD, sufficiently slow peers will get disconnected.
    – Pieter Wuille
    Commented Dec 24, 2019 at 12:37
  • @PieterWuille According to my observation, fast nodes often seemed to be "stuck", as long as slow peers were still not disconnected.
    – Chris Chen
    Commented Dec 24, 2019 at 12:40
  • 4
    @ChrisChen The mechanism for finding good peers is certainly not perfect, but it exists. The answer here claims that nodes are only disconnected when peers go offline or when manually disconnecting, which is completely false. When one peer is preventing us from making progress, they are disconnected (see "stalling block download" messages in debug.log), but there are various other reasons why peers would be disconnected too (e.g. misbehavior, or for incoming connections, better peers taking the slots for worse peers).
    – Pieter Wuille
    Commented Dec 24, 2019 at 12:42
  • 1
    That's already what is done. Only during IBD are peers kicked for being slow.
    – Pieter Wuille
    Commented Dec 24, 2019 at 12:45

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.