Threshold Mining Games

--

A useful primitive for cryptoeconomics would be a game that resolves into a purchasing-power-adjacent signal, however indirect.

We will explore using hash functions to this effect. A good hash function is one-way: given just an output, you cannot easily recover the input. It also should behave as if its outputs were uniformly random: you cannot predict the output without calculating it, and the outputs are uniformly distributed.

For example, SHA256 maps an input to a 256-bit number. If we require the output to be above some threshold, then finding a valid input becomes a trial-and-error process. A threshold near the top of the range requires many more expected attempts than a lower one.

Imagine a game: I give you a seed, and you may combine it with any nonce of your choice as input to SHA256. Your goal is to find a nonce whose output lands above the required threshold. Once you find one, anyone can cheaply verify it.

Since the output behaves like a uniform random draw and the function is one-way, the only way to win the game is to actually try a bunch of different nonces in the hash computation. The higher the threshold, the more expected attempts you need. This process uses real-world resources: compute and electricity.

Up to here, the idea is simple. Higher thresholds require more expected work. The hard part is turning that into an onchain game whose equilibrium output is actually meaningful.

The Threshold Game

A game requester posts a reward to incentivize a threshold report. The requester decides the starting liquidity and timer.

Anyone can report by posting a threshold and liquidity, starting the timer. This kicks off the breaking game: anyone can try to break the reporter by finding a nonce that, combined with their address, the gameId, and the parent block hash captured at report time, hashes above the threshold.

Upon break, part of that reporter’s liquidity is used to fund the next round’s reward, while the remainder goes to the breaker. A multiplier set by the requester governs how much the next round’s reward and liquidity increase. The timer counts down from when the first reporter of the next round shows up.

A reporter can also be replaced during the breaking game if someone posts a sufficiently lower threshold (governed by a replacement decay parameter), which returns the incumbent’s liquidity and refreshes the timer.

The game ends when the timer expires. The surviving reporter earns the reward and their reported threshold is considered final.

Market forces push the winning threshold toward a survivable market price of the liquidity asset in compute terms: if a reported threshold is too low, breaking is profitable and a fresh round starts. If too high, replacing with a lower threshold is profitable and the timer restarts.

Bitcoin uses double-SHA256, so a Stratum pool could route miner work into the breaking game. The miners don’t need to know they’re participating.

Signal

A final threshold implies some expected amount of work required to break it. Normalizing by final round liquidity gives a measure of expected work per unit of the onchain asset, or more simply, the price of compute.

Comparing the price of compute across sequential, equivalently parameterized games gives a signal about how purchasing power changed over the interval, measured against computational cost. If the winning threshold rises from one game to the next, that suggests market participants were willing to burn more real-world compute to win the liquidity, implying stronger purchasing power versus compute. If it falls, that suggests weaker purchasing power.

This does not measure purchasing power in a universal sense. It is not some clean CPI oracle. Computational cost is at least anchored to physical reality, which may be more stable than measuring against another token.

The key thing to understand is that this game is weird and distorted, but the weirdness appears roughly scale-invariant. Most crypto mechanisms break down under the weight of their own incentives at scale, so scale-invariant weirdness is a very nice property.

Manipulation

Manipulation via overspending for breaks runs into an exponential cost wall: each break escalates the next round’s reward and liquidity by the multiplier up to a configured halt.

Trying to delay the oracle via replacement similarly runs into an exponential wall: since each threshold update within a round must be sufficiently lower than the previous (replacement decay), delaying for too long pushes the threshold low enough that breaking becomes attractive, which then kicks the game into a larger next round.

In conclusion

The full state machine implemented in Solidity can be found here, alongside a more detailed writeup.

If this design is the irreducible compute price primitive, there may be no further elegance available without breaking the object.

The next step is to try to build something on top of it, like a flatcoin. Supply shocks and hardware performance increases are still hard problems to engineer around, but at least seem tractable.

As always, we are happy to discuss this mechanism, or any mechanism we publish, in any setting. Feel free to join our discord if you have any questions or want to poke holes in the design.