Thanks Andrew! That's a great start.

Now it's Jason Davies' turn.

The entire transcript will appear here throughout the process:

https://powersoftau-transcript.s3-us-west-2.amazonaws.com/index.html

We can make a more formal announcement once we're in the groove and
everything looks good. We're getting a repo up with attestations soon
also.

Sean

On Fri, Nov 10, 2017 at 12:53 PM, Andrew Miller <soc1...@illinois.edu> wrote:
> OK, I'll go first. Below is my report:
>
> Powers of Tau Operational writeup
> =================================
> Round: 1
> Date: 2011-11-10
> Name: Andrew Miller
> Location: Champaign, Illinois
>
> Challenge: (genesis)
> ce00f2100dd876fdff8dd824f55307bcb72d724f29ff20b9e0760f3a65e5588a65eaed57cbc61697111ae1f4cc7da2e62a85311c2ae683a041fb872b891c68dc
> Response:
> 15729e0edc4201dc5ee6241437d926f614cb4214ff1b9c6fbd73daf401639f7a4238cf04bc94edac9f2ad037003daab9a4408ba7c62a4413dc2a0ddd683bd719
> ./response-2017-11-10-amiller
>
> Preparation steps
> =================
> I used Sean’s powersoftau rust repo, commit
> 9e1553c437183540392a7231d0788318a19b18a3
>
> I followed instructions online for building portable rust binaries,
> and so I ran
> ```
> cargo build --target=x86_64-unknown-linux-musl --release
> --features=u128-support --bin=compute
> ```
>
> Compiler: rustc 1.23.0-nightly (02004ef78 2017-11-08)
>
> I copied the resulting binary to a freshly formatted USB stick I had.
>
> b2sum:
> 9059a0a64f5021c36df630ca48ac40674862b2fea14f4843ff2150256b95162ac4d6d1621d2dd3f5d0d1c604ad8e581c0ff449d2449140380eab075a9b83c960
> ./target/x86_64-unknown-linux-musl/release/compute
>
> I also rummaged through my shelf of several USB sticks, and found one
> that happened to be a Linux Mint 18 USB bootable disk, so I used that
> for my operating system.
>
> Sidechannel defenses
> ====================
> I used an airgap compute node, a Dell Inspiron that I’ve had for about
> a year now (Actually this is a computer I bought last year for
> dress-rehearsals in the Zcash Sprout param generation ceremony).
>
> I unplugged all the computer’s hard drives, and detached its
> wifi/bluetooth radios. I booted the computer from the Linux Mint
> livecd usb stick, and then also copied the binaries into RAM. The
> compute node was located in my bedroom, and I attended it for the ~1hr
> duration of the compute process.
>
> Image: https://pbs.twimg.com/media/DOSZz4FXkAEKC7N.jpg:large
>
> Postprocessing
> ==============
> After compute was finished, I took a cell phone picture of the blake2b
> hash of the response. I then copied the response file to the USB stick
> containing the binaries, and then I unplugged the compute node. Using
> my personal laptop, I posted the blake2b hash to the #mpc chat and
> uploaded the response file to s3.
>
> The repsonse file is hosted here for now, though I expect we'll
> mirror it elsewhere later:
> https://s3.amazonaws.com/socrates1024_a/response-2017-11-10-amiller
>
> I did not destroy the compute node and do plan to use it again,
> although I'm going to leave it unplugged for several days.
>
> On Wed, Nov 8, 2017 at 10:19 PM, Sean Bowe <s...@z.cash> wrote:
>> 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
>
>
>
> --
> Andrew Miller
> University of Illinois at Urbana-Champaign

Reply via email to