Note that the `response` file contains a hash of the `challenge` file
that was used as input for the compute tool. As a result, only the
hashes of the `response` files need to be published; a hash chain is
formed through all participants. The initial challenge file is
deterministic. (You can use the `new` tool on the repository to
The initial challenge file has BLAKE2b hash:
It doesn't hurt to post hashes of everything though. Hash all the things.
On Wed, Nov 8, 2017 at 4:51 PM, Andrew Miller <soc1...@illinois.edu> wrote:
> Thanks Sean!
> My idea is to use an ad hoc and publicly visible process. "Get in
> contact with [sean]" could be as simple as posting in public to this
> thread. Unless we're overrun by trolls, a public mailing list can be
> an informal way to agree on who goes next. Whoever posts and says "Me,
> me! I'd like to go next", should, by convention, go next. Any
> aberrations (parties taking too long or dropping out, posting invalid
> data, etc., can be dealt with as needed).
> I believe it's also the case that
> a) The "response" file from each person is roughly the same as the
> "challenge" file for the next participant, and
> b) The response/challenge files are safe to be published at any time,
> not private at all.
> So, by convention, we should post the hashes of those files here right
> away, and make a best effort to mirror them publicly (each one is like
> a gigabyte, I think).
> What does the initial challenge file consist of? Could you post the
> hash of it here?
> On Wed, Nov 8, 2017 at 3:04 PM, Sean Bowe via zapps-wg
> <zapps...@lists.z.cash.foundation> wrote:
>> Ariel Gabizon, Ian Miers and I have just published a new paper detailing a
>> multi-party computation (MPC) protocol for constructing zk-SNARK public
>> The highlights are:
>> * It allows for a single, gigantic ceremony to take place for all possible
>> zk-SNARK circuits within a given size bound. The results of this ceremony
>> are partial zk-SNARK parameters for the entire community. We call this
>> communal ceremony the Powers of Tau.
>> * If you want to use zk-SNARKs in your protocols, you still have to do an
>> MPC for your circuit. But because of the Powers of Tau ceremony, your
>> ceremony is much cheaper to perform and the costs per-participant scale
>> linearly with respect to the circuit complexity.
>> * The best part is that the Powers of Tau and these circuit-specific MPCs
>> can scale to hundreds/thousands of participants. As the number of
>> participants grows, it becomes unrealistic that all of them could be
>> So, let's do the Powers of Tau ceremony! The Zcash Foundation is excited to
>> participate in the process. The Zcash Company is particularly excited in
>> starting soon because we want to leverage it for our next MPC for the
>> Sapling upgrade of Zcash.
>> The MPC protocol for this ceremony only requires that one participant
>> successfully destroy the secret randomness they sample during their part. We
>> intend to give participants total flexibility in deciding how to
>> participate; we don't mind what software, hardware or OS you use.
>> I have written some Rust software for participants to run:
>> In order to simplify auditing, I won't be making any more changes to the
>> code unless absolutely necessary. You don't have to use this software, but
>> there are no alternative implementations at this time. I think it should be
>> feasible to write a C version of the code using the RELIC toolkit, which has
>> implemented BLS12-381. I am very confident in the Rust code, though, and I
>> believe in its stability/correctness.
>> I have some opinions about the ceremony:
>> 1. I disagree with processes that don't improve security of the ceremony.
>> Having a small surface area of code and process increases the chance that
>> bugs will be discovered by auditors because there are fewer things that can
>> go wrong. Remember that there is already quite a bit for the public to
>> check: the transcript correctness, the code correctness, the randomness
>> beacon, the cryptographic proof, code dependencies, etc.
>> 2. It needs to start soon so that it can be useful for the Sapling MPC.
>> 3. It needs to have lots of reputable participants by the time we start the
>> Sapling MPC.
>> Given the above, I would like to suggest that we start the ceremony now
>> using my existing code, which supports circuits up to 2^21 gates. This means
>> people would just get in contact with me if they want to participate and
>> I'll schedule them in. I'll try to prioritize reputable people, but I'll
>> allow pretty much anyone I have time to. Everything that I do is publicly
>> verifiable (there is a transcript at the end of the ceremony which people
>> can check).
>> Andrew Miller has a few interesting ideas for a more distributed process for
>> scheduling "who goes next" but there are some disadvantages and risks
>> involved IMO. In any case, the process can be changed later without
>> affecting anything, so I don't see a purpose in delaying the start of the
>> ceremony on such things.
>> I'd like to hear from others about this plan so we can begin soon!
>> Sean Bowe
>> Zcash Company
> Andrew Miller
> University of Illinois at Urbana-Champaign