Powers of Tau Operational writeup
=================================

Round: 4
Date: 2017-11-12
Name: Matt Drollette
Location: Dallas, Texas

Challenge:
9b80a6140d42bd234fbe43eea542296df8bcb4c834ea5d0a16a194964b72
fd11a6ee9efae9364eb74f99bb4471e7fb4ac9cb2bb3aa8e03fe22c6279a104f367b

Response:
53b6dc5a91d04c3000037cbc4f6f4bc9e9daf9448a41f997746b156c643a
84f481c49bf7dadce388b3c9e8c147f94c12c5dacb5350a54e112ee45f57ffd8f34c


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:
> >>> >
> >>> > 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):
> >>> >> be42f68b07c5c857bb6561a9ac2967d671ef412a71c87c2fb31776a6ab38
> c756736de66e554553021e129ecab45d922092873df8b71bd9a775ec05f189485198
> >>> >>
> >>> >> 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