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

3rdIteration commented at 2:51 pm on September 15, 2025: none

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…)

Fix BIP85 Timestamp Typo

Geneis block time is correct in Unix time, but human readable version is off by 10 minutes. (Single digit typo)

ee69fc60ee

in bip-0085.mediawiki:385 in ee69fc60ee outdated

381@@ -382,7 +382,7 @@ Keys allocated for RSA-GPG purposes use the following scheme:
382 
383 Note on timestamps:
384 
385-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>).
386+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) 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>).

jonatack commented at 4:07 pm on September 17, 2025:

0The 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) 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>).

akarve commented at 5:04 pm on September 17, 2025:

Since the creation time is set in GPG (right?) this does not affect the BIP-85 output per se. Nevertheless if someone generated a GPG key according to spec this would make any previously generated keys irreproducible. Moreover, the date is given at MUST. Therefore I recommend we not touch the date and instead add footnote on the discrepancy if desired.

3rdIteration commented at 5:14 pm on September 17, 2025:

The BIP85 output is unchanged by this, but the fingerprint generated by GPG changes if the created timestamp is changed. (Even if the primary key itself is identical) The problem is that the spec is ambiguous, not that it should change.

jonatack commented at 5:31 pm on September 17, 2025:

The problem is that the spec is ambiguous

Agree, the spec needs to be clear.

akarve commented at 6:24 pm on September 17, 2025:

Sorry, I missed the inconsistency and it should indeed be resolved. I request both a footnote containing the old human readable ts and a changelog entry for this correction. That way if someone used the incorrect timestamp they can at least get the same fingerprint.

Does the GPG API have a preferred or default timestamp format? If yes and it’s epoch time then this change is less risky.

3rdIteration commented at 6:49 pm on September 17, 2025:

Not sure about API, but GPG packets include a timestamp in Unix time and while the command line tools will normally display a human readable time in your local timezone, if you ask it for the raw key data, you get Unix time.

jonatack commented at 2:34 pm on September 19, 2025:

I request both a footnote containing the old human readable ts and a changelog entry for this correction. That way if someone used the incorrect timestamp they can at least get the same fingerprint. @3rdIteration do you want to update for this feedback?

3rdIteration commented at 3:06 pm on September 19, 2025:

Just added something in https://github.com/bitcoin/bips/pull/1967/commits/188778059d9fa583db615f9fea51e24da6f1acdd

jonatack commented at 4:14 pm on September 17, 2025: member

ACK

Pinging @akarve and @scgbckbone for feedback.

jonatack added the label Pending acceptance on Sep 17, 2025

jonatack added the label Bug fix on Sep 17, 2025

Update bip-0085.mediawiki 188778059d

in bip-0085.mediawiki:450 in 188778059d

442@@ -443,6 +443,12 @@ BIP32, BIP39
443 
444 ==Changelog==
445 
446+===1.3.1 (2025-09-19)===
447+
448+====Corrected==== 
449+
450+*Typo in human-readable timestamp for BIP85 GPG Keys

jonatack commented at 7:53 pm on September 19, 2025:

0* Typo in human-readable datetime for BIP85 GPG Keys that was incorrectly noted as '2009-01-03 18:05:05' rather than '2009-01-03 18:15:05', so implementations that relied on it instead of UNIX Epoch timestamp 1231006505 will produce different key fingerprints.

scgbckbone commented at 0:58 am on September 27, 2025:

nit: would use “datetime string” here too

in bip-0085.mediawiki:448 in 188778059d outdated

442@@ -443,6 +443,12 @@ BIP32, BIP39
443 
444 ==Changelog==
445 
446+===1.3.1 (2025-09-19)===
447+
448+====Corrected====

jonatack commented at 7:53 pm on September 19, 2025:

The usual title for changelog fixes

0====Fixed====

in bip-0085.mediawiki:385 in 188778059d outdated

381@@ -382,7 +382,7 @@ Keys allocated for RSA-GPG purposes use the following scheme:
382 
383 Note on timestamps:
384 
385-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) 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>).
386+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 timestamp was incorrectly noted as '2009-01-03 18:05:05' prior to v1.3.1 of this BIP, so implementations that relied on this 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>).

jonatack commented at 7:59 pm on September 19, 2025:

0The 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>).

jonatack commented at 8:02 pm on September 19, 2025: member

Thanks for updating. Feedback below.

scgbckbone commented at 0:59 am on September 27, 2025: contributor

ACK

akarve commented at 1:54 am on October 6, 2025: contributor

@jonatack anything blocking this merge?

Update bip-0085.mediawiki

Co-authored-by: Jon Atack <jon@atack.com>

3dab73a3c1

Update bip-0085.mediawiki

Co-authored-by: Jon Atack <jon@atack.com>

53a0084a00

Update bip-0085.mediawiki

Co-authored-by: Jon Atack <jon@atack.com>

71e0d819b1

3rdIteration commented at 6:27 pm on October 6, 2025: none

I just committed the suggested tweaks

in bip-0085.mediawiki:385 in 71e0d819b1 outdated

381@@ -382,7 +382,7 @@ Keys allocated for RSA-GPG purposes use the following scheme:
382 
383 Note on timestamps:
384 
385-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>).
386+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>).

jonatack commented at 11:45 pm on October 6, 2025:

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

0The 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>).

jonatack commented at 11:46 pm on October 6, 2025: member

ACK modulo the feedback. Feel free to squash the commits.

jonatack renamed this:
~~Fix BIP85 Timestamp Typo~~
BIP85: fix datetime string typo to align with UNIX Epoch time
on Oct 6, 2025

in bip-0085.mediawiki:450 in 71e0d819b1

442@@ -443,6 +443,12 @@ BIP32, BIP39
443 
444 ==Changelog==
445 
446+===1.3.1 (2025-09-19)===
447+
448+====Fixed==== 
449+
450+* Typo in human-readable datetime for BIP85 GPG Keys that was incorrectly noted as '2009-01-03 18:05:05' rather than '2009-01-03 18:15:05', so implementations that relied on it instead of UNIX Epoch timestamp 1231006505 will produce different key fingerprints.

jonatack commented at 11:56 pm on October 6, 2025:

0* 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.

Update bip-0085.mediawiki

Co-authored-by: Jon Atack <jon@atack.com>

3fa9d10f56

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