[zapps-wg] Powers of Tau Ceremony Proposal
Sean Bowe
sean at z.cash
Sat Nov 11 14:01:24 EST 2017
Kobi Gurkan (from QED-it) wishes to go after cody. I'll double-check later.
On Sat, Nov 11, 2017 at 4:12 AM, cody burns <cody.w.burns at gmail.com> wrote:
> I will go after the unnamed party.
>
>
> On Sat, Nov 11, 2017 at 3:21 AM Sean Bowe via zapps-wg
> <zapps-wg at 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 <jason at 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-wg at 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 <soc1024 at 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 <sean at 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 <soc1024 at 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-wg at 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
>> >
>> >
More information about the zapps-wg
mailing list