-
Notifications
You must be signed in to change notification settings - Fork 209
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
Comments
I don't understand. This library does not offer ring signatures, so we cannot make them linkable. Or what are you referring to? |
We should expose the ring signatures :). |
@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). |
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. |
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:
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."
The text was updated successfully, but these errors were encountered: