diff options
author | MarcoFalke <falke.marco@gmail.com> | 2021-08-06 19:45:32 +0200 |
---|---|---|
committer | MarcoFalke <falke.marco@gmail.com> | 2021-08-06 19:46:04 +0200 |
commit | 4b523c8f0a7288e1be01ce114336aa2bba20b4c5 (patch) | |
tree | f4ba00a5e7b19d8014c671c8930c77c7c8c1a52e /src/rpc/request.h | |
parent | 068ac69b56d649d97dae2036d2e7f5d215888dea (diff) | |
parent | 2a5710805195ca54a02aff3540ceaefb9cb3b3e2 (diff) |
Merge bitcoin/bitcoin#22569: [0.21] Rate limit the processing of rumoured addresses
2a5710805195ca54a02aff3540ceaefb9cb3b3e2 Avoid Appveyor compilation failure (Pieter Wuille)
a653aacbd66a47edd6d14ddc62fec2d4038456b8 Add logging and addr rate limiting statistics (Pieter Wuille)
aaa4833fc9c3d44378e232002f4b9b447a2d18cb Functional tests for addr rate limiting (Pieter Wuille)
8df3e5bd84f2b2b60730034cbd71fe8f3276d434 Randomize the order of addr processing (Pieter Wuille)
83dfe6c65ef6c30ca01348ee5059c3d76e03d1d3 Rate limit the processing of incoming addr messages (Pieter Wuille)
Pull request description:
Backport of #22387.
The rate at which IP addresses are rumoured (through ADDR and ADDRV2 messages) on the network seems to vary from 0 for some non-participating nodes, to 0.005-0.025 addr/s for recent Bitcoin Core nodes. However, the current codebase will happily accept and process an effectively unbounded rate from attackers. There are measures to limit the influence attackers can have on the addrman database (bucket restrictions based on source IPs), but still - there is no need to permit them to feed us addresses at a rate that's orders of magnitude larger than what is common on the network today, especially as it will cause us to spam our peers too.
This PR implements a [token bucket](https://en.wikipedia.org/wiki/Token_bucket) based rate limiter, allowing an average of 0.1 addr/s per connection, with bursts up to 1000 addresses at once. Whitelisted peers as well as responses to GETADDR requests are exempt from the limit. New connections start with 1 token, so as to not interfere with the common practice of peers' self-announcement.
Due to the lack of the `Peer` struct in 0.21, the relevant fields have been added to `CNodeState` instead, necessitating additional locks, and slightly different structure to avoid too much `cs_main` grabbing. The last test-improving commit has also been dropped, as the code has changed too much. Most of the behavior is still tested however, just not the part that compares with RPC statistics.
ACKs for top commit:
achow101:
ACK 2a5710805195ca54a02aff3540ceaefb9cb3b3e2
GeneFerneau:
Approach + code review ACK [2a57108](https://github.com/bitcoin/bitcoin/pull/22569/commits/2a5710805195ca54a02aff3540ceaefb9cb3b3e2)
jnewbery:
reACK 2a5710805195ca54a02aff3540ceaefb9cb3b3e2
Tree-SHA512: ecf4891ac6173d732aa40b4d05fc0dce94127a613cb9051bf6188a2f95824f8234b17d386dd0b352ddf3d352202cc2ff07915ae35657d8e64907e3f80703d1d9
Diffstat (limited to 'src/rpc/request.h')
0 files changed, 0 insertions, 0 deletions