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
construct it.)

The initial challenge file has BLAKE2b hash:

ce00f2100dd876fdff8dd824f55307bcb72d724f29ff20b9e0760f3a65e5588a65eaed57cbc61697111ae1f4cc7da2e62a85311c2ae683a041fb872b891c68dc

It doesn't hurt to post hashes of everything though. Hash all the things.

Sean

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?
>
> Cheers,
>
> 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
>> parameters.
>>
>> https://eprint.iacr.org/2017/1050
>>
>> 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
>> compromised.
>>
>> 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:
>>
>> https://github.com/ebfull/powersoftau
>>
>> 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

Reply via email to