Re: [zapps-wg] Sapling MPC!

2018-07-08 Thread Andrew Miller via zapps-wg
By "this page" I meant:
https://github.com/zcash-hackworks/sapling-mpc/wiki


On Sun, Jul 8, 2018, 6:00 PM Andrew Miller  wrote:

> Hey Ian, any chance we could have an update on how this process is going?
> I don't see any updates to this page since 20 days ago. How else can we
> follow along with the sapling MPC?
>
>
> On Tue, May 29, 2018, 12:38 PM Ian Munoz via zapps-wg
>  wrote:
>
>> Hey everyone,
>>
>> My name is Ian Munoz and I work for the Zcash Company. I'm helping to
>> coordinate the Sapling MPC.
>>
>> You can read the blog post here:
>>
>> https://blog.z.cash/sapling-mpc/
>>
>> You can see the current folks whom have participated here:
>>
>> https://github.com/zcash-hackworks/sapling-mpc/wiki
>>
>> We put together a little bit of automation to help folks to contribute.
>> Essentially once a participant has uploaded there contribution, the
>> verification of their contribution is kicked off automatically to help get
>> more participants in and to prevent any squashing of contributions.
>>
>> If you would like to participate and you haven't already e-mail: mpc at z
>> dot cash
>>
>> You can also reach out on this channel:
>> https://chat.zcashcommunity.com/channel/mpc
>>
>> Thanks!
>> -Ian Munoz
>>
>>


Re: [zapps-wg] Sapling MPC!

2018-07-08 Thread Andrew Miller via zapps-wg
Hey Ian, any chance we could have an update on how this process is going?
I don't see any updates to this page since 20 days ago. How else can we
follow along with the sapling MPC?


On Tue, May 29, 2018, 12:38 PM Ian Munoz via zapps-wg
 wrote:

> Hey everyone,
>
> My name is Ian Munoz and I work for the Zcash Company. I'm helping to
> coordinate the Sapling MPC.
>
> You can read the blog post here:
>
> https://blog.z.cash/sapling-mpc/
>
> You can see the current folks whom have participated here:
>
> https://github.com/zcash-hackworks/sapling-mpc/wiki
>
> We put together a little bit of automation to help folks to contribute.
> Essentially once a participant has uploaded there contribution, the
> verification of their contribution is kicked off automatically to help get
> more participants in and to prevent any squashing of contributions.
>
> If you would like to participate and you haven't already e-mail: mpc at z
> dot cash
>
> You can also reach out on this channel:
> https://chat.zcashcommunity.com/channel/mpc
>
> Thanks!
> -Ian Munoz
>
>


Re: [zapps-wg] Zkproofs.org standards workshop

2018-04-22 Thread Andrew Miller via zapps-wg
Hey Lucas, thanks for pointing this out, I've also found this to be a
missing part of C-S notation. Here's one more subtle reason to be explicit
about what are the public inputs. When you generate public parameters for a
snark scheme, some public values may be hardcoded in the circuit, while
others can be modified without changing the public parameters. Formally
speaking, the hardcoded parts define the "NP language", while the public
inputs define the "statement".

I like your suggestion. For signatures I mentioned earlier using the
bracket notation [m]. In LaTeX I have tried before using subscripts for
public inputs. So for example:
 SoK[m]_H{ (x): H = hash(x) }
But this looks pretty bad in ascii compared to your suggestion. Really
curious if others have preferences, I don't have a strong opinion here.


On Sun, Apr 22, 2018 at 10:21 AM, Lucas Vogelsang via zapps-wg <
zapps...@lists.z.cash.foundation> wrote:

