When a miner claims a certain hash power and timestamps a block they solved, they are making a claim that a certain amount of time has passed since they received previous block. Intentional shenanigans (“time-warp-attack“) may exist when the miner’s timestamp is very different from the actual time at which they solved a block. I was just imagining a method of inhibiting such shenanigans by verifying the density of found hashes. Here’s how that could be done:
How to Measure Hash Density
The number of SHA256 hashes between 2^255 + 2^n and 2^255 – 2^n for any n will increase at a relatively steady rate proportional to the miner’s hash rate. Counting them provides a rough estimate of a miner’s hash rate. A suitable n would have to be chosen for various levels of hash power.
Limiting Data Transfer Requirements
For a miner to prove that they generated a certain number of hashes within a given time frame, they’d have to provide the entire block for each of the generated hashes. However, only a bit more data than the entire first of those blocks is really needed because they could include the nonce and the transaction set delta between the previous block and the current one each time they found one. This could verify that they actually generated at least as many hashes as their timestamp suggests, with an error margin of the time it took for them to get the previously solved block and the error on the previous block’s timestamp.
This might be useful for limiting the shenanigans that messing with timestamps or misreporting hash rate allows. If it can be tightened up enough, it might squeeze out a lot pf potential “time warp” type shenanigans.