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.


    Our first and second priorities will always be:

    1. Security and reliability, and
    2. 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.


    1. 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)

    2. Payment Off-loading will allow users of light wallets to send Zcash to shielded addresses without placing any funds at risk. (Payment Off-loading on GitHub)

    3. Cross-Chain 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)

    4. 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:

    5. User-Issued Tokens, which allow you to issue, transfer, and atomically trade unique tokens for your own purposes, with Zcash's strong privacy protections. (User-Issued Tokens on GitHub)

    The Sapling upgrade with User-Issued Tokens will require a network-wide 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 privacy-protecting 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 SHA-1 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/history-of-hash-function-attacks.html.

    The main result of this investigation is that a cryptosystem which is invulnerable to collision-attacks (even if it is still vulnerable to pre-image attacks), is much stronger than one which is vulnerable to collision-attacks. Another interesting takeaway is that it looks like sometime between 1996 (Tiger) and 2000 (Whirlpool), humanity might have learned how to make collision-resistant hash functions, since none of the prominent secure hash functions designed since that era have succumbed to collision attacks. Maybe modern hash functions like SHA-256, SHA-3, and BLAKE2 will never be broken

    As a graphical reference for the article, I've included a color-coded chronological view of collision attacks, and of second pre-image attacks, as well as a survey of the best known attacks on secure hash functions.


    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 pull-requests 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 off-loading (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 #zcash-dev and #zcash-wizards channels.

    We also released the initial chapter of a series of blog posts on explaining zk-SNARKs. 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 well-received. 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 zero-knowledge 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 multi-party computation of encrypted data.

    The report is aimed at a non-technical audience, so our descriptions and explanations of how the various techniques work, are written to facilitate a high-level 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 fast-evolving 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 co-author 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.7-1

    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.


  • BLS12-381: New zk-SNARK Elliptic Curve Construction

    Our team is continually working to improve the security, performance and usability of our privacy-preserving 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 zk-SNARK proofs.

    I spent some time last month designing and implementing a new pairing-friendly elliptic curve construction that is optimal for zk-SNARKs at the 128-bit 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.

    Barreto-Naehrig curves

    Barreto-Naehrig (BN) curves are a class of pairing-friendlyFq" role="presentation">Fq

    of order r" role="presentation">r, where r≈q" role="presentation">rq. Our current curve construction has q≈2254" role="presentation">q≈2254

    . 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 128-bit 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 multi-exponentiation, fast fourier
    transforms and other cryptographic operations that we need to perform
    efficiently in zk-SNARK schemes and multi-party computations.
    Additionally, the larger scalar field Fr" role="presentation">Fr

    makes keying material unnecessarily large.

    Barreto-Lynn-Scott curves

    Barreto-Lynn-Scott (BLS) curves are a slightly older class of pairing-friendly 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 128-bit
    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.


    In zk-SNARK schemes, we need to manipulate very large polynomials over the scalar field Fr" role="presentation">Fr

    . We can perform efficient multi-point 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 space-efficient, 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 64-bit 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 BLS12-381 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 zk-SNARK project. The library has the goal of being portable, standards compliant, and high performance. Due to the nature of zk-SNARK 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)
    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


    addnode=fhsxfrwpyrtoxeal.onion:8233 addnode=zcash2iihed2wdux.onion:8233

    The nodes are (currently) running Zcash 1.0.7 and Tor (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




  • 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:

    1. No contingency for block space (what we currently see now)
    2. An intermediate phase (perhaps when we see the first full block or a first spam attack)
    3. 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 zk-SNARKs to continue our effort in decypering the “moon math” behind the zero-knowledge 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 tight-knit, focused team, rapid decision-making, 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 for-profit company to have this much power over the evolution of the Zcash technology. Ultimately, there will need to be an independent, inclusive, non-profit 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 cryptographically-protected, decentralized file store, Tahoe-LAFS.

    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 run-up to the Zcash launch consumed all of my time and attention, and the Least Authoritarians continued to develop their cutting-edge 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 full-time 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 freedom-compatible technologies, and has some big things in the works that you'll hear more about soon, including a user-friendly 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 end-to-end 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 Tahoe-LAFS on BitcoinTalk.org back in 2010 and Satoshi Nakamoto replied.)

Log in to reply

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