> Andrew, I wanted to follow up on your proposal of formulating ZkPoKs. One
> thing that was a bit counter intuitive to your notation is the fact that
> while it's very clear what private inputs a snark has, the public inputs
> are not clearly designated. E.g.:
>
> ZkPoK{ (R1, R2): H1 = sha256(R1) and H2 = sha256(R2) and R1 = R2 ^ X }
>
> This example is simple enough that a) X is easy to spot and given it's
> name it's easy to deduct that this is probably not a constant but a public
> input. However if the snark gets longer, intermediary variables (just local
> to the snark) and public inputs are hard to discern. Perhaps it would be
> convenient to write it with the following syntax:
>
> ZkPoK{ W = {R1, R2}, I = {X}: H1 = sha256(R1) and H2 = sha256(R2) and R1 =
> R2 ^ X }
>
> Have you put any thought into this already? Comparing your notation to
> Izaak's pseudocode, I think there is a right time and place for both.
> Although perhaps by the time you're using your proposed syntax, Izaak, it
> might be easier to just write it in snarky, don't you agree?
>
> Lucas
>
> On Mon, Mar 26, 2018 at 6:10 PM, Izaak Meckler via zapps-wg <
> zapps...@lists.z.cash.foundation> wrote:
>
>> One application that I like: sending ads with a proof proving they were
>> generated by some algorithm that is known not to have access to personal
>> data.
>>
>> And I like that notation Andrew -- there is a sort of extension to it
>> (which is basically the idea of snarky) which involves not having to
>> declare all your witnesses up front. The main advantage over
>> the Camenisch-Stadler notation to my mind is modularity/abstraction. (For
>> example, you can factor out the idea of opening a commitment).
>>
>> This is a bit of a contrived example but to get the idea across,
>> "sumCommitmentsIsZero" proves that you know openings to a bunch of
>> commitments such that the openings sum to 0, say.
>>
>> def openCommitment(c):
>>   (value, nonce) = *exists* OpenCommitment(c);
>>   *assert* SHA256(value, nonce) = c;
>>   return value
>>
>> def sumCommitmentsIsZero(cs):
>>   *assert* sum(map cs (fun c -> openCommitment(c))) = 0
>>
>> (sometimes I call exists "request" instead.)
>>
>> If this sort of notation was widely used, people would probably know what
>> you meant when you wrote openCommitment as a function, and so you could
>> just write the second definition in communicating. There are a bunch of
>> other reusable abstractions that arise in zk-proof programming that we
>> could build up a shared vocabulary for as well to make communicating this
>> stuff easier.
>>
>> On Sat, Mar 24, 2018 at 4:05 PM, Andrew Miller via zapps-wg <
>> zapps...@lists.z.cash.foundation> wrote:
>>
>>> Lucas's post reminded me of something I wanted to post about:
>>> If there's one thing I'd like to take up the torch for and advocate as a
>>> standard, it's to use a conventional pseudocode for describing snark
>>> application ideas. What I have in mind is Camenisch-Stadler proof
>>> notation. It looks like this:
>>>
>>>  ZkPoK{ (witness):  Predicate(statement, witness) }
>>>
>>> The idea is that "witness" is the private witness, "statement" is
>>> public information that the verifier provides, and you replace
>>> "Predicate" with whatever pseudocode you want to check.
>>> Here are some examples:
>>>
>>> 1. Pay-to-Sudoku:
>>>  ZkPoK{ (solution, nonce):
>>>  SHA2(nonce || solution) == H,
>>>  CheckSudokuSolution(puzzleBoard, solution) == 1 }
>>>
>>> 2. Show two hashes have related preimages:
>>>
>&g

Re: [zapps-wg] Zkproofs.org standards workshop

2018-03-24 Thread Andrew Miller via zapps-wg
Lucas's post reminded me of something I wanted to post about:
If there's one thing I'd like to take up the torch for and advocate as a
standard, it's to use a conventional pseudocode for describing snark
application ideas. What I have in mind is Camenisch-Stadler proof
notation. It looks like this:

 ZkPoK{ (witness):  Predicate(statement, witness) }

The idea is that "witness" is the private witness, "statement" is
public information that the verifier provides, and you replace
"Predicate" with whatever pseudocode you want to check.
Here are some examples:

1. Pay-to-Sudoku:
 ZkPoK{ (solution, nonce):
 SHA2(nonce || solution) == H,
 CheckSudokuSolution(puzzleBoard, solution) == 1 }

2. Show two hashes have related preimages:

ZkPoK{ (R1, R2): H1 = sha256(R1) and H2 = sha256(R2) and R1 = R2 ^ X }

  https://github.com/ebfull/lightning_circuit/blob/master/README.md

This notation is a starting point, it can be extended to say a
Signature-of-Knowledge, like in BabyZoe (a simplified form of ZSL,
where the only shielded operation is to withdraw 1.0 coin from the
shielded pool):

3. SoK[tx]{ (secretkey, Com, merkleProof):
   // Com is included in the commitment tree
   MerkleVerify(coinTree, merkleProof, Com),
   Com is a commitment to (secretkey, Nullifier)
}

Notes on BabyZoe:
https://github.com/zcash-hackworks/babyzoe/blob/master/talks/2016-07-27-IC3---SNARKs-for-Ethereum.pdf

To take a stab at translating the snark-based password authentication
idea into this pseudocode, I think it could look like this:

4. SoK[signedMessage]{ (derivedkey):
username = SHA256(addrContract, derivedkey)
}

The user would then use standard PBKDF2  from something like:
   derivedKey := Argon2(addrContract, password)

so the snark circuit itself doesn't even have to have the expensive
hash. The smart contract would use the final password hash as the
username.

On Sat, Mar 24, 2018 at 4:47 PM, Andrew Miller <soc1...@illinois.edu> wrote:
> That's awesome Lucas, thanks for this input, these are pretty cool
> application scenarios. They're all quite relevant to a standards effort
> because they seem to involve interfacing between zkSNARKs and other
> standardized primitives (password hash functions, anonymous credentials,
> extensions to ZSL).
>
> On Sat, Mar 24, 2018 at 4:42 PM, Lucas Vogelsang via zapps-wg
> <zapps...@lists.z.cash.foundation> wrote:
>>
>> I've put some thoughts into possible use cases, here are some that we have
>> been thinking about in the context of decentralized business applications.
>> Some of these concepts are things we are actually working on, others just
>> ideas
>>
>> - blind auctions (including double dutch auctions)
>> - page-rank style algorithms on top of anonymous credentials or
>> reputations
>> - build a password-based authentication out of any password hash
>> - give out "referral capabilities" that automatically assign a commission
>> to whoever introduced a subscriber who signs up (this would be part of a
>> privacy-preserving subscription service, that could be built on top of a
>> zcash-like (ZSL protocol) cryptocurrency)
>> - consumer credit scores: create a registry of "bad debtors". use zkproofs
>> both to "register" a bad debt/bad action and allow individuals to provide a
>> proof revealing your score without actual transaction details (not sure how
>> exactly this could work)
>>
>> Curious to hear what other people have thought of!
>>
>>
>> On Fri, Mar 23, 2018 at 11:11 AM, Andrew Miller via zapps-wg
>> <zapps...@lists.z.cash.foundation> wrote:
>>>
>>> Dear Zapps, I just wanted to let you know that there will be a standards
>>> workshop organized by several academics / industry participants in May.
>>> https://zkproof.org
>>>  I want to make sure that the workshop includes input from all the groups
>>> involved in this open source community that are developing tools and
>>> applications and even making initial standardization efforts around
>>> portability between different libraries.
>>>
>>>  I'm especially interested in collecting application ideas to include as
>>> case studies to help make the conversation more concrete. So far I don't
>>> have many ideas. So far I have:
>>> - anonymous credentials
>>> - zcash
>>> - voting
>>> - sudoku solutions / contingent payments
>>> - compressing blockchain verification
>>> - a log of photo edits
>>> - checking that a cloud compute task was done correctly (this is arguably
>>> not specific enough).
>>>
>>> Suggestions of what I'm missing?
>>
>>
>
>
>
> --
> Andrew Miller
> University of Illinois at Urbana-Champaign



-- 
Andrew Miller
University of Illinois at Urbana-Champaign


Re: [zapps-wg] Zkproofs.org standards workshop

2018-03-24 Thread Andrew Miller via zapps-wg
That's awesome Lucas, thanks for this input, these are pretty cool
application scenarios. They're all quite relevant to a standards effort
because they seem to involve interfacing between zkSNARKs and other
standardized primitives (password hash functions, anonymous credentials,
extensions to ZSL).

On Sat, Mar 24, 2018 at 4:42 PM, Lucas Vogelsang via zapps-wg <
zapps...@lists.z.cash.foundation> wrote:

> I've put some thoughts into possible use cases, here are some that we have
> been thinking about in the context of decentralized business applications.
> Some of these concepts are things we are actually working on, others just
> ideas
>
> - blind auctions (including double dutch auctions)
> - page-rank style algorithms on top of anonymous credentials or reputations
> - build a password-based authentication out of any password hash
> - give out "referral capabilities" that automatically assign a commission
> to whoever introduced a subscriber who signs up (this would be part of a
> privacy-preserving subscription service, that could be built on top of a
> zcash-like (ZSL protocol) cryptocurrency)
> - consumer credit scores: create a registry of "bad debtors". use zkproofs
> both to "register" a bad debt/bad action and allow individuals to provide a
> proof revealing your score without actual transaction details (not sure how
> exactly this could work)
>
> Curious to hear what other people have thought of!
>
>
> On Fri, Mar 23, 2018 at 11:11 AM, Andrew Miller via zapps-wg <
> zapps...@lists.z.cash.foundation> wrote:
>
>> Dear Zapps, I just wanted to let you know that there will be a standards
>> workshop organized by several academics / industry participants in May.
>> https://zkproof.org
>>  I want to make sure that the workshop includes input from all the groups
>> involved in this open source community that are developing tools and
>> applications and even making initial standardization efforts around
>> portability between different libraries.
>>
>>  I'm especially interested in collecting application ideas to include as
>> case studies to help make the conversation more concrete. So far I don't
>> have many ideas. So far I have:
>> - anonymous credentials
>> - zcash
>> - voting
>> - sudoku solutions / contingent payments
>> - compressing blockchain verification
>> - a log of photo edits
>> - checking that a cloud compute task was done correctly (this is arguably
>> not specific enough).
>>
>> Suggestions of what I'm missing?
>>
>
>


-- 
Andrew Miller
University of Illinois at Urbana-Champaign


[zapps-wg] Zkproofs.org standards workshop

2018-03-23 Thread Andrew Miller via zapps-wg
Dear Zapps, I just wanted to let you know that there will be a standards
workshop organized by several academics / industry participants in May.
https://zkproof.org
 I want to make sure that the workshop includes input from all the groups
involved in this open source community that are developing tools and
applications and even making initial standardization efforts around
portability between different libraries.

 I'm especially interested in collecting application ideas to include as
case studies to help make the conversation more concrete. So far I don't
have many ideas. So far I have:
- anonymous credentials
- zcash
- voting
- sudoku solutions / contingent payments
- compressing blockchain verification
- a log of photo edits
- checking that a cloud compute task was done correctly (this is arguably
not specific enough).

Suggestions of what I'm missing?


Re: [zapps-wg] ANN: Snarky (OCaml DSL for writing SNARKs)

2018-03-12 Thread Andrew Miller via zapps-wg
This is really cool, thank you for posting here!! I love the overloading
and monadic approach to EDSL in ocaml. It's very much in the style of
Snarklib (and of Viff in the MPC world rather than zksnark world).

On Mon, Mar 12, 2018 at 1:31 PM, Izaak Meckler via zapps-wg <
zapps...@lists.z.cash.foundation> wrote:

> Hi all,
>
> Wanted to announce the initial release of a new high-level language called
> Snarky  for writing verifiable
> computations. Computations are compiled down into rank 1 constraint systems
> and then passed off to a SNARK construction. It’s implemented as an OCaml
> embedded DSL and is parametrized over the SNARK construction (right now
> only libsnark backends are provided with the library but users can add
> their own).
>
> The code is on GitHub  (example file
> here
> )
> and there is a blog post 
> explaining the design at a high-level. Please don’t hesitate to get in
> touch if you have any comments!
>
> Izaak
>



-- 
Andrew Miller
University of Illinois at Urbana-Champaign


Re: [zapps-wg] Cut-off date for Powers of Tau Contributions

2018-03-09 Thread Andrew Miller via zapps-wg
It sounds like an efficient way to dispense with the suggestions Devrandom
raised are to:
1. Do a round with the deterministic Go build, explicitly saving the binary
for posthoc analysis, and ideally running it on a non x86 architecture if
anyone has one...
2. Do a round with mrustc
What would it take to get a concrete plan to include those?

On Fri, Mar 9, 2018 at 2:17 PM, Sean Bowe  wrote:

> As far as security goes, we've successfully guarded against all but
> the most elaborate and unrealistic attack scenarios. The remaining
> threats require some combinatorial explosion of individually
> sophisticated attacks or breakthroughs, like stealthy backdoors in the
> Rust compiler and still for many participants to be colluding in
> secret, somehow without leaving evidence behind.
>
> We don't need an absolutely perfect ceremony to get strong privacy
> guarantees, we get that already even with a totally compromised
> ceremony. We *could* continue to invest time and resources for many
> more months or years in order to make us marginally more resistant to
> these absurd attack scenarios, but by the time we'd be finished with
> the ceremony we'll probably have better proving systems available
> anyway. It's silly to let privacy languish in the meantime.
>
> I think we did the best with the time we had, but if you disagree,
> remember that all of this can be extended and improved by anyone, even
> after this ceremony is done!
>
> Sean
>
> On Fri, Mar 9, 2018 at 11:06 AM, Peter Todd  wrote:
> > On Fri, Mar 09, 2018 at 04:49:37PM +, Devrandom wrote:
> >> Hi all,
> >>
> >> I have some concerns about the lack of diversity of contributions:
> >>
> >> - most (all?) of the contributions used a distributed Rust toolchain,
> which
> >> suffers from the "trusting-trust" issue since they are self-compiled.  I
> >> don't think I've seen any contributions using the mrustc build path.
> >> - there were very few contributions (two?) using the golang
> implementation
> >> - no attempt has been made to replicate the deterministic golang build
> >> - people did not capture the binary they used, so we can't do forensics
> in
> >> case of future questions
> >> - there were no contributions using alternative processor architectures
> >> (e.g. ARM64).  I believe this is possible using the golang
> implementation.
> >> - there was a lot of focus on destroying toxic waste and not enough on
> the
> >> trustworthiness of the tools
> >
> > I agree with all these points, particularly the latter: we should be
> focused on
> > genuine security, not flashy marketing stunts. (indeed, I regret the way
> my own
> > participation was marketted the last time around)
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
>



-- 
Andrew Miller
University of Illinois at Urbana-Champaign


Re: [zapps-wg] Cut-off date for Powers of Tau Contributions

2018-03-08 Thread Andrew Miller via zapps-wg
Let me add a bit to this:
1. First of all, all the code you need to add your own rounds to
powers-of-tau is already provided in Sean's repo. You could fork the
repository and add more rounds yourself if you wanted to. You could also
start using the powers-of-tau from early phases if you want too.
2. While we'll go along with Sean's suggestion to conclude the "official"
one on Mar 15, which will be used for Sapling, if there's interest from the
community in continuing to add more rounds, the Foundation will continue to
facilitate that, probably in another branch to avoid any confusion.
3. So far we have only been doing powers of tau for the 2^21 size circuit,
over the BLS12-381 curve. If there is any interest in conducting Powers of
Tau for larger circuit sizes, or for different curves (such as the
alt_bn128 supported in Ethereum), then the Foundation would support that
too. Although someone would have to adapt Sean's or FiloSottile's code to
do so...

Cheers,

On Mon, Mar 5, 2018 at 11:03 PM, Sean Bowe via zapps-wg <
zapps...@lists.z.cash.foundation> wrote:

> We're almost finished with the Powers of Tau ceremony!
>
> On March 15 no new contributions will be accepted. If you still want to
> participate, you will need to contact Jason Davies ASAP and arrange for a
> time.
>
> I'll be making an announcement about the random beacon soon.
>
> Thanks,
>
> Sean
>



-- 
Andrew Miller
University of Illinois at Urbana-Champaign


Re: [zapps-wg] Powers of Tau

