This implements a speedup to ScalarMult using the endomorphism available to secp256k1.
Note the constants lambda, beta, a1, b1, a2 and b2 are from here:
https://bitcointalk.org/index.php?topic=3238.0
Preliminary tests indicate a speedup of between 17%-20% (BenchScalarMult).
More speedup can probably be achieved once splitK uses something more like what fieldVal uses. Unfortunately, the prime for this math is the order of G (N), not P.
Note the NAF optimization was specifically not done as that's the purview of another issue.
Changed both ScalarMult and ScalarBaseMult to take advantage of curve.N to reduce k.
This results in a 80% speedup to large values of k for ScalarBaseMult.
Note the new test BenchmarkScalarBaseMultLarge is how that speedup number can
be checked.
This closes#1
- Keep comments to 80 cols for consistency with the rest of the code base
- Made verify a method off of Signature instead of PublicKey since one
verifies a signature with a public key as opposed to the other way
around
- Return new signature from Sign function directly rather than creating a
local temporary variable
- Modify a couple of comments as recommended by @owainga
- Update sample usage in doc.go for both signing messages and verifying
signatures
ok @owainga
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
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.
