upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/src/rpc.cpp
diff options
context:
space:
mode:
authorbitflash-maintainer <noreply@bitflash.invalid>2026-09-02 14:33:56 +0000
committerbitflash-maintainer <noreply@bitflash.invalid>2026-09-02 14:33:56 +0000
commit0b7363211f954698e593699f32ed13b425fce2bc (patch)
treed6571a09b702f98aeee84471aca9b9b310026b0c /src/rpc.cpp
parent03a69ccfb36861948e11b0871bb9af8f0b280709 (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/rpc.cpp')
0 files changed, 0 insertions, 0 deletions