Skip to content
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

Expose ring signatures including verifiable anonymity revocation #109

Open
gits7r opened this issue Nov 25, 2020 · 4 comments · May be fixed by #110
Open

Expose ring signatures including verifiable anonymity revocation #109

gits7r opened this issue Nov 25, 2020 · 4 comments · May be fixed by #110

Comments

@gits7r
Copy link

gits7r commented Nov 25, 2020

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."

@real-or-random
Copy link
Collaborator

I don't understand. This library does not offer ring signatures, so we cannot make them linkable.

Or what are you referring to?

@apoelstra
Copy link
Contributor

We should expose the ring signatures :).

@real-or-random real-or-random changed the title Add feature for the real signer to later reveal himself and to verify such claims with 100% probability Expose ring signatures including verifiable anonymity revocation Nov 25, 2020
@apoelstra
Copy link
Contributor

@gits7r to be clear, the term "linkable" is a term of art which referrs to the ability to determine whether two ring signatures were produced by the same person, without revealing who that person was and without requiring they take any action or publish any proofs.

The property you want is "anonymity revocation", i.e. the ability for a signer to reveal themselves after the fact, by publishing a proof (and if they delete this proof they can never reveal themselves no matter what else happens).

@gits7r
Copy link
Author

gits7r commented Nov 28, 2020

That is correct, I misused the term "linkable" in this context - the property needed is "anonymity revocation" by publishing a proof that is only available to the signer (until he decides to revoke his anonymity of course).

@real-or-random sorry for not being clear. This great feature came to light in a very interesting and productive talk with @apoelstra (thanks again so much for the great idea!) and it provides an easy and secure way to entirely mitigate censorship-type threat models in centralized or semi-centralized systems related to Bitcoin with 0 trade-offs to decentralized systems or anything else in the ecosystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants