Zcash knew the problem of backdoor-able initial setup, they understood that it can raise serious doubts on the trustworthiness of their system, they even named the initial key material for setup as "cryptographic toxic waste". As an attempt to bring confidence to the setup ceremony, Zcash used a multiparty setup of 6 people, and invited prominent developers of the cryptocurrency community to participate. The setup was performed at each person's own undisclosed geolocation, and coordinated online. The rough idea was, if at least one participant during the setup was honest, properly destructed the secret, and wasn't hacked, the setup will be secure.
The prominent Bitcoin developer, Peter Todd was invited to participate, too. You can read his entertaining blogpost about the setup procedure at here.
The funny and alarming story is, after he finished the setup, he became increasingly suspicious about the security of the procedures, especially casted doubts on some technical problems that prevented reproducible build (!!!) of the setup programs. And he later had withdrawn his blogpost and all the claims of security altogether. To me, it's alarming, in the end, we'll never get solid security guarantees.
That's true of the original (Sprout) SNARK, but the newer (Sapling) SNARK used a much more scalable MPC ceremony, which they called Powers of Tau: https://z.cash.foundation/blog/powers-of-tau/
There was a public call for participation at the time, so if you wanted to be sure that the ceremony was not corrupted, you could just participate yourself.
For backwards compatibility, the Sprout SNARK can still be used, so if the original ceremony was compromised, an attacker could still create coins "out of thin air". But converting a Sprout account to a Sapling account requires making the amount public, so if the number of coins converted exceeded the intended currency supply, that would be detected. Worst case scenario, a hard fork could be arranged to disable the Sprout SNARK.
Note that the technical problems made it more complicated and messy to reproduce the build, but didn't outright prevent it. Mainly the executable binaries were reproducible, but other metadata in the disk image changed each time. https://github.com/zcash/mpc/issues/2
This discusses a weakness with all zero knowledge proofs which require a trusted setup.
Zero knowledge proofs which don’t require a trusted setup include BCCCGP[1], Bullet Proofs[2], ZKBOO++[3], Ligero[4], Hyrax[5], ZK-STARKs[6], and Aurora[7].
As the article states, but is a confusing in the title, this isn't a problem with all Zero Knowledge Protocols (ZKP) but is a problem with a specific ZKP, namely zk-Snarks.
You can do ZKPs without a trusted setup, they are less performant than zk-Snarks. It seems likely that in the next few years these performance problems will be overcome. Most people I've talked to in the field are very confident that protocols like zk-snarks can be done without trusted setup.
It looks like there's nothing new here, making the title clickbait-y. One of the first things anyone learns about Zcash is that there was a trusted ceremony.
"One of the first things anyone learns about Zcash" is that at least one of the ceremony's participants must be trusted to have securely destroyed his toxic waste.
This article is about the fact that there could be a backdoor, whose absence can only be proven by revealing all participants' toxic waste.
You'll note that these two things are at odds with each other.
This is an attempt to explain the details of the trusted ceremony, why it was needed, and what is being trusted.
I like that it describes two different levels of trust required — trust in both the destruction of the initial secrets and in the original formulation of the problem. Were both levels of trust established, in the case of ZCash?
No. Monero uses RingCT for transaction privacy. RingCT employs Borromean ring signatures, Pedersen Commitments and Bulletproofs (for range proofs). It does not use the zkSNARK construction. The Bulletproof (and the Pedersen Commitments) can be seen as another zero knowledge proof system.
Monero's backdoor was the development team releasing a severely weakened version of the mining app during the phase where 25% of the supply was minted, along with a production curve that released 80% of the supply in less than half the time of Bitcoins minting production time.
[+] [-] segfaultbuserr|7 years ago|reply
The prominent Bitcoin developer, Peter Todd was invited to participate, too. You can read his entertaining blogpost about the setup procedure at here.
https://web.archive.org/web/20161114214233/https://petertodd...
The funny and alarming story is, after he finished the setup, he became increasingly suspicious about the security of the procedures, especially casted doubts on some technical problems that prevented reproducible build (!!!) of the setup programs. And he later had withdrawn his blogpost and all the claims of security altogether. To me, it's alarming, in the end, we'll never get solid security guarantees.
[+] [-] dlubarov|7 years ago|reply
That's true of the original (Sprout) SNARK, but the newer (Sapling) SNARK used a much more scalable MPC ceremony, which they called Powers of Tau: https://z.cash.foundation/blog/powers-of-tau/
There was a public call for participation at the time, so if you wanted to be sure that the ceremony was not corrupted, you could just participate yourself.
For backwards compatibility, the Sprout SNARK can still be used, so if the original ceremony was compromised, an attacker could still create coins "out of thin air". But converting a Sprout account to a Sapling account requires making the amount public, so if the number of coins converted exceeded the intended currency supply, that would be detected. Worst case scenario, a hard fork could be arranged to disable the Sprout SNARK.
[+] [-] socrates1024|7 years ago|reply
[+] [-] RexetBlell|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] paulgerhardt|7 years ago|reply
Zero knowledge proofs which don’t require a trusted setup include BCCCGP[1], Bullet Proofs[2], ZKBOO++[3], Ligero[4], Hyrax[5], ZK-STARKs[6], and Aurora[7].
[1]https://eprint.iacr.org/2016/263.pdf
[2]https://eprint.iacr.org/2017/1066.pdf
[3] https://eprint.iacr.org/2017/279.pdf
[4] https://acmccs.github.io/papers/p2087-amesA.pdf
[5] https://eprint.iacr.org/2017/1132.pdf
[6] https://eprint.iacr.org/2018/046.pdf
[7] https://eprint.iacr.org/2018/828.pdf
To clear up confusion in the comments, the new ZCash release, sappling, used a trusted setup with 87 people up from the original six[8].
[8] https://z.cash/blog/completion-of-the-sapling-mpc/
[+] [-] EthanHeilman|7 years ago|reply
You can do ZKPs without a trusted setup, they are less performant than zk-Snarks. It seems likely that in the next few years these performance problems will be overcome. Most people I've talked to in the field are very confident that protocols like zk-snarks can be done without trusted setup.
[+] [-] scottlocklin|7 years ago|reply
https://medium.com/coinmonks/zk-starks-create-verifiable-tru...
[+] [-] cjbprime|7 years ago|reply
[+] [-] hendi_|7 years ago|reply
"One of the first things anyone learns about Zcash" is that at least one of the ceremony's participants must be trusted to have securely destroyed his toxic waste.
This article is about the fact that there could be a backdoor, whose absence can only be proven by revealing all participants' toxic waste.
You'll note that these two things are at odds with each other.
[+] [-] neolefty|7 years ago|reply
I like that it describes two different levels of trust required — trust in both the destruction of the initial secrets and in the original formulation of the problem. Were both levels of trust established, in the case of ZCash?
[+] [-] sschueller|7 years ago|reply
[+] [-] g45y45|7 years ago|reply
[+] [-] nosuchthing|7 years ago|reply
https://old.reddit.com/r/MoneroMining/comments/6fixnr/monero...
[+] [-] jMyles|7 years ago|reply
[+] [-] diafygi|7 years ago|reply
If so, how did other types of crypto in the early adoption years deal with these types of issues?
[+] [-] simonveith|7 years ago|reply
[deleted]