Bulletproofs (rangeproofs only) #23

apoelstra · 2018-05-25T22:22:21Z

This is #16 without any of the arithmetic circuit stuff.

At this point there are probably still obvious code cleanliness things to be dealt with, but I think it's ready for review. I'd like to get this merged so that we can get the rangeproofs at least into Elements soon.

cc @sipa @real-or-random @jonasnick can a couple of you review this? I'm happy to split it into multple PRs if that makes sense.

rodasmith · 2018-05-26T03:00:18Z

include/secp256k1_commitment.h

+ *  If you need to convert to a format suitable for storage or transmission, use
+ *  secp256k1_pedersen_commitment_serialize and secp256k1_pedersen_commitment_parse.
+ *
+ *  Furthermore, it is guaranteed to identical signatures will have identical


(nit) s/to/two/

real-or-random · 2018-05-26T07:37:20Z

Discussions about ciphers can be annoying... Is there a specific reason to use chacha20? It's just used to derive randomness, why not rely on SHA256? I don't think that performance is a concern here. If performance is a concern, then I guess that AES is the canonical choice because of its hardware implementations (and constant-time software implementations are pretty good too). I know @sipa has looked into these things, so I could imagine that all of this has been discussed extensively and I'm just late to the party. It's also interesting for dicemix, which requires a PRG (or better a PRF) and needs much more randomness, each party needs O(|m| * n^2) bytes for n parties. So the performance of the PRF could be worth to think about and it would be preferable to use something which is already in libsecp256k1 of course. Am 26. Mai 2018 00:22:25 MESZ schrieb Andrew Poelstra <notifications@github.com>:

…

This is #16 without any of the arithmetic circuit stuff. At this point there are probably still obvious code cleanliness things to be dealt with, but I think it's ready for review. I'd like to get this merged so that we can get the rangeproofs at least into Elements soon. cc @sipa @real-or-random @jonasnick can a couple of you review this? I'm happy to split it into multple PRs if that makes sense. You can view, comment on, or merge this pull request online at: #23 -- Commit Summary -- * generator: add constant G and H generators * add chacha20 function * split Pedersen commitments out into their own module * commitment: allow setting the blinding factor generator for Pedersen commitments * bulletproofs: add module, full support for rangeproofs * bulletproofs: add benchmark * bulletproofs: add rangeproof rewinding capability -- File Changes -- M .gitignore (3) M Makefile.am (8) M configure.ac (50) A include/secp256k1_bulletproofs.h (185) A include/secp256k1_commitment.h (167) M include/secp256k1_generator.h (6) M include/secp256k1_rangeproof.h (157) A src/bench_bulletproof.c (337) M src/bench_rangeproof.c (9) A src/modules/bulletproofs/Makefile.am.include (12) A src/modules/bulletproofs/inner_product_impl.h (786) A src/modules/bulletproofs/main_impl.h (249) A src/modules/bulletproofs/rangeproof_impl.h (792) A src/modules/bulletproofs/tests_impl.h (616) A src/modules/bulletproofs/util.h (116) A src/modules/commitment/Makefile.am.include (4) A src/modules/commitment/main_impl.h (186) A src/modules/commitment/pedersen_impl.h (38) A src/modules/commitment/tests_impl.h (230) M src/modules/generator/main_impl.h (26) M src/modules/rangeproof/Makefile.am.include (2) M src/modules/rangeproof/main_impl.h (187) D src/modules/rangeproof/pedersen.h (22) D src/modules/rangeproof/pedersen_impl.h (51) M src/modules/rangeproof/rangeproof_impl.h (12) M src/modules/rangeproof/tests_impl.h (318) M src/scalar.h (3) M src/scalar_4x64_impl.h (91) M src/scalar_8x32_impl.h (100) M src/scalar_low_impl.h (5) M src/secp256k1.c (18) M src/tests.c (70) -- Patch Links -- https://github.com/ElementsProject/secp256k1-zkp/pull/23.patch https://github.com/ElementsProject/secp256k1-zkp/pull/23.diff -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #23

apoelstra · 2018-05-26T14:16:23Z

