Silence a compiler warning about an unitialized use of a scalar in case
the user tries to provide a 0-length list of commitments.
Also ensures that commitments have normalized field elements when they
are loaded into ges.
Provides a method that will give an upper bound on the size of a rangeproof,
given an upper bound on the value to be passed in and an upper bound on the
min_bits parameter.
There is a lot of design freedom here since the actual size of the rangeproof
depends on every parameter passed to rangeproof_sign, including the value to
be proven, often in quite intricate ways. For the sake of simplicity we assume
a nonzero `min_value` and that `exp` will be 0 (the default, and size-maximizing,
choice), and provide an exact value for a proof of the given value and min_bits.
5ac8fb035e surjectionproof: make sure that n_used_pubkeys > 0 in generate (Jonas Nick)
Pull request description:
ACKs for top commit:
apoelstra:
utACK 5ac8fb035e
Tree-SHA512: 915f7181e69e2c4e1f830d6c2620a2d9b0af4d2ae8a63709b489b01ed9e13ccfeeaedebd4680cf2d927cd473a6ae88602cf29e2fdd116cb597fba6c0ab77720d
If the proof was generated with surjectionproof_initialize (as mandated by the
API docs), then n_used_pubkeys can never be 0. Without this commit, compilers
will (rightfully) warn that borromean_s[ring_input_index] is not initialized in
surjectionproof_generate. Therefore, this commit makes sure that n_used_pubkeys
is greater than 0 which ensures that the array is initialized at
ring_input_index.
5a40f3d99b replace memcmp with secp256k1_memcmp_var throughout the codebase (Andrew Poelstra)
92820d944b rangeproof: add a test for all-zero blinding factors (Andrew Poelstra)
Pull request description:
I was curious about under what conditions you can create a rangeproof on an "unblinded" commitment which has a zero blinding factor. Apparently the answer is "when you are proving at least 3-bits". In this case rewinding words and you can encode 32 bytes of data. (In fact I believe you can encode up to 128 but I haven't tested that.)
ACKs for top commit:
real-or-random:
utACK 5a40f3d99b
Tree-SHA512: bed7f9362d082d2b56668809077d5ddde52280109c992a290d87b55cb70138a08799fcca18cafbb3b3e9efed4349418bf9bb2c0ccedacdce0567e841e6d21e13
347f96d94a fix include paths in all the -zkp modules (Andrew Poelstra)
Pull request description:
This is causing out-of-tree build failures in Elements.
ACKs for top commit:
real-or-random:
utACK 347f96d94a
Tree-SHA512: 7d6211f3b8d5612f95bcb3085c22458e7ceaa79f1ee74e37404cc6d1fdf0fbc02b4443b02623b9b6c1225437c1a1954b6d36a953d52b020ac7913326404894e0
d1175d265d surjectionproof: use secp256k1_memcmp_var rather than bare memcmp (Andrew Poelstra)
bf18ff5a8c surjectionproof: fix generation to fail when any input == the output (Andrew Poelstra)
4ff6e4274d surjectionproof: add test for existing behavior on input=output proofs (Andrew Poelstra)
Pull request description:
If any ephemeral input tag equals the ephemeral output tag (i.e. an input asset is exactly equal to the output asset), verification will fail due to an unexpected interaction between our surjectionproof logic and the underlying borromean ring siganture logic. However, our generation code still allows creating proofs like this, "succeeding" in creating bad proofs.
Since we cannot fix the verification side without hardforking Liquid, fix the generation side to fail in this situation.
ACKs for top commit:
real-or-random:
utACK d1175d265d
Tree-SHA512: c15e130de028d6c1f705543fe2774ec23016c71f9d6b38ef0708820a517d156e2126f8369e94f16f9fd1855c29cd907d406f6ea26c95499a9ae1ce0dd92f77b2
