The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33752.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #34654 ([RFC] BlockMap and CChain Concurrency Improvement by alexanderwiederin)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Though, I wonder what the use case is. If someone knows a header, it seems likely they also know about the previous headers and a feature to support asking for them would have no users?

Though, I wonder what the use case is. If someone knows a header, it seems likely they also know about the previous headers and a feature to support asking for them would have no users?

Knowing a header only means that you know the previous block hash. If you want to request headers from best tip to genesis, There is no existing mechanism other than requesting headers one-at-a-time. This makes it possible to batch request headers from tip to genesis, which is much more efficient than requesting one-at-a-time.

Request the starting hash with GET /rest/blockhashbyheight/.<bin|hex|json> and then request headers upward with /rest/headers/?

We currently use this approach at L2L. This strategy is far from ideal - any of the upward requests may return headers from a different active chain, in the event of a re-org. It is necessary to check that the final block hash is the same as the tip hash we want to sync to, and if it is not, then the only way to retrieve the headers would be requesting headers via JSON-RPC, one at a time.

The reorg potential does make using the interface more cumbersome in general, I'm not sure your approach solves that? You're still limited by what's in the active_chain, so you still need logic to deal with what if the index you're requesting a negative count from isn't in the active chain anymore?

@stickies-v Updated to handle the case where the requested block header is no longer in the active chain.

I'm still a bit confused at what this is solving. Re-orgs are just a couple of blocks deep, so it shouldn't make a difference which direction you are querying from. Whether you need to handle reorgs around the tip after querying headers beginning from your current state, or beginning from the last known tip, you still need to reconcile reorgs either way, no?