The previous impl. was in breach of the following section:
> Please note that when k is generated from T, the result of bits2int is
> compared to q, not reduced modulo q. If the value is not between 1 and
> q-1, the process loops.
> Performing a simple modular reduction would induce biases that would be
> detrimental to signature security.
This also adds tests for all other ECDSA serialize/parsing functions.
The k, r, s and D values were sourced from test vectors on
https://bitcointalk.org/index.php?topic=285142.40 .
The compact signatures (aka, i values) were generated from bitcoinjslib, but they
are straight forward anyway.
An ECKey is a composition of a private key (D), a public key (Q) and its
compression flag.
These functions gave the impression of serialization of this
composition, when really they only serialized `D`.
They have therefore been removed in favour of always using a sane
serialization format (WIF) that matches the needed behaviour.
If a user needs the previous functionality, simply use `privKey.D.*`
instead of `privKey.*`, as BigInteger supports `*Buffer/*Hex` functions
as expected.
After a long IRC discussion, it was decided that the use of direct
filepaths instead of the module is a more pure form of testing ,
although it may provide less overall coverage than the mixed integration
style imports used previously.
This will need to be remedied by further integration testing in
/test/integration.
Daniel Cousens
Dave Kerr