little memory when we disconnect the node.
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Co-authored-by: Jack Grigg <str4d@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
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.
(cherry-picked from commit bitcoin/bitcoin@0d64b8f709)
I thought we had removed this a long time ago, TBH, its really
confusing feedback to users that we display whether a tx was
broadcast to immediate neighbor nodes, given that has little
indication of whether the tx propagated very far.
We add a `set +e` around the `sha256sum` invocation, otherwise the shell
errors out instantly (because of the `set -e` at the top), so we have
the chance to print out the custom error message. We `set -e` as soon as
we grab the return value from `sha256sum`.
- We update Windows cross-compile builds to 15.0.7 because binaries are
provided for it, but not currently for any other platform we need.
- We update native x84_64 macOS builds to 15.0.4 because no 15.0.6
binaries are provided, and the 15.0.7 ones appear to be targeted at a
newer Darwin version.
- We keep FreeBSD on 14.0.6 because no Clang 15 binaries are provided,
and as FreeBSD is a Tier 3 platform it doesn't block us from upgrading
the remaining platforms.
Kris Nuttycombe
Daira Hopwood
str4d
Jon Atack
Pieter Wuille
Greg Pfeil
cronicc
Matt Corallo
Jack Grigg
sasha
sasha
Yasser Isa