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