bip-0054: distinguish miner enforcement of the two timestamp restrictions

[douglaz]

Summary

The "Miner forward compatibility" section currently says:

Bitcoin Core version 29.0 and later will not generate a block template that violates the timestamp restrictions introduced in this BIP.

This BIP introduces two timestamp restrictions (Specification, given a block at height N):

• N % 2016 == 0: T_N ≥ T_N−1 − 7200
• N % 2016 == 2015: T_N ≥ T_N−2015

Bitcoin Core 29.0 only accounts for the first one. It gained that in bitcoin/bitcoin#31376 (miner: never create a template which exploits the timewarp bug), with getblocktemplate's mintime following in bitcoin/bitcoin#31600; both are first contained in v29.0. (28.0 already had the template-side adjustment, but gated on enforce_BIP94, so it applied to testnet4/regtest only — 29.0 is the first release where it is unconditional and mintime agrees with it.)

The second restriction was only added to the block template code in bitcoin/bitcoin#35949 (miner: Enforce Murch-Zawy rule (BIP54)), merged 2026-09-07 and so far contained only in v32.0rc1. I checked the 29.x, 30.x and 31.x stable tags for a backport; there is none.

Both rules live in the same GetMinimumTime() helper, which feeds the template header via UpdateTime() and getblocktemplate's mintime/curtime alike, so templates and the RPC fields gain each restriction at the same time.

So versions 29.x through 31.x do not satisfy the blanket wording, which this PR corrects.

Changes

• Split the sentence in two, one per restriction, matching the existing per-version style of the neighbouring paragraphs.
• Scope the "extremely unlikely" explanation to each restriction: the grace period only exists for the first-block rule, so it no longer reads as justifying both.
• Qualify the curtime/mintime advice. It previously promised blocks "valid according to this proposal", which is not true on 29.x–31.x at the last block of a period — exactly the gap the version split makes explicit.
• Add the [Core 32.0] link definition, and a 1.0.1 changelog entry with the matching Version header.

No normative change; this only makes the implementation timeline and the miner guidance accurate.

Open questions for the author/editors

1. The 32.0 link. 32.0 is not released yet (v32.0rc1), so https://bitcoincore.org/en/releases/32.0 404s until it ships. I used the release-page URL for consistency with the [Core 0.16.1], [Core 29.0] and [Core 30.0] definitions — [Core 30.0] was likewise added after 30.0 shipped. Happy to point it at miner: Enforce Murch-Zawy rule (BIP54) bitcoin#35949 instead (there is in-file precedent in [Core BIP 54 implem]), or to hold this until 32.0 is out. Your call.
2. Changelog. BIP3 requires post-Complete changes to be tracked, and gives a PATCH bump for "important clarifications", so I added 1.0.1 and the Version header that BIP3 also requires once a changelog exists. The three previous post-Complete edits to this file did not bump it, so if you consider this too minor to record, I will drop that part.
3. Pre-existing, not addressed here. The last sentence of the paragraph says a timestamp below mintime "already leads to creating an invalid block". That is not categorically true: Core's template floor uses MAX_TIMEWARP = 600 while this BIP permits TN−1 − 7200, so a timestamp in between is below mintime yet valid. Left alone as out of scope — let me know if you want it corrected in the same PR.

[jonatack]

ACK modulo open questions by the PR author for BIP author feedback cc @darosior. Thank you for adding the Version header. Note that this PR presumes that recently merged bitcoin/bitcoin#35949 is not backported.

[douglaz]

Thanks for the review.

Right, the wording presumes bitcoin/bitcoin#35949 is not backported. Nothing appears to be in flight: it was merged to master under the 32.0 milestone with the Mining label rather than a backport label, and the only open backport PR is bitcoin/bitcoin#36267 ([32.x] Backports for rc2), which moves it toward the 32.0 release rather than back into an earlier branch. git tag --contains e014e5bb61 lists only v32.0rc1, and I checked the 29.x, 30.x and 31.x stable tags directly — none of them have the last-block branch in GetMinimumTime(). If it does get backported after all, I am happy to amend the version accordingly.

The two open questions for @darosior are the [Core 32.0] link (the release page 404s until 32.0 ships, versus pointing it at bitcoin/bitcoin#35949 as [Core BIP 54 implem] does) and whether the pre-existing mintime sentence should be corrected here or left for a separate PR.