2018-01-24 Thread Andrew Miller via zapps-wg
That's outstanding, thanks! The independent Go-language implementation of
the compute node is an amazing bonus contribution. I'd love to learn more
about this project. I'll ask questions in the github repo.
Cheers,

On Wed, Jan 24, 2018 at 6:54 PM, Filippo Valsorda via zapps-wg <
zapps...@lists.z.cash.foundation> wrote:

> The BLAKE2b hash of `./response` is:
> 7b55c0f5 68a8b4df 2ca14085 2e816df2
> b9a2dafe 50b2c5e2 5e6c9b6a df239de0
> 223a9866 aba481a8 436fbd42 04a2c48a
> 43725d94 2de47b23 c10c5e87 38fd6467
>
> The main feature of this contribution is that it was computed with an
> independent implementation of Powers of Tau.
>
> My implementation, which I am open sourcing now at [1], was not public at
> the
> time of computation. It is written in Go, shares no code with the main Rust
> implementation, and uses the RELIC library for BLS12-381. The only detail
> that
> was copied verbatim from the Rust codebase is the value of the curve
> coefficient, but that's being resolved at [2]. The Zcash Company sponsored
> this effort, but it was proposed and conducted by me independently.
>
> The computation was simply performed on my main MacBook Pro, where the code
> was developed. The laptop was rebooted after the computation and before
> re-enabling Wi-Fi and reopening the browser. The git hash of the codebase
> was
> 26a0231c674ec6043ef77997d33d94787c55634a, the Go version 1.9.2, extra
> entropy
> was fed to /dev/random before starting.
>
> The full terminal transcript, and this attestation signed with a
> minisign/signify
> key published at [3] are attached, and available at [4].
>
> [1] https://github.com/FiloSottile/powersoftau
> [2] https://github.com/relic-toolkit/relic/issues/64
> [3] https://twitter.com/FiloSottile/status/956325095013863425
> [4] https://gist.github.com/FiloSottile/cc142b683666ee1ce5ee77759bd0a367
>
> -- Filippo Valsorda
>
> 2018-01-22 22:17 GMT+0100 Filippo Valsorda :
> > _o/
> >
> > I'm ready to go whenever there's a slot.
> >
> > It will probably take me half a day, upload included.
>



-- 
Andrew Miller
University of Illinois at Urbana-Champaign


Re: [zapps-wg] Powers of Tau

