Please review #24565 first, while this stays in draft.

Doesn't seem to save much code, and requires revalidating years worth of blocks to ensure it doesn't break consensus. Not really seeing the point of this? Concept -1 from me.

Doesn't seem to save much code

Apologies, the motivation isn't to save code. I've added some text to OP.

Unlike #23536 I don't think this has much (any?) possible effect on wallet behaviour; bip68 only allows time locks up to ~15 months, and bip68 was ~68 months ago (slightly more than "a few months of POW"...), and unlike with taproot/segwit/p2sh any transaction that is invalid right now due to bip68, will eventually become valid.

Also, any static analysis tool that can't cope with conditional consensus logic just doesn't seem suitable for use on the bitcoin codebase in the first place to me.

So still -1 from me; these sorts of unnecessary changes around consensus code seem far more likely to introduce bugs (as #24421 has) than prevent them.

If a BIP 68 violating tx makes it into the mempool in current master (or a previous release), getblocktemplate will refuse to create a block on the current main chain tip. This pull doesn't change that. It enforces BIP 68 rules on all blocks (past and future ones) and block templates. I think this is a motivation for the changes here, since a block template that includes a BIP 68 violation on current master will happily go through for blocks that will never end up in the main chain (built on a stale tip, see the unit test) and it will fail for blocks that are built on the current tip.

If you're relying on someone giving you a bip68-invalid tx to avoid building blocks with a tip that's over 5 years out of date, I think you've already lost...

So still -1 from me; these sorts of unnecessary changes around consensus code seem far more likely to introduce bugs (as #24421 has) than prevent them.

24421 doesn't change consensus code, so I don't think it's a relevant comparison here. The bug introduced in that PR was a functional test simulating an impossible scenario.

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #25311 (remove CBlockIndex copy construction by jamesob)
• #25073 (test: Cleanup miner_tests by MarcoFalke)
• #23897 (refactor: Move calculation logic out from CheckSequenceLocksAtTip() by hebasto)

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.

🐙 This pull request conflicts with the target branch and needs rebase.

_{Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".}

There hasn't been much activity lately and the patch still needs rebase. What is the status here?

• Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
• Is it no longer relevant? ➡️ Please close.
• Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

I'll pick this up later