aboutsummaryrefslogtreecommitdiff
path: root/test/functional/feature_signet.py
diff options
context:
space:
mode:
authorPieter Wuille <pieter@wuille.net>2021-08-05 09:15:44 -0700
committerPieter Wuille <pieter@wuille.net>2021-08-05 09:40:00 -0700
commit83dfe6c65ef6c30ca01348ee5059c3d76e03d1d3 (patch)
treeb0e1cf4aa790609354fc6cfd0ae541b324016164 /test/functional/feature_signet.py
parent068ac69b56d649d97dae2036d2e7f5d215888dea (diff)
Rate limit the processing of incoming addr messages
While limitations on the influence of attackers on addrman already exist (affected buckets are restricted to a subset based on incoming IP / network group), there is no reason to permit them to let them feed us addresses at more than a multiple of the normal network rate. This commit introduces a "token bucket" rate limiter for the processing of addresses in incoming ADDR and ADDRV2 messages. Every connection gets an associated token bucket. Processing an address in an ADDR or ADDRV2 message from non-whitelisted peers consumes a token from the bucket. If the bucket is empty, the address is ignored (it is not forwarded or processed). The token counter increases at a rate of 0.1 tokens per second, and will accrue up to a maximum of 1000 tokens (the maximum we accept in a single ADDR or ADDRV2). When a GETADDR is sent to a peer, it immediately gets 1000 additional tokens, as we actively desire many addresses from such peers (this may temporarily cause the token count to exceed 1000). The rate limit of 0.1 addr/s was chosen based on observation of honest nodes on the network. Activity in general from most nodes is either 0, or up to a maximum around 0.025 addr/s for recent Bitcoin Core nodes. A few (self-identified, through subver) crawler nodes occasionally exceed 0.1 addr/s. Github-Pull: #22387 Rebased-From: 0d64b8f709b4655d8702f810d4876cd8d96ded82
Diffstat (limited to 'test/functional/feature_signet.py')
0 files changed, 0 insertions, 0 deletions