Whisper: wrong proof-of-work calculated

[arnetheduck]

2 suspected issues with proof-of-work calculation:

• When calculating leading zeroes, one byte is skipped leading to a bogus leading_zeroes calc
  • consider a hash that has no leading zeroes / starts with 0xff..
  • the calculation will do hash.get(0 + 1).map_or... - off by one
• the u64 is prone to overflow, for high proof-of-works (a float would handle this)

https://github.com/paritytech/parity-ethereum/blob/93e1040d07e385d1219d00af71c46c720b0a1acf/whisper/src/message.rs#L36

[niklasad1]

Hey @arnetheduck

When calculating leading zeroes, one byte is skipped leading to a bogus leading_zeroes calc
- consider a hash that has no leading zeroes / starts with 0xff..
- the calculation will do hash.get(0 + 1).map_or... - off by one

Yes, you are right it should be just hash.get(leading_zeros) since index starts from zero and it will handle the case of 0xff too

the u64 is prone to overflow, for high proof-of-works (a float would handle this)

Yeah, I agree because the max number of zeros is 256 and any shift left bigger than 63 will end-up in an overflow but I think it will force us to use floating point operations thus no shifting.
We need to do something like 2.0_f64.powi(n as i32) instead (I don't think f64 supports ldexpf) unfortunately it is way slower