blockstreamresearch / secp256k1-zkp Goto Github PK

Nested (or "composable") MuSig is the idea of signing for a combined key that itself consists of combined keys. Ideally, it would not be possible for a signer to determine whether a peer is a single or a combined key. But we don't know how to do that securely at the moment (see @ZmnSCPxj's post for an analysis of the challenges). What we can do instead is a "Multi-R" (non-transparent) variant, where every individual signer in the MuSig reveals their nonce commitment and nonce. However, in that case most protocols could just have the signers agree to flatten their MuSig tree to depth one by revealing their individual keys to each other without adding additional complexity or privacy issues.

The following is how I would imagine it to work in libsecp-zkp. Step 1 and 2 would probably be the same for multi-R and transparent nested MuSig.

1. secp256k1_musig_pubkey_combine can be called multiple times with different pubkeys. For example, to get a combined key for A and (B and C), you'd first call pubkey_combine with pubkeys B and C and then use the result to call pubkey_combine with A. If you're a signer, you should use a different pre_session for each level to allow signing with the correct musig coefficient later. Additionally we should make sure that musig_pubkey_tweak_add also correctly works on the individual levels.

2. secp256k1_musig_session_init gets a new argument, n_layers. Instead of providing a single pre_session, you provide an array of n_layers-many pre_sessions. Instead of signers being an array to signers, it's an array of n_layers-many pointers to signers arrays. n_signers would be an array of size n_layers. Simlarly, my_index will also an array of n_layers. We can also provide a new init function to not make the existing function more complicated than it is already.

3. Every known signer presents a single nonce commitment as before. The difference is that a nonce commitment can either be opened with a nonce or with a list of more nonce commitments. For example, in a MuSig for (A and (B and C)), B and C exchange their nonce commitments hash(R_B) and hash(R_C). Then they combine their commitments into hash(hash(R_B), hash(R_C)) and send that to Alice. Later they reveal their tree of nonces R_B and R_C such that Alice can verify the commitment. The only changes for this code-wise is that set_nonce now gets a tree of nonce commitments and we need to decide how exactly to encode that. H/T to @roconnor for the tree commitment idea (also "If you do this, be sure to use tags so there is no ambiguity about whether you are hashing a nonce versus hashing a set of commitments.")

This is probably a silly question, but how does one go about determining the scratch space size necessary? I'm trying to consume secp256k1_schnorrsig_verify_batch but can't find any documentation on how to determine the appropriate scratch space size.

The ECDH module in secp256k(-zkp) is used in a few places to build ECIES-style public-key encryption. We could offer a module for this.

I'm using the library to implement my own module.

However when I use &ctx->ecmult_gen_ctx in my main_impl.h, the compiler complains with Incomplete definition of type 'struct secp256k1_context_struct'.

I notice the secp256k1_context_struct struct was defined in secp256k1.c file, so all struct member should be invisible to other files, but I notice other main_impl.h file, they also just include secp256k1.h not .c file, and they just work fine. Why it build succeed?

What's the magic here?

Issue

I cannot determine where rand' becomes rand as per the musig2-bip:

