Updated details [ZEC] ZCASH + Announcing Zcash Cloud Mining

The Near Future of Zcash
Our Mission is to make Zcash the premier platform for commerce — secure, borderless, and available equally to every person on our planet. We believe that Zcash can do for resource sharing and coordination what the Internet did for communication.
the story so far
Zcash first launched on October 28, 2016. During the first few months of its life, we focused on stabilization and incremental improvement.
We delivered a series of improvements (the “Zcash Sprout” series of releases) which fix bugs and improve usability based on iterative feedback from our lovely users. Our users are the best! ❤
At the same time, we've been monitoring and supporting the continuous reliable operation of the global Zcash network. So far, the network has experienced zero downtime, and no security breaches.
Now we are announcing our development priorities for the next stage of Zcash's growth.
stability
Our first and second priorities will always be:
 Security and reliability, and
 Iterative improvement in response to demand from our users.
We will continue to vigilantly guard the security of the system, support our users, and deliver regular stable releases as we have been doing.
innovation
Payment Disclosure will allow you to reveal the information about a specific payment (including the encrypted memo field) in the blockchain to a specific party of your choice.
This could be used, for example, by an exchange to prove to a customer or to a third party adjudicator that they sent a certain payment, without revealing the payment information to any unauthorized parties. (Payment Disclosure on GitHub)
Payment Offloading will allow users of light wallets to send Zcash to shielded addresses without placing any funds at risk. (Payment Offloading on GitHub)
CrossChain Atomic Transactions (“XCAT”), part of our Project Alchemy initiative, will allow transactions that span multiple blockchains. This will enable you to trade Zcash, Ethereum, and Bitcoin tokens without relying on an intermediary. (XCAT on GitHub)
The “Sapling” Cryptography Upgrade will be our first upgrade of the core Zcash protocol which will bring efficiency improvements and enable new kinds of core protocol features. The primary example being:
… UserIssued Tokens, which allow you to issue, transfer, and atomically trade unique tokens for your own purposes, with Zcash's strong privacy protections. (UserIssued Tokens on GitHub)
The Sapling upgrade with UserIssued Tokens will require a networkwide upgrade, and once we reach that stage we will name the new release series “Zcash Sapling”. At that point the infant Zcash Sprout series will be no more.
this is only the beginning
This is only the beginning! There are already many gleams in our eyes for dramatic, breakthrough improvements that we intend to make after Sapling. Along the way we might also adapt our priorities to support new developments, like Lightning Network or its more privacyprotecting cousin BOLT. Other teams and companies may also come out with applications that extend Zcash or leverage its unique features, so stay tuned.
We will continue to listen carefully to our users, and learn from them what improvements will help them the most, both in the short term and the long term. Join the growing Zcash community and let us know what you envision for the future!
As we wrote at the beginning, the ultimate destiny of Zcash lies not in our hands but in yours.

History of Hash Function Attacks
The SHA1 hash function, which has long been considered insecure, is now officially broken as of yesterday. Given the renewed interest in hash function collisions, I'd like to point out an article I wrote about attacks on secure hash functions, in the hopes that you will find it useful and interesting.
You can can read the full article at https://z.cash/technology/historyofhashfunctionattacks.html.
The main result of this investigation is that a cryptosystem which is invulnerable to collisionattacks (even if it is still vulnerable to preimage attacks), is much stronger than one which is vulnerable to collisionattacks. Another interesting takeaway is that it looks like sometime between 1996 (Tiger) and 2000 (Whirlpool), humanity might have learned how to make collisionresistant hash functions, since none of the prominent secure hash functions designed since that era have succumbed to collision attacks. Maybe modern hash functions like SHA256, SHA3, and BLAKE2 will never be broken
As a graphical reference for the article, I've included a colorcoded chronological view of collision attacks, and of second preimage attacks, as well as a survey of the best known attacks on secure hash functions.
By,
Zooko Wilcox
Thanks to Andreas Hülsing, Samuel Neves, and Zcash engineer Daira Hopwood for their input on this investigation.
cryptographyhash functions, BLAKE2 

Dev Update  March 3  2017
This week we’re getting ready for the 1.0.72this note9 by Zooko for his perspective of the next release.
Much of engineering time went towards last minute developments to include in this next release in addition to testing and review for any remaining pullrequests tagged for 1.0.7.
One of the more urgent projects we’re working on is documentation and signaling for best privacy and security practices when using Zcash. There are some key considerations for all users interested in maintaining optimal privacy and security when interacting with the network. We hope to have a first version posted to the website for the 1.0.7 release. In particular, there are two types of analysis that could potentially lead to privacy leaks: those on transaction graphs and those on network graphs. In short, we recommend the use of shielded addresses to protect against transaction graph analysis and IP obfuscation tools like Tor to protect against network graph analysis. More on that in an official document in the coming days!
We focused some time on reviewing the Payment Disclosure ZIP draft1 so that next week, work can be put towards a prototype. This is a big step towards improving shielded address functionality and is one of the near future priorities for Zcash engineering. Some examples listed in the ZIP include:
 A sender may need to prove that their payment was sent and received by a recipient. For example, a customer paid too much for an item and would like to claim a refund from the vendor.
 A third party needs to verify that a payment between sender and recipient was executed successfully. For example, a regulator needs to confirm a transfer of funds between two parties
