Heads up before the hardcore folks jump in: I'm fully aware that messing with an 84-byte block header doesn't meet consensus rules, so it can't get out to the network. This is just a cryptographic experiment to push Double-SHA256 to its limits beyond protocol norms.
So here’s the deal:
The usual Genesis block header is 80 bytes, with a 32-bit nonce range. There’s only one valid 32-bit nonce (2083236893) that fits the 10-zero difficulty target. I was curious how things could unfold if I broke that 32-bit barrier on the Genesis block without tweaking the Merkle Root or the extraNonce.
I expanded the Genesis header to 84 bytes by adding an 8-byte (64-bit) nonce at the end of the regular 76-byte prefix.
The Setup and Approach:
I created a custom C++/CUDA program and ran it on a dedicated RTX GPU at a data center. Instead of trying the exhausted range of 0-4.29 billion, I jumped straight into brute-forcing from 4,294,967,296 and up.
The Findings:
After crunching about 1.03 trillion independent hashes, the GPU setup stumbled upon a clean collision that met the 10-zero target.
Winning 64-bit Nonce (in Decimal): 1035160959500
Resulting Double-SHA256 Hash: 00000000001761db1b8fcf38de3ed8b61384c3c306ce53080d3b338268dafc36
For anyone interested in checking the calculations, here’s the exact 76-byte hex prefix I used:
Just add the 64-bit nonce 1035160959500 (in little-endian) to that byte array.
Some people wanted to do another trick: putting extra bits in the previous block hash. For example:
And then, if the previous block hash would be always masked with "bits", then, as the difficulty would grow, it would give us more and more space for nonces. For example:
Also, that kind of trick is described in Hardfork Wishlist:
In the current protocol, the minimal difficulty is set to "1d00ffff", which means, that the last four bytes could be always masked in that way. But in general, as we will have stronger, and stronger block hashes, with more and more zeroes, then it gives us more space, to potentially put something there in the future. For example: if SHA-256 would be replaced with something else, then we could require a block, which would give all zeroes, when hashed through that function, and then simply put the result of the new hash function, running on the same data, in the same place.
In this way, the size of the block header can stay at 80 bytes, which is a nice feature, because then, you can easily calculate offsets for any block headers, and get them with constant time complexity.
Your numbers look like you were really benchmarking against a 10-hex-zero vanity condition, not the actual genesis difficulty target from bits=1d00ffff. Those are very different beasts.
Difficulty-1 target is roughly a 1 in 2^32 event, so after about 1.03 trillion hashes you would expect a whole bunch of valid hits, not one lone wolf. One hit in about 2^40 trials lines up beautifully with "10 leading hex zeroes", which is stricter than the real target and just happens to resemble the published genesis hash.