diff options
| author | Wladimir J. van der Laan <laanwj@gmail.com> | 2017-11-09 19:55:02 +0100 |
|---|---|---|
| committer | Wladimir J. van der Laan <laanwj@gmail.com> | 2017-11-09 19:57:47 +0100 |
| commit | 1f4375f8e75f95522ad763d06da047b1b3893530 (patch) | |
| tree | ab906c533d23f7f8ac301d718b283842feab9010 /src/support | |
| parent | 5e3f5e4f25b65b583d3bfefac9e1148035781089 (diff) | |
| parent | 725b79a9cf9d6af3a9a7a31407f2795fe640f3c6 (diff) | |
| download | bitcoin-1f4375f8e75f95522ad763d06da047b1b3893530.tar.xz | |
Merge #11580: Do not send (potentially) invalid headers in response to getheaders
725b79a [test] Verify node doesn't send headers that haven't been fully validated (Russell Yanofsky)
3788a84 Do not send (potentially) invalid headers in response to getheaders (Matt Corallo)
Pull request description:
Nowhere else in the protocol do we send headers which are for
blocks we have not fully validated except in response to getheaders
messages with a null locator. On my public node I have not seen any
such request (whether for an invalid block or not) in at least two
years of debug.log output, indicating that this should have minimal
impact.
Tree-SHA512: c1f6e0cdcdfb78ea577d555f9b3ceb1b4b60eff4f6cf313bfd8b576c9562d797bea73abc23f7011f249ae36dd539c715f3d20487ac03ace60e84e1b77c0c1e1a
Diffstat (limited to 'src/support')
0 files changed, 0 insertions, 0 deletions