We decided the initial release of Payment Disclosure would come as an experimental feature  only available to nodes with experimental flag marked in the config at startup. There is expectation for some efficiency loss so releasing as an experimental feature will allow us to get some feedback and insight on the effects on efficiency.
Another one of our near future priorities, payment offloading (technically referred to as delegated proving1) also received focused engineering and discussion time this week. A prototype has been in the works with a ZIP for specifying the initial implementation coming next.
The HTLC improvements1 for Bitcoin and Zcash are well underway, a step towards XCAT, another near future priority!
We also did some exploration of transaction malleability solutions such as Bitcoin’s segwit and Bitcoin Classic’s Flexible Transactions. More discussion and research is required for any decision to be made. You can always take part in the discussion (and other topics!) by joining the Community chat1. Our devs typically hold these in the
#zcashdev
and#zcashwizards
channels.We also released the initial chapter of a series of blog posts on explaining zkSNARKs. This first one on Homomorphic Hiding6.
Make sure to keep an eye out for the 1.0.7 release on Monday and to update your nodes when it’s available!

R3 Report on Confidentiality & Privacy for Blockchains
Last year, R3Blockseer) a report that compares and contrasts the different techniques for making blockchains more private. The report was completed in early November and distributed to the R3 consortium’s membership, where it was wellreceived. Today, R3 have published it on their website.
In the report, we describe and compare various approaches to adding confidentiality and privacy to blockchains, including various tumbling and mixing protocols such as Coinjoin and Coinshuffle, the use of stealth addresses, Pedersen commitments with range proofs (more commonly known as Confidential Transactions), ring signatures (used by Monero) and zeroknowledge proofs (as implemented in Zcash). We also take a look at the Hawk and Enigma protocols for enabling the use of private smart contracts and multiparty computation of encrypted data.
The report is aimed at a nontechnical audience, so our descriptions and explanations of how the various techniques work, are written to facilitate a highlevel understanding by people with no background in computer science or cryptography, rather than being exhaustively accurate. For people who are interested in delving deeper into the detail that we have glossed over, we’ve provided links in the footnotes to the relevant source material and academic papers.
Blockchain technology is a fastevolving field, so this report is necessarily a snapshot of the confidential and privacy techniques that were public at the time it was written. The intervening months have seen the release of R3's CordaJP Morgan's Quorum, and Chain has previewed their "Confidential Assets" technology. We expect to see further developments and progress in this space throughout 2017.
We’d like to thank R3 for commissioning this report, and our coauthor Danny Yang for working with us to make it happen. We’d also like to thank everyone who provided feedback and suggestions, particularly Andrew Miller, Antony Lewis, Ariel Gabizon, Emily Rutland, Ian Grigg, Ian Miers, Mike Ward, Paige Peterson, Shihao Guo, Tim Swanson and Vitalik Buterin.
Download the report in PDF format.
Jack Gavigan

Zcash Release V 1.0.71
his release fixes several documentation issues with the 1.0.7 release.
Upcoming Testnet Upgrade
The Zcash testnet will soon be upgraded in order to resolve an issue with the Testnet Founders Reward addresses. This will not affect the main Zcash network. Testnet users must upgrade to at least version 1.0.7 by block 53127, as that is when the testnet network changes will take place. Users who do not upgrade may be left on their own chain, contributing to a chain fork.
Downloads

