bitcoinj / bitcoinj / 1755 / 1

61%

master: 61%

push

travis-ci

ECKey: Fix violation of equals/hashCode contract.

ECKey violates the equals/hashCode contract for
Java objects. Objects that are equivalent via
the equals method, _must_ have the same hash code.

This is not the case for ECKeys when comparing
the compressed and uncompressed forms of a public key.
The implementation of the `equals` method defines
these objects to be equivalent, but the hashCode
method defined them to be distinct!

Original implementation comes from commit
<a class=hub.com/bitcoinj/bitcoinj/commit/640db52cf48416db8e2b24b502b3775243ad5162">640db52cf<a href="https://github.com/bitcoinj/bitcoinj/commit/1746be6e1035631f4875dc77b92ae60cfdbe865f">
which contains this bug. [1]

Note that the comment identifies the correct intent:

&gt; Public keys are random already so we can just use a part of them as the hashcode. Read from the start to
&gt; avoid picking up the type code (compressed vs uncompressed) which is tacked on the end.

But the second sentence is incorrect. The first byte (index 0) is the type code
(compressed vs. uncompressed), not “the end”.

The code has since been refactored in commit
<a class=hub.com/bitcoinj/bitcoinj/commit/9219d8a9b5714cf4e65dc046c70930c86416e65d">9219d8a9b
but the implementation is effectively
identical. [2]

The fix is simple: use the most-significant four
bytes of the X-coordinate of the public key.

[1](https://github.com/bitcoinj/bitcoinj/commit/640db52cf48416db8e2b24b502b3775243ad5162#diff-b59ef8be77b9148b27a14be59762c0c5R353)
[2](https://github.com/bitcoinj/bitcoinj/commit/9219d8a9b5714cf4e65dc046c70930c86416e65d#diff-1849449aac05f7e59de7ebd56efd7f43R1201)

15035 of 20980 relevant lines covered (71.66%)

0.72 hits per line