Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
douglaz wants to merge 1 commit into from
Closed

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 15 additions & 5 deletions bip-0054.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
Type: Specification
Assigned: 2025-04-11
License: CC0-1.0
Version: 1.0.1
```

## Abstract
Expand Down Expand Up @@ -136,11 +137,16 @@ strongly encourage node operators to upgrade in order to fully validate all cons
## Miner forward compatibility

Bitcoin Core version [29.0][Core 29.0] and later will not generate a block template that violates
the timestamp restrictions introduced in this BIP. Although it would be extremely unlikely due to
the grace period used in this proposal, miners should use the `curtime` or `mintime` field from the
`getblocktemplate` result for their block's timestamp to make sure they always create blocks valid
according to this proposal. Note this is not a new requirement: using a timestamp lower than the
`mintime` field from the `getblocktemplate` result already leads to creating an invalid block.
the restriction on the timestamp of the first block of a difficulty adjustment period introduced in
this BIP. Bitcoin Core version [32.0][Core 32.0] and later will also not generate a block template
that violates the restriction on the timestamp of the last block of a difficulty adjustment period
introduced in this BIP. Although it would be extremely unlikely (for the first restriction due to
the grace period used in this proposal, and for the second because the duration of a difficulty
adjustment period should never be negative), miners should use the `curtime` or `mintime` field
from the `getblocktemplate` result of a version which accounts for both restrictions for their
block's timestamp to make sure they always create blocks valid according to this proposal.
Note this is not a new requirement: using a timestamp lower than the `mintime` field from the
`getblocktemplate` result already leads to creating an invalid block.

Bitcoin Core version [30.0][Core 30.0] and later will not generate a block template including a
transaction that violates the signature operations limit introduced in this BIP.
Expand Down Expand Up @@ -178,6 +184,9 @@ This document is licensed under the Creative Commons CC0 1.0 Universal license.

## Changelog

* __1.0.1__ (2026-09-18):
* Clarify which Bitcoin Core versions account for each of the two timestamp restrictions when
generating a block template.
* __1.0.0__ (2026-05-22):
* Complete planned work on the BIP.

Expand Down Expand Up @@ -262,6 +271,7 @@ MERKLEBLOCK] for a full description.
[Core 29.0]: https://bitcoincore.org/en/releases/29.0
[Core BIP 54 implem]: https://github.com/bitcoin/bitcoin/pull/35793
[Core 30.0]: https://bitcoincore.org/en/releases/30.0
[Core 32.0]: https://bitcoincore.org/en/releases/32.0
[Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459
[miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk
[ML remaining concerns]: https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/
Expand Down
Loading