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

  • Zcash Release v1.0.8


  • Explaining SNARKs Part III: The Knowledge of Coefficient Test and Assumption

    << Part II

    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.

    1. Bob chooses random \(\alpha\in\mathbb{F}_p^*\) and \(a\in G.\) He computes \(b=\alpha\cdot a.\)
    2. He sends to Alice the "challenge" pair \((a,b).\) Note that \((a,b)\) is an \(\alpha\)-pair.
    3. Alice must now respond with a different pair \((a',b')\) that is also an \(\alpha\)-pair.
    4. 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 non-negligible 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 non-zero elements of \(\mathbb{F}_p\). It is the same as \(\mathbb{Z}_p^*\) described in Part I.


    is typically called the Knowledge of Exponent Assumption in the
    literature, as traditionally it was used for groups written


    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.


    Ariel Gabizon

  • BIP199 for Hashed Timelocked Contracts

    Hashed Timelocked Contracts (HTLC) are a well-known 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 zero-knowledge 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 work-in-progress 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:

        [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
        <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>

    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 cross-chain atomic swaps can be built with this mechanism:

    1. Alice randomly samples K, the key. She hashes it, producing X.
    2. Alice creates a transaction paying Bob 1 BTC, with a timeout of 1 day, to produce the preimage of X.
    3. 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.
    4. Once Bob's transaction appears in the Zcash blockchain, Alice can obtain her ZEC. The script forces her to reveal K.
    5. 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.


    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 high-level overview of zk-SNARKs.

    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 all-in-one 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 non-mining 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, zcash4win-1.0.5.msi is: acb8e624fc12fa2dca951071bf2015ba7b933187b625c03f3fc39daa7d47ce2f

    It doesn't create a shortcut for the launcher, which is ###code#

    You must have 64-bit 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!


    David Mercer Tucson, AZ

    PS As always, I don't have a day job and do this strictly for donations!



    If You Like Donate To me Here the address

    BTC: 1H9AFcYdZb6mt3wDHg1hc2AjnqrXzmv4xo

    ETH: 0x2587512b27867c2d466c02ccf11424002baac8b4

    ZEC: t1RnYixipZn3LrDdXkdLnR7JUSrCxo26W97

  • Bellman: zk-SNARKs in Rust

    Bellman is a Rust-language library for building zk-SNARKs small, cheap-to-verify zero-knowledge proofs of arbitrary computations. The goal of bellman is to make it easier for the general public to use and

    experiment with zk-SNARKs, 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 BLS12-381 elliptic curve construction that we described scientists. This construction was designed specifically for efficiently
    building zk-SNARKs, while maintaining a high security margin.

    This week, I've added a primitive implementation of a new zk-SNARK 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 zk-SNARKs

    If you're interested in how zk-SNARKs 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.

    zk-SNARKs are powerful proofs that, unlike other zero-knowledge 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 zero-knowledge 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 zk-SNARKs for its shielded transactions, uses parameters that were constructed in a sophisticated multi-party computation ceremony that you can read about here. zk-SNARKs 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 zk-SNARK schemes, the statement being proven is reduced to what is called a rank-1 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:

    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:

    1. 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.
    2. 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:

    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
                LinearCombination::one(e) - var,
                LinearCombination::zero(e) + var,
            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
                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:

    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:

    // 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| {
    }, &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 zk-SNARKs 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 zk-SNARKs 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 multi-party computation ceremony code.

  • ZCash Release  MacOS v1.0.8-3


    ZCash v1.0.8 built from scratch with gcc-6.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

    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 $ ./zcash-fetch-params $ ./zcash-init $ ./zcashd

    You can just run ZCash by launching the daemon afterwards

    $ ./zcashd


  • ZCash Updated Exchanges List 

    Below is a non-exhaustive list of exchanges supporting ZCash (as of April 2017):








    BTC Alphahttps://btc-alpha.com


    BX Thailandhttps://bx.in.th











    The Rock – https://www.therocktrading.com






    Yuanbao – https://yuanbao.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.


  • ZCASH [ZEC] Security Announcement 2017-04-12

    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.


    Zooko Wilcox

Log in to reply

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