Skip to content

BIP85: fix datetime string typo to align with UNIX Epoch time #1967

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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

BIP85: fix datetime string typo to align with UNIX Epoch time #1967

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
ee69fc6
Fix BIP85 Timestamp Typo
3rdIteration Sep 15, 2025
1887780
Update bip-0085.mediawiki
3rdIteration Sep 19, 2025
3dab73a
Update bip-0085.mediawiki
3rdIteration Oct 6, 2025
53a0084
Update bip-0085.mediawiki
3rdIteration Oct 6, 2025
71e0d81
Update bip-0085.mediawiki
3rdIteration Oct 6, 2025
3fa9d10
Update bip-0085.mediawiki
3rdIteration Oct 7, 2025
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
8 changes: 7 additions & 1 deletion bip-0085.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -382,7 +382,7 @@ Keys allocated for RSA-GPG purposes use the following scheme:

Note on timestamps:

The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to unix Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:05:05'</code> UTC) because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>).
The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to UNIX Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:15:05'</code> UTC)<ref>The human-readable datetime string was incorrectly noted as '2009-01-03 18:05:05' prior to v1.3.1 of this BIP, so implementations that relied on it rather than UNIX Epoch timestamp 1231006505 will produce different key fingerprints.</ref> because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>).
Copy link
Member

@jonatack jonatack Oct 6, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should bump to a new major version for possible backwards incompatibility.

Suggested change
The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to UNIX Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:15:05'</code> UTC)<ref>The human-readable datetime string was incorrectly noted as '2009-01-03 18:05:05' prior to v1.3.1 of this BIP, so implementations that relied on it rather than UNIX Epoch timestamp 1231006505 will produce different key fingerprints.</ref> because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>).
The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to UNIX Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:15:05'</code> UTC)<ref>The human-readable datetime string was incorrectly noted as '2009-01-03 18:05:05' prior to v2.0.0 of this BIP, so implementations that relied on it rather than UNIX Epoch timestamp 1231006505 will produce different key fingerprints.</ref> because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>).


Note on GPG key capabilities on smartcard/hardware devices:

Expand Down Expand Up @@ -443,6 +443,12 @@ BIP32, BIP39

==Changelog==

===1.3.1 (2025-09-19)===
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
===1.3.1 (2025-09-19)===
===2.0.0 (2025-09-19)===

Copy link
Contributor

@akarve akarve Oct 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jonatack is a major version change too drastic? only the human readable time was wrong; the epoch remains correct and we've added a note on how to reproduce the old fingerprint. since the implementation is not changing and since we are fixing what is mostly a spec bug i would recommend a minor or patch revision. otherwise we might spook and confuse implementers and vendors.

Copy link
Member

@jonatack jonatack Oct 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understand but still seems appropriate: https://stackoverflow.com/questions/71813328/is-a-small-breaking-change-enough-to-do-a-major-version-upgrade-while-using-semvchange

Per https://semver.org/, "Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API"

Seems safer to signal a major version, unless someone feels strongly that it's incorrect/not public API.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps just bump to 1.4, the jump to 2.0 makes complete sense with the other PR relating to ECC keys options.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it’s not that complicated.

This looks like a breaking change to me, and if that’s so, it should be a bump of the MAJOR version.
Adding more key options sounds like a backward-compatible extension and could be a bump of MINOR.

So, I would propose that we either:

a) Merge #1968 first with a bump of MINOR, and then merge #1968 with a bump of MAJOR, which makes us end up at version 2.0.0.
b) Merge both around the same time, put both changes as being introduced by version 2.0.0 in the Changelog.
c) If people feel that both are MAJOR changes, alternatively bump to 3.0.0. It’s not like version numbers cost us anything.


====Fixed====

* Fixed the human-readable datetime string for BIP85 GPG Keys that was incorrectly stated as '2009-01-03 18:05:05' rather than '2009-01-03 18:15:05'. Implementations that relied on the previously incorrect datetime string instead of UNIX Epoch timestamp 1231006505 will produce different key fingerprints.

===1.3.0 (2024-10-22)===

====Added====
Expand Down