This change removes the internal pad function in favor a more opimized
paddedAppend function. Unlike pad, which would always alloate a new
slice of the desired size and copy the bytes into it, paddedAppend
only appends the leading padding when necesary, and uses the builtin
append to copy the remaining source bytes. pad was also used in
combination with another call to the builtin copy func to copy into a
zeroed byte slice. As the slice is now created using make with an
initial length of zero, this copy can also be removed.
As confirmed by poking the bytes with the unsafe package, gc does not
zero array elements between the len and cap when allocating slices
with make(). In combination with the paddedAppend func, this results
in only a single copy of each byte, with no unnecssary zeroing, when
creating the serialized pubkeys. This has not been tested with other
Go compilers (namely, gccgo and llgo), but the new behavior is still
functionally correct regardless of compiler optimizations.
The TestPad function has been removed as the pad func it tested has
likewise been removed.
ok @davecgh
Since the Z values are normalized (which ordinarily mutates them as
needed) before checking for equality, the race detector gets confused when
using a global value for the field representation of the value 1 and
passing it into the various internal arithmetic routines and reports a
false positive.
Even though the race was a false positive and had no adverse effects, this
commit silences the race detector by creating new variables at the top
level and passing them instead of the global fieldOne variable. The
global is still used for comparison operations since those have no
potential to mutate the value and hence don't trigger the race detector.
This commit exposes a new function named Serialize on the Signature type
which can be used to obtain a DER encoded signature. Previously this
function was named sigDer and was part of btcscript, but as @donovanhide
pointed out in issue btcscript/#3, it really should have been part of this
package.
ok @owainga
Since the function was only exported for use by the test package (and was
commented as such), just move it into the internal_test.go file so it is
only available when the tests run.
This commit essentially rewrites all of the primitives needed to perform
the arithmetic for ECDSA signature verification of secp256k1 signatures to
significantly speed it up. Benchmarking has shown signature verification
is roughly 10 times faster with this commit over the previous.
In particular, it introduces a new field value which is used to perform the
modular field arithmetic using fixed-precision operations specifically
tailored for the secp256k1 prime. The field also takes advantage of
special properties of the prime for significantly faster modular reduction
than is available through generic methods.
In addition, the curve point addition and doubling have been optimized
minimize the number of field multiplications in favor field squarings
since they are quite a bit faster. They routines also now look for
certain assumptions such as z values of 1 or equivalent z values which
can be used to further reduce the number of multiplicaitons needed when
possible.
Note there are still quite a few more optimizations that could be done
such as using precomputation for ScalarBaseMult, making use of the
secp256k1 endomorphism, and using windowed NAF, however this work already
offers significant performance improvements.
For example, testing 10000 random signature verifications resulted in:
New btcec took 15.9821565s
Old btcec took 2m34.1016716s
Closesconformal/btcd#26.
This change pads serialized (big endian) pubkey numbers to a length of
32 bytes. Previously, because serialized pubkey numbers are read
MSB-first, if a number could be serialized in less than 31 bytes, the
deserialized number would be incorrect.
This change adds an additional signature parsing function which
performs additional checks to verify the signature is serialized in a
valid DER (and thus, unique) format, instead of allowing the less
strict BER signatures that ParseSignature will happily accept.
Added additional tests and updated test coverage to reflect changes.
Turns out that there are some signatures in the bitcoin blockchain that have
trailing 0s, for example
12a1b29fd6c295075b6a66f5fd90f0126ceb1fda4f15e4b44d92518bd52a5cdf has a signature
length of 0x45 where there are 0x47 bytes following that length check (one is
hashtype and is supposed to be trimmed out prior to calling the function). We
relax the paranoid length check to permit traling data, but not to permit
buffers that are too short. Change the test to passing with a big comment
stating why this is now considered a valid case.
