d1dc9df Get rid of reserved _t in type names (Pieter Wuille)
Pull request description:
Tree-SHA512: 5da4a2cb15106c47fbe14346562444eff322a5e4e2386af8b0b879b72e22f08d704ac09746d6a22ff76e8892fc20208932b2a45d01de0e2e089686dabe45e633
abe2d3e Fix header guards using reserved identifiers (Dan Raviv)
Pull request description:
Identifiers starting with an underscore and followed immediately by a capital letter are reserved by the C++ standard.
The only header guards not fixed are those in the headers auto-generated from java.
Tree-SHA512: da31b8d718b3c3ffb81b3d12c93ce2d56c176f19a1936776c843fee069dbaa916946556cea16db34e1f977a937924d72c870230ac26e44386706ecd7cb25ba65
8c7ea22 Fixed multiple typos (Dimitris Tsapakidis)
Pull request description:
Forward port of fixes introduced in https://github.com/bitcoin/bitcoin/pull/10633 by @dimitris-t.
Tree-SHA512: a979b3e14bf2660cb0fcd809854654bd0f6277399afe948917be6c061a04835d404e590dc58bcb4a9e2ccfbfb38de944cbdba349092465f637606d3bee49fc16
Identifiers starting with an underscore and followed immediately by a capital letter are reserved by the C++ standard.
The only header guards not fixed are those in the headers auto-generated from java.
bc61b91 add pubkey prefix constants to include/secp256k1.h (Andrew Poelstra)
Pull request description:
In future multisig implementations we will need to pass nonces around, which are algebraically pubkeys but should not be decodable as pubkeys. The way to do this is to change the prefix byte from the ordinary 0x02/0x03 to something else. However, some forks (notably `secp256k1-zkp`) have started using some bytes for their own encodings, and if we continue to use hardcoded constants the risk of conflict is increased.
This commit puts the prefixes used by the main library into the `include/secp256k1.h` so that the constants we're using will at least be in a standard easy-to-reference place.
Tree-SHA512: 37fa25be5074b7c519a9c69421320a62f32a3818f144254eb57f96c6657b993fc01962a5c670574275d1c59b095a6c89e60736123f032d6736907284eac526d7
768514b Fix wnaf_const documentation with respect to return value and number of words set (Jonas Nick)
Pull request description:
Tree-SHA512: e2e49036c5930c74fff12626957a43000e5f86180791f2b857d279e83c609663ee5cbee4c3380f3df3d29e493f40051d63a8eff1badeea99e06652d9e72f4d29
5e95bf2 Remove residual parts from the schnorr expirement. (Gregory Maxwell)
Tree-SHA512: de1e56cc54443e29a60787996a1b1381b0b84eacb87a8f1af06b5ba3900b1771c3a04fd547c65e21979e3c08c3a45d258d699eb951a956f8e617833c5396ecfe
465159c Further shorten the addition chain for scalar inversion. (Brian Smith)
cf12fa1 Minor optimizations to _scalar_inverse to save 4M (Peter Dettman)
Tree-SHA512: b03ae53bd48435f8ef8a89ba3b45f9a35f3f3c6cfba7deb6820ab2146205656d198e4317a4cb98a986f434df244ae735313d303d0ce5a5c40519d37621238957
field_get_b32: min 0.890us / avg 0.905us / max 0.956us
field_set_b32: min 1.12us / avg 1.15us / max 1.19us
becomes
field_get_b32: min 0us / avg 0.000000119us / max 0.000000238us
field_set_b32: min 0.0532us / avg 0.0584us / max 0.0782us
field_get_b32: min 0.647us / avg 0.666us / max 0.751us
field_set_b32: min 0.551us / avg 0.571us / max 0.624us
becomes
field_get_b32: min 0us / avg 0.0000000477us / max 0.000000238us
field_set_b32: min 0us / avg 0.0000000238us / max 0.000000238us
(Patch from https://bitcointalk.org/index.php?topic=1740973.0
_get was reversed from the patch because this order appeared
somewhat faster in testing.)
Signed-off-by: Gregory Maxwell <greg@xiph.org>
5eb030c test: Use checked_alloc (Wladimir J. van der Laan)
Tree-SHA512: f0fada02664fca3b4f48795ce29a187331f86f80fc1605150fcfc451e7eb4671f7b5dff09105c9927e28af6d1dafd1edad1671dddd412110f4b5950153df499d
I think I summarized it correctly after IRC discussion with gmaxwell
and andytoshi; I didn't know it existed :(
It's regrettable to expose this level of detail, but users need to know
this to make a decision about how to use it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
OpenSSL 1.1 makes ECDSA_SIG opaque and our tests need access
inside this object.
The comparison tests against OpenSSL aren't important for most
users, but the build failing is...
Mathematically, we always overflow when using the exhaustive tests (because our
scalar order is 13 and our field order is on the order of 2^256), but the
`overflow` variable returned when parsing a b32 as a scalar is always set
to 0, to prevent infinite (or practically infinite) loops searching for
non-overflowing scalars.
Andrew Poelstra
Daniel Cousens
Thomas Snider
Pieter Wuille
Dimitris Tsapakidis
Dan Raviv
Karl-Johan Alm
Jonas Nick
Dag Robole
Tim Ruffing
Gregory Maxwell
Brian Smith
CryptoGuru
Peter Dettman
Emil Rus
Wladimir J. van der Laan
Rusty Russell
practicalswift