-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Schnorr signatures #212
Conversation
Rebased. |
Rebased. |
TODO: use context to store the batch multipliers |
This is awesome, as Schnorr signatures are dead easy to understand. (just curious) |
They have not been added yet :) |
a446e0f
to
0ab0b47
Compare
Separated batch validation into a separate branch. This pull request should be usable. Question for reviewers:
|
af94dbd
to
71d3db6
Compare
@gmaxwell Added multiparty signing API. |
I'm a bit concerned about using Edit: Oh, I'm being stupid, in Schnorr the messagehash has Edit2: No, I was right the first time :). Regardless of message-hash, two signatures with the same key/nonce represent two equations in two unknowns. |
secp256k1_fe_normalize(&Ra.y); | ||
if (secp256k1_fe_is_odd(&Ra.y)) { | ||
secp256k1_scalar_negate(&n, &n); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a comment above this block explaining that forcing the parity of y allows batch verification (and is part of the definition of Schnorr signatures), at the cost of making inversion-free validation impossible?
@apoelstra You're not being stupid, I think. k is the secret nonce, r is R's x coordinate, m is the message, x is the private key, h = H(m || r). x and k are unknown to an attacker. ECDSA: s_ecdsa * k = m + r * x Or: So: So: |
Fixed the problem listed above by xoring the name of the signature algorithm into the message. Added a rationale for the choice of full R validation and implicit even y. |
6fcf944
to
4ff8567
Compare
Rebased on top of #269 and passing the signature algorithm name into the PRNG, to avoid the issue @apoelstra found above. |
@theuni Feel like writing a patch for that? I'm not sure I follow, but I
think it would be nice to have a clean extension mechanism (the two ECDH
implementations would also fit there).
|
Hmm, I don't know about exposing implementation details in the headers. I
jist thought: if you enable the Schnorr module, the schnorr header file is
installed, otherwise it isn't... no preprocessing needed.
|
@sipa There's no way to tell if it's installed without preprocessing though, you'd just "#include secp256k1_schnorr.h" and hope for the best. I took a quick stab at it here: https://github.com/theuni/secp256k1/tree/212 If you decide to go this route, since the config details become part of the api, we'd need to namespace/cleanup their values. Of course, you could also just take a subset of this and only expose the module details, leaving the rest as it is. |
Well, duh. But how is that different from doing an include #include <gmp.h>
and hoping that that libgmp is installed?
I would really like to avoid having the public API expose implementation
details. I'd rather just see them as two separate APIs that happen to be
implemented in the same library.
|
@sipa Because when you 'apt-get install libgmp', you know you can "#include <gmp.h>". But if I apt-get install libsecp256k1, I have no idea what it contains. Using the existence of a file is shaky at best, as it'd be very easy to hit the system file in /usr/include when building against another or a cross build. No problem if you don't want to expose implementation details, but I still think the user needs some explicit way to know what optional apis are available. |
@theuni What would an application do with the knowledge that an extra API is available? If it needs it, the build will fail (at link time or at compile time), if it doesn't, it doesn't care... |
@sipa Just as libsecp256k1 falls back to internal implementations if gmp isn't usable, an application could do the same if libsecp256k1_foo feature isn't available. But it's really not worth the argument, and certainly not worth holding up this PR. |
@theuni Right, there may be optional behaviour. But that's something you'd typically check at configure time, which can try to compile. I guess the fundamental question I have is: why can you trust that the contents of a file on your disk corresponds with the library installed, when you can't trust the presence of the file corresponding to it. |
@theuni Ok, one other question: when you don't specify --enable-module-schnorr, the schnorr files don't get included in "make dist" I think. Is that something you'd typically want? |
@sipa all files needed to build all configs should be included in the dist tarball. From a quick check, that's currently working as expected:
|
Before merge can you add bench_schnorr_verify to .gitignore? |
Also I think you need to change the last line of |
Rebased. |
@apoelstra Nits addressed. |
Thanks! Tested ACK. |
a5a66c7 Add support for custom EC-Schnorr-SHA256 signatures (Pieter Wuille)
is there anyway to use schnorr combined pubkey in a standard p2sh script? |
I believe schnor is planned for the first segwit upgrade. It will require a new checksig opcode and a soft fork. |
well a new schnorr_sig opcode would make this all too easy :) |
@jl777 Unsure what you mean. Schnorr signatures are not compatible with ECDSA at all, and needs different signing and verification code. Further, Bitcoin scripts that do not use any digital signature are inherently insecure (if there is no secret information being verified, miners can steal all the coins once they see a spend). Thus, indeed, the only way is using a new opcode. |
it would be combined with a normal signature: OP_HASH160 hash(sharedsecret) OP_EQUALVERIFY (normal_pubkey) OP_CHECKSIG granted the protection from just the normal_pubkey OP_CHECKSIG isnt as much as full verification, but if there was a way to offchain calculate a schnorr sig based sharedsecret equivalent, then I think it would work. problem is I dont see a way to know ahead of time any value that a group signature would create. The combined pubkey appears to be a standard pubkey, but without any normal privkey. Maybe there is a way for a set of nodes to create onetime use keypairs and somehow create a combined privkey that can be used with the combined pubkey. |
You seem to be describing a normal signature with a hashlocked secret. Where does Schnorr come in? |
the schnorr would come in offchain, so a group can do larger scale MofN between themselves using shamir's shared secret that each of the participants have and release only if they are satisfied, comes really close to being the hashlocked secret to use. The problem is we cant have any single node to know the secret that is being shamir'ed. maybe some sort of oblivious transfer method could be used, but this is getting to where I am not comfortable as I dont know of any C libraries for that. So the constraints are that each member of the group can directly run the schnorr lib, they can coordinate and precalculate any sort of magic value, but ultimately a hashlocked bitcoin tx needs to be used |
No description provided.