Updated details [ZEC] ZCASH + Announcing Zcash Cloud Mining

  • Zcash and Jaxx Announce ZEC approved and live on iOS Appstore

    Toronto, ON – April 12, 2017 – Today marks another historic day for Zcash as the privacy-oriented cryptocurrency announces its approval on the App Store via Jaxx’s iOS platform.

    The team behind Zcash includes some of the leading scientists behind the advanced zero-knowledge technology used in the protocol. Together with expert engineers, they are continuously researching and developing improvements to the infrastructure and usability for users and third-party services like Jaxx.

    Zooko Wilcox, CEO of the company behind Zcash development, Zerocoin Electric Coin Company, said, “Jaxx is a very simple, easy-to-use wallet and the team behind it has been a pleasure to work with. I’m delighted that thanks to them, hundreds of millions of iPhone users can, for the first time send and receive Zcash from their phones.”

    Jaxx was the first wallet to integrate Zcash following its mainnet launch on October 28, 2016, and is thrilled to now have Zcash available on its iOS platform. Apple has a rigorous approval process, especially for allowing cryptocurrencies onto the App Store, and their approval is a clear indication that Zcash is a fast growing and well respected technology.

    Anthony Diiorio, CEO of Jaxx, said, “The privacy aspect of their technology meshes really well with Jaxx’s philosophies. We’ve been working on a Zcash-integrated iOS version for a long time and we’re over the moon that Zcash has been approved on the App Store.”

    Jaxx also confirmed today that they are in talks with Zcash on the possibility of supporting ZEC shielded addresses. Currently, Jaxx supports transparent addresses which behave similarly to Bitcoin, publishing transaction data publicly to the blockchain. While the mere use of shielded addresses by others provide greater privacy for transparent addresses compared to Bitcoin, official support for shielded addresses in Jaxx will significantly enhance capabilities for users.

    “Zcash is a very well run project and it’s been an absolute pleasure to work with Zooko and team. We look forward to continuous collaboration between our two projects, especially for when we implement Zcash’s shielded addresses,” said Diiorio.

    In addition to being integrated on all of Jaxx’s platforms, Zcash also announced its integration on a second wallet, SmartWallet, a Brazilian money application.

    Jaxx’s iOS version with Zcash is now available for download via jaxx.io or on the Apple App Store.

    Zcash CEO Zooko Wilcox and Jaxx CEO Anthony Diiorio are available for interview.

    About Zcash:

    The Zcash Company is a science-driven team; a combination of academic expertise in computer science and cryptography with security software engineering talent. We are developing the next generation of secure digital currency and blockchain technology through the use of zero-knowledge proofs, to guarantee privacy and confidentiality. We aim to set a new standard for privacy. The Zcash protocol is a decentralized and open-source cryptocurrency offering total payment confidentiality. Unlike Bitcoin, Zcash transactions automatically hide the sender, recipient, and value of all transactions on the blockchain. It is based on peer-reviewed cryptographic research, and built by a world-class, security-focused engineering team. However, as with any new technology, there is risk involved. Currently the team is focused on building and maintaining an open, permissionless system that is viable, robust, and justifiably reliable and secure for users.

    About Jaxx:

    Jaxx is a multi-token blockchain wallet that provides a unified experience across 9 platforms and devices, including Windows, Apple and Linux desktops, Apple and Android mobile devices and tablets, as well as Google Chrome and Firefox extensions. The Jaxx wallet enables crypto-to-crypto exchange with frictionless in-wallet conversion via Shapeshift. Users are always in control of their keys and Jaxx neither holds nor has access to customer funds. Design and user experience driven, and built with simplicity in mind, Jaxx’s mission is to become the interface to the blockchain world.

    To learn more, visit jaxx.io

    Jaxx Press Contact

    Annie Lee

  • Zcash (ZEC) Pre Release  v1.0.8-1


  • Security Announcement 2017-04-13

    Synopsis: A bug related to transaction priority handling may allow an attacker to crash Zcash nodes (DoS) via a specially crafted transaction. A fix is implemented in zcashd release 1.0.8-1.

    There is a separate release post documenting the included changes.

    ZcashCo, and several exchanges, wallet vendors, and miners have already deployed a mitigation as well as detectors for this attack vector. No attacks have been detected.

    Who is at Risk: Users are at risk who rely on zcashd releases starting with 1.0.4 up to and including 1.0.8.

    We have collaborated with major exchanges, wallet providers, and miners and they have already mitigated this issue for their services.

    Who is not at Risk: Users who have upgraded to zcashd 1.0.8-1, or rely on a service which has done so are not at risk.

    How can at-risk users protect themselves?

    1. Upgrading to zcashd release 1.0.8-1 is the most certain protection.
    2. For users of third party services (such as exchanges, wallets, or mining pools), check if the service has announced upgrading to zcashd 1.0.8-1.

    How can I tell if an attack is occurring? ZcashCo and several large exchanges, wallet providers, and miners have deployed sensors which detect attacks against this vector. In the event that an attack is detected, the ZcashCo will take the following actions:

    • The Zcash developers will issue an in-band alert, causing all zcashd nodes to announce the potential attack.

    • ZcashCo will always announce known ongoing attacks in these places:

    • ZcashCo will coordinate in private channels with major exchanges, wallet vendors, and mining outfits to alert them of the attack and to post their own announcements.

    Note: The major exchanges, wallet vendors, and miners we are in communication with are already protected against such an attack.

    Impact: If an attack transaction is successfully executed then only the users running vulnerable clients which have accepted the transaction in their mempool will be vulnerable. Accepting an attacker's transaction with an old client may cause the Zcash client to crash.

    Technical Background: Zcash, like Bitcoin, assigns a priority to transactions in order to decide whether they should be accepted into a node's mempool. In practice the current transaction volume for Zcash is sufficiently low that this rarely has an effect, but the mechanism is still enabled. In Zcash 1.0.4, a change was made to this calculation to boost the priority of shielded transactions. However, an error in this code can –in circumstances that are normally rare, but can be forced by an attacker– result in an out-of-bounds memory access, which causes a segmentation fault.

    Followup Announcements:

    • See the security notifications page for further updates on this issue, and any future security issue.
    • Continue to check this blog.

  • Zcash Announces Apple App Store Approval on Jaxx’s iOS Platform

    An exciting update for the Zcash ecosystem comes from the Jaxx team. Jaxx were one of the very first wallets to support Zcash, implementing it into their Android and desktop wallets only days after the Zcash launch on October 28th.

    In their initial statement announcing integration with Zcash, they indicated upcoming support in their iOS wallet and today, Zcash on Jaxx for iOS is live!

    Anthony Di Iorio, CEO of Jaxx, says, "The privacy aspect of their technology meshes really well with Jaxx’s philosophies. We’ve been working on a Zcash integrated iOS version for a long time and we’re over the moon that Zcash has been approved on the App Store."

    Jaxx for iOS has 32,000 users and growing. With the inclusion of Zcash, now hundreds of millions of users have the ability to send and receive Zcash from their iPhones.

    Jaxx has additionally confirmed their interest in supporting shielded addresses in the future. As more wallets with easy-to-use interfaces introduce shielded addresses into their software, not only will the users of those applications gain enhanced privacy for transactions they send and receive but also, the ecosystem as a whole will become more private.

    We are excited about the expansion of Zcash into additional operating systems and hope to see this trigger more support for Zcash in iOS moving forward.

    Jaxx for iOS joins a growing list of third-party GUI applications supporting Zcash 

    Wallets considering adding Zcash support should reach out to us in emailcommunity chat, we'd be happy to help!

    For more details, see the full press release from Jaxx.

  • Zcash [ZEC] 1.0.9 Postponed

    We have decided to postpone the Zcash Sprout 1.0.9 release from today's planned release date to mid-May.

    We have been planning a transition in May of our release process and policies to improve our collaborations with community and industry partners, to improve safety, and to prepare for our Sapling protocol upgrade. Due to the v1.0.8-1 hotfix release last week, it makes the most sense to postpone 1.0.9 until the new process is in place.

    We'll post an announcement of the new release process and policies ahead of the 1.0.9 release. We have exciting features and collaborations underway. Stay tuned!

  • ZCASH [ ZEC] Payment Contexts & Reusing Shielded Addresses

    The privacy provided in Zcash allows users to disclose a shielded
    payment address publicly or to multiple individuals without the worry of
    transactions sent to that address becoming linked in the blockchain.
    When sending to or from a shielded address, the data involved in that
    side of the transaction is encrypted (regardless if receiving from or
    sending to a transparent address).

    Distinct Payment Contexts

    While shielded addresses are encrypted, the scope of the payment address is something to consider.

    If Alice has a small business she runs out of her home, any business mail sent to her home address provides a clear link between her personal life and business even if the details of the correspondences are secured in envelopes. In a similar fashion, if Alice has a business which accepts Zcash for services or products and personal blog which she posts the same Zcash address for accepting donations to, it is possible for a third-party to correlate the business and blog.

    It is therefore recommended for Alice to use separate payment addresses for her business and blog, similar to having a separate business address (such as a private mailbox) for receiving business correspondence.

    Reusing Shielded Addresses

    Note that it is advisable to reuse shielded addresses for receiving payments within the same context. While it has become standard practice for generating a new address for each receiving transaction in most cryptocurrencies, that is not a problem when using shielded addresses. In fact, it saves the extra hassle of tracking many different addresses and reduces the number of outputs consumed when creating a new transaction. This reduction makes overall transaction size smaller and requires less resources for generating a zero-knowledge proof.

    A great example of this distinction can be seen on the donations page for the non-profit Riseup.net. When a supporter goes to make a bitcoin donation, they're provided with a newly generated address but when a supporter makes a Zcash donation, the same shielded address is provided for everyone!

    One Shielded Address Per Purpose

    We encourage folks to follow suit and reuse shielded addresses for accepting Zcash payments within the same context. For contexts which should remain unassociated, however, make sure to keep the shielded addresses unassociated as well.

    For more user privacy considerations, see the Privacy & Security Recommendations.

  • ZCASH [ZEC] - Dev update April 21, 2017

    At the beginning of the week, we had the first of our regularly scheduled (once a month) meetings about the pre-Sapling hard fork (HF0) in which we narrowed down tickets into a select group using the tag HF0 wishlist. These tickets address the meta goal of making HF0 and future hard forks safer and simpler.

    We also had a topical meeting around revamping the release lifecycle and policy An overview of which will be released as a blog post in the very near future. We also touched on the concept of development environments but did not come to a final resolution on their implementation across the areas in which they aim to be used.

    Work on other process-related concepts like roadmapping and security incident procedure were also discussed more this week with the goal of
    releasing public documents outlining them coming in the near future.

    And with last week’s securityincident engineering timesync behind us, regular work on pull-request review and pre-Sapling features (payment disclosure, payment offloading and XCAT) were back in full swing this week.

    We also continued work on the block observatory and testnet faucet mentioned in last week’s update.

    A handful of new FAQs  were added to the website this week and next week, keep an eye out for the initial version of our zk-SNARK section in addition to the newest in the explaining zk-SNARK blog series.

    We’ve also planned a Google hangout and livestream with Zcash engineers to discuss and explain zk-SNARKs in two weeks on May 6th at 16:00 UTC. Those interested can request an invite to join the hangout or post questions as comments in the video beforehand and/or questions in the chat box when the session is live.

    As a reminder, check out the working groups wiki page if you’re interested in becoming more involved in Zcash core development and ecosystem maintenance and growth. Also, don’t forget to ping us if you’d like to be invited to one of our future topical meetings, we’d love to include those from the greater community who are interested!

  • Zcash- Explaining SNARKs Part V: From Computations to Polynomials

    << Part IV

    In the three previous parts, we developed a certain machinery for dealing with polynomials. In this part, we show how to translate statements we would like to prove and verify to the language of polynomials. The idea of using polynomials in this way goes back to the groundbreaking work of Lund, Fortnow, Karloff and Nisan.

    In 2013, another breakthrough work of Gennaro, Gentry, Parno and Raykova defined an extremely useful translation of computations into polynomials called a Quadratic Arithmetic Program (QAP). QAPs have become the basis for modern zk-SNARK constructions, in particular those used by Zcash.

    In this post we explain the translation into QAPs by example. Even when focusing on a small example rather than the general definition, it is unavoidable that it is a lot to digest at first, so be prepared for a certain mental effort :).

    Suppose Alice wants to prove to Bob she knows c1,c2,c3∈Fp" role="presentation">c1,c2,c3∈F###i


    such that
    (c1⋅c2)⋅(c1+c3)=7" role="presentation">(c1⋅c2)⋅(c1+c3)=7.
    The first step is to present the expression computed from c1,c2,c3" role="presentation">c1,c2,c3 as an arithmetic circuit.

    Arithmetic circuits

    An arithmetic circuit consists of gates computing arithmetic operations like addition and multiplication, with wires connecting the gates. In our case, the circuit looks like this:

    The bottom wires are the input wires, and the top wire is the output wire giving the result of the circuit computation on the inputs.

    As can be seen in the picture, we label the wires and gates of the circuit in a very particular way, that is needed for the next step of translating the circuit into a QAP:

    • When the same outgoing wire goes into more than one gate, we still think of it as one wire - like w1" role="presentation">w1
  • in the example.
  • We assume multiplication gates have exactly two input wires, which we call the left wire and right wire.
  • We don't label the wires going from an addition to multiplication
    gate, nor the addition gate; we think of the inputs of the addition gate
    as going directly into the multiplication gate. So in the example we
    think of w1" role="presentation">w1
  • and w3" role="presentation">w3 as both being right inputs of g2" role="presentation">g2
    • .

    A legal assignment for the circuit, is an assignment of values to the labeled wires where the output value of each multiplication gate is indeed the product of the corresponding inputs.

    So for our circuit, a legal assignment is of the form: (c1,…,c5)" role="presentation">(c1,…,c5)

    where c4=c1⋅c2" role="presentation">c4=c1⋅c2 and c5=c4⋅(c1+c3)" role="presentation">c5=c4⋅(c1+c3)


    In this terminology, what Alice wants to prove is that she knows a legal assignment (c1,…,c5)" role="presentation">(c1,…,c5)

    such that c5=7" role="presentation">c5=7

    . The next step is to translate this statement into one about polynomials using QAPs.

    Reduction to a QAP

    We associate each multiplication gate with a field element: g1" role="presentation">g1

    will be associated with 1∈Fp" role="presentation">1∈F###i

    /i### and g2" role="presentation">g2 with 2∈Fp" role="presentation">2∈F###i

    /i###. We call the points {1,2}" role="presentation">{1,2} our target points. Now we need to define a set of "left wire polynomials" L1,…,L5" role="presentation">L1,…,L5, "right wire polynomials" R1,…,R5" role="presentation">R1,…,R5 and "output wire polynomials" O1,…,O5" role="presentation">O1,…,O5


    The idea for the definition is that the polynomials will usually be zero on the target points, except the ones involved in the target point's corresponding multiplication gate.

    Concretely, as w1,w2,w4" role="presentation">w1,w2,w4

    are, respectively, the left, right and output wire of g1" role="presentation">g1;
    we define L1=R2=O4=2−X" role="presentation">L1=R2=O4=2−X, as the polynomial 2−X" role="presentation">2−X is one on the point 1" role="presentation">1 corresponding to g1" role="presentation">g1 and zero on the point 2" role="presentation">2 corresponding to g2" role="presentation">g2


    Note that w1" role="presentation">w1

    and w3" role="presentation">w3 are both right inputs of g2" role="presentation">g2.
    Therefore, we define similarly L4=R1=R3=O5=X−1" role="presentation">L4=R1=R3=O5=X−1 - as X−1" role="presentation">X−1 is one on the target point 2" role="presentation">2 corresponding to g2" role="presentation">g2

    and zero on the other target point.

    We set the rest of the polynomials to be the zero polynomial.

    Given fixed values (c1,…,c5)" role="presentation">(c1,…,c5)

    we use them as coefficients to define a left, right, and output "sum" polynomials. That is, we define

    L:=∑i=15ci⋅Li,R:=∑i=15ci⋅Ri,O:=∑i=15ci⋅Oi" role="presentation">L:=∑5i=1ciLi,R:=∑5i=1ciRi,O:=∑5i=1ciOi


    and then we define the polynomial P:=L⋅R−O" role="presentation">###i



    Now, after all these definitions, the central point is this: (c1,…,c5)" role="presentation">(c1,…,c5)

    is a legal assignment to the circuit if and only if P" role="presentation">###i


    vanishes on all the target points.

    Let's examine this using our example. Suppose we defined L,R,O,P" role="presentation">L,R,O,###i


    as above given some c1,…,c5" role="presentation">c1,…,c5.
    Let's evaluate all these polynomials at the target point 1" role="presentation">1


    Out of all the Li" role="presentation">Li

    's only L1" role="presentation">L1 is non-zero on 1" role="presentation">1.
    So we have L(1)=c1⋅L1(1)=c1" role="presentation">L(1)=c1⋅L1(1)=c1.
    Similarly, we get R(1)=c2" role="presentation">R(1)=c2 and O(1)=c4" role="presentation">O(1)=c4


    Therefore, P(1)=c1⋅c2−c4" role="presentation">###i


    A similar calculation shows P(2)=c4⋅(c1+c3)−c5" role="presentation">###i



    In other words, P" role="presentation">###i


    vanishes on the target points if and only if (c1,…,c5)" role="presentation">(c1,…,c5)

    is a legal assignment.

    Now, we use the following algebraic fact: For a polynomial P" role="presentation">###i


    and a point a∈Fp" role="presentation">a∈F###i

    /i###, we have P(a)=0" role="presentation">###i

    /i###(a)=0 if and only if the polynomial X−a" role="presentation">Xa divides P" role="presentation">###i

    /i###, i.e. P=(X−a)⋅H" role="presentation">###i

    /i###=(Xa)⋅H for some polynomial H" role="presentation">H


    Defining the target polynomial T(X):=(X−1)⋅(X−2)" role="presentation">T(X):=(X−1)⋅(X−2)

    , we thus have that T" role="presentation">T divides P" role="presentation">###i

    /i### if and only if (c1,…,c5)" role="presentation">(c1,…,c5)

    is a legal assignment.

    Following the above discussion, we define a QAP as follows:

    A Quadratic Arithmetic Program Q" role="presentation">Q

    of degree d" role="presentation">d and size m" role="presentation">m consists of polynomials L1,…,Lm" role="presentation">L1,…,Lm, R1,…,Rm" role="presentation">R1,…,Rm, O1,…,Om" role="presentation">O1,…,Om and a target polynomial T" role="presentation">T of degree d" role="presentation">d


    An assignment (c1,…,cm)" role="presentation">(c1,…,cm)

    satisfies Q" role="presentation">Q if, defining L:=∑i=1mci⋅Li,R:=∑i=1mci⋅Ri,O:=∑i=1mci⋅Oi" role="presentation">L:=∑mi=1ciLi,R:=∑mi=1ciRi,O:=∑mi=1ciOi and P:=L⋅R−O" role="presentation">###i

    /i###:=LRO, we have that T" role="presentation">T divides P" role="presentation">###i



    In this terminology, Alice wants to prove she knows an assignment (c1,…,c5)" role="presentation">(c1,…,c5)

    satisfying the QAP described above with c5=7" role="presentation">c5=7


    To summarize, we have seen how a statement such as "I know c1,c2,c3" role="presentation">c1,c2,c3

    such that (c1⋅c2)⋅(c1+c3)=7" role="presentation">(c1⋅c2)⋅(c1+c3)=7

    " can be translated into an equivalent statement about polynomials using QAPs. In the next part, we will see an efficient protocol for proving knowledge of a satisfying assignment to a QAP.

    [1]excellent post for more details on the transformation from a program to a QAP.

  • NEW ZCash [ZEC] mining pool located in Czech republic

    Low fee 1.2%
    High performance Node.js backend

    We found 1st block after few hours of runing this pool We are currently mining only ZCash

    Payment from 0.01


  • Zcash-Explaining SNARKs Part V: From Computations to Polynomials

    << Part IV

    In the three previous parts, we developed a certain machinery for dealing with polynomials. In this part, we show how to translate statements we would like to prove and verify to the language of polynomials. The idea of using polynomials in this way goes back to thegroundbreaking work of Lund, Fortnow, Karloff and Nisan.

    In 2013, another breakthrough work of Gennaro, Gentry, Parno and Raykova defined an extremely useful translation of computations into polynomials called a Quadratic Arithmetic Program (QAP). QAPs have become the basis for modern zk-SNARK constructions, in particular those used by Zcash.

    In this post we explain the translation into QAPs by example. Even when focusing on a small example rather than the general definition, it is unavoidable that it is a lot to digest at first, so be prepared for a certain mental effort 

    Read full

  • Zcash [ZEC] Internet Money

    Six months ago today we launched an ambitious attempt to create the future of Internet Money. We dream of giving every human on earth free and equal access to a global, programmable financial system. Internet money is to government money as email is to national postal services.

    Today, exactly six months after launch, is the first day that the Zcash market cap reached $100M.

    The history of the Zcash market cap, from https://coinmarketcap.com/curr...

    We’re all extremely excited and proud of our baby blockchain for coming so far so fast.

    There are currently 1.2 million Zcash coins (ZEC) in existence. At the end of the fourth year of the blockchain (in the year 2020), there will be 10.5 million Zcash in existence. Eventually (many years from now) there will be 21 million total.

    During the first six months of Zcash, our development team has focused on ensuring the security and stability of the network, making improved stable releases of the software

    and supporting third-parties who are building products and services on top of Zcash, such as walletse , exchanges.

    Among the many third parties who are building on top of Zcash, a few have recently announced their progress, including Jaxx deploying Zcash on Apple iPhones and CoinBR deploying Zcash to Brazil and South Africa.

    Jaxx told us that they saw the rate of Zcash transactions by their users quadruple from February to March (the most recent month that they have statistics).

    We have big projects in the works, and so do many of our partners in the large and growing Zcash ecosystem. Stay tuned!

    And remember: even though we created Zcash, we do not own or control it. Humanity is too vast and diverse to accept our economy falling under anyone’s control. Zcash is a decentralized, open-source network that anyone on Earth can use, extend, or modify without needing the permission of anyone else. We started the Zcash project, but its future lies in your hands.

  • ZCASH [ZEC] Release Cycle and Lifetimes

    Starting in May the Zcash development effort will instigate a new release policy. There are a few immediate take-aways for users:

    • We'll release monthly on the third Tuesday, starting with 1.0.9 on May 16th.
    • Each release starting with 1.0.9 will become deprecated 4 months after its release date. [1]
    • We may deprecate releases earlier than this schedule to mitigate security vulnerabilities.

    This is an aggressive upgrade schedule and if it doesn't work for your case, we'd love to hear from you as soon as possible. This is all you need to know as a user, and the

    rest of this post describes our rationale and some protocol upgrade  details

    Better Safety and Quality

    Since our launch we've used a tight three-week release schedule. We've shipped every release within a couple of days of the target date, with the exception of the last postponed 1.0.9 release and an 1.0.8-1 hotfix release.

    Our new process has slightly more time between releases. We'll use
    this extra time to add more thorough pre-release and package testing,
    have a retrospective meeting for each release, and begin per-release
    coordination for each of our longer term roadmap priorities.

    Clearer Coordination

    An essential change with this new policy is an explicit release lifecycle, the most important parts of which are the release date and the deprecation date, about four months later on the 4th third-Tuesday after the release.

    For active releases which have not yet reached their deprecation date, we make our best effort to provide security fixes, follow up to bug reports, avoid disruption on the production network, and help users to upgrade to the latest release. For deprecated releases the only help we promise is in upgrading to the latest release.

    In order to codify this cycle, we even intend to introduce a feature called auto-senescence starting in 1.0.9 which will cause nodes to automatically exit when they detect they've reached their deprecation phase. This feature will always have an opt-out, since (as discussed below) our goal is to give users their own choice, not to coerce or control them.

    An important side-note: this policy is defined entirely in the context of a single release, so a user does not need to know anything about our future releases or our new policies for those releases in order to understand this policy for their own installation.

    User autonomy: deprecation vs auto-upgrade

    We consider user choice to be a paramount value to protect. Although this may sound abstract or overly dramatic it directly affects our technical design choices and plays out as our choice of a deprecation approach, rather than an auto-upgrade approach.

    Auto-upgrade of apps has become widespread, because of numerous advantages. One of the most important advantages is in ensuring old software is rare so that vulnerabilities and technical debt are removed from the network thus making the whole safer.

    Meanwhile, most users rely on default behavior, and a default auto-upgrade puts them de facto under the influence of a sole group of application developers. Most people believe this is fine, and while it often has been, we believe we're seeing a deep shift in de-facto governance due to these kinds of technological developments.

    We prefer deprecation rather than auto-upgrade, where users must themselves choose either to upgrade to our new releases or other people's alternatives. We believe this still gives the systemic advantage of removing old software, yet users must explicitly opt-in to each upgrade, and each time is an opportunity to educate themselves and decide on a different fate.

    How is deprecation better for Zcash?

    Because users and our development community have this agreement, we can begin relying on this schedule for protocol upgrades, security fixes, usability improvements, and removing technical debt.

    Once this policy is put in to place starting with our 1.0.9 release in May, we are on track to begin the protocol upgrade to the Sapling feature set.

    We'll also be able to roll out usability improvements, such as payment disclosure and in several months' time we'll know that support for those improvements should be widespread, and therefore all wallets and vendors will benefit from ecosystem-wide consistency.

    I emphasized "should be" because users may always choose to reject our deprecation policy by editing their local configuration or installing alternative implementations. In that case, we'll have a clear signal from the user community about their reservations with our direction, so this is one of the key mechanisms of our improving governance.

    We'd Love to Hear From You

    Please reach out to us with any feedback on this new release policy. You can find us on the community chatemail.

    [1]We're still determining when and how to deprecate releases before 1.0.9.

  • Zcash [ZEC] New public block explorer

    I've been debating tossing up a public Insight instance for zcash, both because its a block explorer and because there is increasing demand for one that people can use for its API calls for various reasons (broadcasting transactions without having your own full node, various wallet applications, etc).

    The recent performance issues on the network tipped me over into doing so, as zcha.in was having issues because of it and more than one view into the network is a Good Thing!

    Its at https://insight.mercerweiss.co...

    zcha.in has great features Insight doesn't, and Insight has some that it lacks, so I think this is a win for everyone. Its going to cost a bit to run it, especially once traffic on it goes up, so please donate to support it via any of the methods at https://zcash.mercerweiss.com/...

    Thanks again for everyone's support, and let me know if you find any issues with it!

    -David Mercer Tucson, AZ

  • ZCASH [ZEC] NEW Pool | PPLNS | 0.5% Fee | 

    I just added a pool for Zcash https://zec.coin-miners.info HOW TO CONNECT stratum+tcp://stratum2.coin-miners.info:3032 ( Auto VarDiff - for GPU ) stratum+tls://stratum2.coin-miners.info:3033 (SSL Support, Automatic VarDiff - Encrypted stratum is currently only supported by the Claymore and Optiminer miner) Nicehash1 : stratum+tcp://stratum2.coin-miners.info:3034 

    Claymore example : 

    ZecMiner64.exe -zpool stratum2.coin-miners.info:3032 -zwal Weblogin.WorkerName -zpsw x -allpools 1 ZecMiner64.exe -zpool stratum+tls://stratum2.coin-miners.info:3033 -zwal Weblogin.WorkerName -zpsw x -allpools 1 

    Happy mining zcash

  • Zcash - Press release: Zero-knowledge Security Layer to be Added to Quorum Blockchain Platform

    The Zerocoin Electric Coin Company (ZECC), developers of the Zcash™ digital currency, today announced a partnership with J.P. Morgan, one of the world’s largest banks, to add technology from Zcash to J.P. Morgan's enterprise blockchain platform, Quorum.

    This technology will extend Quorum’s existing privacy protections — which already offer private smart contracts — to add cryptographically assured, private settlement of digitized assets on a distributed ledger without a central intermediary.

    Zooko Wilcox, CEO of the Zerocoin Electric Coin Company said, “We’re delighted to be working with J.P. Morgan on this project. Quorum’s innovative, open source design demonstrates that J.P. Morgan is leading the way for applications of distributed ledger technology in global finance. Zcash is the leading technology for cryptographic protection of assets on a distributed ledger. Combining these will unlock transformative possibilities.”

    The team behind Zcash includes many of the scientists and engineers behind the advanced cryptography that enables Zcash’s unique privacy and confidentiality. They recently announced plans to explore potential enterprise applications for this technology. Quorum is the first distributed ledger platform that will feature this zero-knowledge security layer (ZSL). J.P. Morgan's Quorum is an enterprise-ready distributed ledger and smart contract platform, based on the Ethereum protocol. It is open source and can be freely used and extended.

    Quorum has been featured in presentations by the Enterprise Ethereum Alliance. J.P. Morgan is a founding member of the Enterprise Ethereum Alliance, and ZECC has just announced that it has also joined the Enterprise Ethereum Alliance.

    “By adding the Zero-knowledge Security Layer into Quorum, we are able to explore how state of the art cryptographic privacy technology will enhance the next generation of financial services applications.” – Suresh Shetty, J.P. Morgan Executive Director and Blockchain Center of Excellence Lead Architect

    Zerocoin Electric Coin Company CEO Zooko Wilcox is available for interview. ZECC press contact: [email protected]

    About Zerocoin Electric Coin Company: The Zerocoin Electric Coin Company is a science-driven team; a combination of academic expertise in computer science and cryptography with security software engineering talent. We are developing the next generation of secure digital currency and blockchain technology through the use of zero-knowledge proofs, to guarantee privacy and confidentiality. More information on Zerocoin Electric Coin Company and the Zcash protocol is available at https://z.cash.

    About J.P. Morgan’s Corporate & Investment Bank: J.P. Morgan’s Corporate & Investment Bank is a global leader across banking, markets and investor services. The world’s most important corporations, governments and institutions entrust us with their business in more than 100 countries. With $21.4 trillion of assets under custody and $391 billion in deposits, the Corporate & Investment Bank provides strategic advice, raises capital, manages risk and extends liquidity in markets around the world. Further information about J.P. Morgan is available atwww.jpmorgan.com.

  • Zcash (ZEC) Release V 1.0.9

    Amgad Abdelhafez (2): Update timedata.cpp Update timedata.cpp

    Daira Hopwood (4): Fix an error reporting bug due to BrokenPipeError and ConnectionResetError not existing in Python 2. refs #2263 Alert 1002 (versions 1.0.0-1.0.2 inclusive). Alert 1003 (versions 1.0.3-1.0.8 inclusive). Disable building Proton by default.

    Jack Grigg (14): Fix prioritisetransaction RPC test torcontrol: Handle escapes in Tor QuotedStrings torcontrol: Add missing copyright header Convert Zcash versions to Debian format [manpage] Handle build numbers in versions Address Daira's comments Address Daira's further comments Correctly handle three-digit octals with leading digit 4-7 Check that >3-digit octals are truncated. Implement automatic shutdown of deprecated Zcash versions Wrap messages nicely on metrics screen Regenerate miner tests Add a benchmark for calling ConnectBlock on a block with many inputs Remove additional sources of determinism from benchmark archive

    Jay Graber (2): Change help text examples to use Zcash addresses Poll on getblocktemplate result rather than use bare sleep to avoid race condition.

    Nathan Wilcox (39): [Direct master commit] Fix a release snafu in debian version string. Show toolchain versions in build.sh. Start on a make-release.py script; currently just arg parsing and unittests [unittests fail]. Update version spec by altering test; also update regex to pass single 0 digits in major/minor/patch. Add another case from debian-style versions. Add all of the zcash release tags in my current repo as positive test vector. Add support for beta/rc release versions. Add version sorting, assert that RELEASE_PREV is the most recent release. Make SystemExit errors less redundant in output; verify clean git status on master. Always run unittests prior to actual runs. Make --help output clean by not running self-test. Add an option to run against a different repo directory. Make sure to pull the latest master. Exit instead of raising an unexpected exception, since it's already logged. Implement PathPatcher abstraction, clientversion.h rewrite, and build numbering w/ unittests. Implement the IS_RELEASE rule for betas. Generalize buildnum patching for both clientversion.h and configure.ac. Modify the APPROX_RELEASE_HEIGHT. Remove portions of ./doc/release-process.md now implemented in make-release.py. Switch from sh_out_logged to sh_log. Shorten the arg log line. Commit the version changes and build. Generate manpages; commit that; improve error output in sh_log. Polish logging a bit more. Tidy up / systematize logging output a bit more. First full-release-branch version of script; rewrite large swatch of release-process.md. [Manually tested.] Enable set -u mode. Fix a variable name typo. Reuse zcash_rpc. Do not use -rpcwait on all zcash_rpc invocations, only block when starting zcashd. Fix release-process.md doc usage for make-release.py to have correct arguments and order. Include release version in commit comments. Examine all future versions which are assumed to follow the same Version parser schema. Consider both beta and rc versions to be IS_RELEASE == false. Add a few more version strings to positive parser test. Define the deprecation policy for 1.0.9. Clarify that the feature is automated shutdown. make-release.py: Versioning changes for 1.0.9. make-release.py: Updated manpages for 1.0.9.

    Paige Peterson (4): wallet backup instructions typo and rewording edits str4d and Ariel's suggestions specify exportdir being within homedirectory

    Sean Bowe (1): Check that pairings work properly when the G1 point is at infinity.

    Simon Liu (5): Add AMQP 1.0 support via Apache Qpid Proton C++ API 0.17.0 Add --disable-proton flag to build.sh. Proton has build/linker issues with gcc 4.9.2 and requires gcc 5.x. Fix proton build issue with debian jessie, as used on CI servers. Change regtest port to 18344. Closes #2269. Patch to build Proton with minimal dependencies.

    emilrus (1): Replace bitcoind with zcashd


  •  ZCASH [ZEC] Dev update

    These updates are now categorized by working groups.

    Meta: As a reminder, the goal of the working groups is to eventually have regular, specialized meetings so that each area of development can move forward more efficiently and provide meeting notes or reports of their recent progress to include in these updates.

    If you have interest in participating in the existing working groups or jumpstarting one of the proposed working groups, let us know!

    Protocol: While discussion about HFO and Sapling were minimal this week due to focusing on the 1.0.9 release, we did manage to merge support for automatic shutdown of deprecated client versions (PR 2297) which is relevant to future hard forks for protocol upgrades. Note that this automatic shutdown is default but can be bypassed via flags in your configuration file.

    A couple of devs spent time this week looking at proving optimizations for generating zk-proofs.


    We released version 1.0.9 on Wednesday this week. Tickets included in 1.0.9 can be seen in the milestone

    Our next release date is for the pre-1.0.10 CI deploy3 on June 6th. As a reminder, these CI releases are scheduled in between client releases so upgrades to development infrastructure and the Zcash client have distict due dates.

    The 1.0.10 release is set for June 20th and you can keep track of what will be included in the milestone

    You can keep track of our highest priorities for future releases via the projects page with Priority 0. Security and stability3 being the highest.

    Development infrastructure: A few minor changes to the dev infrastructure were included in 1.0.9, however, as mentioned above, future changes to the dev infrastructure and continuous integration will happen via separate milestone dates from now on.

    You can keep track of progress related to this working group in the Development infrastructure project.

    Network infrastructure: In the 1.0.9 release, many benchmarks were included and enhanced to better test network behavior. AMQP1 was also finally merged which extends messaging capabilities for third-party devs.

    Berkeley DB replacement: No further discussions this week. See the Wallet DB to SQLite project for current status.

    It’s worth noting that the current proof of concept for Payment disclosure uses Berkeley DB and we’re considering swapping out with SQLite before the feature is released.

    Miscellaneous: This week was quite busy for a few of us in the company, attending Consensus 2017 and Token Summit in NYC. Both were great opportunities to do some business development and outreach!

    We had an internal demo of XCAT and progress is certainly moving forward! With the XCAT, Payment offloading and Payment disclosure proof of concepts coming along nicely, it shouldn’t be too long now until we start seeing some of these as experimental features in the Zcash client.

    We’re a little late on the final installment of the SNARK explainers but expect to see that next week!

  • Zcash [ZEC] wallets list

    ZCash GUI Wallets

    To make the user experience with ZCash more convenient, GUI (Graphical User Interface) wallets have already been created by the community and by companies. Here are the wallet options available to ZCash users as of March 2017:

    ZCash Desktop GUI Wallet

    This wallet is suitable for users and miners who work on desktop systems and wish to have full control of the ZCash private keys. It has all the typical features that might be expected from a desktop crypto-currency wallet:

    • Balance/monetary amounts
    • List of transactions
    • Status of blockchain synchronization
    • Management of ZCash addresses (including Z addresses)
    • Sending ZCash

    ZCash Desktop GUI Wallet

    It communicates with the ZCash server (zcashd) running locally via the
    zcash-cli program. When installed, it is packaged as one executable JAR
    file (ZCashSwingWalletUI.jar) and requires Java (JDK7 or later). The details of how to obtain, and install the ZCash Desktop GUI wallet may be found on GitHub. Users who are less experienced with working on  a command line, may instead use this quite-user-friendly installation guide and usage guide.

    License: Open source – MIT, Usage: Desktop, Private key control: Owned by the user

    ZCash Cockpit UI Wallet

    This wallet allows users to access their ZCash wallet remotely via a Web UI. This makes it ideal for managing multiple systems mining ZCash. Key features include:

    • Balance/monetary amounts
    • Advanced and detailed view of the blockchain
    • Management of ZCash addresses
    • Sending ZCash

    ZCash Cockpit UI Wallet The complete information on how to install the ZCash Cockpit UI Wallet may be found on GitHub. License: Open source – MIT, Usage: Remote/Web UI, Private key control: Owned by the user.

    Waterhole GUI mobile wallet

    License: Proprietary, Usage: Remote/Mobile, Private key control: trusted party.

    JAXX ZCash Wallet

    From a Jaxx representative, “This is a multi-token blockchain wallet that provides a unified experience across 9 platforms and devices, including Windows, Apple and Linux desktops, Apple and Android mobile devices and tablets, as well as Google Chrome and Firefox extensions. The Jaxx wallet enables crypto-to-crypto buying and selling with frictionless in-wallet conversion. Users are always in control of their keys and Jaxx neither holds nor has access to customer funds.” JAXX Web Site License: Proprietary (source code partially open), Usage: Desktop/Remote/Mobile, Private key control: trusted party.

    Cryptonator ZCash Wallet

    Cryptonator is an online wallet that allows users to “manage different cryptocurrencies in one personal account. Securely store, easily receive and quickly send Bitcoins, Litecoins, Dogecoins and other digital currencies.” Also provides “instant and automatic exchange between Bitcoin and other supported cryptocurrencies at very attractive rates and without fees.” Cryptonator Web Site License: Proprietary, Usage: Web/Remote, Private key control: trusted party.

    Freewallet for ZCash

    Freewallet.org allows users to “store and manage digital currencies with ease in the smart and beautiful mobile-first cryptocurrency wallets developed by Freewallet.” Freewallet Web Site License: Proprietary, Usage: Mobile, Private key control: trusted party.

    TREZOR for ZCash

    From a TREZOR representative, “This is a hardware Bitcoin wallet; a single purpose device which allows you to make secure Bitcoin transactions. With TREZOR, transactions are completely safe even when initiated on a compromised or vulnerable computer. Because the use of TREZOR is very easy and intuitive we believe it will help Bitcoin adoption among people not familiar with the security issues.” TREZOR Web Site This is a hardware wallet with strong security, Usage: Desktop, Private key control: Owned by the user

    Bitsquare for ZCash

    From the Bitsquare web site: “Bitsquare is an open-source desktop application that allows you to buy and sell bitcoins in exchange for national currencies, or alternative crypto currencies.” Bitsquare functions as a decentralized privacy-focused exchange and wallet with a strong community behind it. It also supports ZCash: Bitsquare Web Site. License: Open source – AGPL, Usage: Desktop, Private key control: Owned by the user


    From the Blockchains web site: ” Blockchains.My is a decentralized mobile wallet that easily make payments, monitor real-time price changes, get digital currency or gold and trade on our platform. DinarCoin, BitCoin , Ethereum, GSC & ZCash that connect directly to the blockchain with exchange system right in your wallet.” blockchains.my Web Site. License: Proprietary, Usage: Mobile, Private key control: trusted party.

    Waterhole GUI mobile wallet

    waterhole.io is a trading platform and a wallet provider for multiple crypto-currencies. It already supports ZCash. Quote from the official announcement: Waterhole development team is pleased to announce the GUI mobile wallet for Zcash…. Along with the first Zcash GUI wallet, the built-in escrow trading mechanism allows users to trade and chat in-app directly. The OTC feature will be available to existing BTC users and all future Zcash users from day 1 when the new coins get launched. Waterhole already have a lot of users and making BTC and ZEC faucet regularly for new registered users.

  •   ZCASH [ZEC]  - Dev update June 9, 2017

    These updates are now categorized by working groups

    Meta: Progress has been made for a few of the working groups this past week but we’re still hoping to encourage others to take on coordination of existing and proposed groups. If you’re interested in becoming a coordinator, note taker or member of one of the working groups (listed above), certainly get in touch. The minimum goal is to have one meeting per month per group with a status report about the recent progress made.

    Protocol: We made progress on discussing the Sapling crypto upgrade this week, the coordinator lead an informational meeting to highlight the plans and desired features for the upgrade to Zcash employees and external interested parties who reached out to us about attending. You can check out the agenda and notes for the meeting for details about what was discussed.

    Much of the focus for Sapling is on improving efficiency of the
    zero-knowledge components and usability of shielded addresses including private multi-sigaddress viewing keysuser-issued tokens, etc.

    There’s a lot of work to be done here and the Sapling working group have
    already had a follow up meeting to talk about technical requirements
    and design.

    Progress on Sapling can be tracked in the associated Github project

    We missed our deadline for the 1.0.10 CI deployment
    due to lack of time. We’ll continue working towards completing the
    tickets included in that milestone and provide an update next week.

    The [1.0.10 release(https://github.com/zcash/zcash... is still on track for which we’ll be maintaining a focus on security and stability continuous improvement priorities.

    Development infrastructure:

    As mentioned above, this seemed to be a relatively slow week for
    infrastructure development but you can keep track of progress of these
    tickets in the dev infrastructure project.

    Network infrastructure:
    Further discussions and
    progress were made on mempool eviction policies and associated network
    performance improvements. Relevant tickets for this task are #2414#2344, #2384#2342 (with associated PR 2343).

    Berkeley DB replacement: This working group made progress this week on cataloging data stored in leveldb and bdb.

    The database improvement project is where relevant tickets can be tracked.

    We created a new Github project called Beswick which will be the codename for improving the z_sendmany RPC and new RPCs such as z_decryptsinceblock.

    We made futher progress on the UX ecosystem research project which
    includes studying two Zcash supporting wallets and documenting certain
    actions such as sending/receiving ZEC and making a purchase. At the
    conclusion of this project, we’ll have public reports to share which
    will not only benefit Zcash developers but also the greater
    cryptocurrency ecosystem. We’re learning a lot with this project and are
    excited to share our findings.

    The zcash-primitives-js library saw it’s first official version released this week and added to the payment offloading proof of concept.

    The final installment of the zk-SNARK technical explainers was released this week: Explaining SNARKs Part VII: Pairings of Elliptic Curves

    We also just published Pay-to-sudoku Revisited.
    PTS is a project which allows a verifier to pay a prover for knowing
    the solution to a given sudoku puzzle without the solution itself being
    revealed using zero-knowledge contingent payment (ZKCP), an invention by
    Greg Maxwell.

    We’re also making progress on a central documentation source which will merge the various Github wiki’s, /doc files in zcashd and some information on https://z.cash. More details next week!

  • ZCASH [ZEC] Dev update - June 16, 2017

    This week I’m opting for a shorter and simpler format for the dev update compared to recent updates which were categorized by working groups. This is due to some internal shifting + adjusting roles within the company, employees taking much needed time off and focus on the upcoming release.

    Most of this week has seen a lot of engineering stabilization and
    maintenance work. Our focus has been on ticket triaging and review for
    next week’s 1.0.10 release We’ve addressed a number of issues so far including an information leak in chained joinsplits (PR 2440), a non-critical mis-application of consensus code from upstream resulting in a local bug(PR 2386) and a couple of documentation updates (PR 2429) & #2421).

    We’ve finished up the proof of concept for the first iteration of payment offloading.
    After testing and review for the implementation and further security +
    stabilization work for the network, we’ll release this as an
    experimental feature.

    We progressed more on design discussions and development for the XCAT implementation with Zcash and Bitcoin (ZBXCAT)

    Some final touches are being done on a Japanese translation for https://z.cash which will most likely go live next week.

    We progressed in our initial UX research of the Zcash ecosystem. We’ll be concluding this project next week and publishing reports soon thereafter.

    More work on organizing the Sapling upgrade took place this week and you can expect an update on the goals for Sapling via a blog post next week.

    Be sure to look out for next week’s release!

  • Log in to reply

    Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.