Introduce first version of ECDSA adaptor signature spec #114
Conversation
|
@benthecarman That was intentional. I tried to put references in [ ]. I haven't put a list of references at the bottom yet. I find just putting links annoying because then you have to figure out what word to put them on. Perhaps now is the time to make a convention for how to do this? |
|
@LLFourn trying to make your test pass: First vector, I can't parse the adaptor sig, It seems to fail here nkohen/secp256k1@3383459#diff-af7e1bf67c999123aba5f3f14622539c6ac8eb6ce92676ccaa1f5c418bed6574R45 Basically the first FE seems to be too big? |
|
What is the |
|
@NicolasDorier This code doesn't conform the spec yet. From the spec:
So it can parsed like To make the code conform I think there are only a few small changes:
needs to be instead: secp256k1_sha256_initialize_tagged(&sha, algo16, algo16_len(algo16)); # this needs to be the tag from the spec instead
secp256k1_dleq_hash_point(&sha, p1);
secp256k1_dleq_hash_point(&sha, gen2);
secp256k1_dleq_hash_point(&sha, p2);
secp256k1_dleq_hash_point(&sha, r1);
secp256k1_dleq_hash_point(&sha, r2);
I think that's all you'll need to change to get the verification test vectors to pass. After that I would go over the signing code and make sure the nonces are produced in a way that at least approximates the spec (everything that is recommended to be hashed to produce a nonce it hashed). @jesseposner has offered to do the work to make the above happen.
I meant the public signing key. I've changed the test vector to use this instead. |
|
does that mean that all tests vectors that we finally all pass from @nkohen need to follow this new spec? |
|
@NicolasDorier Yes. Any end-to-end test vectors need to be updated. My main goal with this spec is to separate the DLEQ proof from the ECDSA adaptor (since it might be independently useful). Obviously another approach could be just to spec what's in the branch but I thought it would be better to come up with something a little more thought out and easy to justify (not that the all the justifications are in the document yet). |
|
Not to say the spec is frozen, but at this stage several implementation follow it, and breaking it without good reason (like security fix/features) will just waste everybody's time. Both those tests and the specs must be in sync. If somebody come to this repository, and implement DLC starting by this document, most of his effort won't help him to implement the DLC specification. (Formatting data correctly is as much time consuming as monkey porting the math) So in the worst case: A developer come here, pass the tests, then find out that it is not following the spec, update his code to follow the spec, but then the unit tests he did to pass this vector won't pass anymore. |
For |
My feeling was when I was asked to do this specification the expectation was that there would be breaking changes to what exists in the branch. The purpose of this spec is to do the DLEQ proof something like how it a generalized framework for expressing these kinds of proofs would specify it (I am working on such a framework). Perhaps this is premature but I think it's better to be as close as possible to "textbook".
Well spotted. It seems that points are not being SECG encoded but rather being prefixed with a 0 or a 1 instead of the usual 2 or 3. |
|
I think breaking changes here are okay/good to have, but I will note that I do not plan to actually make any other part of the DLC spec or implementations conform to this new ECDSA adaptor spec until there is a stable branch on secp256k1-zkp that we can all use. Once such a branch exists, it should be significantly easier for everyone to switch to using that branch instead of my temporary one and I have code to auto-regenerate the test vectors (which other impls should be able to pass, simply by using the new crypto library) |
ECDSA-adaptor.md
Outdated
| ## Adaptor Signatures | ||
|
|
||
| *Adaptor signatures* are an efficient form of verifiable signature encryption that can achieve our required structure. | ||
| Given a anticipated signature `Y` we may encrypt a signature (for the purposes of this document, an ECDSA signature) under `Y` such that once a party learns the discrete logarithm of `Y` they can decrypt it and get a valid ECDSA signature. |
There was a problem hiding this comment.
nit: Y isn't a signature per se, bur rather a commitment to a signature, or a public key derived from an anticipated signature
There was a problem hiding this comment.
The name I use for the commitment/public key is "anticipated signature". It came from Tadge: https://diyhpl.us/wiki/transcripts/discreet-log-contracts/.
I think I am using it correctly here.
There was a problem hiding this comment.
From that transcript, it looks like it's ambiguous as to whether "Anticipated Signature" refers to Y or just the scheme in general. However, my point might be a little pedantic and I don't think it matters all that much, and I can see the utility of having a shorthand like "Anticipated Signature."
Co-authored-by: Jesse Posner <[email protected]>
|
I implemented the spec in Python here and it runs and passes all the test vectors. |
|
Here's my secp branch that updates the implementation to match the spec: https://github.com/jesseposner/secp256k1/tree/jp/ecdsa-adaptor-sigs This commit has the diff showing the changes that are required to match the spec: bitcoin-core/secp256k1@3246e15 I've also added the first test vector and it passes: bitcoin-core/secp256k1@a8ae212 I will be continuing to work on that branch to finish the TODO items and add more test coverage. draft PR: BlockstreamResearch/secp256k1-zkp#117 |
In this case, this spec should conform to the current spec, then we should just change this spec and the old spec later. |
|
@LLFourn I've updated BlockstreamResearch/secp256k1-zkp#117 with the new changes and test vectors. |
Co-authored-by: Jesse Posner <[email protected]>
|
@jesseposner Thanks. Will review soon. |
|
@LLFourn I'm going to be rebasing to clean up the commits soon in the PR, which should make it much easier to review as a whole (but more difficult to isolate the changes from the original branch). |
|
I've cleaned up the commits and it should be a lot easier to review now by proceeding commit by commit. I'm giving it one last round of polish today and then I will fill out the PR description and move it out of draft mode. |
This commit adds proving and verification functions for discrete logarithm equality. From the spec (discreetlogcontracts/dlcspecs#114): "As part of the ECDSA adaptor signature a proof of discrete logarithm equality must be provided. This is a proof that the discrete logarithm of some X to the standard base G is the same as the discrete logarithm of some Z to the base Y. This proof can be constructed by using equality composition on two Sigma protocols proving knowledge of the discrete logarithm between both pairs of points. In other words the prover proves knowledge of a such that X = a * G and b such that Z = b * Y and that a = b. We make the resulting Sigma protocol non-interactive by applying the Fiat-Shamir transformation with SHA256 as the challenge hash."
This commit adds proving and verification functions for discrete logarithm equality. From the spec (discreetlogcontracts/dlcspecs#114): "As part of the ECDSA adaptor signature a proof of discrete logarithm equality must be provided. This is a proof that the discrete logarithm of some X to the standard base G is the same as the discrete logarithm of some Z to the base Y. This proof can be constructed by using equality composition on two Sigma protocols proving knowledge of the discrete logarithm between both pairs of points. In other words the prover proves knowledge of a such that X = a * G and b such that Z = b * Y and that a = b. We make the resulting Sigma protocol non-interactive by applying the Fiat-Shamir transformation with SHA256 as the challenge hash."
This commit adds proving and verification functions for discrete logarithm equality. From the spec (discreetlogcontracts/dlcspecs#114): "As part of the ECDSA adaptor signature a proof of discrete logarithm equality must be provided. This is a proof that the discrete logarithm of some X to the standard base G is the same as the discrete logarithm of some Z to the base Y. This proof can be constructed by using equality composition on two Sigma protocols proving knowledge of the discrete logarithm between both pairs of points. In other words the prover proves knowledge of a such that X = a * G and b such that Z = b * Y and that a = b. We make the resulting Sigma protocol non-interactive by applying the Fiat-Shamir transformation with SHA256 as the challenge hash."
|
@LLFourn The PR is now stable and out of draft mode. The only thing that should change at this point is updates to respond to comments and potentially adding some additional test cases. |
This commit adds proving and verification functions for discrete logarithm equality. From the spec (discreetlogcontracts/dlcspecs#114): "As part of the ECDSA adaptor signature a proof of discrete logarithm equality must be provided. This is a proof that the discrete logarithm of some X to the standard base G is the same as the discrete logarithm of some Z to the base Y. This proof can be constructed by using equality composition on two Sigma protocols proving knowledge of the discrete logarithm between both pairs of points. In other words the prover proves knowledge of a such that X = a * G and b such that Z = b * Y and that a = b. We make the resulting Sigma protocol non-interactive by applying the Fiat-Shamir transformation with SHA256 as the challenge hash."
This commit adds proving and verification functions for discrete logarithm equality. From the spec (discreetlogcontracts/dlcspecs#114): "As part of the ECDSA adaptor signature a proof of discrete logarithm equality must be provided. This is a proof that the discrete logarithm of some X to the standard base G is the same as the discrete logarithm of some Z to the base Y. This proof can be constructed by using equality composition on two Sigma protocols proving knowledge of the discrete logarithm between both pairs of points. In other words the prover proves knowledge of a such that X = a * G and b such that Z = b * Y and that a = b. We make the resulting Sigma protocol non-interactive by applying the Fiat-Shamir transformation with SHA256 as the challenge hash."
This commit adds proving and verification functions for discrete logarithm equality. From the spec (discreetlogcontracts/dlcspecs#114): "As part of the ECDSA adaptor signature a proof of discrete logarithm equality must be provided. This is a proof that the discrete logarithm of some X to the standard base G is the same as the discrete logarithm of some Z to the base Y. This proof can be constructed by using equality composition on two Sigma protocols proving knowledge of the discrete logarithm between both pairs of points. In other words the prover proves knowledge of a such that X = a * G and b such that Z = b * Y and that a = b. We make the resulting Sigma protocol non-interactive by applying the Fiat-Shamir transformation with SHA256 as the challenge hash."
This commit adds proving and verification functions for discrete logarithm equality. From the spec (discreetlogcontracts/dlcspecs#114): "As part of the ECDSA adaptor signature a proof of discrete logarithm equality must be provided. This is a proof that the discrete logarithm of some X to the standard base G is the same as the discrete logarithm of some Z to the base Y. This proof can be constructed by using equality composition on two Sigma protocols proving knowledge of the discrete logarithm between both pairs of points. In other words the prover proves knowledge of a such that X = a * G and b such that Z = b * Y and that a = b. We make the resulting Sigma protocol non-interactive by applying the Fiat-Shamir transformation with SHA256 as the challenge hash."
|
This document is ready. As I said before I think it would be good if all spectests were updated to align with this one so all the documents are consistent. |
|
A reminder that this should be merged (or not). I am waiting for the spec to be stable before continuing any work on DLC, so as long as this is in "maybe merge, maybe not", I am on the sideline. :/ |
This is a draft of the ECDSA adaptor signature spec.
Feel free to post an early review on structure, format and design decisions.
See if you can find any mistakes in the algorithms.
TODO:
Fixes #50