BLS12381: New zkSNARK Elliptic Curve Construction
Our team is continually working to improve the security, performance and usability of our privacypreserving shielded transactionsnear future priorities
blog post, we are working on a collection of cryptographic improvements
for the next version of Zcash named Sapling. One of our goals is to
make shielded payments more efficient and less memory intensive. We also
intend to improve the concrete security level of the elliptic curve
construction that we use for our zkSNARK proofs.I spent some time last month designing and implementing a new pairingfriendly elliptic curve construction that is optimal for zkSNARKs at the 128bit security level. The construction minimizes performance and usability costs while increasing our security margins.
The construction will appear in an upcoming paper by our scientists, where it will be accompanied by a more thorough description of the construction and how it was selected.
BarretoNaehrig curves
BarretoNaehrig (BN) curves are a class of pairingfriendlyFq" role="presentation">Fq
. Last year, Kim and Barbulescu presented a variant of the Number Field Sieve algorithm which reduced a conservative [1] estimate of the security level to around 110 bits based on a recent paper.
It is possible to construct a new BN curve that targets 128bit security, even according to this conservative estimate, by selecting a curve closer to q≈2384" role="presentation">q≈2384
. However, the larger group order r" role="presentation">r
impairs the performance of multiexponentiation, fast fourier
transforms and other cryptographic operations that we need to perform
efficiently in zkSNARK schemes and multiparty computations.
Additionally, the larger scalar field Fr" role="presentation">Frmakes keying material unnecessarily large.
BarretoLynnScott curves
BarretoLynnScott (BLS) curves are a slightly older class of pairingfriendly curves which now appear to be more useful for targeting this security level. Current research suggests that with q≈2384" role="presentation">q≈2384
,
and with an embedding degree of 12, these curves target the 128bit
security level. Conveniently, the group order for these curves is r≈2256" role="presentation">r≈2256, which allows us to avoid the performance and usability drawbacks that accompany a larger scalar field.
BLS12381
In zkSNARK schemes, we need to manipulate very large polynomials over the scalar field Fr" role="presentation">Fr
. We can perform efficient multipoint evaluation/interpolation with fast fourier transforms, so long as we ensure Fr" role="presentation">Fr is equipped with a large 2s" role="presentation">2s
root of unity.
As is common, we target a subfamily of these curves that has optimal extension field towers and simple twisting isomorphisms. In order to ensure Montgomery reductions and other approximation algorithms are spaceefficient, we target r≈2255" role="presentation">r≈2255
so that the most significant bit of r" role="presentation">r (and q" role="presentation">q
) are unset with 64bit limbs.
As usual, in order to optimize for pairing performance, we ensure the parameterization of the BLS curve has low Hamming weight. The curve we have ultimately chosen is named BLS12381 as q≈2381" role="presentation">q≈2381
.
u = 0xd201000000010000
k = 12
q = 4002409555221667393417789825735904156556882819939007885332058136124031650490837864442687 629129015664037894272559787
r = 52435875175126190479447740508185965837690552500527637822603658699938581184513
E(Fq) := y^2 = x^3 + 4
Fq2 := Fq[i]/(x^2 + 1)
E'(Fq2) := y^2 = x^3 + 4(i + 1)
Rust language implementation
I have begun working on an implementation of the construction in Rust as part of my bellman zkSNARK project. The library has the goal of being portable, standards compliant, and high performance. Due to the nature of zkSNARK schemes, it is difficult to efficiently construct proofs in constant time, and so the library does not currently focus on side channel resistance.
Future blog posts will describe a number of techniques and tools that our scientists have devised for using this curve construction to optimize Zcash.
Menzes, Sarkar and Singh (http://eprint.iacr.org/2016/1102.pdf)
Author,
show 2^110 is a conservative estimate for the size of the space of
polynomials that needs to be scanned for smooth polynomials. However,
for the case q=p^12 relevant for BN curves there is no currently
published efficient method for scanning this space. (Checking each
polynomial separately for smoothness would result in total running time
larger than 2^128.) Thus, to the best of our knowledge the most
efficient currently known fully described algorithm for breaking the
curve Zcash is presently using is Pollard's rho, which would run in time
sqrt(q)~2^127. (Our thanks to Palash Sankar and Shashank Singh for
helping understand their result.)Sean Bowe

Zcash addnode Tor hidden service .onion
Herewith dedicated Zcash addnode Tor hidden service .onion's.
addnode=fhsxfrwpyrtoxeal.onion addnode=zcash2iihed2wdux.onion
or
addnode=fhsxfrwpyrtoxeal.onion:8233 addnode=zcash2iihed2wdux.onion:8233
The nodes are (currently) running Zcash 1.0.7 and Tor 0.2.9.10 (with upgrade notification status being provided via this thread).
Connecting to these Zcash nodes requires Tor : https://www.torproject.org/docs/debian.html.en
Also see : https://github.com/zcash/zcash/blob/master/doc/tor.md4
A client and server guide will follow.
These nodes are run independently, although it is part of a Zcash accepting project. Thus, in terms of a transient internet, these Zcash hidden service .onion's are likely to remain stable for the foreseeable future and beyond.
Donations and community support are welcomed.
taddress : t1bmX8aWjLCUFprFnj1uptNzJazhQE615k2
zaddress (public) : zcGJjhSg4hwaKHcVG9FJedMRVgjS6HdeBtpXNvdmzpd19dBgkzKoKSRNVFkEh8ohBdaCbFqCN4oMpHuAwKUVBaq43vggtQZ
Cheers!
By,

March 17, 2017  Dev update
This past week saw a lot of improvements on the near future priorities21.0.8 release
Some issues we're looking at include setting up better stress tests for memory usage of the client (#2155#2119), a small bug in
progress
reporting in debug logs (#2111#2096) and cleaning up some references to bitcoin from the original fork (#17561).We also had a topical meeting to discuss fee mechanisms. We started the discussion by breaking down the effects of fees in 3 stages:
 No contingency for block space (what we currently see now)
 An intermediate phase (perhaps when we see the first full block or a first spam attack)
 When there's high demand for transaction throughput
We didn't end up at a concrete solution but definitely made progress on considering the various options (constant fee, weighted randomized fee, dynamic fee based on average block availability, etc) and their consequences.We're thinking that by the time stage 3 would happen, we would already have solutions in place to mitigate it like BOLT and/or a blocksize increase. Our goals are to make fees as natural and user friendly as possible while maintaining security against detrimental flood attacks (while also considering the fact that the more minor flood/dos attacks we've seen in bitcoin have no lasting effect and should not stress too much about those.) Because Zcash transactions with transparent addresses are lighter weight but don't offer privacy and transactions with shielded addresses are heavier weight but offer the private capabilities that we want to promote the use of, all of the models we discussed were not based on actual transaction size.
While we already have a Tor service hosting the https://z.cash1explaining zkSNARKs to continue our effort in decypering the “moon math” behind the zeroknowledge system driving the privacy in Zcash.
As mentioned last week, a few of us will be attending the Tor meeting to see what kind of support our teams can give to one another. And relatedly, it's great to see the Zcash community thinking along the same lines.
We also set the next Show & Tell1zmsg4, a small program for sending messages via zcash encrypted memo fields.
Finally, while not explicitly engineering related, the Zcash Foundation initial board was announced todaynew category in this forum specifically for suggestions to the Foundation and hope the community takes advantage of it – especially in these early days!

Announcing the Zcash Foundation
Our Mission is to give every person in the world economic freedom — to do for cooperation what the Internet did for communication.
The organization we created to launch this project is a startup. This provides a tightknit, focused team, rapid decisionmaking, and the possibility of generating additional funding, such as by building blockchain solutions for industry.
However in the long run it would not be appropriate for a single forprofit company to have this much power over the evolution of the Zcash technology. Ultimately, there will need to be an independent, inclusive, nonprofit body to steward the technology in the interests of all users.
Today we are announcing the formation of The Zcash Foundation, which I hope will fill this role.
I hope that The Foundation will also serve as a forum for the Zcash community to work its way through governance issues such as the ones that are currently rending the Bitcoin community.
The Zcash Foundation is funded by the blockchain itself. A portion of the Zcash Founders' Reward ¹² have been donated to the Foundation. These coins will be distributed incrementally over the next 3 and ⅔ years, until November 2021. The total amount donated is 273,000 ⓩ coins. At today's price ($49/ZEC) that would be worth more than $13 million!
This has been made possible by donations from some of the founders of the Zcash project. I personally have donated half of all of the coins I was due to get from the Founders' Reward, and many of my colleagues have donated as generously or even more so!
The initialBoard of Directors of the Foundation is four of the people that I most trust and respect in the field. I personally am not a director of the Foundation, and none of the Directors are employees of the Zcash Company. Nor do I or the Zcash Company have the ability to defund the Foundation. So, it is already, at its birth, independent of me and of the Company.
Please read the Foundation'sHello World blog post to see their initial plans and how you can get involved and help make Zcash live up to its potential!

Spinning Off Our Sibling Company
The Zcash company grew out of a company named “Least Authority”. It was when we were Least Authority that we did a security audit of EthereumCryptoCat, GlobalLeaksSpiderOak, and Ooni). Least Authority also developed the advanced cryptographicallyprotected, decentralized file store, TahoeLAFS.
When we formed a new company to launch Zcash (the “Zerocoin Electric Coin Company”, a.k.a. “The Zcash Company”), we split off from Least Authority and at first I tried to continue acting as the CEO of both companies at once. Perhaps I was influenced by the legends of Elon Musk and Jack Dorsey, two people who currently serve as CEOs of two different companies.
But you know what? No way was that going to work. The runup to the Zcash launch consumed all of my time and attention, and the Least Authoritarians continued to develop their cuttingedge open source technology, but they had to do so without any business support from me.
Therefore I'm delighted to announce that our sibling company, Least Authority, now has a new fulltime CEO: Liz Steininger. I've worked with Liz before on Internet freedom technology; I trust her ethics and her judgment. Her excellent skills at organization, planning, and business are a good match for the excellent cryptography and coding skills of the other Least Authoritarians.
Least Authority has incorporated in Berlin, Germany (the world capitol for Internet freedom hackers) and launched a new web site. The team continues to do specialized security audits and create freedomcompatible technologies, and has some big things in the works that you'll hear more about soon, including a userfriendly way to use their secure storage product.
Right now you can sign up for Least Authority's “S4” service, which is a cloud storage service built on top of Amazon S3, with the addition of our advanced open source endtoend encryption so that your data is never exposed to snooping or injection.
(P.S. For fans of cryptocurrency history, here's that time I posted about TahoeLAFS on BitcoinTalk.org back in 2010 and Satoshi Nakamoto replied.)

Zcash Release v1.0.8
Download

Explaining SNARKs Part III: The Knowledge of Coefficient Test and Assumption
In Part II, we saw how Alice can blindly evaluate the hiding \(E(P(s))\) of her polynomial \(P\) of degree \(d,\) at a point \(s\) belonging to Bob. We called this "blind" evaluation, because Alice did not learn \(s\) in the process.
However, there was something missing in that protocol  the fact that Alice is able to compute \(E(P(s))\) does not guarantee she will indeed send \(E(P(s))\) to Bob, rather than some completely unrelated value.
Thus, we need a way to "force" Alice to follow the protocol correctly. We will explain in part IV precisely how we achieve this. In this post, we focus on explaining the basic tool needed for that  which we call here the Knowledge of Coefficient (KC) Test.
As before, we denote by \(g\) a generator of a group \(G\) of order \(G=p\) where the discrete log is hard. It will be convenient from this post onwards to write our group additively rather than multiplicatively. That is, for \(\alpha\in\mathbb{F}_p,\) \(\alpha\cdot g\) denotes the result of summing \(\alpha\) copies of \(g.\)
The KC Test
For \(\alpha\in\mathbb{F}_p^*\) [1], let us call a pair of elements \((a,b)\) in \(G\) an \(\alpha\)pair if \(a,b \neq 0\) and \(b=\alpha\cdot a.\)
The KC Test proceeds as follows.
 Bob chooses random \(\alpha\in\mathbb{F}_p^*\) and \(a\in G.\) He computes \(b=\alpha\cdot a.\)
 He sends to Alice the "challenge" pair \((a,b).\) Note that \((a,b)\) is an \(\alpha\)pair.
 Alice must now respond with a different pair \((a',b')\) that is also an \(\alpha\)pair.
 Bob accepts Alice's response only if \((a',b')\) is indeed an \(\alpha\)pair. (As he knows \(\alpha\) he can check if \(b'=\alpha\cdot a'.)\)
Now, let's think how Alice could successfully respond to the challenge. Let's assume for a second that she knew \(\alpha.\) In that case, she could simply choose any \(a'\) in \(G,\) and compute \(b'=\alpha\cdot a';\) and return \((a',b')\) as her new \(\alpha\)pair.
However, as the only information about \(\alpha\) she has is \(\alpha\cdot a\) and \(G\) has a hard discrete log problem, we expect that Alice cannot find \(\alpha.\)
So how can she successfully respond to the challenge without knowing \(\alpha?\)
Here's the natural way to do it: Alice simply chooses some \(\gamma\in\mathbb{F}_p^*,\) and responds with \((a',b')=(\gamma\cdot a,\gamma\cdot b).\)
In this case, we have:
\(b'=\gamma \cdot b = \gamma \alpha \cdot a = \alpha (\gamma\cdot a) =\alpha \cdot a',\)
so indeed \((a',b')\) is an \(\alpha\)pair as required.
Note that if Alice responds using this strategy, she knows the ratio between \(a\) and \(a'\). That is, she knows the coefficient \(\gamma\) such that \(a'=\gamma\cdot a.\)
The Knowledge of Coefficient Assumption [2] (KCA) states that this is always the case, namely:
KCA: If Alice returns a valid response \((a',b')\) to Bob's challenge \((a,b)\) with nonnegligible probability over Bob's choices of \(a,\alpha\), then she knows \(\gamma\) such that \(a'=\gamma\cdot a.\)
The KC Test and Assumption will be important tools in Part IV.
What does "Alice knows" mean exactly?
You may wonder how we can phrase the KCA in precise mathematical terms; specifically, how do we formalize the notion that "Alice knows \(\gamma\)" in a mathematical definition?
This is done roughly as follows: We say that, in addition to Alice, we have another party which we call Alice's Extractor. Alice's Extractor has access to Alice's inner state.
We then formulate the KCA as saying that: whenever Alice successfully responds with an \(\alpha\)pair \((a',b'),\) Alice's Extractor outputs \(\gamma\) such that \(a'=\gamma\cdot a.\) [3]
\(\mathbb{F}_p^*\) denotes the nonzero elements of \(\mathbb{F}_p\). It is the same as \(\mathbb{Z}_p^*\) described in Part I.
[1] This
is typically called the Knowledge of Exponent Assumption in the
literature, as traditionally it was used for groups written
multiplicatively.[2] [3]The
fully formal definition needs to give the Extractor "a little slack"
and states instead that the probability that Alice responds successfully
but the Extractor does not output such \(\gamma\) is negligible.Author,
Ariel Gabizon

BIP199 for Hashed Timelocked Contracts
Hashed Timelocked Contracts (HTLC) are a wellknown and simple technique for building protocols for atomic swaps. They allow you to pay another party for some information (generally, a key) with a condition that allows you to receive your money back if the party does not cooperate.
HTLCs are a fundamental tool in the Lightning network, in zeroknowledge contingent payments (ZKCP) like the one we performed last yearthat we announced last month. One of the first steps forward is the inclusion of general HTLC functionality in the Bitcoin Core wallet.
This week, our submitted BIP199 draft was merged. We also have a workinprogress reference implementation in the Bitcoin Core wallet. HTLCs can be used today without any changes to the Bitcoin protocol, so these proposals and implementations are for standardizing best practices and ecosystem compatibility.
Check out the current BIP text here: https://github.com/bitcoin/bip...
Overview of HTLC
HTLC scripts look like this:
1 2 3 4 5 6 7
OP_IF [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash> OP_ELSE <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash> OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG
HASHOP is a hashing algorithm (RIPEMD, SHA256), and TIMEOUTOP is either OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY. This script allows the "buyer" to purchase the preimage to <digest> by forcing the seller to reveal it when they claim their funds. If the seller doesn't reveal it, the buyer can get their money back after the timeout period.
It's easy to see how crosschain atomic swaps can be built with this mechanism:
 Alice randomly samples K, the key. She hashes it, producing X.
 Alice creates a transaction paying Bob 1 BTC, with a timeout of 1 day, to produce the preimage of X.
 Bob waits for Alice's transaction to appear in the Bitcoin blockchain, and then submits an HTLC transaction paying Alice 0.02 ZEC for the preimage of X with a smaller timeout of half a day.
 Once Bob's transaction appears in the Zcash blockchain, Alice can obtain her ZEC. The script forces her to reveal K.
 Once Bob sees Alice's reveal of K, he can obtain his BTC.
The timeouts are selected so that Bob always has an opportunity to obtain a refund before Alice. Otherwise, Alice could wait to obtain her refund, and then claim Bob's money by revealing K.
Having contracts like HTLCs standardized and included in Bitcoin and Zcash will help both of our communities build exciting technologies like decentralized exchanges.
Author,
Sean Bowe

March 31, 2017  Dev update
This week saw the release of 1.0.8, so update your nodes if you haven’t yet! The release includes support not mentioned in previous updates: Tor ephemeral hidden services (PR 2177) which makes it easier for users to run nodes over Tor.
We also released in our blog Explaining SNARKs Part III: The Knowledge of Coefficient Test and AssumptionBIP199 for Hashed Timelock Contracts. HTLC is an important step towards an implementation of XCAT with Zcash and Bitcoin.
In preparation for a Payment Offloading proof of concept, we started work on a Javascript implementation of Zcash which will be available upon completion. This work is being based off of BitcoinJS and beyond the primary goal of moving towards a payment offloading PoC, will offer applications an officially supported JS library for Zcash integration.
We also have plans for reworking some of the website including the new Privacy & Security Recommendations page after receiving some great feedback and improved funneling for new users looking to get started with Zcash.
We’re also making some final touches on a new section of the website dedicated to a highlevel overview of zkSNARKs.
Finally, don’t forget that we’re doing our second Show & Tell featuring zmsg later today at 3pm PST/ 6pm EST/ 10pm UTC!

Zcash for Windows Beta v1.0.8 is now Available
I just uploaded the Beta of zcash4win, my allinone installer that bundles zcash 1.0.5, uses a fork of the SwingUIWallet by @vaklinov for the GUI wallet, downloads the proving keys in the GUI, setups up zcash.conf for a nonmining full node by default, and bundles the needed java runtime.
Its at: https://zcash4win.com280
The msi installer file for the beta isn't signed yet, so it will throw up "Unknown publisher" warnings and complain about that. The final release will be signed, we're still working on that.
The sha256 hash of the beta installer file, zcash4win1.0.5.msi is: acb8e624fc12fa2dca951071bf2015ba7b933187b625c03f3fc39daa7d47ce2f
It doesn't create a shortcut for the launcher, which is ###code#
You must have 64bit Windows 7 or newer (tested on Windows 10 and 2k16 Server)
Please report any issues here or via email to me at [email protected]
Thanks to the Zcash community for all your support the last few months, its been a long slog getting to this point, but we finally have Zcash on Windows!
Cheers,
David Mercer Tucson, AZ
PS As always, I don't have a day job and do this strictly for donations!
https://zcash.mercerweiss.com/index.html#DonationsBy,
If You Like Donate To me Here the address
BTC: 1H9AFcYdZb6mt3wDHg1hc2AjnqrXzmv4xo
ETH: 0x2587512b27867c2d466c02ccf11424002baac8b4
ZEC: t1RnYixipZn3LrDdXkdLnR7JUSrCxo26W97

Bellman: zkSNARKs in Rust
Bellman is a Rustlanguage library for building zkSNARKs small, cheaptoverify zeroknowledge proofs of arbitrary computations. The goal of bellman is to make it easier for the general public to use and
experiment with zkSNARKs, and also as a step forward for improving the security and performance of Zcash's next major release, Sapling.
Bellman contains an implementation of the BLS12381 elliptic curve construction that we described scientists. This construction was designed specifically for efficiently
building zkSNARKs, while maintaining a high security margin.This week, I've added a primitive implementation of a new zkSNARK proving system
designed by Jens Groth. Secure in the generic group model, the new
design produces smaller proofs that can be constructed faster and with
less memory.Overview of zkSNARKs
If you're interested in how zkSNARKs work internally, Ariel Gabizon has been writing a series of blog posts about the underlying math that you should check out! For now, we can understand them on a surface level.
zkSNARKs are powerful proofs that, unlike other zeroknowledge proving schemes, are very small (a couple hundred bytes) and cheap to verify (several milliseconds), even if the statement being proven is large and complicated. Their zeroknowledge property allows the prover to hide details about the computation from the verifier in the process, and so they are useful for both privacy and performance.
The only such schemes known to be efficient are preprocessing. In a sense, this means that a kind of "environment" must be constructed which allows the prover to evaluate the statement and produce a proof. There is no known way to construct such an environment without necessarily being temporarily in possession of information that would allow you to construct false proofs.
Zcash, which uses zkSNARKs for its shielded transactions, uses parameters that were constructed in a sophisticated multiparty computation ceremony that you can read about here. zkSNARKs are also useful in the designated verifier model, where the verifier itself constructs the needed parameters, and so neither the prover nor the verifier are concerned about its integrity.
In many zkSNARK schemes, the statement being proven is reduced to what is called a rank1 quadratic constraint system, or R1CS. In this system, the prover is given a system of arithmetic constraints over a set of variables (elements in a large prime field Fr" role="presentation">Fr
), and asked to produce an assignment to the variables which satisfies the constraints.
Overview of Bellman
Bellman is currently in its infancy, but we can already use it to construct these kinds of proofs. Currently, only a very low level API is available, upon which we can construct DSLs and various abstractions for synthesizing circuits. If you want to experiment with it, grab the bellman crate from crates.io.
All of our circuit abstractions are written generically over an Engine trait that handles the elliptic curve and finite field arithmetic. Central to circuit synthesis is the ConstraintSystem trait:
1 2 3 4 5 6 7 8 9 10 11 12 13
pub trait ConstraintSystem<E: Engine> { /// Allocate a private variable in the constraint system, setting it to /// the provided value. fn alloc(&mut self, value: E::Fr) > Variable; /// Enforce that `A` * `B` = `C`. fn enforce( &mut self, a: LinearCombination<E>, b: LinearCombination<E>, c: LinearCombination<E> ); }
There are two important design decisions here:
 All variable allocation, assignment, and constraint enforcement is done over the same code path. This differs from the design of libsnark’s gadgetlib, for which it was too easy to potentially forget a constraint or notice bugs in existing abstractions because of the separation. This approach makes it easier to write abstractions and perform code review.
 All variable allocation and assignment are done simultaneously, and the existing assignments cannot be queried or modified. This encourages better gadget design, and prevents gadgets from accidentally using the assignments to “communicate” with each other. This also has a performance benefit: since all variables are already assigned, constraint enforcement during proving is directly synthesized into the underlying witnesses to avoid having to keep a constraint system in memory at all.
As an example of a kind of gadget implementation, here's how a boolean constrained variable could be implemented, along with XOR:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55
#[derive(Clone)] pub struct Bit { var: Variable, value: bool } impl Bit { pub fn alloc<E, CS>(e: &E, cs: &mut CS, value: bool) > Bit where E: Engine, CS: ConstraintSystem<E> + ?Sized { // Allocate the variable let var = cs.alloc( if value { E::Fr::one(e) } else { E::Fr::zero() } ); // Enforce (1  var) * var = 0, which requires // var to be either 0 or 1 cs.enforce( LinearCombination::one(e)  var, LinearCombination::zero(e) + var, LinearCombination::zero(e) ); Bit { var: var, value: value } } pub fn xor<E, CS>(&self, e: &E, cs: &mut CS, other: &Bit) > Bit where E: Engine, CS: ConstraintSystem<E> { let new_value = self.value ^ other.value; let new_var = cs.alloc( if new_value { E::Fr::one(e) } else { E::Fr::zero() } ); // 2a * b = a + b  c cs.enforce( LinearCombination::zero(e) + self.var + self.var, LinearCombination::zero(e) + other.var, LinearCombination::zero(e) + self.var + other.var  new_var ); Bit { var: new_var, value: new_value } } }
Building a circuit is a matter of implementing the Circuit and Input traits:
1 2 3 4 5 6 7 8 9 10 11
pub trait Circuit<E: Engine> { type InputMap: Input<E>; fn synthesize<CS: ConstraintSystem<E>>(self, engine: &E, cs: &mut CS) > Self::InputMap; } pub trait Input<E: Engine> { fn synthesize<CS: PublicConstraintSystem<E>>(self, engine: &E, cs: &mut CS); }
This design splits up circuits into a Circuit implementation, which provers instantiate to construct proofs, and a Input implementation, which provers and verifiers use to perform input allocation and related circuit synthesis. This differs from libsnark, where these code paths are redundant, use different utility functions and require careful code review to ensure consistency.
Once we actually do have an implementation of Circuit and Input, we can use the functions provided in the groth16 module: create a keypair (with some randomly selected trapdoors), construct a proof, and perform verifications:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
// Create a proving key and verifying key let (pk, vk) = { let tau = E::Fr::random(e, rng); let alpha = E::Fr::random(e, rng); let beta = E::Fr::random(e, rng); let gamma = E::Fr::random(e, rng); let delta = E::Fr::random(e, rng); let c = DummyCircuit; groth16::keypair(e, c, &tau, &alpha, &beta, &gamma, &delta) }; // Construct a proof let proof = { let r = E::Fr::random(e, rng); let s = E::Fr::random(e, rng); let c = DummyCircuit; groth16::prove(e, c, &r, &s, &pk).unwrap() }; // Prepare the verifying key let pvk = groth16::prepare_verifying_key(e, &vk); // Verify proof assert!(groth16::verify(e, cs { DummyInput }, &proof, &pvk));
Future work
These lower level foundations are all that is available in Bellman right now. In the future we will be writing tools which allow us to build things like hash functions and stream ciphers.
Bellman is still under development and shouldn’t be used in production software yet. In fact, its API deliberately does not expose anything that would allow you to actually use it! It currently serves as an excellent learning opportunity for constructing zkSNARKs safely and efficiently, and the lessons we learn from building it will shape the future of Zcash.
We’re also excited to be writing Bellman in Rust! If you’re a Rustacean and you’re interested in zkSNARKs or Zcash, we invite you to check out our project
join our community chat or look at some of the various things we’ve written in Rust before, like our or look at some of the various things we’ve written in Rust before, like our multiparty computation ceremony code.

ZCash Release MacOS v1.0.83
Contents
ZCash v1.0.8 built from scratch with gcc6.3.0/g++6.3.0 Vaklinov’s ZCash GUI Wallet 0.68 added to precompiled bundle ZCash GUI Wallet needs Java and should be allowed to run via "Security & Privacy Settings" under System Preferences
 ZCash v1.0.886835e20b2c9240ad0826409572bb832e9f0e673
 Berkeley DB 6.2.23
 Boost 1.63.0
 GMP 6.1.2
 GoogleTest/GoogleMock 1.8.0
 Libevent 2.1.8stable
 Librustzcash commit 91348647a86201a9482ad4ad68398152dc3d635e9ada3f84ab484c57b2247c2f41091fd6a0916573
 Libsodium 1.0.12
 LibZMQ 4.2.2
 MiniUPNPC 2.0.20161216
 OpenSSL 1.1.0e
How to use
When launching
Zcash
on MacOS for the first time, certain initalization steps should be completed. Please run the commands below once for the first time$ cd out/usr/local/bin
$ ./zcashfetchparams
$ ./zcashinit
$ ./zcashd
You can just run
ZCash
by launching the daemon afterwards$ ./zcashd
Downloads

ZCash Updated Exchanges List
Below is a nonexhaustive list of exchanges supporting ZCash (as of April 2017):
Allcoin – https://www.allcoin.com
Alcurex – https://alcurex.com
Bitfinex – https://www.bitfinex.com/
Bitlish – https://bitlish.com/
Bitnow – https://bitnow.co.nz/
Bittrex – https://bittrex.com/
Bitsquare – https://bitsquare.io
BTC Alpha – https://btcalpha.com
BTER – https://bter.com
BX Thailand – https://bx.in.th
Changelly – https://changelly.com/
Coinexchange – https://www.coinexchange.io
Cryptonator – https://www.cryptonator.com/
Cryptopia – https://www.cryptopia.co.nz
Freewallet – https://freewallet.org/
HitBTC – https://hitbtc.com/
Kraken – https://www.kraken.com/
LZF – LZF.com
Poloniex – https://poloniex.com/
ShapeShift – https://shapeshift.io
The Rock – https://www.therocktrading.com
TradeSatoshi – https://tradesatoshi.com
TuxExchange – https://tuxexchange.com
USDX – https://www.usdx.com
Waterhole – https://waterhole.io/
Yobit – https://yobit.net
Yuanbao – https://yuanbao.com
YUNBI – https://yunbi.com

Zcash (ZEC) New mining pool (0% fees)
We are a completely costumer centric multiple algorithm mining pool offering our services at 0% fees until we go public. We are currently in beta phase and we are calling all miners to test out our pool.
Salient features of the pool : 1) 0% fees in beta phase. 2) after the beta phase a minimal 2% fees will be applied. 3) 10% of the fees will go to charity 4) one of the only pools with nicehash integration. 5) integrated custom built pool chat. 6) Ssl integration on all the algorithms. 7) shapeshift integration under development. 8) vardiff available on all pools. 9) dedicated unix systems engineer 10) MRR integration under development.
Join us now and avail the early bird benefits.
https://cryptopool.io/

ZCASH [ZEC] Security Announcement 20170412
Update announcement
We have deployed detectors to learn more about the issue and still have no evidence of malicious exploitation.
We are working with our partners on the continued investigation and we will post another update tomorrow.
Initial announcement
We have identified a vulnerability in the Zcash client.
We have not seen any evidence of this vulnerability being exploited in the wild and the engineering team is currently investigating the issue.
We will post more information when available.
By,
Zooko Wilcox