aboutsummaryrefslogtreecommitdiff
path: root/contrib/verify-commits
diff options
context:
space:
mode:
authorMacroFake <falke.marco@gmail.com>2022-05-31 12:05:38 +0200
committerMacroFake <falke.marco@gmail.com>2022-05-31 12:05:46 +0200
commit5f65afff9c4c735d607a69fc3d18b4ecadbf3ba9 (patch)
tree6346684496c004f5623596087c5efe8d8096da3c /contrib/verify-commits
parentbd6c5e410829764ea0a3c4251e42f86242e043a2 (diff)
parenta35f963edf1a14ee572abea106fb0147575e4694 (diff)
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 'contrib/verify-commits')
0 files changed, 0 insertions, 0 deletions