diff options
author | MacroFake <falke.marco@gmail.com> | 2022-05-31 12:05:38 +0200 |
---|---|---|
committer | MacroFake <falke.marco@gmail.com> | 2022-05-31 12:05:46 +0200 |
commit | 5f65afff9c4c735d607a69fc3d18b4ecadbf3ba9 (patch) | |
tree | 6346684496c004f5623596087c5efe8d8096da3c /src/policy/feerate.cpp | |
parent | bd6c5e410829764ea0a3c4251e42f86242e043a2 (diff) | |
parent | a35f963edf1a14ee572abea106fb0147575e4694 (diff) | |
download | bitcoin-5f65afff9c4c735d607a69fc3d18b4ecadbf3ba9.tar.xz |
Merge bitcoin/bitcoin#24178: p2p: Respond to getheaders if we have sufficient chainwork
a35f963edf1a14ee572abea106fb0147575e4694 Add test for getheaders behavior (Suhas Daftuar)
ef6dbe6863d92710fd2da7781e5b2aac87578751 Respond to getheaders if we have sufficient chainwork (Suhas Daftuar)
Pull request description:
Previously, we would check to see if we were in IBD and ignore getheaders requests accordingly. However, the IBD criteria -- an optimization mostly targeted at behavior when we have peers serving us many blocks we need to download -- is difficult to reason about in edge-case scenarios, such as if the network were to go a long time without any blocks found and nodes are getting restarted during that time.
To make things simpler to reason about, just use `nMinimumChainWork` as our anti-DoS threshold for responding to a getheaders request; as long as our chain has that much work, it should be fine to respond to a peer asking for our headers (and this should allow such a peer to request blocks from us if needed).
ACKs for top commit:
klementtan:
crACK a35f963edf1a14ee572abea106fb0147575e4694
naumenkogs:
ACK a35f963edf1a14ee572abea106fb0147575e4694
MarcoFalke:
review ACK a35f963edf1a14ee572abea106fb0147575e4694 🗯
Tree-SHA512: 131e3872e7fe80382ea9c1ec202d6c2dc59c006355c69000aa3f4ce6bccd02a6c689c8cb8f3542b5d9bc48bfa61edcbd1a78535c0b79018971d02bed2655d284
Diffstat (limited to 'src/policy/feerate.cpp')
0 files changed, 0 insertions, 0 deletions