2018-01-23 Thread Andrew Miller via zapps-wg
booted from a
> USB drive with Ubuntu 16.04. The hard drives and wifi were disabled in
> software, but were *not* removed due to the difficulty in unscrewing
> the laptop.
>
> To reduce the risk of side channel attacks, we performed our
> contribution to the ceremony while airborne in Ryan's Piper
> Cherokee. Ryan and Andrew were the only occupants in the aircraft. No
> mobile phones were powered on during the flight. The only mobile
> device in use was an iPad 2, with cellular and WiFi disabled but
> Bluetooth and GPS enabled, running ForeFlight electronic flight bag
> software. We departed on a VFR flight from Waukegan airport (KUGN),
> located in Illinois, near the Wisconsin border. Once we reached 3,000
> feet AMSL, Ryan performed a 360 degree steep turn to assure ourselves
> that no aircraft or drones were following us. We set up the Geiger
> counter RNG and laptop and began the computation. During this time, we
> made occasional random turns, flying over northern Illinois and
> southern Wisconsin while remaining outside the O'Hare Class B
> airspace, until the compute finished. We observed no suspicious
> aircraft attempting to follow us. The total compute time took around
> 30 minutes. We then flew to Schaumburg Airport (06C) where we uploaded
> the response file at Pilot Pete's restaurant. We made a return flight
> to Waukegan later that afternoon.
>
> Pictures from the trip:
>
> https://twitter.com/RyanPierce_Chi/status/954776352225398784
> https://twitter.com/RyanPierce_Chi/status/954777461782470656
> https://twitter.com/RyanPierce_Chi/status/954779454961745921
> https://twitter.com/RyanPierce_Chi/status/954854952396050432
> https://twitter.com/RyanPierce_Chi/status/954908555873849344
> https://twitter.com/RyanPierce_Chi/status/954855811951550464
>
> We’re also currently producing a short video about our trip, which we
> plan to publish to Youtube and notify the zapps-wg mailing list.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJaZisvAAoJEFvUyhfk+7ICLOYQAIX7+nSe6CRVKFuwkjHYXJyu
> Ll5G+X9+Kjrhq0RYXmjix50pEgkpEZhTzKnPxo4tNiiaRc34waKpCAFZpn2Yfpq5
> 8o3R3rTDjYlGcMVyWciipUvbtzxfxrs5GRXknTGhtLvhljZM+fq09O4raPn+oj5Y
> tDiFKAO0tKx5wXqlg8diM5AxUfveX6Kov0844ctV+7rP6OYOgCEjqD/o/vM0kVUR
> R5wvh7dqY2VHvh7LYAjUSOwbQ4M+3LCw9fK0dAZrXqT9Yn5DquGYKj39QsHJoJ9R
> 4uoDb6ltPJuZDCJ0wBKHiyfMr3++UKTDj6dRkHF2OD7aBk4jPZUC6YCC5zgQFPxL
> MrBv137EBijmtu4uFfT2YM7SJkKa+AGXnhzsIdFKy5U4Ahqa7meA9sDdAHdOgR9W
> RVq9wuO3OnL12Oj53N/PEVtxgmWxHVZfIKP5EPihhSklWC6RU8XVgV4OlfGkkYkA
> YyrYNGjSTDI6YXVNXl4uKttzVg965tSt5+83HhuEFepR3+HFgmXz+suYa53J8rxX
> njESFI0qV7j7VzLnwthAjV5u0ZAY0y9vOTnMB1nLwVZEKl/g3/WNZhDes9xuyYqV
> fAXjVfM2YQ2mQui9U60g0XfSgnO/tnLVG8Fsiv3Jy2yx5baZect8nl3wX6qyWAiM
> d/vM2xKNhdf49qfltNQn
> =rmAp
> -END PGP SIGNATURE-
>
> On Sat, Jan 20, 2018 at 12:08 PM, Miller, Andrew via zapps-wg <
> zapps...@lists.z.cash.foundation> wrote:
>
>> Here's our response, should be done uploading to s3 in a moment.
>> 9af2153b5d0f96689f79049337de1fb328873f5f771adef1adf0486e4904
>> b28d96fe602c8866f42e8047ce3bdafe2f9e73c7d2cd1b0c023d3831a46242bd6fc9
>>
>> Long story short:
>> - Contributor: Ryan Pierce and Andrew Miller
>> - Isolation: 3,000 feet above ground in a Piper Cherokee
>> - Entropy source: geiger counter and a Chernobyl reactor graphite sample
>> Entertaining writeup and video to follow! (Note: all appropriate aviation
>> and radiation regulations were followed to a tee)
>>
>> --
>> Andrew Miller
>> University of Illinois at Urbana-Champaign
>> 
>> From: Sean Bowe [s...@z.cash]
>> Sent: Wednesday, January 17, 2018 10:22 PM
>> To: Miller, Andrew
>> Cc: Zapps wg
>> Subject: Re: [zapps-wg] Powers of Tau
>>
>> It does interfere with someone, but we could make it work Saturday
>> morning if you don't expect it to take longer than the morning.
>>
>> Sean
>>
>> On Wed, Jan 17, 2018 at 9:18 PM, Andrew Miller via zapps-wg
>> <zapps...@lists.z.cash.foundation> wrote:
>> > Greetings everyone,
>> >I have a good one planned. But it's got a difficult time constraint.
>> I
>> > need to go this coming Saturday morning. Hopefully it won't interfere
>> with
>> > the batting order much if I ask for priority! Thanks,
>>
>
>
>
> --
> Andrew Miller
> University of Illinois at Urbana-Champaign
>



-- 
Andrew Miller
University of Illinois at Urbana-Champaign


Re: [zapps-wg] Powers of Tau

2018-01-22 Thread Andrew Miller via zapps-wg
urn to assure ourselves
that no aircraft or drones were following us. We set up the Geiger
counter RNG and laptop and began the computation. During this time, we
made occasional random turns, flying over northern Illinois and
southern Wisconsin while remaining outside the O'Hare Class B
airspace, until the compute finished. We observed no suspicious
aircraft attempting to follow us. The total compute time took around
30 minutes. We then flew to Schaumburg Airport (06C) where we uploaded
the response file at Pilot Pete's restaurant. We made a return flight
to Waukegan later that afternoon.

Pictures from the trip:

https://twitter.com/RyanPierce_Chi/status/954776352225398784
https://twitter.com/RyanPierce_Chi/status/954777461782470656
https://twitter.com/RyanPierce_Chi/status/954779454961745921
https://twitter.com/RyanPierce_Chi/status/954854952396050432
https://twitter.com/RyanPierce_Chi/status/954908555873849344
https://twitter.com/RyanPierce_Chi/status/954855811951550464

We’re also currently producing a short video about our trip, which we
plan to publish to Youtube and notify the zapps-wg mailing list.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJaZisvAAoJEFvUyhfk+7ICLOYQAIX7+nSe6CRVKFuwkjHYXJyu
Ll5G+X9+Kjrhq0RYXmjix50pEgkpEZhTzKnPxo4tNiiaRc34waKpCAFZpn2Yfpq5
8o3R3rTDjYlGcMVyWciipUvbtzxfxrs5GRXknTGhtLvhljZM+fq09O4raPn+oj5Y
tDiFKAO0tKx5wXqlg8diM5AxUfveX6Kov0844ctV+7rP6OYOgCEjqD/o/vM0kVUR
R5wvh7dqY2VHvh7LYAjUSOwbQ4M+3LCw9fK0dAZrXqT9Yn5DquGYKj39QsHJoJ9R
4uoDb6ltPJuZDCJ0wBKHiyfMr3++UKTDj6dRkHF2OD7aBk4jPZUC6YCC5zgQFPxL
MrBv137EBijmtu4uFfT2YM7SJkKa+AGXnhzsIdFKy5U4Ahqa7meA9sDdAHdOgR9W
RVq9wuO3OnL12Oj53N/PEVtxgmWxHVZfIKP5EPihhSklWC6RU8XVgV4OlfGkkYkA
YyrYNGjSTDI6YXVNXl4uKttzVg965tSt5+83HhuEFepR3+HFgmXz+suYa53J8rxX
njESFI0qV7j7VzLnwthAjV5u0ZAY0y9vOTnMB1nLwVZEKl/g3/WNZhDes9xuyYqV
fAXjVfM2YQ2mQui9U60g0XfSgnO/tnLVG8Fsiv3Jy2yx5baZect8nl3wX6qyWAiM
d/vM2xKNhdf49qfltNQn
=rmAp
-END PGP SIGNATURE-

