diff options
| author | bitflash-maintainer <noreply@bitflash.invalid> | 2026-09-02 14:33:56 +0000 |
|---|---|---|
| committer | bitflash-maintainer <noreply@bitflash.invalid> | 2026-09-02 14:33:56 +0000 |
| commit | 0b7363211f954698e593699f32ed13b425fce2bc (patch) | |
| tree | d6571a09b702f98aeee84471aca9b9b310026b0c /src/test_relayproc.cpp | |
| parent | 03a69ccfb36861948e11b0871bb9af8f0b280709 (diff) | |
genesis: say that the 2025 nTime is known and must not be "fixed"
nTime is 1753315200, which is 2025-07-24T00:00:00Z. The comment beside it
claimed 2026-07-24, and the headline in pszTimestamp reads 24/Jul/2026, so
the constant looked like a typo somebody ought to correct.
Nothing is wrong with the data. nTime matters only as an input to the
genesis hash, the block hashes to hashGenesisBlock with it, the asserts
pass, and the whole network agrees. The hazard is entirely in acting on the
mismatch. Editing nTime alone trips the assert -- loud, and it reverts.
Editing it and regenerating GENESIS_NONCE and hashGenesisBlock to match is
the quiet one: that node starts without complaint, builds its own chain
from height 0, and rejects every real peer, and the re-mining branch a few
lines below prints exactly the constants needed to do it.
So: correct the comment rather than the constant, state the discrepancy as
known and uncorrectable, and have the re-mining printout say what those
constants are and are not for. No value changes -- pszTimestamp, the
scriptPubKey, nTime, nBits, nNonce, GENESIS_NONCE, hashGenesisBlock and
hashGenesisMerkleRoot are all byte-identical.
Diffstat (limited to 'src/test_relayproc.cpp')
0 files changed, 0 insertions, 0 deletions