[P2P] Rate limiting rumored address processing #2824
Conversation
Liquid369
force-pushed
the
2023_rate_limit_getaddr
branch
2 times, most recently
from
98bf8ce to
fb8f511
Compare
Fuzzbawls
changed the title
Liquid369
force-pushed
the
2023_rate_limit_getaddr
branch
2 times, most recently
from
fea7667 to
a6d69d8
Compare
Liquid369
force-pushed
the
2023_rate_limit_getaddr
branch
from
a6d69d8 to
3c6280b
Compare
Liquid369
force-pushed
the
2023_rate_limit_getaddr
branch
from
3c6280b to
0c2deb2
Compare
Fuzzbawls
left a comment
Fuzzbawls
left a comment
There was a problem hiding this comment.
Functional ACK, one minor clang-tidy cleanup.
Liquid369
force-pushed
the
2023_rate_limit_getaddr
branch
from
0c2deb2 to
01e2e26
Compare
Fuzzbawls
left a comment
Fuzzbawls
left a comment
There was a problem hiding this comment.
ACK 01e2e26f905850a878e438c124b7a00cb6011ed2
Liquid369
force-pushed
the
2023_rate_limit_getaddr
branch
4 times, most recently
from
611cd77 to
3717978
Compare
panleone
left a comment
panleone
left a comment
There was a problem hiding this comment.
another comment on the latest commit
test/functional/p2p_addrv2_relay.py
Outdated
There was a problem hiding this comment.
Wrote yesterday on discord, but rewriting here so we don't forget:
Imo the assert here should not be changed because we are functional testing a specific expected behaviour. If this change is due to the fact that m_addr_token_bucket is empty then it is better if you change the node time to refill it, if it's not that then the PR introduced a bug
test/functional/p2p_addr_relay.py
Outdated
There was a problem hiding this comment.
same comment here, an assert that tested an expected result has been changed. If this was due to the fact that the bucket is empty then ok change the node's time to refill it and the unchanged assert should pass. If it does not a bug was introduced
There was a problem hiding this comment.
In this regard, I have restored the old logs but have changed the addr_token_bucket from 1.0 to 10.0 to reflect the logging more accurately rather than accounting for a stricter rate limit.
Take a look let me know, ima try to get this last test working...again
Set for every instance and fix test peer, remove var Refactor debug logs Adjust p2p invalid msgs
Liquid369
force-pushed
the
2023_rate_limit_getaddr
branch
from
0e7eb41 to
c5fd91e
Compare
3 participants
As of recent there was a release on https://www.halborn.com/blog/post/halborn-discovers-zero-day-impacting-dogecoin-and-280-networks
We want to address potential situation that can cause network instability and node attacks.
This PR back ports
bitcoin#22387
bitcoin#15617
This implements a token bucket for rate limiting addresses, allowing up to 1000 in one request. Getaddr requests are exempt from this rate limiting. Then we are also no longer going to relay to other nodes peers we have banned. Functional tests included.