<p>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.</p>
<blockquote>
<p>I wonder how does Bitcoin Core manage its peers? Will it disconnect with slower nodes, and then turn to faster ones?</p>
</blockquote>
<p>This <a href="https://bitcoin.stackexchange.com/questions/3536/how-do-bitcoin-clients-find-each-other">question</a> 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 <a href="https://bitcoincore.org/en/doc/0.19.0/rpc/network/disconnectnode/" rel="nofollow noreferrer">disconnectnode</a> and <a href="https://bitcoincore.org/en/doc/0.19.0/rpc/network/addnode/" rel="nofollow noreferrer">addnode</a>.</p>

CC BY-SA 4.0
2019-12-24T12:34:42.877Z
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
CC BY-SA 4.0
2019-12-24T12:37:59.007Z
This is incorrect. During IBD, sufficiently slow peers will get disconnected.
Pieter Wuille
CC BY-SA 4.0
2019-12-24T12:40:57.427Z
@PieterWuille According to my observation, fast nodes often seemed to be "stuck", as long as slow peers were still not disconnected.
Chris Chen
CC BY-SA 4.0
2019-12-24T12:42:45.500Z
@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
CC BY-SA 4.0
2019-12-24T12:43:01.273Z
Additionally, after the first "header-sync" and the second "catching up" stage were complete, I think the full node could then go into the third "steady" stage, which would work in a way that's similar to the current situation (keep connections with randomly-selected nodes - which are also required to be distributed among several different CIDRs, if I recalled corrrectly).
Chris Chen
CC BY-SA 4.0
2019-12-24T12:45:33.183Z
That's already what is done. Only during IBD are peers kicked for being slow.
Pieter Wuille
CC BY-SA 4.0
2019-12-24T12:51:09.533Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/102540/discussion-between-chris-chen-and-pieter-wuille).
Chris Chen
CC BY-SA 4.0
2019-12-24T12:25:46.073Z
2022-05-12T19:20:21.183Z
2022-05-12T19:20:21.183Z
Matthew Cruz
<p>It's usually frustrating when my Bitcoin Core full node is syncing, especially just catching up from merely several hours/days ago.</p>

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

<p>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.</p>

<p>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.</p>

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

<bitcoin-core><peer-discovery><bandwidth>
How does Bitcoin Core manage its peer nodes? Is it possible to let it automatically switch to faster nodes?
Chris Chen
# How does Bitcoin Core manage its peer nodes? Is it possible to let it automatically switch to faster nodes?

(Asked by: username_0 on 2019-12-24)

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?

**Tags:** bitcoin-core, peer-discovery, bandwidth


---

## 1 answers

### Answer by username_1 on 2019-12-24. Score: 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](https://bitcoin.stackexchange.com/questions/3536/how-do-bitcoin-clients-find-each-other) 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](https://bitcoincore.org/en/doc/0.19.0/rpc/network/disconnectnode/) and [addnode](https://bitcoincore.org/en/doc/0.19.0/rpc/network/addnode/).

> **Comments:**
> **username_0**: 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.  
> **username_2**: This is incorrect. During IBD, sufficiently slow peers will get disconnected.  
> **username_0**: @username_2 According to my observation, fast nodes often seemed to be "stuck", as long as slow peers were still not disconnected.  
> **username_2**: @username_0 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).  
> **username_0**: Additionally, after the first "header-sync" and the second "catching up" stage were complete, I think the full node could then go into the third "steady" stage, which would work in a way that's similar to the current situation (keep connections with randomly-selected nodes - which are also required to be distributed among several different CIDRs, if I recalled corrrectly).  
> **username_2**: That's already what is done. Only during IBD are peers kicked for being slow.  
> **username_0**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/102540/discussion-between-username_0-username_0-and-username_2-username_2).  

---

