Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
64 bit seed exploits ASIC resistance #51
Hi @kik - thank you for this! Could you clarify in your post the number of keccak items required to produce one (theoretical) ProgPoW hash, and the time to produce them? The feasibility in a <14 second block time environment seems low.
We will adjust to uint128_t regardless. Good find!
I don't think this attack is very practical. First you need to solve
Edit: plus, since
This issue requires a custom implementation of node generating block templates.
where a solution is found but on a completely different header_hash
It's possible though that an "attacker" runs his own custom node.
There is another point though which is easy to amend in PP:
This allows you to do the following:
This can be voided in two ways:
With 128-bit, we have 2 vs 4 registers taken from the main loop, which forces spilling registers to memory, which in turn results in a performance cliff. In a 256-bit environment, it's worse.
512-bit was dropped to 64-bit to reduce register pressure, hence why hash_mix has PROGPOW_REGS set to 32, where 32 registers are used as part of the random sequence of math. With Ethash, 16 registers were used to store the seed across the hash_mix call.
This is wasteful on your register file - one of the most power and area intense parts of a CPU/GPU core. An ASIC could then store the 512-bit seed on the side in a much more area/power efficient manner - reducing to 64-bits reduces that advantage.
The proposed fix we are suggesting would be to have hash_mix consume all 256 bits of the seed produced by the initial keccak, while having the final keccak consume only 64 bits of the seed. That keeps 256 bits of security, but does not hammer the file register.
There is a trade off to every single step in hardware, and we are careful to ensure there is a balance between what an ASIC can trivially store (and perform) and what a GPU can do. Thus this approach.
What are your thoughts?
@AndreaLanfranchi is also playing with some alternate solutions that reduce register pressure.
a) To find a target in 2^64 , even linear searching , is a very difficult thing already , if using the 4000 cores to build 1000 thread with 1Ghz, long time.
b) Mining Pool can't degree this difficulty because it can not get proven of work for every dedicate miners.
So should it be changed?