diff options
| author | fanquake <fanquake@gmail.com> | 2022-06-27 14:17:01 +0100 |
|---|---|---|
| committer | fanquake <fanquake@gmail.com> | 2022-06-27 14:21:49 +0100 |
| commit | 2fe27029f5426592d0edddf40b36af54709ddb80 (patch) | |
| tree | 1d304a28dc7f3a1c0128530dc7f76ff51a29bc77 /src/pubkey.h | |
| parent | c8261026a4baf5b189ff555f4d53d4d426ec6441 (diff) | |
| parent | e357c8953880715a943b892deed04e7777187999 (diff) | |
| download | bitcoin-2fe27029f5426592d0edddf40b36af54709ddb80.tar.xz | |
Merge bitcoin/bitcoin#25404: p2p, doc: Use MAX_BLOCKS_TO_ANNOUNCE consistently
e357c8953880715a943b892deed04e7777187999 p2p, doc: Use MAX_BLOCKS_TO_ANNOUNCE consistently (Martin Zumsande)
Pull request description:
Block announcements via headers may have up to `MAX_BLOCKS_TO_ANNOUNCE = 8` entries according to the definition of this constant.
However, there are a few spots saying they should have a size _less than_ `MAX_BLOCKS_TO_ANNOUNCE`. Fix these.
I don't think that this is critical (this only changes behavior when we get a headers announcement with exactly `MAX_BLOCKS_TO_ANNOUNCE` blocks which we can't connect), but it would be nice to handle this limit consistently.
ACKs for top commit:
dergoegge:
utACK e357c8953880715a943b892deed04e7777187999 - This PR makes the usage and docs of `MAX_BLOCKS_TO_ANNOUNCE` consistent with its description.
Tree-SHA512: f3772026ab0f402e3a551127ef6e4a98fa9e7af250715fe317c05988b5b33f2f3e098a00e03960d4d28c8bd2b7a97231f7f99f22f1c152c000b2e27b658cf8f2
Diffstat (limited to 'src/pubkey.h')
0 files changed, 0 insertions, 0 deletions