Please provide maths we can use to verify your claims.
This is like asking to provide maths for the multiplication table. The topic of fair H160 pools impossibility has already been debated to death in the last 10 years, and the proof is easily understandable by a 5-year child. What do you want, a drawing? Understand that it's impossible to compute a
proof that some data made out of
independent items has been computed, without actually
computing all the independent items of the data itself to
verify them.
Though it's in the spirit of the thread to reach every single day the full non-sense point, where people confuse facts for opinions, and then ask for proofs.
kTimesG,
You said fair H160 pool verification is impossible. Then you called my request for math "daily nonsense."
Here is the math.
Bram already verified a distributed H160 scan across 25K GPUs for puzzle 67. Each worker submitted HASH-160 keys with 48 leading zero bits as proof of work. Expected submissions per worker per range of size R:
E = R 2^48
Standard deviation:
sigma = sqrt(E)
A worker submitting fewer than E - 3*sigma submissions is cheating with >99.7% confidence. For puzzle 67 with 256 workers scanning 2^58 keys each, E = 1024, sigma = 32. Observed: 938 to 1108. Every worker within 3 sigma. This was verified by Cricktor in post #7575.
That is not cryptographic proof. It is probabilistic verification. It works. It was used. The distinction matters.
If you meant "perfect cryptographic proof is impossible" then say that. Nobody disagrees. But that is not what you wrote. You wrote "it's impossible to compute a proof that some data made out of independent items has been computed." This is true only for perfect proofs. Probabilistic proofs with quantifiable error rates exist and have been deployed.
Now here is the math you did not provide.
Puzzle 71 full scan estimate at current aggregate: 421 years. If your SOTA+ with 1M+1S overhead cuts k by 10%, that is 379 years. If it cuts k by 50%, that is 210 years. If it cuts k by 90%, that is 42 years. None of these are practical. The exponential curve has hit a wall at 2^70 regardless of implementation details.
Meanwhile the puzzle creator designed 256 wallets with a 160-bit address layer. RIPEMD160 outputs exactly 160 bits. After puzzle 160 the brute force cost flatlines at 2^160 for every puzzle 161 through 256. The measuring instrument stops measuring. The creator called 161-256 "silly" and moved the funds. The wallets still exist. Puzzle 256 still has dust.
You are arguing about saving one multiplication per kangaroo jump while the puzzle creator built a puzzle, the BIP39 word mapping of keys, the f6f5431d cluster, and the 256 addresses themselves. The instrument already gave its reading. Brute force hit the ceiling. The creator is measuring something else now.
If your SOTA+ can solve puzzle 71, solve it. If not, then we agree on the math: the exponential curve is the wall, and no constant-factor optimization changes that.
