Thanks Matt, that's really cool. I've verified your contribution and
it's now in the transcript.

I've put some minimal information here about your contribution:

https://github.com/ZcashFoundation/powersoftau-attestations/tree/master/0004

Would you mind submitting a PR (along with a signed attestation if you can)?

Kobi wished to go next but won't be available for a little while. Then
someone else (who hasn't posted "i'm going next" on the mailing list
yet) indicated they would like to go.

Sean

On Sun, Nov 12, 2017 at 7:05 PM, Matt Drollette via zapps-wg
<zapps...@lists.z.cash.foundation> wrote:
> Powers of Tau Operational writeup
> =================================
>
> Round: 4
> Date: 2017-11-12
> Name: Matt Drollette
> Location: Dallas, Texas
>
> Challenge:
> 9b80a6140d42bd234fbe43eea542296df8bcb4c834ea5d0a16a194964b72fd11a6ee9efae9364eb74f99bb4471e7fb4ac9cb2bb3aa8e03fe22c6279a104f367b
>
> Response:
> 53b6dc5a91d04c3000037cbc4f6f4bc9e9daf9448a41f997746b156c643a84f481c49bf7dadce388b3c9e8c147f94c12c5dacb5350a54e112ee45f57ffd8f34c
>
>
> Preparation steps
> =================
>
> I noticed most participants were taking on a significant responsibility in
> securing their own hardware and infrastructure in order to participate in
> this
> process. I took a different approach in that I wanted to leverage the
> security
> work done by people much more qualified than myself. I therefore used Google
> Cloud Platform to generate my response (https://cloud.google.com/security/).
>
> First, I created a new GCP project under a gmail account not belonging to
> any
> other organizations and configured with Advanced Protection
> (https://landing.google.com/advancedprotection/).
>
> Next, I created a Compute Instance with an external IP to serve as the
> bastion
> for external network access and collecting the responses.
>
> I then created three compute instances in three different regions having
> three
> different instance types. Each instance was running Google's
> Container-Optimized
> OS (https://cloud.google.com/container-optimized-os/docs/concepts/security)
> and
> did not have an external IP address.
>
> Next, on the bastion I built a Docker image containing the compute binary
> built
> from https://github.com/ebfull/powersoftau at commit
> 9e1553c437183540392a7231d0788318a19b18a3
>
> I downloaded the challenge file to the bastion host and then transferred it
> to
> each compute instance along with the compute Docker image via scp over the
> internal network. I verified the sha256 hash of each challenge and compute
> binary on each instance and then began the computation using different
> random
> inputs for each process.
>
> ```
> bastion
> 480c27457c467362a1d3dd3d972844e1230abde236f4d153d80938ab7ec19f7d  challenge
> 4952c8b4e8d3e75ded8fafa28bffb4082e26732f17ec8176c7cd26591adaf93e
> powersoftau.docker
> 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a
> /powersoftau/target/x86_64-unknown-linux-musl/release/compute
>
> instance-1
> 480c27457c467362a1d3dd3d972844e1230abde236f4d153d80938ab7ec19f7d  challenge
> 4952c8b4e8d3e75ded8fafa28bffb4082e26732f17ec8176c7cd26591adaf93e
> powersoftau.docker
> 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a
> /powersoftau/target/x86_64-unknown-linux-musl/release/compute
>
> instance-2
> 480c27457c467362a1d3dd3d972844e1230abde236f4d153d80938ab7ec19f7d  challenge
> 4952c8b4e8d3e75ded8fafa28bffb4082e26732f17ec8176c7cd26591adaf93e
> powersoftau.docker
> 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a
> /powersoftau/target/x86_64-unknown-linux-musl/release/compute
>
> instance-3
> 480c27457c467362a1d3dd3d972844e1230abde236f4d153d80938ab7ec19f7d  challenge
> 4952c8b4e8d3e75ded8fafa28bffb4082e26732f17ec8176c7cd26591adaf93e
> powersoftau.docker
> 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a
> /powersoftau/target/x86_64-unknown-linux-musl/release/compute
> ```
>
>
> Sidechannel defenses
> ====================
>
> The scale of GCP and sheer number of compute instances makes a targeted
> sidechannel attack practically impossible. Also, Google takes great care in
> preventing known attack methods
> (https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html).
>
> In addition to Google's security practices, I also ran multiple compute
> instances in multiple regions computing responses on the same challenge file
> at
> the same time. I then selected only one of these responses at random to
> submit
> and destroyed the others. I do not know which node computed the response
> that I
> submitted.
>
>
> Postprocessing
> ==============
>
> Once the responses were computed on each instance, I recorded the hashes of
> each
> response file and transferred all 3 files back to the bastion host and
> deleted
> the 3 compute instances. I did not record which instance computed which
> response. I then selected one of the 3 response files by dice roll and
> submitted
> its hash to the mailing list and uploaded the file to S3. I then deleted the
> bastion compute instance and deleted the entire GCP project.
>
>
> ---
> Matt Drollette
>
> On Sun, Nov 12, 2017 at 4:45 PM, Sean Bowe <s...@z.cash> wrote:
>>
>> Unfortunately, Cody had some problems and needs to reschedule. Also,
>> Kobi doesn't have time right now, so it's Matt's turn!
>>
>> Sean
>>
>> On Sun, Nov 12, 2017 at 12:40 PM, Sean Bowe <s...@z.cash> wrote:
>> > Cody is going but I haven't heard back in a while. In let's say about
>> > five hours if we still don't hear back we'll move on to Kobi and
>> > reschedule with Cody later. Matt can go after that! :)
>> >
>> > Sean
>> >
>> > On Sat, Nov 11, 2017 at 8:24 PM, Matt Drollette via zapps-wg
>> > <zapps...@lists.z.cash.foundation> wrote:
>> >> 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:
>> >>> >
>> >>> >
>> >>> > e712fa22f1d027a0b4ce3ef698f26d5cab07c3380e4c24a479a914c85617fd1a2960b386cceb5c94718979010a1b7ed8b6145da872f0744e06503bd664fe7283
>> >>> > Response:
>> >>> >
>> >>> >
>> >>> > cb48afb82ab4c476ae741633c3eb6643e7700dc7b2b4701af91e3cc932270b96c375e5f3a5c20c96fac6c9b40a5bba6c956d66f223f090c545c277aa05427757
>> >>> >
>> >>> > 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:
>> >>> >>
>> >>> >> 467bc84f6eb98ff956eaf12a1b7ef4dc0aff1093c7a0d5c1dfbdb85bbfffb20a43965d0daefee3fec6c1a47af69100e117b44b74371824ac8af1e33b6f91add5
>> >>> >> Response:
>> >>> >>
>> >>> >> 2f728af894524f55bda7a3e2c2e2db6a57a992811e90ed57456d62aead5106cdc5c97c86532d14b5185cc74d169f1b0c2c0ef1e582231ffa7936da55047c0cb2
>> >>> >>
>> >>> >> 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):
>> >>> >>
>> >>> >> be42f68b07c5c857bb6561a9ac2967d671ef412a71c87c2fb31776a6ab38c756736de66e554553021e129ecab45d922092873df8b71bd9a775ec05f189485198
>> >>> >>
>> >>> >> I used a brand new 16GB USB stick and loaded
>> >>> >> ubuntu-17.04-desktop-amd64.iso; b2sum:
>> >>> >>
>> >>> >> 6a1c975b25b4e7f2dbf4fda84fe8b5de3ed6f4532b8c4f17e533ed11a0a8b5b9ad9fb83e8e4b89447c3a427be73f77a5f7c71b7f733fcc4bebf346e9c5c0de43.
>> >>> >>
>> >>> >> 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)
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> 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