kayabaNerve
commented
3 years ago sketchCheck is consensus critical making the hash algorithm consensus critical. That said, this doesn't really change this issue, as this would likely be part of a hard fork anyways. Just a note about an inaccuracy in the above.
For our sketches, we use Blake2b-64 to generate a 8-byte hash of the Verification Packet. This isn't as efficient as it could, especially since this may be run thousands of times when verifying a Block (so it must be done in a fraction of a second).
We could lower the iteration count of Blake2, like how Blake3 did, yet it still wouldn't be optimal. It also would require implementations shipping a custom Blake file with said lowered iterations.
CRC32 only uses its current state and the next byte it's iterating over. With our salt appending, any Verification Packet which has a collision won't be affected by the salt. By prepending the salt, this behavior changes, yet CRC32 is still an extremely simple, and game-able algorithm.
XXH64 (https://cyan4973.github.io/xxHash/) is extremely performant and native to this bit size. That said, it's not cryptographically secure, as it's not meant to be. Even with our salt (provided through its seed interface or as part of the data itself), it's unsure if there are inputs which would always collide.
I would like to tackle this at some point, yet due to this being an optimization, sketches not being consensus-critical, and the amount of work needed to verify non-cryptographically secure hashes validity for this purpose... this will probably be tackled after mainnet.