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