Bitcoin full node and query server

Sep 18, 2026

View in context in the libbitcoin Slack #general mirror.

evoskuil21:00
In reviewing the bitcoind endpoints I found that Core has a "feature" that allows the node to be configured to stop providing blocks once the byte upload has exceeded a threshold in a 24hr period. It drops peers that make block requests after this limit is reached. The node keeps advertising NODE_NETWORK, which makes this a bug. We implement DoS protection via a continuously imposed rate limit on outbound traffic. We throttle the next request reader based on the previous response size, so as to not exceed the outbound rate (except instantaneously). Since we also manage peer count, the combination allows the admin to set an overall rate limit. This prevents one channel from eating the bandwidth limit for all others.
4 replies · neillm, evoskuil · last Sep 18, 2026
evoskuil21:08
These are the other fields that they have to put out so that callers can manage this "feature".
image.png
evoskuil21:09
IOW, they are really trying to implement rate limit, but just don't seem to know how. The difference in behavior is that you can pull down a lot fast on one channel, and then nobody gets anything for the reset of the day - as opposed to every channel getting a maximum continuous rate. But it's not clear to me why you want rando internet peers to choke each other out and to provide a sawtooth pattern of service unreliability.
(edited)
evoskuil21:13
  • correction, not "callers" managing, it's the admin of the node that sees the client-server report on the status of the feature.
(edited)