I will go after the unnamed party.
On Sat, Nov 11, 2017 at 3:21 AM Sean Bowe via zapps-wg <zapps...@lists.z.cash.foundation> wrote: > 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 > > > > >
