I'd like to be added to the queue. Happy to go after Cody unless there are
others already lined up.


---
*Matt Drollette*

On Sat, Nov 11, 2017 at 4:31 PM, Sean Bowe via zapps-wg <
zapps...@lists.z.cash.foundation> wrote:

> Thanks Jared! Awesome! I've verified the contribution and put your
> response file up on the transcript repository.
>
> Can you submit a PR here to fill in more information (including a
> signed attestation):
> https://github.com/ZcashFoundation/powersoftau-
> attestations/tree/master/0003
>
> Cody Burns is going next.
>
> Sean
>
> On Sat, Nov 11, 2017 at 1:35 PM, Jared Tobin <ja...@jtobin.io> wrote:
> >
> > Hi all, here's my report:
> >
> > Powers of Tau Operational Writeup
> > =================================
> >
> > Round: 3
> > Date: 2017-11-12
> > Name: Jared Tobin
> > Location: Auckland, NZ
> >
> > Challenge:
> > e712fa22f1d027a0b4ce3ef698f26d5cab07c3380e4c24a479a914c85617
> fd1a2960b386cceb5c94718979010a1b7ed8b6145da872f0744e06503bd664fe7283
> > Response:
> > cb48afb82ab4c476ae741633c3eb6643e7700dc7b2b4701af91e3cc93227
> 0b96c375e5f3a5c20c96fac6c9b40a5bba6c956d66f223f090c545c277aa05427757
> >
> > Preparation Steps
> > =================
> >
> > Being somewhat pressed for time and hardware, I recruited several
> > geographically-distributed volunteers that I know well and trust
> > completely to help me out.  In the end, the following volunteers were
> > able to get back to me in time:
> >
> > * Shawn Tobin (RSA Canada)
> > * Fredrik Harryson (Parity Technologies)
> > * Jason Forbes (Kraken Sonar Systems)
> >
> > I set up a private Keybase team with the above volunteers, distributed
> > the challenge to them over KBFS, and gave them instructions over the
> > team chat on how to proceed.  Each was to add entropy and compute the
> > response locally using whatever mechanisms they preferred (report not
> > required), then return their response/hash pairs to me over KBFS.  Each
> > member was to use the code in Sean's powersoftau repository as of commit
> > 9e1553c437183540392a7231d0788318a19b18a3 to perform the computation.
> >
> > Procedure
> > =========
> >
> > I computed a response locally in rather mundane fashion using rustc
> > 1.21.0 on an early-2015 model Macbook Air running Sierra.  Eventually
> > the volunteers managed to upload their response/hash pairs to KBFS, and
> > I randomly selected one of the resulting four responses to submit for my
> > piece of the MPC.
> >
> > I uploaded the resulting response via the handy app Sean provided me
> with.
> >
> > Side channel defences
> > =====================
> >
> > I used broad geographical distribution and randomness to mitigate the
> > possibility of successful side channel attacks.  Shawn was located in
> > Vancouver, Canada, Fredrik was located in Malmö, Sweden, and Jason was
> > located in St. John's, Canada.
> >
> > I selected the response to upload by pre-determining a correspondence
> > between names and numbers, and then walking outside and asking the first
> > stranger I saw to pick a number between one and four.
> >
> > - jared
> >
> >
> > On Sat, Nov 11, 2017 at 12:25:33AM +0000, Jason Davies via zapps-wg
> wrote:
> >> Hi all,
> >>
> >> Here is my report:
> >>
> >> Powers of Tau Operational Writeup
> >> =================================
> >>
> >> Round: 2
> >> Date: 2017-11-10
> >> Name: Jason Davies
> >> Location: London, UK
> >>
> >> Challenge: 467bc84f6eb98ff956eaf12a1b7ef4dc0aff1093c7a0d5c1dfbdb85bbfff
> b20a43965d0daefee3fec6c1a47af69100e117b44b74371824ac8af1e33b6f91add5
> >> Response: 2f728af894524f55bda7a3e2c2e2db6a57a992811e90ed57456d62aead51
> 06cdc5c97c86532d14b5185cc74d169f1b0c2c0ef1e582231ffa7936da55047c0cb2
> >>
> >> Preparation Steps
> >> =================
> >>
> >> Git repository: https://github.com/ebfull/powersoftau
> >> Commit hash: 9e1553c437183540392a7231d0788318a19b18a3
> >> Compiler: rustc 1.23.0-nightly (d6b06c63a 2017-11-09)
> >> Build: cargo build --release --features=u128-support
> >> b2sum(./target/release/compute): be42f68b07c5c857bb6561a9ac2967
> d671ef412a71c87c2fb31776a6ab38c756736de66e554553021e129ecab4
> 5d922092873df8b71bd9a775ec05f189485198
> >>
> >> I used a brand new 16GB USB stick and loaded 
> >> ubuntu-17.04-desktop-amd64.iso;
> b2sum: 6a1c975b25b4e7f2dbf4fda84fe8b5de3ed6f4532b8c4f17e533ed11a0a8
> b5b9ad9fb83e8e4b89447c3a427be73f77a5f7c71b7f733fcc4bebf346e9c5c0de43.
> >>
> >> I reformatted a second brand new 16GB USB stick to ext4, then copied the
> >> `challenge` file and the `target/release/compute` binary.
> >>
> >> Sidechannel Defences
> >> ====================
> >>
> >> First of all, I lined a large cardboard box with aluminium foil in
> order to
> >> make a rudimentary faraday cage.  Then, I assembled an airgap compute
> node
> >> using some relatively cheap parts, putting them all inside the box:
> >>
> >> * Motherboard: Asus H81 Pro BTC (no radio, bluetooth or speakers AFAIK)
> >> * CPU: Intel G1840
> >> * Ram: 2x cheap 1GB sticks
> >> * PSU: EVGA SuperNOVA 1300 G2
> >> * Monitor: old Dell TFT display
> >> * Keyboard: generic USB keyboard
> >>
> >> No other peripherals or cables were connected.  I placed the compute
> node in my
> >> cellar (~6ft below ground level) and I remained with the node during
> the entire
> >> time it was computing, without using any other devices in the vicinity
> (no
> >> mobile phone etc.)  The only cables coming out of the box were the two
> power
> >> cables, one for the PSU and one for the monitor.
> >>
> >> Image: https://pbs.twimg.com/media/DOT55KUXUAEV44-.jpg:large
> >>
> >> Procedure
> >> =========
> >>
> >> I booted the node, with "Try Ubuntu" (Live CD mode).  Then, I inserted
> the
> >> challenge USB stick and ran `./compute` in the USB media directory,
> entering
> >> some additional entropy as requested by typing randomly on the
> keyboard.  The
> >> box lid was only partially opened to allow use of the keyboard and to
> view the
> >> monitor at this point.  After 60 minutes had passed, I looked inside
> the lid
> >> and saw that the computation had completed, so I wrote down the BLAKE2b
> hash,
> >> and unmounted and removed the USB stick, and then powered the node down.
> >>
> >> Postprocessing
> >> ==============
> >>
> >> I took the USB stick and transferred the response file to my laptop,
> and then
> >> uploaded it using the laptop to S3 via Sean Bowe's transcript site.
> >>
> >> I did not destroy the compute node but I'm unlikely to use it or plug
> it in for
> >> some time.
> >> --
> >> Jason Davies, https://www.jasondavies.com
> >>
> >
> >
> >>
> >>
> >> > On 10 Nov 2017, at 22:11, Sean Bowe via zapps-wg
> <zapps...@lists.z.cash.foundation> wrote:
> >> >
> >> > 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)
> >> >> ce00f2100dd876fdff8dd824f55307bcb72d724f29ff20b9e0760f3a65e5
> 588a65eaed57cbc61697111ae1f4cc7da2e62a85311c2ae683a041fb872b891c68dc
> >> >> Response:
> >> >> 15729e0edc4201dc5ee6241437d926f614cb4214ff1b9c6fbd73daf40163
> 9f7a4238cf04bc94edac9f2ad037003daab9a4408ba7c62a4413dc2a0ddd683bd719
> >> >> ./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:
> >> >> 9059a0a64f5021c36df630ca48ac40674862b2fea14f4843ff2150256b95
> 162ac4d6d1621d2dd3f5d0d1c604ad8e581c0ff449d2449140380eab075a9b83c960
> >> >> ./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:
> >> >>>
> >> >>> ce00f2100dd876fdff8dd824f55307bcb72d724f29ff20b9e0760f3a65e5
> 588a65eaed57cbc61697111ae1f4cc7da2e62a85311c2ae683a041fb872b891c68dc
> >> >>>
> >> >>> 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