Daniel James 1746be6e10 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 640db52cf4 which contains this bug. [1] Note that the comment identifies the correct intent: > Public keys are random already so we can just use a part of them as the hashcode. Read from the start to > 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 9219d8a9b5 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](640db52cf4 (diff-b59ef8be77b9148b27a14be59762c0c5R353)) [2](9219d8a9b5 (diff-1849449aac05f7e59de7ebd56efd7f43R1201))		2016-10-30 12:59:47 +01:00
..
src	ECKey: Fix violation of equals/hashCode contract.	2016-10-30 12:59:47 +01:00
findbugs.xml	Renamespace to org.bitcoinj away from com.google.bitcoin, as bitcoinj is no longer a Google project and being namespaced under com.google causes issues with Sonatype/Maven Central.	2014-09-30 17:05:07 +02:00
pom.xml	Update to OkHttp 2.7.5.	2016-09-06 15:28:41 +02:00