Timeline for How does Bitcoin Core manage its peer nodes? Is it possible to let it automatically switch to faster nodes?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 12, 2022 at 19:20 | history | edited | Murch♦ | CC BY-SA 4.0 |
Edits are obvious from edit history
|
| Dec 24, 2019 at 12:54 | history | edited | Matthew Cruz | CC BY-SA 4.0 |
Removing incorrect information about p2p nodes
|
| Dec 24, 2019 at 12:51 | comment | added | Chris Chen | Let us continue this discussion in chat. | |
| Dec 24, 2019 at 12:45 | comment | added | Pieter Wuille | That's already what is done. Only during IBD are peers kicked for being slow. | |
| Dec 24, 2019 at 12:43 | comment | added | Chris Chen | 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). | |
| Dec 24, 2019 at 12:42 | comment | added | Pieter Wuille | @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). | |
| Dec 24, 2019 at 12:40 | comment | added | Chris Chen | @PieterWuille According to my observation, fast nodes often seemed to be "stuck", as long as slow peers were still not disconnected. | |
| Dec 24, 2019 at 12:37 | comment | added | Pieter Wuille | This is incorrect. During IBD, sufficiently slow peers will get disconnected. | |
| Dec 24, 2019 at 12:34 | comment | added | Chris Chen | 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. | |
| Dec 24, 2019 at 12:25 | history | answered | Matthew Cruz | CC BY-SA 4.0 |