Suhas Daftuar

It's worth pointing out that initial headers sync will be slowed down by this PR, not just because we will download headers twice before storing, but also because the additional...

> 4.2 suggests picking a maximum number of header chains to store, before pruning the shortest. It suggests storing 10 chains for a total of 480MB. @pinheadmz @sjors Absent other...

> Update 2022-08-06: why do we need bitdeque instead of just std::vector? Is it only because we call m_header_commitments.pop_front()? Couldn't we also just keep the commitments, track our index with...

Updated this PR to include the many improvements @sipa drafted in his branch (thank you!). Also included a fuzz test by @mzumsande, and addressed many of the review comments from...

> > related question: Is the sync state exposed anywhere via RPC? `getchaintips` showed nothing happening either. > > Seems like it might be good to at least report the...

Thanks @sipa, I have pushed your latest branch with the logging code here (and I squashed the lock-inversion fix into the commit where I had introduced the bug).

After seeing the discussion between @ajtowns and @sipa regarding bandwidth optimization involving what locators we send and how we process "skipping ahead" in our headers download (in the situation where...

Pushed two commits to address the following: - If a peer has a chain whose work is less than minchainwork, but is a subset of the main chain (m_best_header or...

Addressed review feedback and included some changes to further clean up the logic in `ProcessHeadersMessage()`. Also, I included a new test for large reorg handling.

Addressed latest review feedback from @sjors, unsquashed branch is [here](https://github.com/sdaftuar/bitcoin/commits/25717.6) for comparison.