Let ''rand'' be the byte-wise xor of ''sk'' and ''hash<sub>MuSig/aux</sub>(rand')''

I imagine the transformation would take place in secp256k1_nonce_function_musig.

Assumptions

• The musig implementation found here follows musig2-bip.
• The session_id32 parameter is equivalent to the rand' parameter found in musig2-bip.

https://api.travis-ci.org/v3/job/474955336/log.txt and https://api.travis-ci.org/v3/job/474955338/log.txt respectively

Key sections:

make[4]: Entering directory '/home/travis/build/ElementsProject/elements/build/bitcoin-i686-w64-mingw32/src/secp256k1'
  CC       src/bench_verify.o
  CC       src/bench_sign.o
  CC       src/bench_internal-bench_internal.o
  CC       src/bench_ecmult-bench_ecmult.o
  CC       src/tests-tests.o
In file included from src/secp256k1.c:9:0,
                 from src/tests.c:17:
src/modules/rangeproof/tests_impl.h: In function ‘test_rangeproof_fixed_vectors’:
src/modules/rangeproof/tests_impl.h:667:9: warning: passing argument 2 of ‘secp256k1_rangeproof_verify’ from incompatible pointer type [-Wincompatible-pointer-types]
         &min_value_1, &max_value_1,
         ^
src/util.h:40:39: note: in definition of macro ‘EXPECT’
 #define EXPECT(x,c) __builtin_expect((x),(c))
                                       ^
src/modules/rangeproof/tests_impl.h:665:5: note: in expansion of macro ‘CHECK’
     CHECK(secp256k1_rangeproof_verify(
     ^~~~~
In file included from src/secp256k1.c:626:0,
                 from src/tests.c:17:
src/modules/rangeproof/main_impl.h:255:5: note: expected ‘uint64_t * {aka long long unsigned int *}’ but argument is of type ‘size_t * {aka unsigned int *}’
 int secp256k1_rangeproof_verify(const secp256k1_context* ctx, uint64_t *min_value, uint64_t *max_value,
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from src/secp256k1.c:9:0,
                 from src/tests.c:17:
src/modules/rangeproof/tests_impl.h:667:23: warning: passing argument 3 of ‘secp256k1_rangeproof_verify’ from incompatible pointer type [-Wincompatible-pointer-types]
         &min_value_1, &max_value_1,
                       ^
src/util.h:40:39: note: in definition of macro ‘EXPECT’
 #define EXPECT(x,c) __builtin_expect((x),(c))
                                       ^
src/modules/rangeproof/tests_impl.h:665:5: note: in expansion of macro ‘CHECK’
     CHECK(secp256k1_rangeproof_verify(
     ^~~~~
In file included from src/secp256k1.c:626:0,
                 from src/tests.c:17:
src/modules/rangeproof/main_impl.h:255:5: note: expected ‘uint64_t * {aka long long unsigned int *}’ but argument is of type ‘size_t * {aka unsigned int *}’
 int secp256k1_rangeproof_verify(const secp256k1_context* ctx, uint64_t *min_value, uint64_t *max_value,
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  CC       src/exhaustive_tests-tests_exhaustive.o
  CC       src/bench_recover.o
  CC       src/bench_generator.o
  CC       src/bench_rangeproof.o
  CC       src/bench_whitelist.o
  CCLD     bench_verify.exe
  CCLD     bench_sign.exe
  CCLD     bench_internal.exe
  CCLD     bench_ecmult.exe
  CCLD     bench_recover.exe
  CCLD     bench_generator.exe
  CCLD     bench_rangeproof.exe
  CCLD     bench_whitelist.exe
  CCLD     exhaustive_tests.exe
  CCLD     tests.exe
make  check-TESTS
make[5]: Entering directory '/home/travis/build/ElementsProject/elements/build/bitcoin-i686-w64-mingw32/src/secp256k1'
make[6]: Entering directory '/home/travis/build/ElementsProject/elements/build/bitcoin-i686-w64-mingw32/src/secp256k1'
PASS: exhaustive_tests.exe
FAIL: tests.exe
========================================
   libsecp256k1 0.1: ./test-suite.log
========================================

# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests
===========

test count = 64

random seed = 70d70b000a5a188bb73a4cb95772b1d1

src/modules/rangeproof/tests_impl.h:672: test condition failed: secp256k1_rangeproof_verify( ctx, &min_value_1, &max_value_1, &pc, vector_1, sizeof(vector_1), NULL, 0, secp256k1_generator_h )

FAIL tests.exe (exit status: 3)

I want to use musig api in my program. I run the following commands:
./autogen.sh
./configure --enable-experimental --enable-module-schnorrsig --enable-module-musig
make
sudo make install
Then,the headfiles are in /usr/local/include directory,libsecp256k1.a is in /usr/local/lib directory.
I include the main_impl.h in my program,but I meet the problem of "invalid use of incomplete typedef ‘secp256k1_context'","unknown type name ‘secp256k1_scalar’"and so on .What else should I do?

I'm writing some CFFI Python bindings to the musig module and when doing so, I got the following error:

generating cffi module 'build/temp.macosx-11-x86_64-3.9/_libsecp256k1.c'
already up-to-date
building '_libsecp256k1' extension
clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -DCFFI_ENABLE_RECOVERY -I/usr/local/include -I/usr/local/opt/[email protected]/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/[email protected]/Frameworks/Python.framework/Versions/3.9/include/python3.9 -Ibuild/temp.macosx-11-x86_64-3.9/include -I/Users/martijndevos/Documents/coincurve/build/temp.macosx-11-x86_64-3.9/include -c build/temp.macosx-11-x86_64-3.9/_libsecp256k1.c -o build/temp.macosx-11-x86_64-3.9/build/temp.macosx-11-x86_64-3.9/_libsecp256k1.o
In file included from build/temp.macosx-11-x86_64-3.9/_libsecp256k1.c:574:
build/temp.macosx-11-x86_64-3.9/include/secp256k1_musig.h:244:178: error: '__nonnull__' attribute parameter 1 is out of bounds
) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4) SECP256K1_ARG_NONNULL(5) SECP256K1_ARG_NONNULL(7) SECP256K1_ARG_NONNULL(8) SECP256K1_ARG_NONNULL(11);
                                                                                                                                                                                 ^                     ~~
build/temp.macosx-11-x86_64-3.9/include/secp256k1.h:167:54: note: expanded from macro 'SECP256K1_ARG_NONNULL'
#  define SECP256K1_ARG_NONNULL(_x)  __attribute__ ((__nonnull__(_x)))
                                                     ^           ~~
1 error generated.
error: command '/usr/bin/clang' failed with exit code 1

The error seems to originate from this line. I'm not entirely sure, but I suspect that the SECP256K1_ARG_NONNULL(11) is wrong since the secp256k1_musig_session_init function only has ten parameters (given that they start counting parameter indices from 1). Changing this to SECP256K1_ARG_NONNULL(10) seems to fix the compilation issue, although I'm not sure if this is the proper fix.

The library already has an API for sign-to-contract signature tweaks for ECDSA, but not BIP-340 Schnorrs. This issue is to colect a feedback on the best way of its implementation before I will start work on a PR.

To build with ECDH and RANGEPROOF do I need to pass any flags into the build steps on the README or....?

Thanks
Frank

The musig nonce function looks as follows:

static void secp256k1_nonce_function_musig(secp256k1_scalar *k, const unsigned char *session_id, const unsigned char *key32, const unsigned char *msg32, const unsigned char *agg_pk, const unsigned char *extra_input32) {

There's a chance that if this nonce function is accidentally called twice with the same argument values, the argument pointers store different addresses. Thus, we could hash these locations like this:

secp256k1_sha256_write(&sha, (unsigned char *)&session_id, sizeof(session_id));

However, it should be possible to test the nonce function without this, to make sure that different values are sufficient to produce a different hash.

This idea was originally brought up by @elichai.

I have a few questions about the compilation of the project...

After running autogen and configure with the custom flags, at that point is it possible to compile the project without using the newly generated makefile (aka use directly the gcc command) or something like that.

I'm trying also to compile the project from xcode because I have the need to use this code in a swift library... the main problems encountered with the compilation from xcode are wrong includes in the files. I'm not an expert on AutoMake, but from what I have understood, all the includes are managed by automake, is there a way to do it manually?

I found that functions secp256k1_pedersen_context_initialize and secp256k1_rangeproof_context_initialize declared in /include/secp256k1_rangeproof.h have no implementations.
Is it true, that it is unnecessary to additionaly initialize context?

Libsecp256k1 provides an interface for operations on curve secp256k1. However, following the principle "Be difficult to use insecurely", only a specific API which directly describes operands was exposed. For instance, instead of functions for sum and multiply by scalars on curve points, only specific functions for sum and multiplications for public keys were made available.

However, during development the number of objects which inherently are points on curve has been growing and presently there are public keys, pedersen commitments and generators.

Our application (leer) requires (de)serialization for curve points independent of the nature of those points (we are developing a virtual machine where stack may contain curve points and has native opcodes for curve operations). Besides that, such functionality is required by libsecp256k1 modules by themselves: rangeproof module uses its own point serialization format https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/rangeproof/rangeproof_impl.h#L54 .

Hence it looks expedient to provide API for point (de)serialization as well as for bidirectional casting between points and other objects with specific purposes (that are inherently points) .

Chosing of header byte

Currently there are these rules for headers byte.
Header bytes 0b00000000,0b00000001,0b00000110 and 0b00000111 are reserved for special form of public keys for historical compatibility with bitcoin code.
For other object:

• Lowest bit always encodes whether y-coordinate of point is odd or even.
• 0b0000001x header is used for public keys
• 0b0000101x header is used for generators
• 0b0000100x header is used for pedersen commitments

Since point object is a uniting type, and there will probably be other specific objects which represent points in the future, it is pertinent to use a distinctive header, such as 0b1000000x or 0b1111111x.

When I read the musig2 paper, I noticed that the coefficient of second_pk can be 1, and second_pk is defined as the second smallest public key (e.g., the lexicographic) of the public keys

Then I started reading the source code and found that the way to determine second_pk is to test if the pk is equal to the first pk.

    if (secp256k1_memcmp_var(pubkeys[0], pubkeys[i], sizeof(*pubkeys[0])) != 0) {
        ecmult_data.second_pk_x = pt.x;
        break;
    }

This confuses me, does it mean that pubkeys copy second_pk into the first place when they are initialized? But when I read the tests I found that it was simply a matter of initialising the two public keys. And it seems like second_pk_x in this case would be 0?

I'm sorry if I've missed anything, and I'd be grateful if you could clarify my confusion!

update:

Apologies for getting the code wrong, comparing results that are not equal to 0 means they are different...

Does libsecp256k1-zkp offer a straightforward way to produce Schnorr adaptor signatures? I see that it has an API for ECDSA adaptor signatures, and that the Musig2 API has an "adaptor" aspect, but I'm interested in simply creating basic adaptor signatures that can be used with BIP-340, and I don't see a clear way to do this.

• Add tweaking (#167).
• Add reference code (#166).
• Try to avoid O(n²) algorithm for finding of second unique key
• Add more test vectors (in particular, test vectors that result in failure).
• Add proper design and motivation section.
  • Mention that sorting the keys is optional and why.
• Improve nonce derivation.
  • As specified right now, if the output of the RNG used as the secret nonce ever repeats, the secret key leaks immediately. It is possible to (slightly) reduce the possibility of nonce reuse by deriving the secret nonce from the RNG output, aggregate public key and message.
  • Mention "counter mode" nonce derivation, i.e. deriving from secret key and non-repeating counter.
  • Add BIP 340-like sidechannel resistance.
  • Explain deterministic nonce derivation 2-of-2 nonce example.
• Post BIP draft to bitcoin-dev mailing list.

We're using this repository as a submodule in trezor-firmware and we are bound the secp256k1-zkp branch. We are currently locked to commit 9ecd8bf, but this commit is not in the git tree anymore. Try clean clone and check out this commit:

git clone [email protected]:ElementsProject/secp256k1-zkp.git
git checkout 9ecd8bf38a77a97b44e8c830b286c65051f2f707
fatal: reference is not a tree: 9ecd8bf38a77a97b44e8c830b286c65051f2f707

It seems to me someone forced-push into this branch removing any reference to this commit. Is that correct?

1. Please do not force push to this branch
2. Which commit should we use? What is the new corresponding one?

IIRC that's a remnant of the time when secp256k1-zkp was rebased on upstream. But I think it's confusing now.

The function secp256k1_ec_privkey_negate does not clear a copied secret key after negation.

If the array size is smaller than n_keys there is an out of bounds read in whitelist_sign and whitelist_verify. Either it must be clearly stated in the documentation that before whitelist_verify the caller must check that the length of the online and offline arrays are equal to secp256k1_whitelist_signature_n_keys(sig). Or both functions need additional arguments for the sizes of the online and offline key arrays to do that check inside the function.

As of now secp256k1-zkp builds successfully when the MuSig module is enabled, though when trying to use it there are two problems:

1 - the module is missing the extern header/footer, so it must be externed manually - not sure if this is intentional since the module is experimental, but other experimental modules like schnorrsig do include this.

2 - On line 272, the last ARG_NONNULL flag does not match the function definition (args 1-3 must be non-null, not 1-2 & 4). This results in this error when building a project that includes secp256k1-zkp built with the musig module:

secp256k1-zkp/.libs/include/secp256k1.h:153:70: error: nonnull argument references non-pointer operand (argument 1, operand 4)
define SECP256K1_ARG_NONNULL(_x) attribute ((nonnull(_x)))
^
secp256k1-zkp/.libs/include/secp256k1_musig.h:272:53: note: in expansion of macro ‘SECP256K1_ARG_NONNULL’
) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(4);
^~~~~~~~~~~~~~~~~~~~~

I've fixed this by just changing the 4 to a 3 on that line.

Is there a way to use this code in java?

Is anyone working on, or considering adding VRF support to secp256k1-zkp?

There is a fork of libsecp at https://github.com/aergoio/secp256k1-vrf that implements it. (/cc by @aergoio @kroggen)

from: README.md#verifiable-random-function-vrf:

This library has an implementation of an ECVRF based on the IETF draft 05 using the secp256k1 curve, SHA256 as hash function and try-and-increment as hash to curve method (cipher suite SECP256K1_SHA256_TAI). The cipher suite code used is 0xFE for compatibility with other implementations.

It was implemented as a fork because the parent library does not export the required functions.

There are many interesting use case for VRFs (Verifiable Random Functions [original paper]), but for our @BlockchainCommons roadmap, we would like to see use it in a similar way that CONIKS [pdf], Key Transparency [design doc] [slides] & Kademilia [paper] use them for private commitments. We can't use Schnorr signatures as they are do not guarantee uniqueness of the signature because of the random nonce requirements (sidenote: @sipa does Musig-DN qualify as a VRF?).

Other uses for VRFs are: random oracles, non-interactive lottery systems, updatable zero-knowledge databases, Resettable zero-knowledge proofs, L2 e-cash, rotatable Decentralized Identifiers (DIDs), and more.

Our challenge is that we also want to support MUSIG2 now and FROST when it gets finished here, but likely before they will likely be merged into the upstream master. We don't want to have to support 2 forks of the secp256k1 upstream master, so would really like to see VRFs in THIS fork. We don't want to support draft-irtf-cfrg-vrf-11 because it is 25519, not curve secp256k1.

/cc @jesseposner @wolfmcnally @kanzure @maaku

Some other related links:

• What is the difference between signatures and VRF? | Stack-Exchange Cryptography
• CONIKS vs Key Transparency vs Certificate Transparency vs Blockchains | okTurtles Blog

Any chance we could see zkp adding to its roadmap SecQ curve support (swap n & p and test various optimizations and side-channel issues caused by the swap) followed by bulletproofs in SecQ?

See BlockchainCommons/Community#71 (comment)

@jonasnick told me to post this for visibility. Invented originally by @ajtowns because he was chagrined by my current solution to the problem at hand.

First, a bit of motivation.

In ln-symmetry(eltoo) channels I have sketched out and implemented as well as other channel constructions, there is a desire to keep channel updates at least in the two party case to half a round trip. Alice sends an update with a signature, and Bob can immediately forward any HTLCs required without delay. This improves latency, and simplifies the channel state machine.

These types of channels have two stages of presigned transactions, in the ln-symmetry case, we have two symmetric transactions per channel update:

1. update transaction, which are posted during the contention period
2. settlement transaction, which is posted after a relative timeout when update transactions cease to be posted

If Alice wants to send an update to Bob, she cannot send both a signature for the update and settlement transactions, since Bob could take the update transaction to chain, and withhold a signature for the follow-up settlement transaction. The safe course is to send the settlement signature first, wait for Bob to hand his update signature, then respond with her update signature, increasing the RTT to 1.5 instead of 0.5 RTT.

Here's an alternative approach using adaptor signatures that I believe achieves the original goal:

1. Update transaction has a 2-of-2 OP_CSA script, one key for Alice, one for Bob
2. Settlement transaction has a 2-party MuSig key
3. Nonces are preshared always
4. Alice generates a channel state update, generating unsigned update and settlement transactions
5. Alice calls secp256k1_musig_partial_simulate on the settlement transaction, which allows Alice to "simulate" partial signing routine for any public key in the session, outputting s*G rather than s since that can be computed for any party.
6. Alice then uses s*G as the adaptor for her update transaction's signature (1-of-1 MuSig session?)
7. Alice sends channel update along with her partial sig and presignature to Bob
8. If Bob goes to chain with the update transaction, he leaks his s, allowing Alice to complete the settlement transaction.

TL;DR: the adapter signature is a fair exchange of Alice's update signature and Bob's settlement partial signature.

See discussion here

Is there a well defined way to open a Pedersen commitment? I was hoping to find a function that I could pass the commitment and blind value to and it would return the commitment value, but I did not find such a function. Do point me in the right direction if you can.

Thanks!

The readme should reference that experimental features can be enabled for example via

./configure --enable-experimental --enable-module-schnorrsig --enable-module-musig

or more general ./configure --help

I'm porting BlindTransaction() function from Elements Core (https://github.com/ElementsProject/elements/blob/5467be3b16f014b371ecf6bced73be0254755cfa/src/blind.cpp#L193) to python, using ctypes FFI.
(I want https://github.com/Simplexum/python-bitcointx to be able to blind/unblind Elements sidechain txs on its own).

working with secp256k1_* functions was easy until now, but I hit a problem with secp256k1_surjectionproof_initialize. It requires a reference to secp256k1_surjectionproof struct, but the size of this structure may change for different platforms or versions. This means that the only way to reliably use surjectionproof functions is to call them from C/C++ code that can include the header file for a particular version of the library. And then you probably want to ship this library with your code, or link with it statically, or else there might be size mismatch if you use the code compiled with old-version secp256k1_surjectionproof.h but have new-version dynamic library installed.

The calling code that do not have access to relevant header file might try to just alloc a big buffer and hope that the structure will not ever be bigger than that. But that is unclean and unreliable.

the library could export the size of the structure as a global symbol
const int SECP256K1_SURJECTIONPROOF_RAW_SIZE = sizeof(secp256k1_surjectionproof);

or export a function that will return this size, or somehow expose this size in another way (but of course the caller itself should allocate the buffer of the specified size, not the library)

I understand that secp256k1-zkp is work in progress, and to be used on one's own risk. But it would be excellent to be able to use it (on my own risk) from python :-)

There is this line in combine_pubkeys:

ARG_CHECK(n_pubkeys > 0);

Given that it doesn't make sense for n_pubkeys to be 1, I was wondering if this check should be changed to be "> 1"?

Hi, Can someone suggest how to build libseckp256k1.a using this github code? I need libsecp256k1.a with architecture armv7,armv7s and arm64.Thanks.

https://github.com/ElementsProject/secp256k1-zkp/blob/43dd1f4fe732268734f0b4efd8e99ea4ff1e49a1/include/secp256k1_rangeproof.h#L240
In particular, size values > 4096 are undefined behavior but also shorter array won't work properly.

API

• Make aborts identifiable, so that signers can be blamed if they send garbage. In particular, this means updating the partial_sig_agg failure case to return the index of the offending sig.
• Allow signing variable length messages (i.e. with length != 32) as proposed for BIP-340 by adding an msglen argument to all function currently only taking an msg32.
• Support sign-to-contract (@dr-orlovsky)
• Consider adding a flag to the secp256k1_musig_partial_sign interface. If true it would do a partial signature verification before returning (H/T @robot-dreams).i
• Consider treating pre_sig64 argument of musig_adapt and musig_extract_adaptor as secret (for constant-timeness test)

Internal

• musig_nonce_gen currently rejects session_id32=0 if there's no seckey. This check could be stronger and reject weak entropy counters, for example in a endianness-independent way by checking that the middle 16-bytes are not all 0 (H/T @robot-dreams).
• Unify handling of cryptographically unreachable code, i.e., always use VERIFY_CHECK instead of returning 0.
• Keep up to date with test vectors from the MuSig spec (#211)
• Strengthen nonce generation by feeding addresses of arguments to the function (#152)
• Reenable efficient multiexponentiation (ecmult_multi) in pubkey_agg when confidence in its implementation is higher.
• Fix TODO items: "use multiexp to compute -s*G + e*mu*pubkey + aggnonce[0] + b*aggnonce[1]" and "Cache mu".

We have posted an advance reading for a designshop on the topic of "Rebooting the Web of Trust" which talks about moving over to Schnorr signatures, and specifically refers to this library. Can someone involved in this library read over and post issues there about any inaccuracies, or other comments about using Schnorr signatures under secp256k1? Thanks!

https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/topics-and-advance-readings/Schnorr-Signatures--An-Overview.md

-- Christopher Allen

Now that libsecp256k1 has release tags, it would be good to rebase on those.

Hi

I would have done a PR, but I was not sure how you handle rebasing.

Anyway, it would be great to rebase this on upstream. I am particularly interested in pulling in this change: bitcoin-core/secp256k1#337, so I can skip some custom commits on my fork of libwally-core.

See ElementsProject/elements#540

We generate a group signature, built w/ N individual secret/public keys.
We then sign a transaction using the group signature.
We then send a message, including the group key & signature in a payload.

We're now at the receiver of this message.
We have the group key, the group signature.
We also have 1 / N of those original, individual public keys.
How can we prove that 1 key is part of the group key?
How can we prove that 1 key is part of the group signature?
If not, why not?

Thanks for a lovely library :)

Just trying to get up and running, the following:

// Preamble omited

secp256k1_pedersen_commit(none, &commit, blind, val, secp256k1_generator_h);

compiles OK but I get the undefined reference error noted in subject when linking.

Setting it to NULL compiles and links OK.

Is that generator not meant to be used?

This is ridiculous. We should use an unsigned char* like we do for the rangeporofs and every other variable-length large object in this library.

See discussion here.

https://github.com/ElementsProject/secp256k1-zkp/blob/725d895fc54cf82da1c2a9c69048656405da556d/include/secp256k1_ecdsa_s2c.h#L100

Is anyone working on implementing this protocol for Schnorr signatures? Since Taproot is now active, it would be great to have this available to implement in hardware wallets.

@jonasnick @apoelstra

We have secp256k1_clz64_var in our code and a while ago (safegcd) upstream has added a more polished secp256k1_ctz64_var and secp256k1_ctz32_var. We should probably make these consistent.

@apoelstra

I should have mentioned that in the original post: when I build the library here is my flags in the ./configure step:

./configure --enable-module-generator --enable-experimental --enable-module-ecdh --enable-module-rangeproof

Also, I am linking against the shared library. When doing a readelf -Ws libsecp256k1.so the const doesn't show, as expected given the link error I am getting.

I also tried secp256k1-mw (bulletproofs branch) using these flags: --enable-module-generator --enable-experimental --enable-module-ecdh --enable-module-commitment --enable-module-rangeproof

In that case, neither secp256k1_generator_const_h or secp256k1_generator_const_g are resolved at link time.

This work is epic, thanks to everyone involved.

In order to wide up its application areas, it would be very much useful to add functionality so that a signer in a group can later identify himself as the real signer with 0% false positive rate.

This opens the door for many use cases, for example assigning data to public ring signatures that is later granted to the signer that reveals himself as the real singer. This requires:

• functionality to create such a "link-able" ring-signature (with a special flag in the command of the request maybe, if the default is "unlikable")
• functionality to verify the claim of a signer that later reveals himself

From the old How to leak a secret original paper:
"However, there may be cases in which the signer himself wants to have the option of later proving his authorship of the anonymized email (e.g., if he is successful in toppling the disgraced Prime Minister). Yet another possibility is that the signer A wants to initially use {A,B,C} as the list of possible signers, but later prove that C is not the real signer. There is a simple way to implement these options, by choosing the xi values for the nonsigners in a pseudorandom rather than truly random way. To show that C is not the author, A publishes the seed which pseudorandomly generated the part of the signature associated with C. To prove that A is the signer, A can reveal a single seed which was used to generate all the nonsigners’ parts of the signature.The signer A cannot misuse this technique to prove that he is not the signer since his part is computed rather than generated, and is extremely unlikely to have a corresponding seed. Note that these modified versions can guarantee only computational anonymity, since a powerful adversary can search for such proofs of non authorship and use them to expose the signer."

Is anyone currently working on a 2P-ECDSA module, or know of a current implementation using libsecp256k1?

If not, I'm interested in implementing one.

I looked at at src/modules/whitelist/whitelist.md and at secp256k1_whitelist_compute_keys_and_message(), to better understand how whitelisting is done.
https://github.com/ElementsProject/secp256k1-zkp/blob/1bbad3a04be42edb1dda16c9eab24345b1f63c5d/src/modules/whitelist/whitelist_impl.h#L120

I noticed that the case when H + Q addition results in infinity is not treated as an error. This might be by design, but it seems to me that this might result in a potential problem. My understanding may be wrong or incomplete, and this might be a non-issue, but I would like to know what am I missing. Does the following looks correct ?

If an attacker knows the online key P, he can whitelist garbage keys, but he can also whtielist -Q.

The formula: L_j = P_j + H(W + Q_j)(W + Q_j). If W = -Q, the sum W + Q will be infinity.

If the sum is infinity, secp256k1_whitelist_tweak_pubkey() will not do anything, and only online key will be stored in keys[i] (if a is infinity, secp256k1_gej_add_ge_var(&r, &a, &b, NULL) sets r = b).

Attacker will sign with just online key to whitelist sending funds to -Q, but the fact that the funds are still accessible with -Q will not be obvious, and if the participant does not know about this possibility, this could result in eventual leak of Q: participant might think that funds were sent to garbage address, the funds controlled by Q would be preceived as 'lost', and the security measures for Q might be lessened.

Of course if participant knows and checks for this, there would be no problem. But wouldn't it be better to return 0 from secp256k1_whitelist_compute_keys_and_message() if the result of W+Q is infinity ? Or maybe just document this possibility so participants will know to check for it.