It was performance motivated. The prover derives 64 * n_gates bytes of randomness, so there was a measurable performance improvement from using chacha. In the rewinding failure case, deriving randomness is a nontrivial portion of the computation (the whole thing is only a couple microseconds and a SHA2 compression is ~300 ns, so that's 10%).

Interesting observation about AES hardware. In general we haven't done any hardware-specific optimizations in -zkp, though we have assembler implementations of some operations upstream. Another motivation was to keep things simple, and chacha is (a) dead simple and (b) we already had code for it laying around in multiple places.

real-or-random · 2018-05-26T16:10:57Z

Okay I see, that makes sense. ChaCha20's software performance is certainly excellent and the way to go if hardware optimizations are not a goal, and they're indeed a doubly-edged sword: If you have AES-NI, AES is super fast and well, if you don't have it, then ChaCha20 is much faster. So ChaCha20 is a choice that does not prefer peers with a specific architecture [1]. And I think that's the right way to go in systems where everybody should be able to participate.

(That's by the way interesting for online protocols such as DiceMix. Everybody needs to wait for the slowest peer every round, so if you want to optimize for a lower wall-clock time, you can even make the argument that it makes sense to optimize for slower machines. Though I don't think that matters a lot for protocols where bandwidth is the bottleneck and not computation. But that's another story.)

[1] https://calomel.org/aesni_ssl_performance.html

real-or-random

More next week. :)

real-or-random · 2018-05-26T16:51:27Z

src/modules/generator/main_impl.h

+ *  import hashlib
+ *  C = EllipticCurve ([F (0), F (7)])
+ *  G_bytes = '0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8'.decode('hex')
+ *  H = C.lift_x(int(hashlib.sha256(G_bytes).hexdigest(),16))


I need H = C.lift_x(F(int(hashlib.sha256(G_bytes).hexdigest(),16))) here.

Interesting, this must be a new change in sage. Thanks for the fix!

real-or-random · 2018-05-26T17:12:26Z

src/scalar_4x64_impl.h

+        x10 = LE32(seed32[6]);
+        x11 = LE32(seed32[7]);
+        x12 = idx;
+        x13 = idx >> 32;


This right shift has undefined behavior if idx/size_t has 32 bits (or fewer). Same below.

(I guess this is rather a concern in the other file.)

This is still open.

idx is now a uint64_t.

real-or-random · 2018-05-29T12:13:55Z

src/scalar_4x64_impl.h

+#define LE32(p) (p)
+#endif
+
+static void secp256k1_scalar_chacha20(secp256k1_scalar *r1, secp256k1_scalar *r2, const unsigned char *seed, size_t idx) {


This is related to the comment below: size_t idx is somewhat strange. The code below is intended to handle foridx values that are longer than 32 bits but then size_t is not the right type to do this consistently on every platform, i.e., the 32-bit and 64-bit machines will behave differently (even if idx >> 32 == 0 on a 32-bit machine).

My suggestion is to use uint32_t here and set x13 = 0 (and accept that we won't need more than 256 GiB of randomness. Another way is simply to use uint64_t.

real-or-random · 2018-05-29T12:15:42Z

src/scalar_4x64_impl.h

+
+static void secp256k1_scalar_chacha20(secp256k1_scalar *r1, secp256k1_scalar *r2, const unsigned char *seed, size_t idx) {
+    size_t n;
+    size_t over_count = 0;


I wouldn't use size_t for the two counter variables either (because the values do not express memory sizes). But in this case this is probably just personal taste. ;)

real-or-random · 2018-05-29T12:29:54Z

Does not compile for me.

src/bench_bulletproof.c:43:5: error: unknown type name ‘secp256k1_bulletproof_circuit’
     secp256k1_bulletproof_circuit **circ;
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/bench_bulletproof.c:44:5: error: unknown type name ‘secp256k1_bulletproof_circuit_assignment’
     secp256k1_bulletproof_circuit_assignment *assn;
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from src/bench_bulletproof.c:12:
src/bench_bulletproof.c: In function ‘bench_bulletproof_circuit_setup’:
src/bench_bulletproof.c:109:11: warning: implicit declaration of function ‘secp256k1_bulletproof_circuit_prove’; did you mean ‘secp256k1_bulletproof_rangeproof_prove’? [-Wimplicit-function-declaration]
     CHECK(secp256k1_bulletproof_circuit_prove(data->common->ctx, data->common->scratch, data->common->generators, data->circ[0], data->common->proof[0], &data->common->plen, data->assn, NULL, 0, data->common->nonce, &data->common->value_gen[0], NULL, 0) == 1);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

apoelstra · 2018-05-29T12:32:34Z

Derp, I forgot to commit the circuit-removal from the benchmarks. Fixed.

real-or-random

I know all of this is just moved code but here are a few nits... Feel free to ignore.

real-or-random · 2018-05-29T12:33:42Z

include/secp256k1_commitment.h

+/** Initialize a context for usage with Pedersen commitments. */
+void secp256k1_pedersen_context_initialize(secp256k1_context* ctx);
+
+/** Generate a pedersen commitment.


s/pedersen/Pedersen

I'll add a commit that fixes these typos and renames some things. I'll leave any re-ordering of arguments to future PRs because that'll break Elements.

real-or-random · 2018-05-29T12:35:29Z

include/secp256k1_commitment.h

+ *  In:     ctx:        pointer to a context object (cannot be NULL)
+ *          blinds:     pointer to pointers to 32-byte character arrays for blinding factors. (cannot be NULL)
+ *          n:          number of factors pointed to by blinds.
+ *          npositive:       how many of the initial factors should be treated with a positive sign.


indentation of the second column

I found initial initially confusing here. ;)

real-or-random · 2018-05-29T12:36:40Z

include/secp256k1_commitment.h

+  size_t npositive
+) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3);
+
+/** Verify a tally of pedersen commitments


real-or-random · 2018-05-29T12:40:50Z

include/secp256k1_commitment.h

+ * In:     ctx:        pointer to a context object (cannot be NULL)
+ *         commits:    pointer to array of pointers to the commitments. (cannot be NULL if pcnt is non-zero)
+ *         pcnt:       number of commitments pointed to by commits.
+ *         ncommits:   pointer to array of pointers to the negative commitments. (cannot be NULL if ncnt is non-zero)


In the above function, n was the prefix for "number", so I expected ncommits to be the number of commitments, but this function apparently uses a cnt suffix.

real-or-random · 2018-05-29T12:45:28Z

include/secp256k1_commitment.h

+ *         generator_blind: array of asset blinding factors, `r` in the above paragraph
+ *                          May not be NULL unless `n_total` is 0.
+ *                 n_total: Total size of the above arrays
+ *                n_inputs: How many of the initial array elements represent commitments that


Here the prefix is n_ even.

real-or-random · 2018-05-29T12:46:56Z

include/secp256k1_commitment.h

+ *         generator_blind: array of asset blinding factors, `r` in the above paragraph
+ *                          May not be NULL unless `n_total` is 0.
+ *                 n_total: Total size of the above arrays
+ *                n_inputs: How many of the initial array elements represent commitments that


In secp256k1_pedersen_commit, we had the positive summands first, then the negative ones. Maybe this makes sense like this, I don't know.

I'd rather not move arguments around unless there's a strong argument, as they're in use already.

real-or-random

I tried to read the callback function in innerproduct_impl but I got lost in too many variables. The long comment is very nice but it's kind of hard to map the symbols in the comment to actual variable names, and all the cached/helper values add to my confusion.

I think a few comments to explain variables and to explain how some code lines relate to the verification formula would be helpful for further review.

real-or-random · 2018-05-31T09:08:28Z

src/modules/commitment/pedersen_impl.h

-    secp256k1_scalar_set_b32(sec, data, NULL);
-    memset(data, 0, 32);
-}
+/* sec * G + value * G2. */


real-or-random · 2018-05-31T09:43:26Z

include/secp256k1_bulletproofs.h

+#define SECP256K1_BULLETPROOF_CIRCUIT_VERSION	1
+
+/* Maximum depth of 31 lets us validate an aggregate of 2^25 64-bit proofs */
+#define SECP256K1_BULLETPROOF_MAX_DEPTH 60


real-or-random · 2018-05-31T09:49:50Z

include/secp256k1_bulletproofs.h

+ *  Args:          ctx: pointer to a context object (cannot be NULL)
+ *  In:   blinding_gen: generator that blinding factors will be multiplied by (cannot be NULL)
+ *                   n: number of NUMS generators to produce
+ *           precomp_n: for each NUMS generator, plus the blinding factor generator, how many multiples to precompute


real-or-random · 2018-05-31T10:22:49Z

src/modules/bulletproofs/util.h

+        secp256k1_fe_normalize(&pointx);
+        secp256k1_fe_get_b32(&out[bitveclen + i*32], &pointx);
+        if (!secp256k1_fe_is_quad_var(&pt[i].y)) {
+            out[i/8] |= (1ull << (i % 8));


ull seems overkill

real-or-random · 2018-05-31T10:36:47Z

src/modules/bulletproofs/inner_product_impl.h

+ *
+ */
+
+/* For the G and H generators, we choose the ith generator with a scalar computed from the


New comment intentional? You may want to wrap formulas in ``.

real-or-random · 2018-05-31T15:13:54Z

src/modules/bulletproofs/main_impl.h

+        unsigned char tmp[32] = { 0 };
+        secp256k1_generator gen;
+        secp256k1_rfc6979_hmac_sha256_generate(&rng, tmp, 32);
+        CHECK(secp256k1_generator_generate(ctx, &gen, tmp));


It's certainly okay to bail out here but usually we handle (computationally) unreachable code more gracefully.

real-or-random · 2018-05-31T15:57:53Z

src/modules/bulletproofs/main_impl.h

+    size_t n;
+    secp256k1_ge *gens;
+    secp256k1_ge *blinding_gen;
+};


Shouldn't secp256k1_bulletproof_generators store precomp_n too?

I think I should just drop the precomp stuff for this PR since it isn't actually used (I had hacked it in when testing Jonas' multiexp code but never implemented it in an acceptable way).

Dropped precomp.

real-or-random · 2018-05-31T16:13:08Z

src/modules/bulletproofs/main_impl.h

+    size_t n;
+    secp256k1_ge *gens;
+    secp256k1_ge *blinding_gen;
+};


An explanation of what is stored at what array index would have helped me a lot, including a comment that says that blinding_gen points into gens[]

real-or-random · 2018-05-31T16:13:45Z

src/modules/bulletproofs/main_impl.h

+#include "modules/bulletproofs/rangeproof_impl.h"
+#include "modules/bulletproofs/util.h"
+
+secp256k1_bulletproof_generators *secp256k1_bulletproof_generators_create(const secp256k1_context *ctx, const secp256k1_generator *blinding_gen, size_t n, size_t precomp_n) {


s/secp256k1_bulletproof_generators_create/secp256k1_bulletproof_generators_generate
would be slightly more consistent with the naming in the generators module

real-or-random · 2018-05-31T16:27:57Z

include/secp256k1_bulletproofs.h

+    size_t nbits,
+    const secp256k1_generator* value_gen,
+    const unsigned char* const* extra_commit,
+    size_t *extra_commit_len


const size_t *extra_commit_len

real-or-random · 2018-05-31T16:58:31Z

.gitignore

@@ -6,6 +6,9 @@ bench_verify
 bench_schnorr_verify
 bench_recover
 bench_internal
+bench_generator


since you're adding bench_generator', you could also add the missing bench_whitelist`

HaxThePlanet · 2018-06-10T19:12:46Z

Any news on this making it's way into Elements? Looking forward to it

apoelstra · 2018-06-15T21:44:50Z

@real-or-random I replaced all the comments in the inner-product verification callback function. It should be possible to follow now.

instagibbs

Some preliminary comments with looking towards usage in Elements.

configure.ac

include/secp256k1_bulletproofs.h

instagibbs · 2018-06-19T16:19:08Z

include/secp256k1_bulletproofs.h

+ *  Returns a list of generators, or NULL if allocation failed.
+ *  Args:          ctx: pointer to a context object (cannot be NULL)
+ *  In:   blinding_gen: generator that blinding factors will be multiplied by (cannot be NULL)
+ *                   n: number of NUMS generators to produce


Is there any realistic upper-limit as per above constants, or can we go all the way up size_t modulo memory?

Not really any upper limit. They take a while to generate, on the order of 1000/sec.

include/secp256k1_bulletproofs.h

instagibbs · 2018-06-19T16:50:21Z

include/secp256k1_commitment.h

+ *         generator_blind: array of asset blinding factors, `r` in the above paragraph
+ *                          May not be NULL unless `n_total` is 0.
+ *                 n_total: Total size of the above arrays
+ *                n_inputs: How many of the initial array elements represent commitments that


I'd rather not move arguments around unless there's a strong argument, as they're in use already.

instagibbs · 2018-06-19T16:51:12Z

include/secp256k1_generator.h

+/** Standard secp256k1 generator G */
+extern const secp256k1_generator secp256k1_generator_const_g;
+
+/** Alternate secp256k1 generator from Elements Alpha */


We really don't need to support Elements Alpha.

It's useful to have a standard second generator though for non-CA applications.

apoelstra · 2018-06-20T15:46:10Z

@instagibbs fixed your comments

include/secp256k1_bulletproofs.h

src/scalar.h

yeastplume · 2018-06-28T12:49:18Z

We haven't been able to get secp_bulletproof_rangeproof_verify_multi working thus far. In our testing, it seems to work fine when passing in a single proof and a single commit but as soon as we pass in multiples (which verify when passing in one-by-one,) it refuses to validate.

Also noticing that none of the tests for verify_multi actually specify a length of more than a single commit. Might be worth adding a test or case or two for this?

…commitments We now use ecmult_const rather than ecmult_gen, which will slow down the generation of Pedersen commitments. However as far as I'm aware, this is never the bottleneck in proof generation.

apoelstra · 2019-02-07T00:50:36Z

Rebased on #35

src/modules/bulletproofs/main_impl.h

…m Ruffing)

…e expired TODOs

…ent timeout

real-or-random · 2019-02-15T15:05:48Z

As pointed out by drexl in IRC, we should make sure to read https://grin-tech.org/audits/jpa-audit-report.html and mimblewimble/secp256k1-zkp#37

real-or-random

I think the missing deallocate is the only thing that applies to this PR (but someone else should have a second look).

real-or-random · 2019-02-15T23:37:40Z

src/modules/bulletproofs/main_impl.h

+        int overflow;
+        secp256k1_gej commitj;
+        secp256k1_scalar_set_b32(&blinds[i], blind[i], &overflow);
+        if (overflow || secp256k1_scalar_is_zero(&blinds[i])) {


Suggested change

if (overflow || secp256k1_scalar_is_zero(&blinds[i])) {

if (overflow || secp256k1_scalar_is_zero(&blinds[i])) {

secp256k1_scratch_deallocate_frame(scratch);

src/modules/bulletproofs/main_impl.h

real-or-random · 2019-02-15T23:50:42Z

cc @veorq, just for reference

garyyu · 2019-02-27T23:18:55Z

src/modules/commitment/tests_impl.h

+    /* Correct for blinding factors and do the commitments */
+    CHECK(secp256k1_pedersen_blind_generator_blind_sum(ctx, value, (const unsigned char * const *) generator_blind, pedersen_blind, n_generators, n_inputs));
+    for (i = 0; i < n_generators; i++) {
+        CHECK(secp256k1_pedersen_commit(ctx, &commit[i], pedersen_blind[i], value[i], &generator[i], &secp256k1_generator_const_h));


The last parameter should be secp256k1_generator_const_g instead of secp256k1_generator_const_h.

Related PR in Grin: mimblewimble/secp256k1-zkp#44

Fix fuzztarget ECDH to be symmetric

dr-orlovsky · 2020-09-12T00:13:17Z

@apoelstra any chances of having this rebased and getting the great work and effort be finally merged?

apoelstra · 2020-11-09T22:01:30Z

@dr-orlovsky yes, very good chance in the next week or two :)

apoelstra · 2020-11-13T15:11:57Z

Closing this. Will retry in a more staged fashion.

apoelstra · 2020-11-24T06:50:59Z

Closing in favor of #108. Note that the new proofs are not remotely compatible with the old ones.

rodasmith reviewed May 26, 2018

View reviewed changes

real-or-random reviewed May 26, 2018

View reviewed changes

real-or-random reviewed May 29, 2018

View reviewed changes

apoelstra force-pushed the bulletproofs-rangeonly branch from dfeff0d to 4ac6b21 Compare May 29, 2018 12:32

real-or-random reviewed May 29, 2018

View reviewed changes

yeastplume mentioned this pull request May 31, 2018

Integrate latest Bulletproofs from Elements into Grin mimblewimble/grin#1108

Closed

real-or-random reviewed May 31, 2018

View reviewed changes

apoelstra force-pushed the bulletproofs-rangeonly branch 5 times, most recently from 4706f75 to 8822988 Compare June 6, 2018 00:23

apoelstra force-pushed the bulletproofs-rangeonly branch from ec203a8 to d1e9c44 Compare June 15, 2018 21:48

instagibbs reviewed Jun 19, 2018

View reviewed changes

apoelstra force-pushed the bulletproofs-rangeonly branch from d1e9c44 to 6290992 Compare June 20, 2018 15:40

apoelstra mentioned this pull request Jun 23, 2018

undefined reference to `secp256k1_generator_h' #26

Closed

yeastplume mentioned this pull request Jun 25, 2018

T3 - Use updated bulletproof API mimblewimble/grin#1194

Merged

yeastplume reviewed Jun 26, 2018

View reviewed changes

include/secp256k1_bulletproofs.h Outdated Show resolved Hide resolved

yeastplume reviewed Jun 26, 2018

View reviewed changes

src/scalar.h Show resolved Hide resolved

apoelstra force-pushed the bulletproofs-rangeonly branch from 6290992 to 2d48ea5 Compare June 27, 2018 17:16

apoelstra added 2 commits February 7, 2019 00:47

split Pedersen commitments out into their own module

db39447

commitment: allow setting the blinding factor generator for Pedersen …

0ac92f4

…commitments We now use ecmult_const rather than ecmult_gen, which will slow down the generation of Pedersen commitments. However as far as I'm aware, this is never the bottleneck in proof generation.

apoelstra force-pushed the bulletproofs-rangeonly branch from 1fab8eb to a1fc838 Compare February 7, 2019 00:49

garyyu reviewed Feb 8, 2019

View reviewed changes

src/modules/bulletproofs/main_impl.h Outdated Show resolved Hide resolved

apoelstra added 6 commits February 8, 2019 19:34

bulletproofs: add module, full support for rangeproofs

72ffc02

bulletproofs: add rangeproof rewinding capability

14b003f

bulletproofs: add benchmark

9601a66

commitment and bulletproof: fix a bunch of typos and stuff (thanks Ti…

849a258

…m Ruffing)

bulletproofs: extensively comment inner product proof, remove a coupl…

6922c91

…e expired TODOs

bulletproofs: add n_commits to the hash of all rangeproof input data

81d22c9

apoelstra force-pushed the bulletproofs-rangeonly branch from a1fc838 to 8e93c4c Compare February 8, 2019 19:35

apoelstra added 2 commits February 8, 2019 20:27

add new modules to travis

5cda465

rangeproof: reduce test iterations; add echo script to travis to prev…

6fb7e05

…ent timeout

apoelstra force-pushed the bulletproofs-rangeonly branch from 8e93c4c to 6fb7e05 Compare February 8, 2019 20:28

real-or-random reviewed Feb 15, 2019

View reviewed changes

garyyu reviewed Feb 27, 2019

View reviewed changes

apoelstra force-pushed the secp256k1-zkp branch from bcabca9 to 6f3b0c0 Compare May 30, 2019 15:28

tomtau pushed a commit to crypto-com/secp256k1-zkp that referenced this pull request Jul 9, 2020

Merge pull request BlockstreamResearch#23 from TheBlueMatt/master

02d8a51

Fix fuzztarget ECDH to be symmetric

jonasnick force-pushed the secp256k1-zkp branch from dc4181a to fabc8f7 Compare July 24, 2020 19:52

dr-orlovsky mentioned this pull request Sep 17, 2020

Investigate possibility of using bulletproofs from Monero LNP-BP/rust-lnpbp#99

Closed

apoelstra closed this Nov 24, 2020

apoelstra deleted the bulletproofs-rangeonly branch November 24, 2020 06:51

dr-orlovsky mentioned this pull request Feb 18, 2021

Use secp256k1-zkp for bulletproofs & Pedersen commitments RGB-WG/rgb-core#9

Open

7 tasks

	if (overflow \|\| secp256k1_scalar_is_zero(&blinds[i])) {
	if (overflow \|\| secp256k1_scalar_is_zero(&blinds[i])) {
	secp256k1_scratch_deallocate_frame(scratch);

Bulletproofs (rangeproofs only) #23

Bulletproofs (rangeproofs only) #23

Conversation

apoelstra commented May 25, 2018

Choose a reason for hiding this comment

real-or-random commented May 26, 2018 via email

apoelstra commented May 26, 2018

real-or-random commented May 26, 2018

real-or-random left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

real-or-random commented May 29, 2018

apoelstra commented May 29, 2018

real-or-random left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apoelstra May 29, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

real-or-random left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HaxThePlanet commented Jun 10, 2018

apoelstra commented Jun 15, 2018

instagibbs left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apoelstra commented Jun 20, 2018 • edited Loading

yeastplume commented Jun 28, 2018

apoelstra commented Feb 7, 2019

real-or-random commented Feb 15, 2019

real-or-random left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

real-or-random commented Feb 15, 2019

Choose a reason for hiding this comment

dr-orlovsky commented Sep 12, 2020

apoelstra commented Nov 9, 2020

apoelstra commented Nov 13, 2020

apoelstra commented Nov 24, 2020

apoelstra May 29, 2018 •

edited

Loading

apoelstra commented Jun 20, 2018 •

edited

Loading