The Dark Side of Zero Knowledge: Masking the initial setup in Zk-SNARK
blog.smartdec.net
blog.smartdec.net
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.
Your reply here is highly misleading, even lying by omission.
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.
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].
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.
https://medium.com/coinmonks/zk-starks-create-verifiable-tru...
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?
"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.
Not sure why this isn't mentioned in the article.
> This article is about the fact that there could be a backdoor, whose absence can only be proven by revealing all participants' toxic waste.
This is incorrect, as stated above. Instead of revealing their toxic waste, we reveal proofs-of-knowledge so we can use pairings to ensure the parameters encode the circuit correctly.
I still learned something "new" from the article, I was only aware of the ceremony issue that "everbody knows" of.
https://old.reddit.com/r/MoneroMining/comments/6fixnr/monero...
...
> [Monero] was a fork of Bytecoin designed to not have the 80% premine. But its initial developer either didn't know, didn't care, or wanted to profit from the de-optimized hashing. That initial developer was pretty quickly given the boot by the community, and in came an unrelated group of developers who took it over---who were, as far as I can tell, completely unaware of the deoptimization. So things sat there for a few weeks in the same state as Bytecoin.
...
> This was a brilliantly designed proof-of-work function targeting the strengths of modern CPUs -- native AES encryption and fast 64 bit multipliers -- tuned to use a scratchpad exactly the size of the per-core L3 cache on Intel CPUs (about 2MB) that someone then wrapped in such a thick blanket of crap it was nearly unrecognizable until you started jumping in, tearing it apart, and putting it back together again.
https://da-data.blogspot.com/2014/08/minting-money-with-mone...
If so, how did other types of crypto in the early adoption years deal with these types of issues?