tranvictor
Why use 16-byte truncated hashes?
Generally, sha2 has 2^(len/2) bits of collision resistance. So truncating to 128 bit digests gives only 64 bits of collision resistance. This means your commitments can be collided in ~2 hours on a modern GPU. How does this affect the security of the verifier?
@prestwich it seems the Merkle Tree is used to proof ethash PoW validity. While bruteforcing merkle tree costs more than Ethereum PoW it is not an issue.
Sure, but then you should clearly make the argument that this merkle tree is not critical to the security of the verifier
It seems also that current difficulty it about 2^51, so we have time until network difficulty will grow in 2^13 times (8192).
Generally, sha2 has
2^(len/2)bits of collision resistance. So truncating to 128 bit digests gives only 64 bits of collision resistance. This means your commitments can be collided in ~2 hours on a modern GPU. How does this affect the security of the verifier?
It breaks the security in a 2 hours delay. However, in the production environment, the hash should be at least 128 bits collision resistance. The current version I have in this repo is actually for a PoC (experiments) and it is pretty easy to change it in the code.
Another note: If someone wants to apply the preimage attack (eg. they have an ideal hash and need to find another element to produce the same hash), the resistance is still 2^len.
