Hennadii Stepanov

@jamesob Will try to describe a problem better. The `blocks/blk00877.dat` file is somehow broken on _my_ disk. The master branch: - encounter an error in `blkdat >> block` - reports...

May I suggest a patch: ```diff --- a/src/validation.cpp +++ b/src/validation.cpp @@ -4719,6 +4719,7 @@ void LoadExternalBlockFile(const CChainParams& chainparams, FILE* fileIn, FlatFi blkdat.Skip(nBlockPos + nSize - blkdat.GetPos()); const uint256 hash =...

I think the benchmarks for this PR should additionally provide "Out of order block..." log message count. The lower this count is the lower `-reindex` speedup should be expected.

@LarryRuane You described the scenario when a _block is corrupted_ within a block file. In my situation (don't know how it was happened though) a block file has random/broken bytes...

> > a block file has random/broken bytes but _all block are correct_ within it. > > Can you explain more? Where exactly is the corruption? [blk00877.dat.error](https://drive.google.com/file/d/1WSfWcHcmdA5NhgBI8HkvrLG11dH0bcgy/view?usp=sharing)

@LarryRuane 1. `FindByte()` speed up is great, but combining two different speed optimizing solutions in a single PR is not a good idea. I'd suggest to separate the `FindByte()` patch...

@LarryRuane Thanks! Two last commits with the same messages are confusing. Did you mean that they should be a single commit (that seems reasonable)?

Was writing a review on e5724b5fde855b67ff500e21f11274f12b5c893a and noticed a fresh push. What is its goal?

The latest commit 969366d07c8cfdf8ea56cdb2ae11f5c648152345 looks good, but it adds _another_ behavior change into this PR. I think it deserves its own PR to get the measurable effects from each improvement.

Wrt a failed Win64 cross-compiled [build](https://cirrus-ci.com/task/6688875159486464). I've managed to successfully link `libbitcoinconsensus.la` with the following patch: ```diff --- a/src/Makefile.am +++ b/src/Makefile.am @@ -507,8 +507,6 @@ libbitcoin_consensus_a_SOURCES = \ primitives/transaction.h \...