BIP85: fix datetime string typo to align with UNIX Epoch time #1967
Conversation
Geneis block time is correct in Unix time, but human readable version is off by 10 minutes. (Single digit typo)
jonatack
added
Pending acceptance
|
ACK |
|
@jonatack anything blocking this merge? |
Co-authored-by: Jon Atack <[email protected]>
Co-authored-by: Jon Atack <[email protected]>
Co-authored-by: Jon Atack <[email protected]>
|
I just committed the suggested tweaks |
| 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>). |
There was a problem hiding this comment.
We should bump to a new major version for possible backwards incompatibility.
| 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>). |
|
ACK modulo the feedback. Feel free to squash the commits. |
jonatack
changed the title
| ==Changelog== | ||
|
|
||
| ===1.3.1 (2025-09-19)=== |
There was a problem hiding this comment.
| ===1.3.1 (2025-09-19)=== | |
| ===2.0.0 (2025-09-19)=== |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Perhaps just bump to 1.4, the jump to 2.0 makes complete sense with the other PR relating to ECC keys options.
There was a problem hiding this comment.
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.
Co-authored-by: Jon Atack <[email protected]>
Genesis block time is correct in Unix time, but human readable version is off by 10 minutes. (Single digit typo)
Basically this changes the fingerprint, so should be consistent so as to ensure compatibility between BIP85-GPG implementations.
(I am comparing my SeedSigner to Krux GPGap in this instance, the latter of which has gone with the human-readable time from the BIP whereas I went with Unix time and couldn't work out why the same input produced different results...)