On Sat, Jan 20, 2018 at 12:08 PM, Miller, Andrew via zapps-wg <
zapps...@lists.z.cash.foundation> wrote:

> Here's our response, should be done uploading to s3 in a moment.
> 9af2153b5d0f96689f79049337de1fb328873f5f771adef1adf0486e4904
> b28d96fe602c8866f42e8047ce3bdafe2f9e73c7d2cd1b0c023d3831a46242bd6fc9
>
> Long story short:
> - Contributor: Ryan Pierce and Andrew Miller
> - Isolation: 3,000 feet above ground in a Piper Cherokee
> - Entropy source: geiger counter and a Chernobyl reactor graphite sample
> Entertaining writeup and video to follow! (Note: all appropriate aviation
> and radiation regulations were followed to a tee)
>
> --
> Andrew Miller
> University of Illinois at Urbana-Champaign
> 
> From: Sean Bowe [s...@z.cash]
> Sent: Wednesday, January 17, 2018 10:22 PM
> To: Miller, Andrew
> Cc: Zapps wg
> Subject: Re: [zapps-wg] Powers of Tau
>
> It does interfere with someone, but we could make it work Saturday
> morning if you don't expect it to take longer than the morning.
>
> Sean
>
> On Wed, Jan 17, 2018 at 9:18 PM, Andrew Miller via zapps-wg
> <zapps...@lists.z.cash.foundation> wrote:
> > Greetings everyone,
> >I have a good one planned. But it's got a difficult time constraint. I
> > need to go this coming Saturday morning. Hopefully it won't interfere
> with
> > the batting order much if I ask for priority! Thanks,
>



-- 
Andrew Miller
University of Illinois at Urbana-Champaign
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Powers of Tau Operational writeup
=
 
Round: 41
Principals: Ryan Pierce and Andrew Miller
Date: 2018-01-20
Location: North Illinois and Southern Wisconsin
Altitude: 3,000' AMSL / approx. 2200' AGL
Commit version: 9e1553c437183540392a7231d0788318a19b18a3
SHA256 of ./compute: 
922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a
SHA256 of challenge file: 
c48fbf0a267ea9a9596c09aaf91f6acc18b48430e9239c18de583055b32d503d
 
blake2sum of response:
8a5a9bcb a9c3ab76 c7e3a881 2ccd01e6
9af2153b 5d0f9668 9f790493 37de1fb3
28873f5f 771adef1 adf0486e 4904b28d
96fe602c 8866f42e 8047ce3b dafe2f9e
73c7d2cd 1b0c023d 3831a462 42bd6fc9
 
 
Preparation steps
=
 
As we know, Powers of Tau is all about generating and safely disposing
of cryptographic "toxic waste." So, what better way to generate
entropy than with actual radioactive toxic waste?

For our contribution, the entropy source was a hardware-based random
number generator utilizing a Geiger tube and a radioactive source,
constructed and programmed by Ryan Pierce. It was based off of the
MightyOhm Geiger Counter kit, available for purchase at
http://mightyohm.com/geiger

The radioactive source chosen was a very small, low activity sample of
the graphite moderator ejected from the core of the Chernobyl Unit 4
nuclear reactor during the 1986 explosion and meltdown. The primary
a

[zapps-wg] Powers of Tau

2018-01-17 Thread Andrew Miller via zapps-wg
Greetings everyone,
   I have a good one planned. But it's got a difficult time constraint. I
need to go this coming Saturday morning. Hopefully it won't interfere with
the batting order much if I ask for priority! Thanks,


Re: [zapps-wg] Participation request

2018-01-05 Thread Andrew Miller via zapps-wg
Bump for Nick to go soon!

On Jan 4, 2018 8:29 PM, "Nick Sullivan via zapps-wg"
 wrote:

> I'd like to participate when there's a free slot.
>
> Nick
>


Re: [zapps-wg] Powers of Tau participation + zk proof question

2018-01-03 Thread Andrew Miller via zapps-wg
Thank you so much for expressing your question in Camenisch-Stadler
notation! That makes it very clear what you're going for.

What hash function H do you have in mind, would SHA2 work? Also what group
G do you have in mind, secp256k1?

If so, I do not know of any existing implementation of secp256k1 operations
specifically in libsnark, so that would presumably be the biggest challenge.

