All is verified and mirrored so far! Thanks! I've invited someone else to be next, but I'm not sure if they wanted me to identify them publicly before they were finished.
Sean On Fri, Nov 10, 2017 at 5:25 PM, Jason Davies <ja...@jasondavies.com> 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 > >
