Proof of Work Integrity revisited!

Once upon a nonce in Hoosat Network. We moved from Pyrinhash to Hoohash, because so called The Entity was mining Pyrinhash. That meant it was time for our first Hard Fork in 2024 and update the algorithm. After the hard fork we noticed The Entity or someone with extremely high hashrate was able to still mine in Humpool without finding correct blocks and few Pyrinhash miners reported to me that they could get ~50% acceptable shares and even hitting blocks when mining Hoohash, then Bawls from Mining4People insisted me to find the issue, while he thought the issue was because of similarity in the algorithms. But that was not the case.

The case was protocol level issue originating from Bitcoin and let me explain the issue yet again and then show current example of it happening.

The protocol issue simplified

In normal Proof-of-Work mining, a miner requests a block template from the pool or node, then iteratively increments the nonce (and other fields like timestamp and extranonce2) until it finds a Proof of Work hash that meets the required difficulty set by the pool for valid shares or the network for valid blocks.

Then comes the fact that we can guess those iterative data fields and do block submit to stratum protocol or directly to cryptocurrency node without doing the intended algorithm work.

Only protection currently is high hashrate which creates high difficulty. But with FPGA/ASIC/Quantum resistant PoW algorithms, we need to make the algorithms slower, which means difficulty drops to be more favorable for nonce guessing. So the lower the difficulty, the more nonce spamming possibilities.

But anyway take for example Bitcoin. To submit a block to the Bitcoin network using the submitblock RPC command, the data must be a complete, raw, serialized block in hexadecimal format. The raw block data format in the following picture.

You can see that Bitcoin node does not require sending the miners found hash in Bitcoin submitblock RPC command. This means the work done by the miner is never validated to be correctly done and that the input to submitblock RPC command can be guessed, which opens several different attack vectors such as Stratum payment scheme share stealing.

I’ve researched this issue since summer 2024.

• I’ve researched how many duplicate nonces Bitcoin has had and what kind of patterns we could find from the existing Bitcoin blocks.
• We’ve tested mining several algorithms with incorrect algorithm.
• I’ve written a self published paper on the issue. https://network.hoosat.fi/downloads/The_Integrity_of_Proof_of_Work__Nonce_Spamming-1.1.pdf
• I’ve submitted solution for stratum pools, which does not infringe my patent application. https://medium.com/@toni.lukkaroinen/stratum-share-stealing-7617d56ea3c3

Current Xelis situation as an example.

Xelis did a hard fork to enable smart contracts and update their algorithm from XelishashV2 to XelishashV3. But afterwards there has been some issues and one of them seems to be seen on the hashrates.

In the miningpoolstats picture you can see that Herominers has 68.67% hashrate of the network hashrate, with only 25.3% of blocks from the last 1000 blocks. That means something is affecting the herominers hashrate and I don’t think Herominers is intentionally bloating their hashrate reports as such actions only hurt the pools.

It’s sad that I can not view single miner in herominers and see how much they find shares compared to blocks, but if pool has 50% hashrate they should produce 50% of the blocks on the network. Unless something is completely wrong, but I believe the issue is that some XelishashV2 miners are still mining to Herominers and they have been slowly switching to XelishashV3.

This would explain the bloated hashrate Herominers is displaying without pointing fingers on other than on the technology.

Final word

If you don’t take me seriously on the topic now, you will take it seriously soon, because we will still need to make our algorithms slower. On the memory side. XelishashV3 is not the end of the cat race, because HBM4 mass production is supposed to start in 2026 and HBM3e has already increased pin speed considerably. XelishashV3 is a patch for now.

The point being that we want to create egalitarian and accessible algorithms, and want to keep the barrier to entry low, which means we need to resist the fast computation devices. When the fast devices with their optimizations become able to handle the algorithm better than intended devices, we need to update the algorithms or allow the hashrate to move to the faster computation devices.

My bet is on FP64 non-linear equation calculation speed over memory hardness and the patent pending Proof of Work Integrity fix on the protocol issue network wide.