On Jan 3, 2018 1:47 PM, "James Prestwich via zapps-wg"
 wrote:

I'd like to participate in the setup ceremony.

I also have an app I'd like to build using a zk-proof of knowledge of an
ECC private key. {(a) : A = a * G, B = H(a)}. Can anyone point me to good
resources on getting started?


Re: [zapps-wg] Powers of Tau contribution

2018-01-02 Thread Andrew Miller via zapps-wg
Hi Kevin, thanks for your note, I think we were just thrown off by the word
"mining" and wondered if you were in the wrong place :)
Do you want to go next? If so Sean will designate you a spot in the queue...

To contribute, I'd suggest reading a sample of a few reports from people
who have gone earlier, for where to find the software and possible steps
you can take to contribute with good opsec.
https://github.com/ZcashFoundation/powersoftau-attestations

You can get the software to run from this github repository:
https://github.com/ebfull/powersoftau/ though others have made mirrors and
dockerfiles etc you could use too.

On Tue, Jan 2, 2018 at 7:11 PM, Zx100 via zapps-wg <
zapps...@lists.z.cash.foundation> wrote:

> Excuse us? You asked "how do I start mining?" which is completely
> unrelated to the topic at hand. You are not entitled to a response,
> especially since it takes two minutes to Google for the official
> information.
>
>  Original Message 
> Subject: Re: [zapps-wg] Powers of Tau contribution
> Local Time: January 3, 2018 12:45 AM
> UTC Time: January 3, 2018 12:45 AM
> From: zapps...@lists.z.cash.foundation
> To: zapps...@lists.z.cash.foundation
>
>
> Not to hijack the thread, but I've asked how to contribute and was not
> given an answer.
>
>
>
> On 1/2/2018 3:12 PM, Tony Arcieri via zapps-wg wrote:
>
> I have finished running Powers of Tau. Here is the output:
>
> The BLAKE2b hash of `./response` is:
> d129d960 a645c735 ec52fc80 91f081d1
> a6e4ff78 90e4fa55 51faa85e 95e3878a
> 96bd0c07 8315c0d4 e8e3f1a3 26dbb607
> 1ea2b43b 844a0d1e 0a3bca5a 8e21c3a5
>
> I'm not a fan of GPG, but I can post a raw Ed25519 signature of
> ./response, with Base64 public key:
>
> a7aP6Okqx1YBtRubECVoiY2Z4reR34F9BPuPwTtxpQU
>
> I have also posted this same public key to Twitter: https://twitter.com/
> bascule/status/948285074872532992
>
> The Base64url signature on my response under the aforementioned key is:
>
> BkDDl831jxB21rPHX-6pC1REdZ2UoZs_sGuAfCTt8xAP_E-Cva6Qg72fjX8yuMG-
> ufn3sc4FoAuMKGMT_OGPBQ
>
> I have since destroyed the private key/scalar used to produce this
> signature.
>
> --
>
> Tony Arcieri
>
>
>
>
> 
> Virus-free. www.avast.com
> 
>
>
>


-- 
Andrew Miller
University of Illinois at Urbana-Champaign


[zapps-wg] Where are all your circuits? Phase 2 planning discussion and more in this thread

2017-12-07 Thread Andrew Miller via zapps-wg
Dear esteemed zapps-wg members,
  Just a reminder that the "Powers of Tau" part of the snark setup
procedure requires a Phase 2 as well (right now we have only been focusing
on conducting Phase 1). I'm writing this note just so everyone realizes
that a second phase is needed too, so you don't burn out all your
enthusiasm and good cheer in the first phase.
  The computational steps of Phase 2 are actually very similar to those of
Phase 1, however
  A) Phase 2 uses the final output of Phase 1 as an input,
  B) Phase 2 depends on *the particular arithmetic circuit for which we are
generating the parameters*. This means that if we want to generate circuits
for multiple applications at the same time and not just Zcash Sapling,
we'll need to have those circuits ready when we start P2.

If you want to get involved, there are several technical projects that are
still in the #design-needed phase and could use development leaders:
- What should the Phase 2 process look like? Can we generate parameters for
multiple people's circuits at the same time? How many should we do at once,
and how should we pick?
- It would be such low hanging fruit to propose a standard ".r1cs" file
format, and then we can adapt all the various SNARK compilers to output /
read this format. Please, someone, take this up as a challenge and do it!
- Where are all y'alls circuits? I would love to see some R1CS files posted
to this list. Hey! You! Why not spend the weekend whipping up a stupid
ZeroKitties circuit?
- Has anyone looked at adapting existing compilers like Pequin, Geppetto,
or Zokrates to output BLS12-381 compatible arithmetic circuits?
- The current Powers-of-Tau is specific to the BLS12-381-Groth16 snark
configuration, whereas Ethereum Byzantium currently only supports alt_bn128
operations. If someone customizes the powers-of-tau code to work on
alt_bn128, then we could also use this mailing list to coordinate
Byzantium-compatible snark parameters.

Please consider using this thread to informally discussion the
possibilities :)
Cheers,
-- 
Andrew Miller
University of Illinois at Urbana-Champaign