diff options
| author | fanquake <fanquake@gmail.com> | 2021-06-16 11:26:53 +0800 |
|---|---|---|
| committer | fanquake <fanquake@gmail.com> | 2021-06-16 11:27:16 +0800 |
| commit | 6bc1eca01b2f88e081e71b783b3d45287700f8a5 (patch) | |
| tree | ec52af5c8c3d19ae6978f6285e400d44d19ad4c0 /src/key_io.cpp | |
| parent | eb63b1db2c4d2877a10fce391cf2c0c60b6210f3 (diff) | |
| parent | 79c02c88b347f1408a2db307db2654917f9b0bcc (diff) | |
Merge bitcoin/bitcoin#22144: Randomize message processing peer order
79c02c88b347f1408a2db307db2654917f9b0bcc Randomize message processing peer order (Pieter Wuille)
Pull request description:
Right now, the message handling loop iterates the list of nodes always in the same order: the order they were connected in (see the `vNodes` vector). For some parts of the net processing logic, this order matters. Transaction requests are assigned explicitly to peers since #19988, but many other parts of processing work on a "first-served-by-loop-first" basis, such as block downloading. If peers can predict this ordering, it may be exploited to cause delays.
As there isn't anything particularly optimal about the current ordering, just make it unpredictable by randomizing.
Reported by Crypt-iQ.
ACKs for top commit:
jnewbery:
ACK 79c02c88b3
Crypt-iQ:
ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
sdaftuar:
utACK 79c02c88b347f1408a2db307db2654917f9b0bcc
achow101:
Code Review ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
jamesob:
crACK https://github.com/bitcoin/bitcoin/pull/22144/commits/79c02c88b347f1408a2db307db2654917f9b0bcc
jonatack:
ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
vasild:
ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
theStack:
ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
Tree-SHA512: 9a87c4dcad47c2d61b76c4f37f59674876b78f33f45943089bf159902a23e12de7a5feae1a73b17cbc3f2e37c980ecf0f7fd86af9e6fa3a68099537a3c82c106
Diffstat (limited to 'src/key_io.cpp')
0 files changed, 0 insertions, 0 deletions