From b724b6c20829de396cf436b27f6a89bbb2739a99 Mon Sep 17 00:00:00 2001 From: Ryan Taylor Date: Wed, 11 Apr 2018 15:44:29 +0200 Subject: [PATCH] Full export from WordPress at https://blog.z.cash (Zcash Blog) - wpghs --- _pages/tags.md | 11 + _posts/2016-01-20-helloworld.md | 78 +++++ _posts/2016-02-01-funding.md | 61 ++++ _posts/2016-02-09-welcoming-jack-grigg.md | 33 ++ _posts/2016-02-29-snark-parameters.md | 43 +++ _posts/2016-03-18-science-roundup.md | 47 +++ ...ha-release-equihash-and-founders-reward.md | 30 ++ _posts/2016-04-15-why-equihash.md | 45 +++ _posts/2016-04-26-fixing-zcash-vulns.md | 84 +++++ _posts/2016-05-09-sprout-roadmap.md | 28 ++ .../2016-05-17-new-alpha-release-libzcash.md | 31 ++ _posts/2016-05-25-hiring.md | 35 ++ ...-01-new-alpha-release-mining-slow-start.md | 22 ++ ...17-new-alpha-release-faster-block-times.md | 23 ++ ...2016-07-06-pairing-cryptography-in-rust.md | 99 ++++++ ...2016-07-08-new-alpha-release-2mb-blocks.md | 19 ++ ...cash-website-now-in-english-and-chinese.md | 17 + ...-alpha-release-terminology-and-security.md | 21 ++ _posts/2016-07-27-science-roundup-july.md | 48 +++ _posts/2016-07-28-zksnarks-in-ethereum.md | 32 ++ ...016-08-01-bolt-private-payment-channels.md | 55 +++ ...elease-optimization-and-nonmalleability.md | 22 ++ _posts/2016-08-17-auditing-zcash.md | 54 +++ _posts/2016-08-17-zcash-launch-and-roadmap.md | 46 +++ ...ease-solidifying-the-consensus-protocol.md | 26 ++ _posts/2016-08-26-taylors-next-adventure.md | 18 + ...metamorphosis-of-malleable-transactions.md | 20 ++ ...2016-09-05-september-2016-new-hire-post.md | 58 ++++ _posts/2016-09-07-supporting-coin-center.md | 15 + _posts/2016-09-09-announcing-beta-series.md | 43 +++ _posts/2016-09-09-expanding-zcash-content.md | 16 + _posts/2016-09-19-project-alchemy.md | 20 ++ _posts/2016-09-21-announcing-miner-contest.md | 23 ++ ...9-23-continued-funding-and-transparency.md | 91 +++++ .../2016-09-25-generating-zcash-parameters.md | 98 ++++++ .../2016-09-27-open-source-miner-challenge.md | 23 ++ ...release-audit-mitigations-and-bug-fixes.md | 26 ++ _posts/2016-10-07-consensual-currency.md | 44 +++ ...6-10-14-slow-start-and-mining-ecosystem.md | 35 ++ _posts/2016-10-17-deterministic-builds.md | 45 +++ ...-fixes-packaging-and-launch-preparation.md | 27 ++ ...016-10-17-open-source-miner-submissions.md | 17 + _posts/2016-10-18-zcash-evolution.md | 89 +++++ ...are-usability-and-hardware-requirements.md | 24 ++ ...ew-release-candidate-less-than-one-week.md | 33 ++ _posts/2016-10-24-miner-challenge-deadline.md | 16 + .../2016-10-26-the-design-of-the-ceremony.md | 78 +++++ _posts/2016-10-27-audit-results.md | 74 ++++ ...elease-candidate-final-snark-parameters.md | 53 +++ _posts/2016-10-28-zcash-begins.md | 22 ++ _posts/2016-10-29-third-party-support.md | 75 +++++ ...6-10-31-state-of-the-network-2016-10-31.md | 36 ++ .../2016-11-03-new-release-minor-bugfixes.md | 21 ++ .../2016-11-07-new-release-fix-joinsplits.md | 22 ++ .../2016-11-15-founders-reward-transfers.md | 60 ++++ _posts/2016-11-17-new-release-1-0-3.md | 22 ++ .../2016-11-18-the-zcash-equihash-analysis.md | 29 ++ ...-11-22-security-announcement-2016-11-22.md | 75 +++++ _posts/2016-11-23-anatomy-of-zcash.md | 43 +++ .../2016-11-29-zcash-private-transactions.md | 123 +++++++ .../2016-12-03-open-source-miner-winners.md | 22 ++ _posts/2016-12-05-encrypted-memo-field.md | 54 +++ _posts/2016-12-15-new-release-1-0-4.md | 29 ++ _posts/2017-01-11-future-friendly-fork.md | 21 ++ _posts/2017-01-19-zcash-eth.md | 74 ++++ _posts/2017-01-23-new-release-1-0-5.md | 30 ++ _posts/2017-01-25-transaction-linkability.md | 47 +++ _posts/2017-02-13-new-release-1-0-6.md | 28 ++ _posts/2017-02-21-the-near-future-of-zcash.md | 50 +++ _posts/2017-02-24-hash-functions.md | 19 ++ _posts/2017-02-28-shielded-ecosystem.md | 32 ++ _posts/2017-02-28-snark-explain.md | 66 ++++ _posts/2017-03-06-new-release-1-0-7.md | 26 ++ _posts/2017-03-08-r3-blockchain-report.md | 17 + _posts/2017-03-11-new-snark-curve.md | 51 +++ _posts/2017-03-13-snark-explain2.md | 64 ++++ ...7-03-17-announcing-the-zcash-foundation.md | 20 ++ ...-03-20-spinning-off-our-sibling-company.md | 24 ++ _posts/2017-03-23-zsl.md | 91 +++++ _posts/2017-03-27-new-release-1-0-8.md | 23 ++ _posts/2017-03-28-snark-explain3.md | 91 +++++ _posts/2017-03-29-htlc-bip.md | 41 +++ ...7-04-02-state-of-the-network-2017-04-03.md | 21 ++ _posts/2017-04-04-bellman-zksnarks-in-rust.md | 317 ++++++++++++++++++ _posts/2017-04-11-snark-explain4.md | 85 +++++ ...-04-12-security-announcement-2017-04-12.md | 32 ++ _posts/2017-04-13-new-release-1-0-8-1.md | 18 + ...-04-13-security-announcement-2017-04-13.md | 64 ++++ _posts/2017-04-14-zcash-on-ios.md | 18 + _posts/2017-04-17-zcash-1-0-9-postponed.md | 16 + ...-04-18-zcash-in-brazil-and-south-africa.md | 19 ++ .../2017-04-19-shielded-address-contexts.md | 30 ++ _posts/2017-04-25-snark-explain5.md | 97 ++++++ _posts/2017-04-28-internet-money.md | 23 ++ .../2017-05-01-release-cycle-and-lifetimes.md | 68 ++++ _posts/2017-05-10-snark-explain6.md | 96 ++++++ .../2017-05-11-getting-started-developing.md | 28 ++ _posts/2017-05-22-zsl-quorum.md | 32 ++ _posts/2017-05-24-new-release-1-0-9.md | 29 ++ _posts/2017-06-07-snark-explain7.md | 142 ++++++++ _posts/2017-06-08-pay-to-sudoku-revisited.md | 18 + _posts/2017-06-21-global-growth.md | 35 ++ _posts/2017-06-22-new-release-1-0-10.md | 24 ++ _posts/2017-06-24-new-release-1-0-10-1.md | 21 ++ ...tivating-sapling-new-crypto-foundations.md | 47 +++ _posts/2017-08-16-new-release-1-0-11.md | 23 ++ _posts/2017-08-21-ux-research.md | 28 ++ _posts/2017-09-01-community-projects.md | 66 ++++ _posts/2017-09-11-atomic-trades.md | 18 + _posts/2017-09-12-zcash-on-bitpie.md | 18 + ...-13-cultivating-sapling-faster-zksnarks.md | 25 ++ _posts/2017-09-20-ethereum-snarks.md | 21 ++ _posts/2017-09-21-ceremony-audit-results.md | 54 +++ _posts/2017-09-22-release-cycle-update.md | 28 ++ _posts/2017-09-28-new-release-1-0-12.md | 28 ++ _posts/2017-09-28-zcash-on-bithumb.md | 19 ++ _posts/2017-09-29-crypto-is-currency.md | 27 ++ _posts/2017-10-02-zcash-on-cexio.md | 17 + _posts/2017-10-17-jpm-quorum-integration.md | 30 ++ .../2017-10-28-state-of-the-network-1-year.md | 20 ++ _posts/2017-10-31-new-mpc-protocol.md | 36 ++ _posts/2017-11-09-zcash-investment-trust.md | 15 + _posts/2017-11-13-ux-evaluation-openbazaar.md | 50 +++ _posts/2017-11-20-new-release-1-0-13.md | 28 ++ _posts/2017-11-27-new-hires-2017.md | 67 ++++ ...2-04-new-research-on-shielded-ecosystem.md | 32 ++ _posts/2017-12-08-roadmap-update-2017-12.md | 47 +++ _posts/2017-12-29-zcash-in-2017.md | 25 ++ _posts/2018-01-04-new-release-1-0-14.md | 58 ++++ ...-16-ux-guidelines-for-wallet-developers.md | 28 ++ ...01-22-viewing-keys-selective-disclosure.md | 45 +++ _posts/2018-02-14-shielded-pia.md | 52 +++ _posts/2018-03-02-new-release-1-0-15.md | 41 +++ _posts/2018-03-02-overwinter.md | 23 ++ ...sh-team-grows-with-new-hires-in-q1-2018.md | 95 ++++++ _posts/2018-03-27-2018-security-audits.md | 26 ++ ...03-27-2018-zcash-security-audit-details.md | 54 +++ ...ash-ux-guidelines-for-wallet-developers.md | 25 ++ 138 files changed, 5893 insertions(+) create mode 100644 _pages/tags.md create mode 100644 _posts/2016-01-20-helloworld.md create mode 100644 _posts/2016-02-01-funding.md create mode 100644 _posts/2016-02-09-welcoming-jack-grigg.md create mode 100644 _posts/2016-02-29-snark-parameters.md create mode 100644 _posts/2016-03-18-science-roundup.md create mode 100644 _posts/2016-04-13-new-alpha-release-equihash-and-founders-reward.md create mode 100644 _posts/2016-04-15-why-equihash.md create mode 100644 _posts/2016-04-26-fixing-zcash-vulns.md create mode 100644 _posts/2016-05-09-sprout-roadmap.md create mode 100644 _posts/2016-05-17-new-alpha-release-libzcash.md create mode 100644 _posts/2016-05-25-hiring.md create mode 100644 _posts/2016-06-01-new-alpha-release-mining-slow-start.md create mode 100644 _posts/2016-06-17-new-alpha-release-faster-block-times.md create mode 100644 _posts/2016-07-06-pairing-cryptography-in-rust.md create mode 100644 _posts/2016-07-08-new-alpha-release-2mb-blocks.md create mode 100644 _posts/2016-07-13-zcash-website-now-in-english-and-chinese.md create mode 100644 _posts/2016-07-22-new-alpha-release-terminology-and-security.md create mode 100644 _posts/2016-07-27-science-roundup-july.md create mode 100644 _posts/2016-07-28-zksnarks-in-ethereum.md create mode 100644 _posts/2016-08-01-bolt-private-payment-channels.md create mode 100644 _posts/2016-08-06-new-alpha-release-optimization-and-nonmalleability.md create mode 100644 _posts/2016-08-17-auditing-zcash.md create mode 100644 _posts/2016-08-17-zcash-launch-and-roadmap.md create mode 100644 _posts/2016-08-25-new-alpha-release-solidifying-the-consensus-protocol.md create mode 100644 _posts/2016-08-26-taylors-next-adventure.md create mode 100644 _posts/2016-08-31-metamorphosis-of-malleable-transactions.md create mode 100644 _posts/2016-09-05-september-2016-new-hire-post.md create mode 100644 _posts/2016-09-07-supporting-coin-center.md create mode 100644 _posts/2016-09-09-announcing-beta-series.md create mode 100644 _posts/2016-09-09-expanding-zcash-content.md create mode 100644 _posts/2016-09-19-project-alchemy.md create mode 100644 _posts/2016-09-21-announcing-miner-contest.md create mode 100644 _posts/2016-09-23-continued-funding-and-transparency.md create mode 100644 _posts/2016-09-25-generating-zcash-parameters.md create mode 100644 _posts/2016-09-27-open-source-miner-challenge.md create mode 100644 _posts/2016-10-04-new-beta-release-audit-mitigations-and-bug-fixes.md create mode 100644 _posts/2016-10-07-consensual-currency.md create mode 100644 _posts/2016-10-14-slow-start-and-mining-ecosystem.md create mode 100644 _posts/2016-10-17-deterministic-builds.md create mode 100644 _posts/2016-10-17-new-beta-release-fixes-packaging-and-launch-preparation.md create mode 100644 _posts/2016-10-17-open-source-miner-submissions.md create mode 100644 _posts/2016-10-18-zcash-evolution.md create mode 100644 _posts/2016-10-19-software-usability-and-hardware-requirements.md create mode 100644 _posts/2016-10-22-new-release-candidate-less-than-one-week.md create mode 100644 _posts/2016-10-24-miner-challenge-deadline.md create mode 100644 _posts/2016-10-26-the-design-of-the-ceremony.md create mode 100644 _posts/2016-10-27-audit-results.md create mode 100644 _posts/2016-10-27-new-release-candidate-final-snark-parameters.md create mode 100644 _posts/2016-10-28-zcash-begins.md create mode 100644 _posts/2016-10-29-third-party-support.md create mode 100644 _posts/2016-10-31-state-of-the-network-2016-10-31.md create mode 100644 _posts/2016-11-03-new-release-minor-bugfixes.md create mode 100644 _posts/2016-11-07-new-release-fix-joinsplits.md create mode 100644 _posts/2016-11-15-founders-reward-transfers.md create mode 100644 _posts/2016-11-17-new-release-1-0-3.md create mode 100644 _posts/2016-11-18-the-zcash-equihash-analysis.md create mode 100644 _posts/2016-11-22-security-announcement-2016-11-22.md create mode 100644 _posts/2016-11-23-anatomy-of-zcash.md create mode 100644 _posts/2016-11-29-zcash-private-transactions.md create mode 100644 _posts/2016-12-03-open-source-miner-winners.md create mode 100644 _posts/2016-12-05-encrypted-memo-field.md create mode 100644 _posts/2016-12-15-new-release-1-0-4.md create mode 100644 _posts/2017-01-11-future-friendly-fork.md create mode 100644 _posts/2017-01-19-zcash-eth.md create mode 100644 _posts/2017-01-23-new-release-1-0-5.md create mode 100644 _posts/2017-01-25-transaction-linkability.md create mode 100644 _posts/2017-02-13-new-release-1-0-6.md create mode 100644 _posts/2017-02-21-the-near-future-of-zcash.md create mode 100644 _posts/2017-02-24-hash-functions.md create mode 100644 _posts/2017-02-28-shielded-ecosystem.md create mode 100644 _posts/2017-02-28-snark-explain.md create mode 100644 _posts/2017-03-06-new-release-1-0-7.md create mode 100644 _posts/2017-03-08-r3-blockchain-report.md create mode 100644 _posts/2017-03-11-new-snark-curve.md create mode 100644 _posts/2017-03-13-snark-explain2.md create mode 100644 _posts/2017-03-17-announcing-the-zcash-foundation.md create mode 100644 _posts/2017-03-20-spinning-off-our-sibling-company.md create mode 100644 _posts/2017-03-23-zsl.md create mode 100644 _posts/2017-03-27-new-release-1-0-8.md create mode 100644 _posts/2017-03-28-snark-explain3.md create mode 100644 _posts/2017-03-29-htlc-bip.md create mode 100644 _posts/2017-04-02-state-of-the-network-2017-04-03.md create mode 100644 _posts/2017-04-04-bellman-zksnarks-in-rust.md create mode 100644 _posts/2017-04-11-snark-explain4.md create mode 100644 _posts/2017-04-12-security-announcement-2017-04-12.md create mode 100644 _posts/2017-04-13-new-release-1-0-8-1.md create mode 100644 _posts/2017-04-13-security-announcement-2017-04-13.md create mode 100644 _posts/2017-04-14-zcash-on-ios.md create mode 100644 _posts/2017-04-17-zcash-1-0-9-postponed.md create mode 100644 _posts/2017-04-18-zcash-in-brazil-and-south-africa.md create mode 100644 _posts/2017-04-19-shielded-address-contexts.md create mode 100644 _posts/2017-04-25-snark-explain5.md create mode 100644 _posts/2017-04-28-internet-money.md create mode 100644 _posts/2017-05-01-release-cycle-and-lifetimes.md create mode 100644 _posts/2017-05-10-snark-explain6.md create mode 100644 _posts/2017-05-11-getting-started-developing.md create mode 100644 _posts/2017-05-22-zsl-quorum.md create mode 100644 _posts/2017-05-24-new-release-1-0-9.md create mode 100644 _posts/2017-06-07-snark-explain7.md create mode 100644 _posts/2017-06-08-pay-to-sudoku-revisited.md create mode 100644 _posts/2017-06-21-global-growth.md create mode 100644 _posts/2017-06-22-new-release-1-0-10.md create mode 100644 _posts/2017-06-24-new-release-1-0-10-1.md create mode 100644 _posts/2017-07-26-cultivating-sapling-new-crypto-foundations.md create mode 100644 _posts/2017-08-16-new-release-1-0-11.md create mode 100644 _posts/2017-08-21-ux-research.md create mode 100644 _posts/2017-09-01-community-projects.md create mode 100644 _posts/2017-09-11-atomic-trades.md create mode 100644 _posts/2017-09-12-zcash-on-bitpie.md create mode 100644 _posts/2017-09-13-cultivating-sapling-faster-zksnarks.md create mode 100644 _posts/2017-09-20-ethereum-snarks.md create mode 100644 _posts/2017-09-21-ceremony-audit-results.md create mode 100644 _posts/2017-09-22-release-cycle-update.md create mode 100644 _posts/2017-09-28-new-release-1-0-12.md create mode 100644 _posts/2017-09-28-zcash-on-bithumb.md create mode 100644 _posts/2017-09-29-crypto-is-currency.md create mode 100644 _posts/2017-10-02-zcash-on-cexio.md create mode 100644 _posts/2017-10-17-jpm-quorum-integration.md create mode 100644 _posts/2017-10-28-state-of-the-network-1-year.md create mode 100644 _posts/2017-10-31-new-mpc-protocol.md create mode 100644 _posts/2017-11-09-zcash-investment-trust.md create mode 100644 _posts/2017-11-13-ux-evaluation-openbazaar.md create mode 100644 _posts/2017-11-20-new-release-1-0-13.md create mode 100644 _posts/2017-11-27-new-hires-2017.md create mode 100644 _posts/2017-12-04-new-research-on-shielded-ecosystem.md create mode 100644 _posts/2017-12-08-roadmap-update-2017-12.md create mode 100644 _posts/2017-12-29-zcash-in-2017.md create mode 100644 _posts/2018-01-04-new-release-1-0-14.md create mode 100644 _posts/2018-01-16-ux-guidelines-for-wallet-developers.md create mode 100644 _posts/2018-01-22-viewing-keys-selective-disclosure.md create mode 100644 _posts/2018-02-14-shielded-pia.md create mode 100644 _posts/2018-03-02-new-release-1-0-15.md create mode 100644 _posts/2018-03-02-overwinter.md create mode 100644 _posts/2018-03-23-zcash-team-grows-with-new-hires-in-q1-2018.md create mode 100644 _posts/2018-03-27-2018-security-audits.md create mode 100644 _posts/2018-03-27-2018-zcash-security-audit-details.md create mode 100644 _posts/2018-04-10-updated-zcash-ux-guidelines-for-wallet-developers.md diff --git a/_pages/tags.md b/_pages/tags.md new file mode 100644 index 0000000..740ce4e --- /dev/null +++ b/_pages/tags.md @@ -0,0 +1,11 @@ +--- +ID: 2365 +post_title: Tags +author: Ryan Taylor +post_excerpt: "" +layout: page +permalink: https://blog.z.cash/tags/ +published: true +post_date: 2018-02-08 13:40:42 +--- +[get_tags] \ No newline at end of file diff --git a/_posts/2016-01-20-helloworld.md b/_posts/2016-01-20-helloworld.md new file mode 100644 index 0000000..337a264 --- /dev/null +++ b/_posts/2016-01-20-helloworld.md @@ -0,0 +1,78 @@ +--- +ID: 1569 +post_title: Hello, World! +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/helloworld/ +published: true +post_date: 2016-01-20 00:00:00 +--- +I'm extremely happy to announce the Zcash project. + +Zcash (formerly “Zerocash”/“Zerocoin”) is a project to create a new currency for the Internet, inspired by Bitcoin. + +Bitcoin is an amazing and complex machine, but the most important thing about it is simple: it is an open financial system which anyone can connect to without requiring permission from anyone else. For the same reason, anyone can extend and improve it without permission. + +Making a financial system open is revolutionary, and seven years into the Bitcoin project, we're still in the early days of understanding what's possible, what's impossible, and how the possibilities will play out in real communities and economies around the globe. + +The improvement that the Zcash team is working on is the addition of privacy. We have assembled a world-class team of cryptographers and engineers, made scientific advances in the underlying mathematics, and built a working, privacy-preserving variant of the Bitcoin software. +
+

What we've done

+What we're releasing today is a working “Technology Preview” release. Developers can download the source code, compile it, and connect to our live testnet. You can mine play-money “testnet-bux” and spend them with a fully private, cryptographically-protected transaction. + +There is still much work to be done before Zcash matures into an open system that people can rely on. The current software is insecure in several serious ways, and testnet-bux are worthless and always will be. This Technology Preview release is solely for other developers and entrepreneurs around the world, who can help us inspect, debug, and improve the technology and who can learn how it works and how they can use it. + +Everything we're releasing today is under an open source licence and we have not applied for any patents on these inventions. + +
+
+

Why do we do this?

+I'll be writing a series of blog posts in the coming days explaining different parts of the system, including how it works, our funding model, and how you can help, but for this first blog post I want to concentrate on the most important question: Why?. +
+

Because privacy is a human right

+We believe that personal privacy is necessary for core human values like dignity, intimacy, and morality. + +Privacy is about consent. You have the right to choose which of your movements, words, and actions will be shared or published. You have the right to choose whether every detail of your life will be recorded and analyzed, by acquaintances, neighbors, family, employers, faceless organizations, or massive supercomputers. + +If someone tells you that it is hopeless and that you have no privacy rights left, don't believe them. It is worth fighting for, and we can win. + +
+
+

Because privacy is necessary for businesses

+Companies need privacy in order to conduct their business. This is true for all sorts of companies, in all sorts of businesses. + +I was surprised when I started talking to businesses about Zcash at the strength of the positive response from the financial tech industry. They've been developing "blockchain technology" products, and they've suddenly realized that they are accelerating toward a roadblock, because their customers (banks) have assumed all along that their “blockchain technology” product comes with privacy, and it doesn't. Banks and their customers absolutely require privacy in their financial transactions. + +
+
+

Because privacy is necessary for commerce

+A currency needs privacy to be long-term viable as a medium of exchange, because of fungibility. “Fungibility” is the property that “All coins are created equal.”. Fungibility means that when someone offers to pay you $20, and they have two different twenty-dollar bills in their wallet, it doesn't matter which one you take. The two $20's are worth just as much as one another, and it doesn't matter who any of the previous owners of either one of those $20's was. + +This is necessary for large-scale commerce. If, every time someone were going to accept money, they had to think about the consequences of accepting this particular payment vs. some other payment of the same amount, commerce would grind to a halt, or would be limited to small groups of shared trust. + +In an open and programmable financial system, financial privacy is the only way to ensure fungibility. + +
+
+

Because privacy is a social value

+We believe that privacy strengthens social ties and social institutions, protects societies against their enemies, and helps societies to be more peaceful and more prosperous. A robust tradition of privacy is a common feature in rich and peaceful societies, and a lack of privacy is often found in struggling and failing societies. + +As we move more of our lives into the Internet, and integrate our lives more with the lives of people from around the globe, we want the new society we are building to be one of the peaceful and prosperous kind. + +
+
+

But… but… won't bad guys use it?

+Yes, but bad guys will use anything. Bad guys use cars, bad guys use the Internet, bad guys use cash, bad guys use the current banking system. Our goal is not to invent something that bad guys can't use, it is to invent something that can empower and uplift the billions of good people on this planet. + +
+
+
+

Join us!

+These are the reasons why we are devoting these years of our lives to this project. Many of the leading thinkers in the Bitcoin community have already expressed their support. We welcome your help and support. You can find our conversations at the Zcash forum. + +Coming soon: How is the Zcash project funded? + +— Zooko Wilcox, Jan 20, 2016 + +
\ No newline at end of file diff --git a/_posts/2016-02-01-funding.md b/_posts/2016-02-01-funding.md new file mode 100644 index 0000000..974f7dc --- /dev/null +++ b/_posts/2016-02-01-funding.md @@ -0,0 +1,61 @@ +--- +ID: 1563 +post_title: Funding, Incentives, and Governance +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/funding/ +published: true +post_date: 2016-02-01 00:00:00 +--- +In my first blog post I focused on the most important thing: our values. Now I turn to the next-most-important issue for our mission: funding. Here's how we've gathered the necessary resources to get us this far, and how we plan to successfully launch Zcash. + +Even though the Zcash technology is being built by a company (the Zcash Electric Coin Company), nothing in Zcash is proprietary or closed. Zcash is a fully open system: + +All of this is necessary for Zcash to be an open system that anyone can use, and to allow permissionless innovation. It is also necessary to establish trust that the resulting system is free of security vulnerability and backdoors. + +How can such a high-powered team afford to devote years of our lives to this project when everything we're producing is public, open, and permissionless? +
+

Founders Reward

+Zcash's monetary base will be the same as Bitcoin's — 21 million Zcash currency units (ZEC, or ⓩ) will be mined over time. 10% of that reward will be distributed to the stakeholders in the Zcash Company — founders, investors, employees, and advisors. We call this the “Founders Reward”. + +Founders Reward GraphAt first, 50 ZEC will be created every ten minutes. 80% of the newly created ZEC will go to the miners, and 20% ZEC to the founders. + +Every four years, the rate of ZEC being created will halve (again, just like in Bitcoin). After the first four years the ZEC created per ten minutes will drop to 25ⓩ, but after the first four years, 100% of it goes to the miners. + +The end result (as shown in the diagram) is that there will ultimately be 21 million ⓩ, and 10% of it, or 2.1 million ⓩ, will have been initially distributed to the founders. + +With this approach, the founders are incentivized to support Zcash for the long haul (at least for four years), and they have limited ability to pump-and-dump. + +
+
+

Our Investors

+With the plan above, a dream team of investors stepped up to fund the Zcash Company, because they believe in our mission, and in the value of this technology for all kinds of people and industries. + +We have closed a $1M funding round with these investors. By acquiring a stake in the Zcash Company, they stand to benefit both from the Founders Reward as well as from the value of any other products that the Zcash Company may create. + +I am grateful to them for giving us the opportunity to do this and for the valuable business expertise they are providing. + +
+
+

The Zcash Foundation

+The Zcash Company is a good vehicle to draw this team together, organize us, and launch the technology, but in the long run Zcash will need to be maintained by people who are serving the interests of all users equally. + +To that end, some of the founders have agreed to donate part of their reward, currently amounting to more than 10% of the Founders Reward — i.e. more than 1% of all of the Zcash monetary base — to a future non-profit “Zcash Foundation”. + +It has not yet been determined how that foundation will be organized, but the intent is that it will provide a natural locus for voluntary governance, i.e. for maintenance and evolution of the protocols and software. I hope that having a well-funded non-profit foundation dedicated to serving the interests of all Zcash users will avoid some of the uncertainties which are currently rending our beloved Bitcoin community. + +
+
+

Conclusion

+There was a lot in here, but it was important to me to get this all on the record. I am very proud of having drawn together these resources and created this organization to advance our mission. I hope you who share our values agree that this plan is fair and fit to purpose and that you will support us and join the Zcash community. + +Coming soon: Zcash and Bitcoin + +— Zooko Wilcox, Feb 1, 2016 + +
\ No newline at end of file diff --git a/_posts/2016-02-09-welcoming-jack-grigg.md b/_posts/2016-02-09-welcoming-jack-grigg.md new file mode 100644 index 0000000..656092a --- /dev/null +++ b/_posts/2016-02-09-welcoming-jack-grigg.md @@ -0,0 +1,33 @@ +--- +ID: 1647 +post_title: Welcoming Jack Grigg +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/welcoming-jack-grigg/ +published: true +post_date: 2016-02-09 00:00:00 +--- +Hello, I'm Nathan Wilcox and I do project management and engineering on Zcash. I'm delighted to announce the most recent hire onto our engineering team: Jack Grigg. + +When Zooko first excitedly exclaimed he had been in contact with Jack about working with us, I'll admit the name wasn't familiar to me. It turns out, that's because I was only familiar with his superhero alter-ego: str4d. +
Jack Grigg aka str4d +

Jack Grigg aka str4d

+ +
+By day, Jack is an applied physics PhD student, and by night, a privacy-focused crypto hacker. At Real World Crypto '16, str4d made the bold step of unmasking this pseudonym. + +I first became aware of str4d as a contributor on the integration of privacy-preserving network protocols such as Tor and I2P into foolscap, a capabilities-secure remote procedure call Python library and protocol. Under this pseudonym, Jack actively contributes to or leads development on I2P, I2P Android, and the txi2p endpoint for Twisted, as well as ed25519-java. + +All of this has been in addition to his by-day work as a physics student where he's working on a thesis about sheep's wool. A true polyglot, Jack's been settling in quite naturally on our team. His first task is to create a mining prototype for Zcash [*]. Please join us in welcoming Jack Grigg aka str4d out of the crypto-closet and into wondrous land of cryptocurrency. + +— Nathan Wilcox, 2016-02-09 + + + + + + + +
[*]We've seen a lot of curiosity about Zcash mining. While we haven't settled on specifics, this is certainly the codebase to watch in the coming month to see what we're prototyping.
\ No newline at end of file diff --git a/_posts/2016-02-29-snark-parameters.md b/_posts/2016-02-29-snark-parameters.md new file mode 100644 index 0000000..af98a7a --- /dev/null +++ b/_posts/2016-02-29-snark-parameters.md @@ -0,0 +1,43 @@ +--- +ID: 1631 +post_title: > + How To Generate SNARK Parameters + Securely +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/snark-parameters/ +published: true +post_date: 2016-02-29 00:00:00 +--- +

There are a lot of cryptographic challenges to making a fully secure and reliable open financial system.

+

Our current top priority in the Zcash development process is to securely generate “SNARK public parameters”.

+
+

What's the problem?

+

The simple way to generate “SNARK public parameters” also produces a kind of cryptographic “toxic waste” which makes Zcash counterfeitable. Here’s our plan to prevent counterfeiting.

+

SNARKs — a very efficient form of Zero-Knowledge Proofs — are a cryptographic building block in Zcash. They are what allow Zcash miners to validate transactions and reject invalid transactions without disclosing any private information about the content of the transactions to those miners.

+

SNARKs require something called “the public parameters”. The SNARK public parameters are numbers with a specific cryptographic structure that are known to all of the participants in the system. They are baked into the protocol and the software from the beginning.

+

The obvious way to construct SNARK public parameters is just to have someone generate a public/private keypair, similar to an ECDSA keypair [*], and then destroy the private key.

+

The problem is that private key. Anybody who gets a copy of it can use it to counterfeit money. (However, it cannot violate any user’s privacy — the privacy of transactions is not at risk from this.)

+

Mitigating this threat is currently our top priority in the Zcash development process. We call the private key material “the toxic waste byproduct” — something that is produced as an unwanted side-effect of the public parameter generation, and that we need to contain and destroy as safely as possible.

+
+
+

What can we do about it?

+

We’ve devised a secure multiparty computation in which multiple people each generate a “shard” of the public/private keypair, then they each destroy their shard of the toxic waste private key, and then they all bring together their shards of the public key to to form the SNARK public parameters. If that process works — i.e. if at least one of the participants successfully destroys their private key shard — then the toxic waste byproduct never comes into existence at all.

+

We wrote a paper on the cryptographic science behind that process, which we presented at the IEEE “Oakland” Security and Privacy conference in 2015.

+

We're working on the engineering and operational details of how to implement that secure multiparty computation, using a set of well-known, trusted people to serve as the participants. We're also exploring whether there are other applications of SNARKs outside of Zcash that have the same need for public parameters, because we could generate the public parameters for those other applications at the same time as we do for Zcash.

+
+
+

What else can we do?

+

So does this fix the problem? We think this solution is good enough to move ahead with. It completely eliminates the toxic waste private key if it works, and it would be extremely difficult for any adversary to defeat it.

+

Unfortunately there is no way to confirm, after the fact, that it actually worked. It will always be possible to worry that all N out of N of the participants may have secretly colluded together to share their private key shards, or that all N out of N participants may have had their computers compromised by an adversary who stole all of the private key shards.

+

Therefore, we're also exploring long-range ideas which — if they work out — could further mitigate this risk and other risks like it.

+
+
+

The Bottom Line

+

There’s a kind of “cryptographic toxic waste”, which if it were to be created and exploited, would allow the attacker to counterfeit currency (although it wouldn’t allow them to violate anyone’s privacy). Our plan to prevent that uses a secure multiparty computation in which a set of well-known people each contribute, in such a way that if any one of them successfully destroys their shard, then the cryptographic toxic waste can never come into existence. We’re also working on other potential long-term defenses against risks like this.

+
[*]I'm totally oversimplifying here. SNARK public parameters are not just an ECDSA public key — they're more like a set of a million ECDSA public keys, each of which contains an encoding of a specific wire in the SNARK circuit. But that doesn't matter for the point of this blog post.
\ No newline at end of file diff --git a/_posts/2016-03-18-science-roundup.md b/_posts/2016-03-18-science-roundup.md new file mode 100644 index 0000000..d07c4a1 --- /dev/null +++ b/_posts/2016-03-18-science-roundup.md @@ -0,0 +1,47 @@ +--- +ID: 1616 +post_title: Science Roundup +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/science-roundup/ +published: true +post_date: 2016-03-18 00:00:00 +--- +

We are a science-driven company, and our team is always working on advancing the forefront of human knowledge. Here is a round-up of science news from our team.

+
+

Zero-Knowledge Contingent Payments

+ZKCP Demo at FC16 Bitcoin Workshop

Zcasher Sean Bowe, working with Greg Maxwell and Peter Wuille (both of Blockstream and Bitcoin Core) demoed the first zero-knowledge contingent payment on the Bitcoin network. Also referred to as ZKCP, this payment protocol (invented by Greg Maxwell) is a reliable way for two parties to exchange information and money atomically.

+

In the demo performed live at Financial Cryptography 2016, Sean and Greg (remotely) swapped the solution to a 16x16 sudoku puzzle for 0.1 Bitcoin.

+

Such an atomic swap of money for information without either party being vulnerable to someone else has never before been possible. Before ZKCP, the only way that money and information could be swapped was for one side to hand over their goods first, thus risking that the other side would cheat and keep both, or for both sides to agree on a third party escrow agent that they would each hand over their goods to, and rely on that third party to act honestly.

+

In addition to being atomic, ZKCP is also private. In ZKCP, only the buyer and the seller learn the content of the information being swapped. This makes it private in a way that is currently not possible with a smart-contracting system like Ethereum.

+

I'm excited about this demo because it shows that zero-knowledge proofs are a flexible and powerful tool that may find many different kinds of applications beyond Zcash. In this implementation, Sean used the same kinds of tools for constructing zero-knowledge proofs that we use for Zcash, such as libsnark.

+

Sean also submitted a pull-request to Bitcoin Core which provides support for HTLC (Hashed Timelock Contracts) used by ZKCP and other protocols like Paypub and Lightning.

+

For more details, please read Greg's blog post on the Bitcoin Core blog.

+
+
+

Remote Key Extraction via Side Channel Attacks

+
+don't let this guy stand next to your laptop or phone
+

Zcasher Eran Tromer and co-authors have published two new papers about side-channel attacks, one attacking GPG and another attacking ECDSA. Using small and non-intrusive sensors, the electromagnetic emanations of the device are analyzed and private keys are derived from the signals.

+

The attacks were detailed in two papers, "ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels" and "ECDH Key-Extraction via Low-Bandwidth Electromagnetic Attacks on PCs".

+
+Phone Key Stealer
+

The ECDSA attack was able to steal the secret key out of a Bitcoin wallet that was running on a phone sitting on a glass tabletop. We notified the Bitcoin Core team about this attack and confirmed that Bitcoin Core since v0.10.0 is safe from this attack.

+

These are powerful, practical attacks that underscore that danger lies ahead for software vulnerable to side-channel attacks.

+
+
+

Honey Badger BFT

+
+the friendly author for the latest and greatest BFT
+

Zcasher Andrew Miller and his co-authors released a pre-print paper draft of "The Honey Badger of Byzantine Fault Tolerance Protocols". They've invented a Byzantine Fault Tolerance protocol that does not have hard-coded timeouts. This means that the system can operate normally, and retain its fault-tolerance properties, even when the network has worse latency than anticipated.

+

It also means that in case of a temporary network interruption, Honey Badger BFT recovers quickly compared to other Byzantine Fault Tolerance protocols.

+
+the friendly mascot for the latest and greatest BFT
+

Honey Badger BFT may eventually be applicable to cryptocurrencies — where in future designs it could potentially serve as a high-performance BFT protocol in a hybrid mode with a more expensive censorship-resistant protocol. It may also be applicable to “blockchain” use cases, where a group of participants need a robust and efficient agreement protocol, but don't need censorship-resistance.

+
+
+

Conclusion

+

That's just the most recent batch of science results from Zcashers. Stay tuned for the next batch!

+

— Zooko Wilcox, March 18, 2016

+
\ No newline at end of file diff --git a/_posts/2016-04-13-new-alpha-release-equihash-and-founders-reward.md b/_posts/2016-04-13-new-alpha-release-equihash-and-founders-reward.md new file mode 100644 index 0000000..31d19ee --- /dev/null +++ b/_posts/2016-04-13-new-alpha-release-equihash-and-founders-reward.md @@ -0,0 +1,30 @@ +--- +ID: 1578 +post_title: 'New Alpha Release: Equihash and Founders’ Reward' +author: Taylor Hornby +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-alpha-release-equihash-and-founders-reward/ +published: true +post_date: 2016-04-13 00:00:00 +--- +Today, we deployed a new alpha release of the Zcash reference implementation, v0.11.2.z2, to the testnet. The new release includes the following changes [1]: +
    +
  1. We've added the Equihash proof-of-work for block mining (#27).
    2. +
  2. We've implemented the Founders' Reward as described in our funding post (#125).
    3. +
  3. We've added a performance measurement system to improve performance in future releases (#748).
    4. +
+Equihash is a Proof-of-Work algorithm devised by Dmitry Khovratovich and Alex Biryukov. It relies on RAM as the bottleneck resource for generating proofs and we believe this makes it ASIC resistant. We'll post soon with more detail on our motivations, algorithm selection, and implementation. This release uses temporary proof-of-concept parameters and an unoptimized implementation. + +This release breaks compatibility with the old testnet. Several of our upcoming releases will also break compatibility because we'll be adjusting each of these features as we move forward, such as #762 Mining Slow Start, #856 Select Equihash Parameters, and #857 Optimize Equihash Implementation. + +To get connected to the new testnet, follow the instructions on the Public Alpha Guide. + + + + + + + +
[1]For more specific detail, view our PoW Release github milestone.
\ No newline at end of file diff --git a/_posts/2016-04-15-why-equihash.md b/_posts/2016-04-15-why-equihash.md new file mode 100644 index 0000000..71a485c --- /dev/null +++ b/_posts/2016-04-15-why-equihash.md @@ -0,0 +1,45 @@ +--- +ID: 1648 +post_title: Why Equihash? +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/why-equihash/ +published: true +post_date: 2016-04-15 00:00:00 +--- +In our last blog post, we announced that we have started using Equihash as the proof-of-work for block mining in Zcash (#27). + +Equihash is a Proof-of-Work algorithm devised by Alex Biryukov and Dmitry Khovratovich. It is based on a computer science and cryptography concept called the Generalized Birthday Problem. +
+

Why are we using it?

+Equihash has very efficient verification. This could in the future be important for light clients on constrained devices, or for implementing a Zcash client inside Ethereum (like BTC Relay, but for Zcash). + +Equihash is a memory-oriented Proof-of-Work, which means how much mining you can do is mostly determined by how much RAM you have. We think it is unlikely that anyone will be able to build cost-effective custom hardware (ASICs) for mining in the foreseeable future. + +We also think it is unlikely that there will be any major optimizations of Equihash which would give the miners who know the optimization an advantage. This is because the Generalized Birthday Problem has been widely studied by computer scientists and cryptographers, and Equihash is close to the Generalized Birthday Problem. That is: it looks like a successful optimization of Equihash would be likely also an optimization of the Generalized Birthday Problem. + +Nevertheless, we can't know for certain that Equihash is safe against these issues, and we may change the Proof-of-Work again, if we find some flaw in Equihash or if we find another Proof-of-Work algorithm which offers higher assurance. + +
+
+

How can I mine?

+The same way as before! Just add gen=1 to your config file, or run ./src/zcashd -gen. + +
+
+

What are the mining requirements?

+The memory requirements for testnet mining are currently set very low, because the implementation is not optimised. So currently, anyone who was mining before can still mine. + +Once we have optimised the implementation (#857), we will bump up the memory requirements to around 1 GB of RAM (#856), so you will need that much free memory per mining thread. + +
+
+

What's next?

+The next step in our use of Equihash is to write an optimised implementation. Once that is done, we will reset the testnet with higher-memory parameters. + +Further down the track, our goal is to have the Equihash solver optimised for running on smartphones. We hope that this will greatly aid the decentralization of mining — users could mine Zcash while their phones are plugged in and unused overnight! + +Stay tuned for an upcoming blog post about how Equihash works! + +
\ No newline at end of file diff --git a/_posts/2016-04-26-fixing-zcash-vulns.md b/_posts/2016-04-26-fixing-zcash-vulns.md new file mode 100644 index 0000000..7476f47 --- /dev/null +++ b/_posts/2016-04-26-fixing-zcash-vulns.md @@ -0,0 +1,84 @@ +--- +ID: 1561 +post_title: > + Fixing Vulnerabilities in the Zcash + Protocol +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/fixing-zcash-vulns/ +published: true +post_date: 2016-04-26 00:00:00 +--- +

Intro

+by Zooko + +I've worked in cryptography, information security, and digital money for half of my life (20 years, but who's counting?), and I've never worked on a cryptosystem as ambitious as Zcash. Fortunately, I've also never worked with a team so uniquely skilled at the exacting task of constructing secure and practical cryptosystems. + +An essential part of the practice of computer security is an “adversarial” process in which you try to attack a system — to find weaknesses in it — at the same time as you are trying to strengthen it. This process can be disconcerting to outsiders, but to computer security experts, if we see someone finding, fixing, and publishing security issues, this gives us confidence that the system is getting stronger. + +Members of our team have previously done this sort of security auditing work for others, including Cryptocat, GlobaLeaks, SpiderOak, and Ethereum. + +In this blog post, we report on the security issues we've found in the Zcash protocol while preparing to deploy it as an open, permissionless financial system. + +Some of our team published the original Zerocash science paper, with scientific peer review, in 2014. Recently, we have extended and improved the protocol, written a detailed new protocol specification, and scoured it for security vulnerabilities. + +To date, we've found and fixed three security vulnerabilities: +
    +
  1. Zooko Wilcox found the Faerie Gold vulnerability, which would have made it possible to fool a Zcash user into thinking they received a bunch of spendable notes. In fact, when they try to spend the notes they will find that only one of them can be spent.
    2. +
  2. Taylor Hornby found the InternalH Collision vulnerability, which would let someone double-spend a specially-crafted note, if they have a computer powerful enough to find 128-bit hash collisions.
    3. +
  3. Daira Hopwood found a non-exploitable mistake in the security proof, where if one of the pseudorandom functions the protocol uses is not also collision-resistant, then notes sent to a specially-crafted private address could be double spent. (This was not exploitable because the function that is actually used does happen to be collision-resistant.)
    4. +
+Here is Taylor's write-up of the most impactful of these three — the InternalH Collision Vulnerability, which he found. + +— Zooko Wilcox, 2016-04-25 + +

The InternalH Collision Vulnerability

+by Taylor + +Had we launched Zcash without finding and fixing the InternalH Collision vulnerability, it could have been exploited to counterfeit currency. Someone with enough computing power to find 128-bit hash collisions would have been able to double-spend money to themselves, creating Zcash out of thin air. + +Finding 128-bit hash collisions requires :math:`2^{64}` parallelizable operations, which is within reach of attackers today, so the vulnerability would have been exploitable in practice. Let's see how the attack works, and what we did to fix it. +

The Mistake

+The weakness was in the commitment scheme for notes. Commitment schemes are useful cryptographic tools because they let you publish a commitment to some information without revealing it. Then, at some later time, you can open the commitment to reveal the information and prove to everyone that it's the same information you committed to in the first place. + +In order for this to work, commitment schemes need to satisfy two properties: +
    +
  1. Hiding: You don't learn anything about the information from seeing the commitment. Even if you're pretty sure of what the information was, you shouldn't be able to confirm your guess.
    2. +
  2. Binding: If you commit to some value, you shouldn't be able to change your mind later and say you actually committed to a different value. A commitment should open to one unique value, and it shouldn't be possible to open the commitment to any other value.
    3. +
+In Zcash, the fundamental object of value is called a “note”, which consists of the values :math:`(a_{pk}, v, ρ, r)` which have special meanings in the protocol. As part of the protocol, commitments to notes are published onto the blockchain. Here's how that commitment was computed in the original design: + +:math:`InternalH = \text{SHA256Compress}(a_{pk} \text{ \| } ρ) \text{ truncated to 128 bits }` +:math:`k = \text{SHA256Compress}(r \text{ \| } InternalH)` +:math:`cm = \text{SHA256Compress}(k \text{ \| } [0]^{192} \text{ \| } v)` + +Here, SHA256Compress is the compression function used internally by the SHA256 hash function. + +The InternalH Collision vulnerability exists because this scheme is missing the binding property. It's possible to commit to one note and then open the commitment later to a different note. + +It's easy to see how this can be done if you can collide 128-bit hashes. The commitment starts out by computing :math:`InternalH`, an 128-bit hash of :math:`a_{pk}` and :math:`ρ`, and then committing to that hash. If you find an +InternalH collision, then you have two different :math:`a_{pk}` and :math:`ρ` pairs :math:`(a_{pk}, ρ)` and :math:`(a_{pk}\prime, ρ\prime)` that give the same :math:`InternalH`, and you'll be able to open the commitment to either of :math:`(a_{pk}, v, ρ, r)` or :math:`(a_{pk}\prime, v, ρ\prime, r)`. So the commitment scheme isn't binding. How does this weakness translate into an attack? +

The Attack

+Commitments to all notes in existence are stored on the blockchain. In order to spend a note, you must prove in zero-knowledge that you know the spending key for a note that was committed to on the blockchain and you must reveal that note's nullifier. The nullifier is a value that's supposed to be unique for each note. To make sure no note can be spent twice, all nodes on the network check that they haven't seen the newly-revealed nullifier before. + +The nullifier of a note :math:`(a_{pk}, v, ρ, r)` owned by a spending key :math:`a_{sk}` is computed by applying a psuedorandom function to :math:`ρ`, i.e. the nullifier is :math:`PRF_{a_{sk}}^{nf}(ρ)`. The spender must prove in zero-knowledge (without revealing :math:`ρ` or :math:`a_{sk}`) that they computed the nullifier correctly. + +The InternalH weakness lets an attacker craft a note commitment for which two different valid :math:`ρ` values exist. They can find :math:`ρ_1` and a different :math:`ρ_2` such that the commitment opens to either :math:`(a_{pk}, v, ρ_1, r)` or :math:`(a_{pk}, v, ρ_2, r)`. The attacker can spend the note commitment a first time using :math:`ρ_1` revealing the nullifier :math:`PRF_{a_{sk}}^{nf}(ρ_1)`, and then spend it a second time using :math:`ρ_2` revealing the nullifier :math:`PRF_{a_{sk}}^{nf}(ρ_2)`. In effect, this note has two different nullifiers instead of just one, so it can be spent twice. Since all of this is done in zero knowledge, none of the nodes on the network can tell that both spends are referencing the same note commitment. Another variant of the attack works by finding two different :math:`a_{pk}`, rather than two different ρ. + +For every 128-bit hash collision the attacker finds, they can effectively double their wealth by combining all of their Zcash into one double-spendable note and then double-spending it to themselves. So even though the :math:`2^64` operations to find a collision aren't cheap, the attack quickly pays off. +

The Fix

+If you read Section 5.1 of the original Zerocash science paper, you'll find that :math:`InternalH` was chosen to be 128 bits in order to give the commitment scheme a very strong property called statistical hiding. The ordinary hiding property is computational: it says that you can't learn anything about the input unless you have an absurdly fast computer (i.e. capable of breaking SHA256). Statistical hiding says that even if you have an infinitely fast computer, you still can't learn anything about the input. This would have allowed Zcash to retain its privacy guarantees even if one day the SHA256 hash function were broken. + +To fix the vulnerability, we switched to a different commitment scheme that has secure binding. In order to keep the Zcash zero-knowledge proofs efficient to compute, we dropped the powerful statistical hiding property and settled for the regular one. This shouldn't matter in practice, since in order to break the hiding property of our new commitment scheme, you'd have to break a well-studied security property of SHA256, which seems unlikely to happen anytime soon. Here's our current design for the note commitment scheme: + +:math:`cm = \text{SHA256}(\text{0xB0} \text{ \| } a_{pk} \text{ \| } v \text{ \| } ρ \text{ \| } r)` + +

Conclusion

+Building secure crypto protocols is hard, and even our team of world-class cryptographers and security engineers will make mistakes along the way. Despite the challenge, we're optimistic that our practices of careful security review and transparency will lead to a secure product. + +At this point the Zcash protocol has been subjected to intense security review, first through scientific peer review, and then by our in-house team of experts. But we need even more scrutiny to gain assurance that the protocol is safe. + +If you like the challenge of hunting for bugs in crypto protocols, we would love it if you had a look over our protocol specification. If you can break our protocol and tell us how you did it, you will be helping all of humanity to gain an open, permissionless, privacy-preserving financial system! + +— Taylor Hornby with Zooko Wilcox, 2016-04-25 \ No newline at end of file diff --git a/_posts/2016-05-09-sprout-roadmap.md b/_posts/2016-05-09-sprout-roadmap.md new file mode 100644 index 0000000..bb04048 --- /dev/null +++ b/_posts/2016-05-09-sprout-roadmap.md @@ -0,0 +1,28 @@ +--- +ID: 1634 +post_title: Announcing Zcash Sprout +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/sprout-roadmap/ +published: true +post_date: 2016-05-09 00:00:00 +--- +
+

2016-09-27 Update:

+

The schedule in this post is outdated. Please see our newer post Zcash Launch and Roadmap for the up-to-date schedule for the Zcash launch and the Sprout release series.

+
+
+Zcash Sprout Logo

Zcash Sprout Series

+
+

In September 2016 the first open, permissionless financial system with zero-knowledge security will launch: the Zcash blockchain.

+

Starting with version 1.0 of Zcash, we're launching the Sprout series, emphasizing that Zcash will begin life as a young, tender thing, but will be a living organism with great potential to grow. It will be a Bitcoin-like cryptocurrency with zero-knowledge privacy, a new Proof-of-Work algorithm, and an API.

+

The Zcash core design is now in our Zcash Protocol specification. Our roadmap for the 1.0 launch has firmed up. It's embodied in our github milestones.

+

Sprout is only the beginning and there are exciting innovations to come.

+
+

Get Involved

+

If you're interested in infrequent announcements, such as for our launch, sign up for our email announcement list.

+

Join our forum for user discussions, or our Community Slack if you want realtime developer chat.

+

If you're the adventurous type who wants to play with our current alpha code, check out our Public Alpha Guide.

+

— Nathan Wilcox and Zooko Wilcox, 2016-05-09

+
\ No newline at end of file diff --git a/_posts/2016-05-17-new-alpha-release-libzcash.md b/_posts/2016-05-17-new-alpha-release-libzcash.md new file mode 100644 index 0000000..e1735aa --- /dev/null +++ b/_posts/2016-05-17-new-alpha-release-libzcash.md @@ -0,0 +1,31 @@ +--- +ID: 1580 +post_title: 'New Alpha Release: libzcash' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-alpha-release-libzcash/ +published: true +post_date: 2016-05-17 00:00:00 +--- +Today, we deployed a new alpha release of the Zcash reference implementation, v0.11.2.z3, to the testnet. The new release includes the following changes [1]: +
    +
  1. We've implemented the Zcash protocol in the form of libzcash, including a rewrite of our zkSNARK circuit. (#908)
    2. +
  2. We have a new implementation of our incremental merkle tree with better space efficiency and memory safety. (#889)
    3. +
  3. We've replaced crypto++'s key-private encryption with NoteEncryption as defined in our protocol specification. (#888)
    4. +
  4. We've added googletest to our test suite for isolated unit testing of libzcash and other core components in our protocol. (#879)
    5. +
+We've been hard at work solidifying a protocol specification which addresses security and terminology issues in the original Zerocash design, some of which we mentioned in a previous blog post. libzcash is a replacement for the old protocol implementation which brings us closer to realizing this new design. + +As with our previous alpha releases, this resets our testnet, invalidating all previous coins and breaking backwards compatibility. To get connected to the new testnet, follow the instructions on the Public Alpha Guide. + +To follow our progress, watch the github project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here. + + + + + + + +
[1]For more specific detail, view our Zcash Protocol 2.0 github milestone.
\ No newline at end of file diff --git a/_posts/2016-05-25-hiring.md b/_posts/2016-05-25-hiring.md new file mode 100644 index 0000000..e73b814 --- /dev/null +++ b/_posts/2016-05-25-hiring.md @@ -0,0 +1,35 @@ +--- +ID: 1570 +post_title: Hiring +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/hiring/ +published: true +post_date: 2016-05-25 00:00:00 +--- +

Jobs at Zcash

+We're on a mission to give everyone on Earth an open, permissionless financial system, and we need your help. + +We have three different needs right now, and we're actually hoping to meet someone who can help out with more than one of these. But if you can do a world-class job in at least one of these roles, please get in touch. +
+

Engineering

+cryptography, cryptocurrencies, C++, distributed systems, secure coding, network protocols, test-driven development, Rust + +
+
+

Devops

+operational security, web site, backups, source code management, monitoring and alerting, continuous integration, measurement and visualization + +
+
+

External Communications

+writing, editing, social media, design, community relations, press relations, international relations, Chinese, Spanish, Portugese, Russian + +
+ +
+

Our culture

+We believe in respectfulness, inclusivity, and openness. Our work springs out of passion, but we temper our enthusiasm with respect for our co-workers and families. The company is entirely distributed and everyone works remotely, except those lucky few who happen to live in the same city as one another and can meet up to collaborate in-person. + +Join us! Please send your interest, résumé and achievements to info@z.cash. \ No newline at end of file diff --git a/_posts/2016-06-01-new-alpha-release-mining-slow-start.md b/_posts/2016-06-01-new-alpha-release-mining-slow-start.md new file mode 100644 index 0000000..9250a62 --- /dev/null +++ b/_posts/2016-06-01-new-alpha-release-mining-slow-start.md @@ -0,0 +1,22 @@ +--- +ID: 1581 +post_title: 'New Alpha Release: Mining Slow Start' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-alpha-release-mining-slow-start/ +published: true +post_date: 2016-06-01 00:00:00 +--- +

Taylor Hornby, Sean Bowe

+

Today, we deployed a new alpha release of the Zcash reference +implementation, v0.11.2.z4, to the testnet. The new release includes the following changes [1]:

+
  1. We implemented a mining slow start to slowly ramp up the controlled currency supply after launch. (#762).
    2. +
  2. We enabled binary serialization (#954) and multicore zkSNARK computation in libsnark (#957) which provide performance improvements visible on our new performance tracker.
    3. +
  3. We added cryptographic binding of transactions using Ed25519 (#976).
    4. +
  4. We optimized the memory usage of our implementation of the Equihash proof of work (#921). The differences in running time and memory usage between the unoptimized and optimized versions are visualized in this chart.
    5. +

With mining slow start, the block reward linearly ramps up over a period of 5000 blocks before reaching its maximum value. This limits the effect of the "race to start", by providing a window after production launch during which the reward is low. Miners surprised by the launch will only be missing out on the low-value early blocks. Mining slow start was suggested by Jack Gavigan, one of our advisors.

+

As with our previous alpha releases, this resets our testnet, invalidating all previous coins and breaking backwards compatibility. To get connected to the new testnet, follow the instructions on the Public Alpha Guide.

+

To follow our progress, watch the github project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.

+
[1]For more specific detail, view our Protocol 2016.0-beta github milestone.
\ No newline at end of file diff --git a/_posts/2016-06-17-new-alpha-release-faster-block-times.md b/_posts/2016-06-17-new-alpha-release-faster-block-times.md new file mode 100644 index 0000000..87e50e2 --- /dev/null +++ b/_posts/2016-06-17-new-alpha-release-faster-block-times.md @@ -0,0 +1,23 @@ +--- +ID: 1579 +post_title: 'New Alpha Release: Faster Block Times' +author: Taylor Hornby +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-alpha-release-faster-block-times/ +published: true +post_date: 2016-06-17 00:00:00 +--- +

Today, we deployed a new alpha release of the Zcash reference implementation, v0.11.2.z5, to the testnet. The new release includes the following changes [1]:

+
  1. The block interval target has been decreased to 2.5 minutes, without changing the monetary supply curve (#989).
    2. +
  2. The difficulty adjustment has been changed to one based on DigiShield v3/v4 (#147, #1004).
    3. +
  3. Coinbase rewards must be protected before they can be used in transparent transactions (#1017).
    4. +
  4. Upstream's soft forking rules now apply unconditionally to all blocks from the start (#1016).
    5. +
  5. The Equihash implementation has been optimized further (#988), enabling us to switch to more difficult (higher memory) parameters (#1003). The difference can be seen on our performance tracker.
    6. +
  6. The -relaypriority default has been set to false, to enable spending of low-value rewards during mining slow start (#1001).
    7. +
  7. The note commitment tree depth has been increased from 20 to 29 (#994). The resulting increase in memory usage when creating a JoinSplit is visible here.
    8. +
  8. Zcash addreses and spending keys are now encoded with Base58Check (#1026).
    9. +

As with our previous alpha releases, this resets our testnet, invalidating all previous coins and breaking backwards compatibility. To get connected to the new testnet, follow the instructions on the Public Alpha Guide.

+

To follow our progress, watch the github project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.

+
[1]For more specific detail, view our Protocol 2016.1 Implementation github milestone.
\ No newline at end of file diff --git a/_posts/2016-07-06-pairing-cryptography-in-rust.md b/_posts/2016-07-06-pairing-cryptography-in-rust.md new file mode 100644 index 0000000..7e532a0 --- /dev/null +++ b/_posts/2016-07-06-pairing-cryptography-in-rust.md @@ -0,0 +1,99 @@ +--- +ID: 1609 +post_title: Pairing cryptography in Rust +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/pairing-cryptography-in-rust/ +published: true +post_date: 2016-07-06 00:00:00 +--- +Pairing cryptography is an exciting area of research, and an essential component of Zcash's zkSNARKs — proofs that transactions are valid without requiring users to reveal private information. Earlier this year we also used zkSNARKs to make Bitcoin's first zero-knowledge contingent payment! + +One of our goals going forward is to better explain how these tools work, and to make them more accessible to the public. As a first step, we're starting development of a pairing cryptography library for Rust called "bn". Pairing cryptography is important for zkSNARKs, but what exactly is it? +

Elliptic Curves

+Regular elliptic curve constructions like secp256k1 — used in Bitcoin — are designed for things like digital signatures. The points on the curve form a cyclic group: they can be added together and multiplied by scalars. It is believed to be infeasible to find the multiplicand given a point and the product point, called the "elliptic curve discrete logarithm problem". + +This asymmetry (the ease of multiplying but the difficulty of the reverse) is used to make a number of useful tools and protocols. Diffie-Hellman key exchange is a simple example: Alice multiplies Bob's public key by her (scalar) private key, and vice versa, to find a shared secret in the presence of an eavesdropper. + +This key exchange protocol can be extended to three parties, but requires two rounds: for parties A, B, and C, A obtains the shared secret by having B send his public key to C, who multiplies it by her private key and sends the result to A, who can then derive the shared secret by multiplying it by her private key. +

Pairing cryptography

+Pairing cryptography is an extension of these concepts. Now imagine that we have two cyclic groups: :math:`G_{1}` and :math:`G_{2}`, written additively, and a mapping to a third cyclic group of the form e: :math:`G_{1} \times G_{2} \rightarrow G_{T}`, where :math:`G_{T}` is written multiplicatively. If this mapping is bilinear, then: + +:math:`e(a g_{1}, b g_{2}) = e(g_{1}, g_{2})^{ab}` where :math:`a` and :math:`b` are scalars and :math:`g_{1}` and :math:`g_{2}` are generators for their respective groups. + +Essentially, a scalar multiplication of one of the first two group elements is equivalent to an exponentiation of the final group element. +

Joux's key agreement protocol

+Let's apply pairing cryptography to the three-party key exchange scenario above. Using pairings, we can perform the exchange in one round. Each party :math:`P` publishes their public key :math:`P^{pk} = (P^{sk} g_{1}, P^{sk} g_{2})` and keeps their private key :math:`P^{sk}` secret. All of the parties :math:`A, B, C` can compute the same shared secret using the bilinear pairing function: + + + + + + + + + + + + + + + + + + +
Alice ComputesBob ComputesCarol Computes
:math:`e(B_{1}^{pk}, C_{2}^{pk})^{A^{sk}}`:math:`e(C_{1}^{pk}, A_{2}^{pk})^{B^{sk}}`:math:`e(A_{1}^{pk}, B_{2}^{pk})^{C^{sk}}`
All equivalent to :math:`e(g_{1}, g_{2})^{A^{sk} B^{sk} C^{sk}}`
+ +Or, if you prefer code, check out an example from our new library: + + + + + + + +
+
+
 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
+12
+13
+14
+15
+16
+
 +
+
// Generate private keys
+let alice_sk = Scalar::random(rng);
+let bob_sk = Scalar::random(rng);
+let carol_sk = Scalar::random(rng);
+
+// Generate public keys in G1 and G2
+let (alice_pk1, alice_pk2) = (G1::one() * &alice_sk, G2::one() * &alice_sk);
+let (bob_pk1, bob_pk2) = (G1::one() * &bob_sk, G2::one() * &bob_sk);
+let (carol_pk1, carol_pk2) = (G1::one() * &carol_sk, G2::one() * &carol_sk);
+
+// Each party computes the shared secret
+let alice_ss = pairing(&bob_pk1, &carol_pk2) ^ &alice_sk;
+let bob_ss = pairing(&carol_pk1, &alice_pk2) ^ &bob_sk;
+let carol_ss = pairing(&alice_pk1, &bob_pk2) ^ &carol_sk;
+
+assert!(alice_ss == bob_ss && bob_ss == carol_ss);
+
+
+ +

bn

+The "bn" crate is a Rust language library for performing these pairing operations using a cryptographic construction designed by our scientists in [BCGTV14]. It uses a Barreto-Naehrig elliptic curve tuned for use in zkSNARKs. The library is new and incomplete and shouldn't be used in production software, but it is a nice step forward in our goal of making this new kind of cryptography more widely understood and easier to use. + +Check out the bn crate on github or on crates.io! And feel free to join our Slack or sign up for email notifications from our team! \ No newline at end of file diff --git a/_posts/2016-07-08-new-alpha-release-2mb-blocks.md b/_posts/2016-07-08-new-alpha-release-2mb-blocks.md new file mode 100644 index 0000000..8a1cd64 --- /dev/null +++ b/_posts/2016-07-08-new-alpha-release-2mb-blocks.md @@ -0,0 +1,19 @@ +--- +ID: 1577 +post_title: 'New Alpha Release: 2MB blocks' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-alpha-release-2mb-blocks/ +published: true +post_date: 2016-07-08 00:00:00 +--- +

Today, we deployed a new alpha release of the Zcash reference implementation, v0.11.2.z6, to the testnet. The new release includes the following changes [1]:

+
  1. The block size limit has been increased to 2MB. (#765) We're tracking the worst-case verification costs in some new performance measurements and in #1077 in +order to mitigate potential DoS attacks.
    2. +
  2. Equihash nonces are now randomized to avoid duplicate effort by miners. (#1060)
    3. +
  3. Equihash solving runs are now slightly more efficient. See #1049 and the change in performance measurements on our tracker.
    4. +

Unlike previous alpha releases, we have not reset the testnet in order to give our mining slow start more time to run. Therefore, the block size limit change has been introduced as a (naive) hardfork.

+

To follow our progress, watch the github project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.

+
[1]For more specific detail, view our Consensus Parameter Tuning / Optimization github milestone.
\ No newline at end of file diff --git a/_posts/2016-07-13-zcash-website-now-in-english-and-chinese.md b/_posts/2016-07-13-zcash-website-now-in-english-and-chinese.md new file mode 100644 index 0000000..ab8aabf --- /dev/null +++ b/_posts/2016-07-13-zcash-website-now-in-english-and-chinese.md @@ -0,0 +1,17 @@ +--- +ID: 1661 +post_title: > + The Z.cash Website is Now in Both + English and Chinese +author: Maureen Walsh +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/zcash-website-now-in-english-and-chinese/ +published: true +post_date: 2016-07-13 00:00:00 +--- +

Today we are releasing the Zcash website in Chinese. And soon we will have Chinese-specific sections of our Zcash Forum, Slack Community for our Chinese-speaking enthusiasts to participate and grow that part of the Zcash ecosystem.

+

The Zcash team is proud of this release, as we intend to translate the site into many other languages over the coming months. Zcash aims to create an open, permissionless financial network, which all of the world's people can use to give themselves financial freedom and safety; having our content in multiple languages is one of the many ways we hope to achieve that goal.

+

We love and cherish the many contributors, listeners, advocates, ambassadors, technicians, and enthusiasts that live and work all over the world. Thank you to our trusted translators and those who helped engineer this translation project, namely Zcash engineer Jay Graber, consultant Jing Wang, and Zcash investor group, Fenbushi Capital.

+

Zcash is a global company, interested in inviting all Zcash participants around the world to join the conversation!

\ No newline at end of file diff --git a/_posts/2016-07-22-new-alpha-release-terminology-and-security.md b/_posts/2016-07-22-new-alpha-release-terminology-and-security.md new file mode 100644 index 0000000..663f850 --- /dev/null +++ b/_posts/2016-07-22-new-alpha-release-terminology-and-security.md @@ -0,0 +1,21 @@ +--- +ID: 1584 +post_title: 'New Alpha Release: Terminology and Security' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-alpha-release-terminology-and-security/ +published: true +post_date: 2016-07-22 00:00:00 +--- +

Today, we deployed a new alpha release of the Zcash reference implementation, v0.11.2.z7, to the testnet. The new release includes the following changes [1]:

+
  1. The terminology of the RPC and internal code has been modified to reflect our +protocol specification. (#1090)
    2. +
  2. We have forked libsnark and made a number of changes to improve security and performance. The public parameters have shrunk by about 35% and memory usage during JoinSplit creation has improved by several hundred megabytes. (#1104)
    3. +
  3. We have published guidelines about side-channel attacks and other security warnings.
    4. +
  4. The alert key has been changed. (#1105)
    5. +
  5. A bug in the difficulty adjustment algorithm has been fixed. (#1124)
    6. +

We have changed protocol version numbers, which requires all old nodes to upgrade to continue to use the testnet network. However, we are not resetting the testnet blockchain for this release.

+

To follow our progress, watch the github project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.

+
[1]For more specific detail, view our z7 release github milestone.
\ No newline at end of file diff --git a/_posts/2016-07-27-science-roundup-july.md b/_posts/2016-07-27-science-roundup-july.md new file mode 100644 index 0000000..0ccb26c --- /dev/null +++ b/_posts/2016-07-27-science-roundup-july.md @@ -0,0 +1,48 @@ +--- +ID: 1615 +post_title: Science Roundup +author: Maureen Walsh +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/science-roundup-july/ +published: true +post_date: 2016-07-27 00:00:00 +--- +

Zcash is a science-driven company, and our team is always working on advancing the forefront of human knowledge. Here is a round-up of science news from our team.

+ +

Side Channel Attacks on Everyday Applications

+

Zcasher Taylor Hornby will be presenting on Side Channel Attacks on Everyday Applications at the Black Hat conference on August 3.

+

In this talk, Taylor will briefly describe how the FLUSH+RELOAD attack works, and how it can be used to build input distinguishing attacks. In particular, he’ll demonstrate how when the user Alice browses around the top 100 Wikipedia pages, the user Bob can spy on which of those pages she's visiting. This isn't an earth-shattering attack, but as the code he’ll release shows, it can be implemented reliably. The goal is to convince the community that side channels, FLUSH+RELOAD in particular, are useful for more than just breaking cryptography.

+

Known for his carefully written security tools, including a side-channel-free password generator and a cryptography library for PHP, Taylor regularly contributes to a number of open-source projects by security auditing and reviewing source code. This work builds on the foundations laid in part by Zcash scientist Eran Tromer (http://cs.tau.ac.il/~tromer/cache/).

+

The event is in Las Vegas, USA from July 30-Aug 4, 2016. Full info here: https://www.blackhat.com/us-16/

+ +

Image Authentication

+

Zcash scientist, Eran Tromer, presents an application of SNARKs in the area of image authentication.

+

Authenticity of digital photographs is important in many contexts, including social websites, dating, news reporting, and legal evidence. In principle, authenticity could be ensured by secure in-camera signing of images, as offered by some cameras. However, users often need to apply some legitimate editing operations to images (e.g., cropping, downscaling and brightness adjustment), in order to prepare them for publication. Creating an image authentication scheme that allows some editing operations, but not others, has been a subject of active research for decades.

+

Eran and his student have created a new image authentication scheme, PhotoProof, which is the first to allow complete flexibility in the choice of what editing operations are permissible, and is also more robust to forgery. The scheme is based on the same zero-knowledge SNARK proof systems that underlie Zcash. Whereas Zcash reasons about the provenance of digital currency across payment operations, PhotoProof reasons about the provenance of images across editing operations.

+

There is more information about this here: https://cs.tau.ac.il/~tromer/photoproof/

+ +

Lawsuit on DMCA Section 1201: Research & Technology Restrictions Violate 1st Amendment

+

The Electronic Frontier Foundation (EFF) is suing the U.S. government on behalf of technology creators and researchers to overturn onerous provisions of copyright law that violate the First Amendment, as stated in this blog post.

+

Zcasher Matthew Green is a plaintiff in the trial “who wants to make sure that we all can trust the devices that we count on to communicate, underpin our financial transactions, and secure our most private medical information. Despite this work being vital for all of our safety, Green had to seek an exemption from the Library of Congress last year for his security research.”

+ +

Blind Off-Chain Lightweight Transactions

+

Matthew Green and Ian Miers, two of the seven founders/scientists of the Zcash company, have a paper on BOLT (Blind Off-chain Lightweight Transactions). It’s roughly a privacy preserving version of payment channels like Lightning for Zcash. We will be publishing a more in-depth blog post about it early next week.

+

Private payment channels are important because they allow you to pay someone without waiting for block confirmation and they greatly reduce the volume of transactions that must be recorded in the blockchain. Payment channels work by creating blockchain-backed IOUs between two parties, which they can then update without using the blockchain to reflect the balance of funds between them. But this process isn’t private since the IOU serves as a unique identifier the merchant can use to link multiple payments together. So for example, if you are using a payment channel to pay for page views on a website, it’s effectively a tracking cookie.

+

BOLT uses blind signatures and commitments to make private IOUs. When you present one to a merchant, these record the fact that the merchant’s balance in the IOU has increased, but without actually revealing which IOU it is you are using and thus who you are. BOLT even supports payments via an intermediary when there is no direct channel between two parties. And the intermediary learns nothing, not even the amount that is paid.

+ +

Towards Trapdoor-Free Zero Knowledge Proving Systems

+

The strong privacy guarantees of Zcash are made possible by significant computer science breakthroughs from the last few years. These breakthroughs circumvent the use of Probabilistically Checkable Proofs (PCPs).

+

PCPs are a powerful theoretical computer science tool, and until recently were considered essential for efficient Zero-Knowledge proof systems. The reason for wanting to avoid the use of PCPs is that although they are efficient from a theoretical standpoint, they are considered notoriously inefficient and too complex in practice.

+

This avoidance comes at a cost: in these new systems there is always trapdoor information that should be destroyed after the system is initialized, and which could compromise the system if ever discovered.

+

In a recent work, SCIPR Lab has made a significant first step towards making PCP-based systems, in which no such trapdoor exists, closer to practice. Currently they are able to generate proofs about programs that use a million machine cycles. The team working on this includes five Zcashers: Eli Ben-Sasson, Alessandro Chiesa, Ariel Gabizon, Eran Tromer and Madars Virza.

+ +

Ciphertext Attacks on iMessage

+

The Washington Post published the story: "Johns Hopkins researchers poke a hole in Apple’s encryption," which describes the results of research that Zcashers Matthew Green, Ian Miers, and Christina Garman (along with others) have been working on over the past few months. Below is part of Matthew Green’s blog post to describe the research and implications. For more technical reading, the academic paper can be found here: “Dancing on the Lip of the Volcano: Chosen Ciphertext Attacks on Apple iMessage.”

+

From Matthew Green’s blog post (full text here)... +“As you might have guessed from the headline, the work concerns Apple, and specifically Apple's iMessage text messaging protocol. Over the past months my students Christina Garman, Ian Miers, Gabe Kaptchuk and Mike Rushanan and I have been looking closely at the encryption used by iMessage, in order to determine how the system fares against sophisticated attackers. The results of this analysis include some very neat new attacks that allow us to –under very specific circumstances– decrypt the contents of iMessage attachments, such as photos and videos.”

+
+iMessage research team
+

The research team. From left: Gabe Kaptchuk, Mike Rushanan, Ian Miers, Christina Garman

+

Connect to the Zcash conversation by joining our Slack channel or get infrequent email notifications by signing up.

\ No newline at end of file diff --git a/_posts/2016-07-28-zksnarks-in-ethereum.md b/_posts/2016-07-28-zksnarks-in-ethereum.md new file mode 100644 index 0000000..25d9c75 --- /dev/null +++ b/_posts/2016-07-28-zksnarks-in-ethereum.md @@ -0,0 +1,32 @@ +--- +ID: 1662 +post_title: zkSNARKs in Ethereum +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/zksnarks-in-ethereum/ +published: true +post_date: 2016-07-28 00:00:00 +--- +

Over the last week, Zcashers Vitalik Buterin, Andrew Miller, Eran Tromer and myself have been at the Ethereum/IC3 Bootcamp at Cornell. At the event, we worked with a fantastic team of Cornell students/interns and a member of the Ethereum foundation to bring zkSNARKs to Ethereum for the first time.

+
+SNARKs in Ethereum Team Photo

(Left to Right) Yuncong Hu, Casey Detrio, Josh Gancher, Sean Bowe, Eran Tromer

+
+
+

SNARKs

+

zk-SNARKs are the cryptographic tool underlying Zcash. They are proofs that you have performed a computation over some inputs without revealing all of the inputs. Zcash uses these proofs to verify transactions while protecting users' privacy.

+

In addition to being great for privacy, they're also great at reducing the verification cost of complicated smart contracts. Since they can be verified quickly, and because the proofs are small, they can protect the integrity of the computation without burdening non-participants.

+

In our work this week, we extended the Ethereum contract language to efficiently support verification of zkSNARK proofs. Specifically, we added a snarkverify precompile (like an opcode) to a fork of Parity which uses libsnark to verify generic proofs.

+
+
+

Zerocash over Ethereum

+Sean Bowe demonstrates the circuit.

As a demonstration, we used this new zkSNARK verifier in Ethereum to implement a primitive coin mixing contract using a simplified variant of Zerocash -- the academic protocol that Zcash based its implementation on. We call this "baby" ZoE, for Zerocash over Ethereum. The contract allows you to deposit discrete amounts (units of ETH) by inserting a commitment to a "serial number" into a merkle tree maintained by the contract.

+

In order to withdraw without revealing which commitment you're spending, which would link the withdrawal with the deposit, we use a zkSNARK to prove that we know a commitment inside of the merkle tree of the contract. In order to prevent double-spending, we do so while revealing the serial number, which the contract remembers and prohibits reuse of.

+

In order to prevent other users from taking the proof and withdrawing without your permission, the proof also authenticates for a withdrawal address (in Ethereum) which is authorized to receive the funds from the contract.

+

The idea of integrating Zerocash into a currency using a SNARK verification opcode goes back to the original Zerocash paper (Section 6.3 in Zerocash extended version). Following this prescription, it is possible to extend the ZoE contract to work with the complete Zerocash protocol.

+
+
+

Conclusion

+

We love contributing to both Bitcoin and Ethereum, and look forward to more collaboration with the broader cryptocurrency community. You can look at our group's code here.

+
\ No newline at end of file diff --git a/_posts/2016-08-01-bolt-private-payment-channels.md b/_posts/2016-08-01-bolt-private-payment-channels.md new file mode 100644 index 0000000..9da1e2c --- /dev/null +++ b/_posts/2016-08-01-bolt-private-payment-channels.md @@ -0,0 +1,55 @@ +--- +ID: 1549 +post_title: 'BOLT: Private Payment Channels' +author: Ian Miers +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/bolt-private-payment-channels/ +published: true +post_date: 2016-08-01 00:00:00 +--- +

Matthew Green and I have written a paper introducing BOLT (Blind Off-chain Lightweight Transactions), which offers a fast, private payment channel protocol inspired by the Lightning Network. We believe that this will make Zcash more scalable and practical, while maintaining its strong privacy protections.

+

TL;DR: Using BOLT, multiple payments on the same channel cannot be linked together, even by colluding parties. Payments occur in milliseconds and do not require block confirmation. All a merchant learns is that he is being paid on some channel he has open. Payments can be routed via third parties, avoiding the need for a customer and merchant to directly have a channel, while maintaining privacy against malicious third parties by both keeping the participants anonymous (even if the third party colludes), and hiding the value transferred. All of this requires that the channel be funded with private funds, otherwise malicious parties can violate your privacy by forcing channel closure. A pre-print of the paper can be found at http://eprint.iacr.org/2016/701.

+
+

The Problem

+

Blockchain-based cryptocurrencies work by recording every transaction in public on a blockchain. This has the distinct advantage of eliminating the need for trusted parties. But it has serious privacy, scalability, and latency problems because you are recording every transaction in public on a blockchain. You need the space to record every transaction in the blockchain (see the whole Bitcoin block size debate), recording the transaction in a block takes minutes, and of course the recording is public, so people can figure out a lot about what you are doing.

+
+
+

Payment channels

+

Payment channel protocols, such as the Lightning Network, address the scale and latency issues by using the blockchain only to escrow funds and resolve disputes. Other than that, users exchange what are essentially blockchain-enforced IOUs, which aren’t recorded on the blockchain unless there is a dispute.

+

How does this work? Alice and Bob both agree to an initial IOU splitting funds they put in the channel (e.g. they each put in $50 and the IOU is Alice: $50, Bob: $50). This money is held in escrow on the blockchain and released only by a valid IOU signed by both Alice and Bob. For Alice to pay Bob $5, she verifiably destroys her old IOU, and she and Bob sign a new IOU “Alice: $45, Bob: $55.” They can do this repeatedly until either party wants to cash out. At this point, either Alice or Bob can post the latest IOU to the blockchain (or both can post, in the event of a dispute). Thus only channel opening and closure are recorded on the blockchain.

+
+
+

Channels are not private

+

Channel opening and closure leaves a record identifying the customer, merchant, and the initial and final split of funds. These are often the very things that must be hidden.

+

Suppose Tor (or another anonymity service) took micropayments to pay for bandwidth. Effectively, every webpage Alice views via Tor would require a micropayment via a payment channel, at say a tenth-of-a-cent per page view. If we can see that Alice has a payment channel with Tor for $1.00 that closes with a zero balance every month, then we know she is a heavy Tor user. If Alice is an activist or a journalist, this may bring her to the attention of the authorities as someone with “something to hide” even if she is careful to only use Tor from coffee shops or the like. And If Alice lives in e.g. Turkey, that might be a very bad idea.

+

Fortunately, this is exactly the sort of problem that Zcash was designed to solve. By using Zcash instead of an all-transparent ledger like Bitcoin or Ethereum, the blockchain no longer contains information linking channel opening and closure back to Alice. But Zcash only handles privacy for on-chain payments; it does not deal with the IOUs.

+

The problem is these IOUs form a unique identifier which can be used to track Alice much like a cookie. Anyone who observes these (e.g. the Tor exit node) will not a priori know who the identifier belongs to—her actual identity is still protected by the anonymity service—but they can still observe page views and patterns because multiple payments on a payment channel are inherently linkable. This might be enough to uniquely identify Alice (e.g. if she looks at documents related to newspaper articles she wrote), or it could reveal other information—like what subject she is writing an article on. Thus Zcash is part of the solution, but Zcash itself does not a private payment channel make.

+
+
+

BOLT: Private Payment Channels

+

Enter BOLT, which Matt and I have been working on for the past few months. BOLT eliminates the linkage between payments within a channel. This ensures that Alice’s payments are hidden within the set of all payments made to that recipient.

+

We have designed two protocols, one that is non-interactive but only allows payment from Alice to Bob of fixed values, and one that allows bidirectional payments of arbitrary values but requires interaction. We will focus on the bidirectional protocol here.

+

The basic idea of the protocol is to build private IOUs. We do this using two pieces of technology: blind signatures and commitments. Commitments allow Alice to hide the value of the IOU (which could identify it). Blind signatures convince Bob the IOU is authentic —because he must have signed it—but ensure that he cannot recognize the signature or IOU specifically out of any of the set of IOUs he signed.

+
+BOLT Diagram
+

Alice pays Bob by proving she has such an IOU, invalidating it (by signing it with the Revocation key), and getting Bob to sign a new IOU with a balance that is the same as the old one less the amount of payment. Similarly, when Bob pays Alice the amount is added to the new IOU. The actual balance and signature remains hidden from Bob, ensuring he cannot tell if two distinct payments came from the same channel or different ones.

+

The real challenge is invalidating the old IOU and signing the new one atomically. And—this is the hard part—doing it without leaking which channel Alice is using. If Alice invalidates the old IOU first, and Bob refuses to sign the new IOU, Alice cannot close the channel so she loses her money. If Bob signs the new IOU before the old one is invalidated, then Alice can defraud Bob: She can then take the new IOU Bob signed and use it for a series of payments, but then cash out the original IOU keeping all her money. In normal payment channels, this cannot happen because Bob will recognize Alice’s subsequent fraudulent payments. Doing so for private channels, however, is impossible.

+BOLT Diagram

To solve this, we separate the process of generating IOUs for channel closure from allowing the IOUs to be used for future transactions. An IOU is a commitment to both the balance and a one-time-use public key called the revocation key. We assume Alice has an existing (blindly) signed IOU from channel establishment. ① Alice first creates a new IOU and proves that it pays Bob $5 more than some IOU Bob signed previously. ② Alice then provably reveals the revocation public key of the old IOU and gets ③ Bob to sign the new IOU for closure (after of course proving the new IOU is correctly formed with respect to the old one). ④ Then she signs a message invalidating the old IOU with the revocation key and gives the message + signature to Bob. This is safe because she can now close the channel with the new IOU no matter what happens. ⑤ After ensuring the old IOU is revoked, Bob now signs the new IOU as valid for use in the next payment. This is safe because the old IOU is invalid and thus Bob is assured Alice can never revert back to an old state where she has more money. Alice can now use the new IOU in the next BOLT payment.

+

From Bob's perspective, he knows that he has received a payment (of $5 in this example) on one of his payment channels (or rather, he will receive $5 more when that payment channel is closed) but he doesn't know which payment channel was actually used for the payment : we’ve hidden the actual IOU, its balance, and Bob’s signature on it from him and these are the only ways he could identify the channel.

+

The interesting part is all of this is simple, fast, and uses very well understood crypto. A prototype will be released soon, but we believe it will take less than 50 ms and 10 MB of memory to execute this protocol.

+
+
+

Indirect Payment Channels

+

So far, we require Alice and Bob to have a payment channel. But what if they don’t?

+

Like Lightning, BOLT allows payments when there is no direct channel between parties, provided they share an intermediary (e.g. Coinbase). We do this by making the IOUs’ usage for channel closure conditional on the other transactions going through. Unlike Lightning, a single intermediary learns neither the participants involved nor the amount transferred. To do this, it’s crucial that the channels themselves are funded anonymously, as the third party can abort and observe who closes their channel. If the channel itself is anonymous, this information is worthless.

+

It is likely we can generalize BOLT’s indirect payments to payments via multiple intermediaries, as in Lightning, but at the moment BOLT does not do so.

+
+
+

Can BOLT work without Zcash?

+

We can set up BOLT to work with most cryptocurrencies provided we can add the primitives. We might even be able to do this without any changes to Bitcoin, though at the cost of using hash-based commitments and generic circuit-based multi-party computation (MPC) for blind signing with ECDSA. But any real privacy provided by BOLT fundamentally depends on channel establishment and closure being anonymous.

+

In Bitcoin, funding a channel is not private: there is a record of who you opened the channel with, the amount, and what it closed for. BOLT alone does not solve this problem—it only makes payments on the same channel unlinkable to each other. Worse, if a merchant or third party can force an abort in the BOLT protocol, then they can identify which channel you are using. They can only do this once, so multiple payments on the same channel cannot be linked, but if you did not open the channel anonymously, then that (aborted) payment can be linked to you.

+

To avoid this, you need anonymous funds to create the channel. Indeed, the privacy requirements for funding a channel are as high as those for normal payments. So you want as strong privacy as you would for normal payments. And Zcash is the best way to get strongly private funds.

+

I’d like to thank Sean Bowe, one of the Zcash developers, for suggesting the idea of combining Lightning and Zerocash. And Sean, Maureen, Matthew, Daira, Jack, and the anonymous leopard for feedback on this blog post.

+
\ No newline at end of file diff --git a/_posts/2016-08-06-new-alpha-release-optimization-and-nonmalleability.md b/_posts/2016-08-06-new-alpha-release-optimization-and-nonmalleability.md new file mode 100644 index 0000000..224ae77 --- /dev/null +++ b/_posts/2016-08-06-new-alpha-release-optimization-and-nonmalleability.md @@ -0,0 +1,22 @@ +--- +ID: 1582 +post_title: 'New Alpha Release: Optimization and Non-malleability' +author: Simon Liu +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-alpha-release-optimization-and-nonmalleability/ +published: true +post_date: 2016-08-06 00:00:00 +--- +

Today, we deployed a new alpha release of the Zcash reference implementation, v0.11.2.z8, to the testnet. The new release includes the following changes [1]:

+
  1. Equihash mining parameters have been adjusted to n=200, k=9 to reduce average solution search time to <45 seconds, and average time-to-first-solution to <30 seconds. (#856)
    2. +
  2. The Equihash miner will now interrupt and cancel an existing solution search when a new valid block arrives. (#1055)
    3. +
  3. The Equihash miner will now check solutions as soon as they are found. (#1143)
    4. +
  4. Transaction malleability has been fixed so that valid transactions can not be modified in-flight. (#1144)
    5. +
  5. The SIGHASH_SINGLE bug has been fixed. (#1078)
    6. +
  6. Compilation flags have been updated to harden security. (#1064)
    7. +

The zcraw* RPC commands are still available for use but will be deprecated in a future release.

+

This alpha release will reset our testnet, invalidating all previous coins and breaking backwards compatibility. To get connected to the new testnet, follow the instructions on the Public Alpha Guide.

+

To follow our progress, watch the github project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.

+
[1]For more specific detail, view our z8 release github milestone.
\ No newline at end of file diff --git a/_posts/2016-08-17-auditing-zcash.md b/_posts/2016-08-17-auditing-zcash.md new file mode 100644 index 0000000..8438428 --- /dev/null +++ b/_posts/2016-08-17-auditing-zcash.md @@ -0,0 +1,54 @@ +--- +ID: 1547 +post_title: Auditing Zcash +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/auditing-zcash/ +published: true +post_date: 2016-08-17 00:00:00 +--- +

Our mission is to make the first open financial technology with zero-knowledge privacy, for every person in the world to use. To that end we are commissioning multiple security audits and design evaluations, and will publish the results in full.

+
+

Audit Strategy

+

Zcash combines novel cryptography with blockchain consensus, and our reference implementation is a C++ networking application. Our auditing strategy is to engage experts with different specializations to focus on different aspects of the system, including: cryptography, cryptocurrency (esp. Bitcoin), C++, networking, and traditional application security.

+
+
+

Auditors and Consultants

+

Given our strategy, we've initiated two audits and one design analysis with leading experts in different areas. Each consultant will have their own distinct scope and focus, which will be clearly delineated in their respective reports.

+

NCC Group - From working alongside NCC Group as the Least Authority auditing team, we were impressed with their abilities as skilled security auditors for cryptographic software.

+

Coinspect - When we wanted to find cryptocurrency specialists, Coinspect quickly came to mind. They've published many innovative protocol designs, as well as insightful analyses.

+

Solar Designer - We chose Solar Designer because he is a famous old school hacker, developed return to libc (ret2libc), which started the move from injected code (shellcode) to borrowed code, and developed the first generic heap-based buffer overflow exploitation technique (by +attacking "unlink", an operation that coalesces adjacent chunks when an +allocation is freed).

+

We are proud to work with teams that, like us, value open source, and aim to create accessible and secure systems for everyone.

+
+
+

Scope

+

We are focusing our audits on specific components:

+
  • zkSNARK cryptography (eg: libsnark)
    • +
  • Zcash cryptographic construction (our "zk-SNARK circuit")
    • +
  • Proof of Work algorithm - Equihash
    • +
  • Consensus changes (from Bitcoin)
    • +
  • Specification adherence
    • +
  • C++, race conditions, networking, buffer overflows, dependency management
    • +

We have a limited budget and schedule so we must be selective in our focus. In selecting the audit scope, we're relying on a few assumptions that we believe mitigate security risk:

+
  • Bitcoin Core has survived for ~7 years, controlling billions of dollars worth of funds and is thus well tested in the wild. We will focus primarily on our changes from Bitcoin, although we are doing some auditing for memory safety problems in code that hasn't changed from Bitcoin Core and its dependencies.
    • +
  • The zkSNARK cryptographic technique is peer reviewed, so we won't look for breakthroughs there.
    • +
  • We use only a subset of libsnark, so we'll ignore the parts we don't use [1].
    • +
  • The Zcash circuit is modified from the peer-reviewed Zerocash circuit, so we will focus more on the changes than the whole construction.
    • +
+
+

Schedule

+

The first audits have already begun, and we may schedule future audits to gain further confidence in our security at launch. With proper and thorough auditing the aim is to mitigate all vulnerabilities and lessen risk--this thoroughness is one reason for our launch delay. We described this schedule change in our Zcash Sprout Launch post.

+
+
+

Understanding Risk

+

For an open, permissionless system to be viable, users must be able to justifiably rely on its security and robustness. Ensuring that this a daunting task. The best service we can provide for potential users of Zcash is to ensure they understand the associated risks as well as possible.

+

Security audits and algorithm analyses are not guarantees of safety or correct operation. Each consultant is focused on a specific kind of analysis and cannot vouch for the entire system, nor do they necessarily endorse Zcash as a whole.

+
+
+

Conclusion

+

Zcash is based on peer-reviewed cryptographic research, and built by a security-specialized engineering team on an open source platform based on Bitcoin Core's battle-tested codebase. Publishing multiple security audits is yet another example of our best effort at deploying a system designed to withstand the demands of world-wide financial infrastructure.

+

— Nathan Wilcox, 2016-08-17

+
[1]We have created a libsnark fork which removed portions unused by Zcash.
\ No newline at end of file diff --git a/_posts/2016-08-17-zcash-launch-and-roadmap.md b/_posts/2016-08-17-zcash-launch-and-roadmap.md new file mode 100644 index 0000000..9d01cdf --- /dev/null +++ b/_posts/2016-08-17-zcash-launch-and-roadmap.md @@ -0,0 +1,46 @@ +--- +ID: 1655 +post_title: Zcash Launch and Roadmap +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/zcash-launch-and-roadmap/ +published: true +post_date: 2016-08-17 00:00:00 +--- +
+Zcash Sprout Launch Logo

Zcash Sprout Launch

+
+

The Zcash team is nearing the time to release our code and launch the genesis block of the Zcash blockchain. This is an exciting time to be involved in cryptocurrency and we hope this launch will be a milestone for the field.

+

When the Zcash genesis block is launched, anyone in the world will be able to mine Zcash, and users will be able to send it to anyone in the world with the advantage of full zero-knowledge privacy. The interface will be a command-line tool on Linux, and will not include a graphical user interface, nor run on Windows or Mac OS at launch time. We will continue adding improvements in response to user demand following this initial release.

+

As you will read in our next blog post we are currently undergoing the audit phase of our code; and as such we have delayed our Sprout release for security and safety reasons. Our aim in creating the Zcash blockchain is to launch the first open, permissionless financial system with zero-knowledge privacy and best achievable security. This post will describe, in chronological order, our engineering roadmap and the steps involved in creating this first release of what will (hopefully!) become a safe, viable, trusted network with this experimental and complex technology.

+
+

Audits

+

We have contracted a few of the best audit firms and most trusted hacker minds to help us review our code and correct vulnerabilities. The first audits have already begun; we may schedule future audits to gain further confidence in our security at launch. A blog post following this one will go into further depth about our auditors, when the full audit reports will be published, the scope of the audits, and current risk involved with the Zcash launch. We hope that with proper and thorough auditing we will mitigate all vulnerabilities and lessen risk; this thoroughness is one reason for our launch delay.

+
+
+

Beta

+

Starting on September 7, 2016 we will release the first version of our Beta code. This is still testnet. This series will be feature complete including having our consensus rules frozen, and a new, easier to use RPC interface in place.

+

This is a good time to begin the work of integrating Zcash into your products and services. Check back after the 7th for a new Public Beta Guide, which will replace our current Public Alpha Guide.

+

Our Alpha releases had changing consensus rules and had a difficult-to-use RPC interface (which will be removed). The Beta Series will present stable features, although they may be tweaked slightly before 1.0 launch, based on user feedback or bugfixes.

+

The potential exceptions to feature-completeness in our Beta Series may be changes to our Equihash Proof-of-Work, security issues found in auditing, bugs that aren't disruptive to fix, and changes required for our production launch such as initial block constants, hard-coded node ids, and removal of unused code and documentation.

+
+
+

Beta Phase Goals

+

Previously we described our plan to launch in September of 2016. Although our main software development is still on that schedule, we've decided to prolong our Beta phase for three crucial goals: secure parameter generation, security auditing, and integration work with ecosystem partners.

+

We'll describe each of these Beta Phase goals in the coming months when the time is right. Stay tuned!

+
+
+

The Launch and Sprout Series

+

The launch target date for the Zcash blockchain is set for October 28, 2016. This is when the first Zcash monetary units will come into existence, based on securely generated zkSNARK parameters. The software release for the launch will be the first in our Sprout Series releases. We are calling this software release, and this initial phase of the blockchain ‘Sprout’ to emphasize that it is a young, budding blockchain with great potential to grow.

+

In the coming few months we will be publishing content about: how to mine Zcash, information for integration, partnerships in the works, the parameter generation and setup ceremony, other cool science projects our team is working on, as well as a detailed FAQ that will help developers, miners, engineers, scientists, economists, enthusiasts, and anyone interested in Zcash join the conversation.

+
+
+

Get Involved

+

The updated Zcash core design is in our Zcash Protocol specification. Our roadmap for the Beta and 1.0 launches is embodied in our github milestones.

+

If you're interested in infrequent announcements, such as for our launch, sign up for our email announcement list.

+

Join our forum for user discussions, or our Community Slack if you want realtime developer chat.

+

If you're the adventurous type who wants to play with our current alpha code, check out our Public Alpha Guide.

+

— Nathan Wilcox, 2016-08-15

+
\ No newline at end of file diff --git a/_posts/2016-08-25-new-alpha-release-solidifying-the-consensus-protocol.md b/_posts/2016-08-25-new-alpha-release-solidifying-the-consensus-protocol.md new file mode 100644 index 0000000..971893f --- /dev/null +++ b/_posts/2016-08-25-new-alpha-release-solidifying-the-consensus-protocol.md @@ -0,0 +1,26 @@ +--- +ID: 1583 +post_title: 'New Alpha Release: Solidifying the Consensus Protocol' +author: Daira Hopwood +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-alpha-release-solidifying-the-consensus-protocol/ +published: true +post_date: 2016-08-25 00:00:00 +--- +

Today, we deployed a new alpha release of the Zcash reference implementation, v0.11.2.z9, to the testnet. The new release includes the following changes [1]:

+
  1. Decreased block header size to address a bug interfering with the testnet (#1289).
    2. +
  2. Ensured that Zcash secrets are saved along with Bitcoin secrets in wallets (#1198).
    3. +
  3. Implemented more space-efficient encodings for Equihash solutions (#1175).
    4. +
  4. Implemented more space-efficient encodings for zk-SNARK proofs following an IEEE standard (#1262).
    5. +
  5. Increased the size of the memo field sent with notes, to 512 bytes (#1187).
    6. +
  6. Merged in upstream Bitcoin patches related to Denial-of-Service protection (#1251).
    7. +
  7. Implemented the first stages of adding a new higher-level RPC interface so that clients don't have to deal with details of the underlying cryptographic protocol (#701, #756, #1197).
    8. +
  8. Began addressing issues found by NCC Group as part of our security audits (#1214, #1215).
    9. +

We do not expect to make any other changes to the consensus protocol, except for possible security fixes, until after 1.0.

+

This alpha release will reset our testnet, invalidating all previous coins and breaking backwards compatibility. To get connected to the new testnet, follow the instructions on the Public Alpha Guide.

+

To follow our progress, watch the github project and join the forum. To +get an email announcement when Zcash Sprout is ready, put your email address +in here.

+
[1]For more specific detail, view our z9 release github milestone.
\ No newline at end of file diff --git a/_posts/2016-08-26-taylors-next-adventure.md b/_posts/2016-08-26-taylors-next-adventure.md new file mode 100644 index 0000000..9839979 --- /dev/null +++ b/_posts/2016-08-26-taylors-next-adventure.md @@ -0,0 +1,18 @@ +--- +ID: 1639 +post_title: 'Taylor’s Next Adventure' +author: Taylor Hornby +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/taylors-next-adventure/ +published: true +post_date: 2016-08-26 00:00:00 +--- +

I'm both excited and saddened to announce that I'm leaving the Zcash team to pursue a Master's degree in Quantum Information at the University of Waterloo.

+

I'm excited because physics and computer science are my two favorite interests, and quantum information lies neatly at the intersection of the two. Influences like Carl Sagan and Richard Feynman taught me that learning our place in +the universe, and learning how our world works, is a humbling experience that transforms us into better people. The physical worldview is one I hold dear, so I can't wait to begin learning and popularizing the mathematics of quantum information. If you're interested in following my studies, I'll be blogging at BQP.io.

+

I'm saddened to be leaving an amazing team and an amazing place to work. One of the best things about working for Zcash is that we all have domains of expertise and we all learn from each other. I'm leaving as a more productive programmer, better communicator, more patient mathematician, and a more careful security engineer than I was when I joined Zcash over a year ago. I owe thanks to every member of the Zcash team.

+

The great team makes me confident Zcash will be a success, and I'm super excited for the production blockchain to launch this Fall!

+

Stay tuned for our next blog post about the new hires.

+

— Taylor Hornby, Aug 26, 2016

\ No newline at end of file diff --git a/_posts/2016-08-31-metamorphosis-of-malleable-transactions.md b/_posts/2016-08-31-metamorphosis-of-malleable-transactions.md new file mode 100644 index 0000000..dbe32e2 --- /dev/null +++ b/_posts/2016-08-31-metamorphosis-of-malleable-transactions.md @@ -0,0 +1,20 @@ +--- +ID: 1575 +post_title: > + The Metamorphosis of Malleable + Transactions +author: Simon Liu +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/metamorphosis-of-malleable-transactions/ +published: true +post_date: 2016-08-31 00:00:00 +--- +

Transaction malleability has been a long-standing issue for Bitcoin-derived cryptocurrencies and it's an issue which the Zcash team have been keen to address. Let's explore what the problem is and why it's important to solve in the long run.

+

In a nutshell, transaction malleability is where a valid transaction can be modified in-flight as it propagates across the network. The details can be found here. While the modifier doesn't have access to the private keys of the sender and is unable to steal funds for personal gain, the modified transaction does pose a problem because it can be considered valid by the network. That is, there could be two transactions attempting to spend the same coins but with different transaction IDs.

+

Although such modifications are often thought to be just a nuisance, transaction malleability does have real-world impact. First, wallet software cannot rely on a transaction ID to track a movement of funds. Second, businesses relying on chained transactions, where the change from one transaction is spent immediately in a new transaction, will find that the chain can be broken. Thirdly, off-chain solutions designed to improve transaction throughput, such as Lightning and BOLT, are more practical if transaction malleability is first solved.

+

So how to fix malleability? One solution proposed to us has been to back-port Segregated Witness (segwit) which addresses a range of issues including malleability. However, it was decided a few months ago that it was not possible to do so within the Zcash project’s timeline, especially as segwit was a work-in-progress at the time. Today, development of segwit is mostly complete, but it has yet to be deployed and activated across the Bitcoin network.

+

Our own attempt at a smaller and more focused solution was released a few weeks ago as part of the z8 alpha release and deployed to the test network. Although no issues cropped up in daily use, we had always been conscious that there might be edge cases and security concerns we had not yet detected. In fact, there is a bug where a newly mined block could be modified posing a risk of denial-of-service, which fortunately was found by our auditors as part of the security audit of Zcash. Although the fix itself is fairly simple, the ensuing discussion raised a number of issues for the team to evaluate in order to provide a comprehensive and robust solution.

+

After consideration, given the available resources and the project schedule, the team have decided to roll back the changes made. We feel it would be prudent to launch with known knowns rather than introduce new unknowns. Our exploration of transaction malleability highlights the importance of independent third-party review to the development process, especially around the consensus protocol where even the smallest of changes can ripple out with hard-to-predict Kafkaesque side effects. We are grateful to our auditors Coinspect for helping us to catch some butterflies!

+

Please help us by running the latest z9 alpha release of Zcash and letting us know of any bugs, issues and usability problems you come across. You can reach the team by filing a GitHub issue or visiting the Zcash Community Slack channel. Thank you.

\ No newline at end of file diff --git a/_posts/2016-09-05-september-2016-new-hire-post.md b/_posts/2016-09-05-september-2016-new-hire-post.md new file mode 100644 index 0000000..9d67832 --- /dev/null +++ b/_posts/2016-09-05-september-2016-new-hire-post.md @@ -0,0 +1,58 @@ +--- +ID: 1620 +post_title: Announcing Zcash New Team Members +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/september-2016-new-hire-post/ +published: true +post_date: 2016-09-05 00:00:00 +--- +

Zcash is a science-based company, made up of world-class talent. It is with pride that we announce a few new members to the team.

+
+

Ariel Gabizon

+
+

Cryptographic Engineer

+

Ariel is currently a researcher at the Computer Science Department at Technion - Israel Institute of Technology. For most of his career he has focused exclusively on theoretical computer science, obtaining a PhD from the Weizmann Institute in 2008. A few years ago he discovered the world of bitcoin and blockchain technology, and sees it as a fascinating potential meeting place of beautiful theoretical computer science ideas and real-world applications. Motivated by this, he shifted his focus in 2014 from pure theory to "theory-to-practice" research. As a member of the Succinct Computational Integrity and Privacy Research (SCIPR) Lab, he works on making tools such as Zero-Knowledge and Probabilistically Checkable proofs more efficient and practical.

+
+“After having spent most of my working life in academia, I was drawn to Zcash by a desire to see Zero-Knowledge proofs—the complex cryptographic object on which Zcash is based—brought from the realm of theoretical computer science into the real world. I currently work on the parameter setup protocol whose object is to ensure no party will possess trapdoor information enabling them to perform fraudulent transactions.”
+
+
+
+

Kevin Gallagher

+
+

Devops Engineer

+

Kevin Gallagher is a DevOps engineer and Linux systems administrator assisting Zcash with infrastructure and operational security. He's also an activist who is committed to privacy, security and freedom of information. He previously worked for Freedom of the Press Foundation, a non-profit that supports transparency journalism. He’s been an advocate as the director of Free Barrett Brown, a support network and legal defense fund formed to help a jailed journalist. Additionally, he's recently done work with Transparency Toolkit, an organization that gathers open data on surveillance and human rights abuses and develops free software to analyze it, as well as the Library Freedom Project, a project to make real the promise of intellectual freedom and privacy within libraries.

+
+"To me, zero-knowledge proofs represent one of the most exciting milestones in the history of cryptography. Zcash will enable true privacy and confidentiality in financial transactions, and I'm thrilled to be part of a world-class team intent upon bringing this technology to the masses."
+
+
+
+

Jay Graber

+
+

Web Developer

+

Jay is a web developer with experience organizing political campaigns to protect privacy and the open internet. Her interest in virtual currencies goes back to a Timebank she started in college.

+
+“Zcash is making an important contribution to cryptocurrency. By allowing users to have privacy and selective transparency for transactions, zero-knowledge proofs applied to blockchains will enable many new use cases. I’m excited to be helping bring this open platform into reality.”
+
+
+
+

Simon Liu

+
+

Senior Software Engineer

+

Simon is a member of the founding team behind the MultiChain private blockchain platform. He has over a decade of experience building native applications for Mac OS X and iOS having founded his own software company. He helped kickstart Tokyo HackerSpace, loves disruptive peer-to-peer systems and used to code assembly language demos on the Amiga. Simon is a pragmatic polyglot on both client and server. He holds a BA in Computer Science from Cambridge University and lives in San Francisco, California.

+
+“Zcash is an engaging project to work on, fusing together a 30-year old branch of cryptography with the world's most battle-tested cryptocurrency. The result is an emerging fintech platform designed around provably private transactions, one able to support truly fungible digital assets which will be of benefit to both individuals and businesses alike."
+
+
+
+

Paige Peterson

+
+

Communication/Design

+

Paige has been immersed within the peer-to-peer technology world for 5 years and counting. Through roles with mesh networking startup, Open Garden, p2p storage and communications company, MaidSafe, and as Co-organizer for the San Francisco Bitcoin Meetup, she has gained appreciation for the diverse applications of decentralized networks. She enjoys exploring ways to simplify explanations of these seemingly complex topics and supporting better Internet security and privacy practices for more general audiences. Previously, she studied Interrelated Media at Massachusetts College of Art building interactive art projects with a focus on realistic simulations and abstract conceptualizations of natural systems and processes.

+
+“To me, Zcash hovers in the top of 'Can't Wait To Use & See Used Technologies' and 'Would Love To Work With Team'. As a big fan of tools which aim to keep its users secure and private by default, I'm excited about the implications of a privacy-preserving cryptocurrency on the freedom of individuals and markets around the world. Additionally as a fan of open development strategies and organizational accountability, I'm happy to be part of a team which exudes these properties."
+

Zcash is not currently hiring. That said, we love our contributors and the positive, enthusiastic community of enthusiasts. Please join the Zcash community by contributing to our Slack or Forum conversations.

+
+
\ No newline at end of file diff --git a/_posts/2016-09-07-supporting-coin-center.md b/_posts/2016-09-07-supporting-coin-center.md new file mode 100644 index 0000000..336e980 --- /dev/null +++ b/_posts/2016-09-07-supporting-coin-center.md @@ -0,0 +1,15 @@ +--- +ID: 1638 +post_title: Supporting Coin Center +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/supporting-coin-center/ +published: true +post_date: 2016-09-07 00:00:00 +--- +

Last week Coin Center celebrated two years of support and service to the cryptocurrency community. Today we’re announcing that the Zcash Company is the newest supporter of Coin Center.

+

Personally, I feel indebted to Jerry Brito, Peter Van Valkenburgh, and the other people of Coin Center for the invaluable education and advice they've freely given to us since the inception of the Zcash project. I'm also grateful to them for teaching and informing others: policy-makers, law enforcement officials (with the Blockchain Alliance), and the general cryptocurrency community. I've observed multiple times when misinformation and FUD were sweeping like wildfire through the cryptocurrency community, and Coin Center was there to put it out with a big splash of facts and logic.

+

This donation that we're making to Coin Center shouldn't be construed as an endorsement of any of their particular policy positions. I usually don't have an opinion on such policy issues, but I trust the people of Coin Center to be well-informed, accurate, fair, and to work for the best interests of our society. Our community needs an independent voice which is both trusted and accurate, and Coin Center is providing that.

+

As another note, when I offered to donate to Coin Center in U.S. Dollars, they said no! They said they wanted Zcash instead. I love them for that. ❤

\ No newline at end of file diff --git a/_posts/2016-09-09-announcing-beta-series.md b/_posts/2016-09-09-announcing-beta-series.md new file mode 100644 index 0000000..1021456 --- /dev/null +++ b/_posts/2016-09-09-announcing-beta-series.md @@ -0,0 +1,43 @@ +--- +ID: 1542 +post_title: 'New Beta Release: Announcing the Zcash Beta Series' +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/announcing-beta-series/ +published: true +post_date: 2016-09-09 00:00:00 +--- +

Today, we deployed the first beta release of the Zcash reference implementation, v1.0.0-beta1, to the testnet. This release, Beta 1, is the first release of the Zcash Beta Series and represents a new phase of development.

+

Note: the official Zcash currency is non-existent until our October 28th launch. Only testnet coins exist and they carry no value.

+
+

Zcash Beta Series

+

The Beta series is the final phase of development prior to the launch of Zcash 1.0.0, which begins the Sprout Series. The Beta Series is notably different from our earlier alpha releases in several ways:

+
  • We're using a new versioning scheme, the first beta release is v1.0.0-beta1, the next v1.0.0-beta2 and so on.
    • +
  • Starting with v1.0.0-beta1 the new high level RPC interface is in place. The early RPC interface is deprecated and will be removed.
    • +
  • Only high priority changes will be merged, including: important security mitigations, fixing bugs which inhibit basic operation, improving build, packaging, and documentation, and changes for production infrastructure.
    • +

As we approach our target 1.0 Sprout launch date of October 28th, 2016, we'll release several Beta versions. During this time we'll be working with partners and community members to integrate Zcash into more tools, products, and services.

+

The Zcash Beta Series is a good time for integration work for third party services and products interested in deploying Zcash support.

+

As the Beta Series matures, we'll enter a pre-release phase during which we'll publish several essential items:

+
  • security audit reports
    • +
  • proof-of-work analysis
    • +
  • source code and security proof of our secure parameter setup
    • +
  • securely generated parameters
    • +

Stay tuned for those publications.

+
+
+

About Beta 1 release

+

Today we've released Zcash Beta 1, aka v1.0.0-beta1. Building on the previous alpha release which finalized consensus changes (unless we discover critical flaws) this release adds the new high level RPC interface. The v1.0.0-beta1 release includes these major changes:

+
  • Wallet support for the high-level interface, including detecting received notes, selecting notes for transfers, listing transactions, getting balances, and calculating block subsidies. See RPC interface. [#1355, #1323, #1315, #1233]
    • +
  • We rolled back a "stable txid" feature intended to fix malleability issues, see our post about the rollback. [#1316]
    • +
  • We tweaked the difficulty adjustment algorithm. [#1338]
    • +
  • Several other security and other bug fixes and cleanups, full details on the Beta 1 github milestone.
    • +

Caution: In the interest of getting user feedback we're releasing v1.0.0-beta1 today even though it lacks the same level of automated test coverage as our core consensus code. Future releases in the Beta series will focus on improving test coverage as well as discovering and fixing bugs.

+

Additionally, every release moving forward will contain a document with security warnings. For this release, see security-warnings.md. Important: Please also regularly check out website for security issues discovered after a release is deployed to users.

+
+
+

Stay Involved

+

Try out the Beta series releases by following the Beta Guide.

+

To follow our progress, watch the github project and join the forum. To get an email announcement when Zcash Sprout Series is ready, put your email address in here. We tweet @ZcashCo.

+
\ No newline at end of file diff --git a/_posts/2016-09-09-expanding-zcash-content.md b/_posts/2016-09-09-expanding-zcash-content.md new file mode 100644 index 0000000..fb418c7 --- /dev/null +++ b/_posts/2016-09-09-expanding-zcash-content.md @@ -0,0 +1,16 @@ +--- +ID: 1560 +post_title: 'Expanding Zcash Content: Russian, Spanish, Brazilian Portuguese' +author: Maureen Walsh +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/expanding-zcash-content/ +published: true +post_date: 2016-09-09 00:00:00 +--- +

Today we have published the Zcash website content in three new languages: Russian, Spanish and Brazilian Portuguese. It is the main site content that we have completed, and we will be publishing blog posts in all three new languages as we are able.

+

Please use the “language” button in the top right corner to toggle between languages.

+

Zcash is a global company, and we invite all Zcash participants around the world to join the conversation. As we expand and build we hope to add more languages and translations and support the growth of many communities and many forums.

+

Thank you to our trusted translators and those who helped engineer this translation project, namely Zcash engineer Jay Graber, translators Evandro Reis Matias, Evgeny Dmitriev, Sp Zhang, Lupa, and transation consultants: Jason Fang, Ishbir Singh, Vlad of vk.com/zcash, Aliaksei Liutsich, Yuriy Nikulichev, JZA, and Herman Junge.

+

Please email press@z.cash if you have questions or would like to participate in future translations of Zcash content.

\ No newline at end of file diff --git a/_posts/2016-09-19-project-alchemy.md b/_posts/2016-09-19-project-alchemy.md new file mode 100644 index 0000000..eb5d595 --- /dev/null +++ b/_posts/2016-09-19-project-alchemy.md @@ -0,0 +1,20 @@ +--- +ID: 1611 +post_title: Introducing Project Alchemy +author: Jay Graber +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/project-alchemy/ +published: true +post_date: 2016-09-19 00:00:00 +--- +
+Bridging Zcash and Ethereum

Bridging Zcash and Ethereum

+
+

The technical innovation that Zcash is contributing to cryptocurrency is the introduction of reliably private transactions on the blockchain through the application of zero-knowledge proofs. However, much of the value in this ecosystem comes from projects building on each other's strengths. The open, programmable platform that Ethereum introduced is inspiring developers to build new systems that were not possible before. Our team has also been inspired to start brainstorming potential applications.

+

One of the projects we're looking forward to working on is codenamed Project Alchemy. This will be a Zcash-Ethereum integration that will enable a decentralized exchange between the two blockchains. The core component we're focused on first is a cross-chain Order that will allow decentralized order execution.

+

Here’s the basic outline of how it would work: Sellers will be able to publish an Ethereum contract called an Order, and anyone can fulfill it by sending out an appropriately formatted Zcash transaction. The funds the initiator wants to exchange will be essentially held in escrow by the smart contract while they wait for a buyer to match them. A buyer will be able to create a Zcash transaction that may contain the destination address, and the validity of this transaction will be verified by the Ethereum contract before the funds are released to complete the trade.

+

An implementation of a bridge for Bitcoin-to-Ether exchange already exists in BTC Relay, so we are planning to model an exchange for Zcash along these lines [1]. There are several steps necessary to further develop this idea. One component is an implementation of the BLAKE2b hash function in Solidity, which is necessary to check Zcash’s proof of work — this has already been written. The hash function will be used to implement an Equihash verifier. Once we can verify Zcash’s proof of work, we can create an example contract template for the Order logic. From there, we would need UI components to place, discover, and fulfill orders on the two blockchains.

+

The small but dedicated Zcash team is currently devoting our time and energy toward launching a secure, usable open blockchain. We don’t have the capacity to build out all of the things we'd like to see exist right away, but we’re excited to start developing projects like this after launch.

+

Please join us in discussing projects like this on our Forum or Slack channels (including #alchemy for this project).

+
[1]The same building blocks with minor modifications will also allow Bitcoin-Ethereum decentralized exchange, thus enabling currency to flow between the three systems through a decentralized market-price mechanism.
\ No newline at end of file diff --git a/_posts/2016-09-21-announcing-miner-contest.md b/_posts/2016-09-21-announcing-miner-contest.md new file mode 100644 index 0000000..15f2999 --- /dev/null +++ b/_posts/2016-09-21-announcing-miner-contest.md @@ -0,0 +1,23 @@ +--- +ID: 1543 +post_title: > + Announcing the Zcash Open Source Miner + Contest +author: Liz Steininger +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/announcing-miner-contest/ +published: true +post_date: 2016-09-21 00:00:00 +--- +
+Cartoon of pickaxe mining ZEC

Mining ZEC ;)

+
+

All coins are created equal. All coins should be equally accessible.

+

On October 28, 2016, the launch of Zcash will make ZEC coins available for mining. Since Zcash is an open source, decentralized cryptocurrency, we believe that mining should be available to everyone, regardless of their access to specialized hardware; anyone should be able to use a computer to “mine” by using open source software, and add more transactions to the Zcash ledger to get Zcash coins in return for their effort. By distributing the ability to perform mining, the Zcash network can be a more accessible and a truly community-supported cryptocurrency.

+

To achieve this, we need open source miners for anyone to use. Least Authority, as a supporter of the Zcash Company, is creating momentum for developers to begin building open source mining software by launching the Zcash Open Source Miner Contest.

+

The Least Authority team will be operating the contest and more information will be posted next week on the official website for the contest: http://zcashminers.org The Zcash Company will sponsor a prize fund of $30,000 for the winner(s) of the contest; the contest will reward both CPU and GPU implementations.

+

Incentivizing the creation of open source miners will enable a wider community to mine for Zcash coins and take ownership of the network as a public good. While we expect a full range in size of Zcash miners to exist, the more individuals who run a miner (whether GPU or CPU) the stronger the network.

+

This is just an initial description of Least Authority’s intent to present this contest—more details, criteria and submission deadlines will be announced next week with the full launch of the Zcash Open Source Miner Contest.

+

Join in the mining conversations on the Zcash Forum or the Zcash Slack #mining channel.

\ No newline at end of file diff --git a/_posts/2016-09-23-continued-funding-and-transparency.md b/_posts/2016-09-23-continued-funding-and-transparency.md new file mode 100644 index 0000000..089d449 --- /dev/null +++ b/_posts/2016-09-23-continued-funding-and-transparency.md @@ -0,0 +1,91 @@ +--- +ID: 1553 +post_title: Continued Funding and Transparency +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/continued-funding-and-transparency/ +published: true +post_date: 2016-09-23 00:00:00 +--- +Our mission is to create open financial technology with zero-knowledge privacy, for everyone in the world to use. The first application of that technology is Zcash, a cryptocurrency and blockchain with privacy built in. +
+

Continued funding

+Today we're announcing that this past summer we took in a new round of funding. Seventeen investors put in a total of $2 million dollars into the Zcash Electric Coin Company in exchange for equity in the company. The investors in this round are: Aaron Grieshaber, Branson Bollinger, Maple Ventures (Amir Chetrit and Steven Nerayoff), Brian Cartmell, Vlad Zamfir, Roger Ver, Digital Currency Group, Barry Silbert, Charles Songhurst, Fenbushi, Shapeshift, Erik Voorhees, David Lee Kuo Chuen, Fred Ehrsam, Sebastian Serrano, and Li Xiaolai. + +This is a huge vote of confidence in the Zcash team and in the value of the Zcash project, and it gives us plenty of cash to assist the upcoming launch of Zcash Sprout. + +We are using the money to hire several awesome new people for our team, to further invest in security assurance such as by hiring independent security auditors, to fund the Zcash Open Source Miner Contest, and to lay plans for several more projects. + +Stay tuned to this blog to hear more about all of these exciting developments! + +
+
+

Continued transparency

+The Zcash Company has always been exceptionally transparent about our backers and our company finances. + +But, with this blog post we are radically increasing our transparency, to a degree beyond what is considered normal or even acceptable in Silicon Valley. + +We're doing this in order give the public a clear picture of the incentives we're operating under, and the “initial conditions” of the Zcash economy that is about to be born. +
+

Pricing

+In return for $2 million, the new round of investors collectively took ownership of 6.25% of the company.That implies that the new investors were effectively valuing the company at $32 million (at a time when the uncertainties were greater).The overall amount raised including the previous round is $3 million, and the investors collectively now own 16.4% of the company. + +Since the Founders' Reward is 2.1 million coins (10% of the total long-run monetary base of 21 million coins), and since the Founders' Reward will be split among the owners of the Zcash Company in proportion to their ownership, this means the new round of investors paid $2M for an eventual distribution of 131,250 Zcash coins. Therefore, they effectively paid $15.24 per coin. + +Be aware that the investors received not only a right to an eventual distribution of Zcash coins, but also a permanent share of the Zcash Electric Coin Company, which may prove to have independent value. So you can't simply say that the investors valued coins at $15.24 a piece. Instead, they might have chosen to invest partly because of the accompanying equity in the company. From my personal experience negotiating with them, there were a variety of attitudes, with the majority of them more interested in the coin than in the company, but a substantial minority the other way around. + +The investors will receive their share of the Founders' Reward over the first year of mining. The rest of the founders will receive their share of the Founders' Reward over the first four years of mining. (This doesn't change the size of the Founders' Reward per block — it is still 2.5 ⓩ for the founders and 10 ⓩ for the Miner for each block in the first four years. It just means more of the Founders' Reward goes to the investors than to the other founders during the first year. See Funding, Incentives, and Governance for why the Founders' Reward is on this four-year schedule.) +
+ +
+

The distribution of Zcash

+

90% of the Zcash monetary base goes to the miners, to reward them for doing a public service by maintaining a secure global blockchain, that anyone can use, and that can hold validated but private transactions.

+
Zcash Distribution
+

I urge everyone to run a Zcash miner! It is the easiest thing you can do to support the open, permissionless network and the new economy, and (if you're lucky) you might also get a Miners Reward for doing it. You can get started today (on the not-real-money-yet testnet) by following the Zcash Mining Guide.

+
+ +
+

The distribution of the Founders' Reward

+

10% of the Zcash monetary base goes to the “Founders' Reward”.

+
Zcash Distribution, The Founders' Reward
+ +An interesting fact about this distribution is that there are no large pie slices. I arranged to distribute the Founders' Reward widely, so that there would be a lot of early stakeholders with a stake in the success of the coin, and nobody would have a much larger stake than the others. This includes myself; my own personal share of the Founders' Reward is no greater than that of some of the other founders. + +The investors (this new round plus all previous investments) collectively will receive 1.65% of Zcash's ultimate monetary base. + +Among the investors, the equity is evenly distributed. Even the investor with the largest share will eventually (over the course of the first year) receive only 0.2% of the Zcash monetary base. + +The founders, employees, and advisors (myself included) will collectively get 5.72% of the Zcash monetary base through the Founders' Reward. + +Among this group, the equity is also more evenly distributed than a typical startup. Even the founders with the largest share will be receiving only about 0.5% of the Zcash monetary base (over four years). + +The two biggest single beneficiaries of the Founders' Reward are the Zcash Company strategic reserve and the non-profit Zcash Foundation. + +The Zcash Company's “strategic reserve” will receive 1.19% of the Zcash monetary base (over four years), and is intended to fund new projects to increase the value of the Zcash Company. + +The non-profit Zcash Foundation will receive 1.44% of the monetary base (over four years). The Foundation will maintain and improve the Zcash protocol in the interests of all users, present and future. + +The Zcash Foundation's share is provided by donations from myself and many of the other founders and investors, and I thank them for helping to sustain an open and safe financial network that anyone in the world will be able to use. That's why we do this. + +
+
+
+

Recap

+We've taken in another $2M worth of investment to power the next stage of the project. The investors in that round valued the Founders' Reward (along with the accompanying ownership of Zcash Co) at about $15 per Zcash coin. + +We're practicing radical transparency, because this project's success depends on the goodwill of the public, and the public has a stake in knowing the financial structure of the ecosystem. + +Miners will receive 90% of the Zcash monetary base, and I encourage everyone to run a miner, as a contribution to the public good, and because if you get lucky you might win a Miners Reward. + +The founders, employees, and advisors are collectively receiving 5.7% of the monetary base over the four years. The investors are receiving 1.6% of the Zcash monetary base, over the first year. The Zcash Co is receiving 1.2% of the monetary base (over four years) to fund new commercial projects. The Zcash Foundation is receiving 1.4% of the monetary base (over four years) to support the technology, on behalf of all users. + + + + + + + +
[1]These numbers are subject to change if, for example, more investors or ZECC employees decide to donate to the Zcash Foundation, or if the company grants more equity to employees, or employees leave the company.
+
\ No newline at end of file diff --git a/_posts/2016-09-25-generating-zcash-parameters.md b/_posts/2016-09-25-generating-zcash-parameters.md new file mode 100644 index 0000000..a9af12c --- /dev/null +++ b/_posts/2016-09-25-generating-zcash-parameters.md @@ -0,0 +1,98 @@ +--- +ID: 1565 +post_title: > + Zcash Parameters And How They Will Be + Generated +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/generating-zcash-parameters/ +published: true +post_date: 2016-09-25 00:00:00 +--- +At its core, Zcash's privacy technology relies on a novel cryptographic tool called a zkSNARK - a small zero-knowledge proof that is cheap to verify. Zcash will be the first to employ this powerful tool on a large scale. For these zkSNARKs to work, a setup phase is required where the "system parameters" are generated. This setup phase is similar to the setup phase of a public-key cryptosystem, but with a catch: As in the public-key cryptosystem, a pair (:math:`\mathsf{privkey},` :math:`\mathsf{pubkey)}` is generated, but then :math:`\mathsf{privkey}` is destroyed. Indeed, it will be essential for the integrity of the system that after the setup phase nobody possesses :math:`\mathsf{privkey}.` + +:math:`\mathsf{pubkey}` corresponds to the required system parameters. :math:`\mathsf{privkey}` corresponds to what has been called the "toxic waste" here, and possessing it enables counterfeiting new coins (but does not enable violating the privacy of other users' transactions). + +To reduce risk, Zcash has designed a multi-player protocol where :math:`\mathsf{pubkey}` will be generated. The protocol has the property that :math:`\mathsf{privkey}` now corresponds to the concatenation of all participants' secret randomness. Thus, :math:`\mathsf{privkey}` will be destroyed unless all of the participants are dishonest or compromised. + +The purpose of this post is to give a simplified explanation of what :math:`\mathsf{pubkey}` looks like, and how the protocol for generating it works. +

What :math:`\mathsf{pubkey}` looks like

+Suppose :math:`g` is a generator of a group :math:`G` where the discrete log is hard. We assume :math:`G` has order :math:`r` for some prime :math:`r,` and we write group operations additively. So for :math:`s\in \mathbb{F}`, where :math:`\mathbb{F}` is the field of size :math:`r`, we can write :math:`s\cdot g` to denote scalar multiplication of :math:`g` by :math:`s`; i.e. :math:`s\cdot g` is obtained by adding :math:`s` copies of :math:`g`. A simplified version of (:math:`\mathsf{privkey},` :math:`\mathsf{pubkey)}` is that :math:`\mathsf{privkey}` is simply a uniformly random element :math:`s\in \mathbb{F}^*` and :math:`\mathsf{pubkey}` is the sequence of group elements +
:math:`\mathsf{pubkey}=` :math:`(g,s\cdot g, s^2\cdot g,\ldots, s^d\cdot g)`
+Above, :math:`\mathbb{F}^*` denotes the set of all non-zero elements of :math:`\mathbb{F}.` +

How :math:`\mathsf{pubkey}` is generated

+We'll say a few words later about why :math:`\mathsf{pubkey}` looks like this and how it is used, but let's concentrate for now on designing the protocol for generating :math:`\mathsf{pubkey}.` + +Let's fix :math:`d=2` for simplicity; and also omit the first :math:`g` element from :math:`\mathsf{pubkey}`, as it's straightforward to generate that. Suppose we have two parties, Alice and Bob, that wish to generate a valid public key :math:`\mathsf{pubkey}=` :math:`(s\cdot g, s^2\cdot g)` for the system. They wish to do so in a way that will ensure neither of them will know :math:`s.` Let's make it simpler first: suppose they just want to generate :math:`s\cdot g` (again, in a way that neither will know :math:`s)`. They use the following protocol: +
    +
  1. Alice chooses a random :math:`a\in \mathbb{F}^*`, and sends :math:`M_1:= a\cdot g` to Bob.
    2. +
  2. Bob then chooses a random :math:`b\in \mathbb{F}^*` and multiplies :math:`M_1` by :math:`b`. He sends back the message :math:`M:= b\cdot M_1` as their joint output.
    3. + +
+At the end of the protocol, we have :math:`M=b\cdot a \cdot g = (a b)\cdot g`. Let's denote :math:`s:= a b`. + +Note that + + + +So as long as one of them follows the protocol correctly, :math:`M=s\cdot g` will be of the right form. + +Now let's try to use a similar idea for generating :math:`(s\cdot g, s^2\cdot g)`: + + + +If Alice and Bob follow the protocol, we get :math:`M= (b a \cdot g, b^2 a^2 \cdot g) = ( a b\cdot g, (a b)^2\cdot g).` So this vector is of the right form for :math:`s:= a b.` + +Here's one problem: What if Bob cheats and multiplies :math:`B` by some :math:`c\neq b^2`? So we get :math:`(a b\cdot g, a^2 c \cdot g),` which is not of the form :math:`(s\cdot g, s^2\cdot g)` for any :math:`s.` We need to somehow check that our output vector is of the form :math:`(s\cdot g, s^2\cdot g)` for some :math:`s.` In many groups, this is conjectured not to be efficiently doable - this is what's called the square decisional Diffie-Hellman assumption. However, in our setting we are working with a group that has a bilinear pairing. This is a map :math:`e:G\times G\to G_T,` into a group :math:`G_T` also of order :math:`r` with generator :math:`\mathbf{g},` written multiplicatively, such that + +:math:`e(a\cdot g, b\cdot g) = \mathbf{g}^{a b}` + +for any :math:`a,b\in\mathbb{F}.` This gives us the following way to check the output :math:`M` has the right form. We simply check if + +:math:`e(g,B) = e(A,A).` + +Let's see that if nobody cheated, this check will pass. When nobody cheats we have :math:`A=s\cdot g,` and :math:`B=s^2\cdot g.` So + +:math:`e(g,B) = e(g,s^2\cdot g) =\mathbf{g}^{s^2}`, + +and also + +:math:`e(A,A) = e(s\cdot g,s\cdot g) = \mathbf{g}^{s^2}.` + +One can do a similar computation to see that when :math:`M` is not of this form, these two values will differ and the test will fail. +

How :math:`\mathsf{pubkey}` is used

+Recall that a polynomial :math:`P` of degree :math:`d` over :math:`\mathbb{F}` is an expression of the form + +:math:`P(X) = a_0 + a_1\cdot X + a_2\cdot X^2 + \ldots + a_d\cdot X^d` + +We can evaluate a polynomial at a point :math:`s\in \mathbb{F}` by substituting :math:`s` for :math:`X,` and computing the resultant sum. A useful fact is that if :math:`P` and :math:`Q` are different polynomials of degree at most :math:`d,` they can agree on at most :math:`d` points. In Zcash the sender needs to construct two degree :math:`d` polynomials :math:`P` and :math:`Q` in a certain way, and a lot of mathematical magic ensures that they can make them the same polynomial, i.e., get :math:`P=Q,` only if the transaction is valid. + +:math:`\mathsf{pubkey}` can now be used to test if :math:`P` and :math:`Q` are equal at a point :math:`s` not known by the sender. Say + +:math:`P(X) = a_0 + a_1\cdot X + a_2\cdot X^2 + \ldots + a_d\cdot X^d` + +and + +:math:`Q(X) = b_0 + b_1\cdot X + b_2\cdot X^2 + \ldots + b_d\cdot X^d` + +Using :math:`\mathsf{pubkey}=` :math:`(g,s\cdot g, s^2\cdot g,\ldots, s^d\cdot g),` the verifier can compute + +:math:`P(s)\cdot g = a_0\cdot g + a_1 s \cdot g + a_2s^2 \cdot g + \ldots + a_d s^d\cdot g` + +and compute :math:`Q(s)\cdot g` similarly. The verifier can then check if they are equal. + +Since the sender of a non-valid transaction has to construct distinct :math:`P` and :math:`Q` without knowing :math:`s,` the chance that :math:`P(s)=Q(s)` is very small. + +

Disclaimer

+Please note, this post is a significantly simplified presentation of the underlying protocol. A detailed description can be found in the whitepaper. + +

References

+Our zkSNARKS use SCIPR Lab's implementation of the Pinnochio protocol, which in turn is based on the work of Gennaro, Gentry, Parno and Raykova. Our protocol for parameter generation builds on a previous work of Ben-Sasson, Chiesa, Green, Tromer and Virza. \ No newline at end of file diff --git a/_posts/2016-09-27-open-source-miner-challenge.md b/_posts/2016-09-27-open-source-miner-challenge.md new file mode 100644 index 0000000..0cdc051 --- /dev/null +++ b/_posts/2016-09-27-open-source-miner-challenge.md @@ -0,0 +1,23 @@ +--- +ID: 1606 +post_title: 'Accepting Submissions: Zcash Open Source Miner Challenge' +author: Liz Steininger +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/open-source-miner-challenge/ +published: true +post_date: 2016-09-27 00:00:00 +--- +

All coins are created equal. All coins should be equally accessible.

+

Last week, we announced our dedication to incentivize more open source miners to be available to the Zcash community, through the Zcash Open Source Miner Challenge. We believe that mining for ZEC is an important way to contribute to our growing and enthusiastic community.

+

The Challenge is now live and we are accepting submissions until 27 October at 23:59 UTC. All details are now available on the Zcash Open Source Miner Challenge website; there you can also find the form to submit your entry. Please read all criteria, rules and guidelines before submitting. If you’d like your code to be considered for the $30,000 of prizes that will be awarded, you must also post your code to a public GitHub repository.

+

The technical guidelines for this challenge are:

+

To learn more about the judging criteria and the timeline, please visit the Challenge website.

+

You can also join in the mining conversations on the Zcash Forum or email challenge@zcashminers.org with any specific questions.

\ No newline at end of file diff --git a/_posts/2016-10-04-new-beta-release-audit-mitigations-and-bug-fixes.md b/_posts/2016-10-04-new-beta-release-audit-mitigations-and-bug-fixes.md new file mode 100644 index 0000000..084a6d5 --- /dev/null +++ b/_posts/2016-10-04-new-beta-release-audit-mitigations-and-bug-fixes.md @@ -0,0 +1,26 @@ +--- +ID: 1585 +post_title: 'New Beta Release: Audit Mitigations and Bug Fixes' +author: Jack Grigg +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-beta-release-audit-mitigations-and-bug-fixes/ +published: true +post_date: 2016-10-04 00:00:00 +--- +

Today, we deployed the second beta release of the Zcash reference implementation, 1.0.0-beta2, to the testnet. This is the second release of the Zcash Beta Series. The new release includes the following changes [1]:

+
  1. We have changed the address prefixes. (#1477)
    2. +
  2. Encrypting your wallet with a passphrase now also encrypts the spending key for zaddrs. (#1372)
    3. +
  3. Founders’ Reward addresses will now rotate monthly. (#1398)
    4. +
  4. We have re-enabled disabled compiler warnings and updated all dependencies, including Boost and OpenSSL. (#1429)
    5. +
  5. We have merged in upstream patches to mitigate the risk of DoS attacks. (#1411, #1407)
    6. +
  6. We have deployed a dnsseed to improve launching and connecting to the network. (#1443)
    7. +
  7. The RPC call getbalance now returns a correct balance for UTXOs. (#1427)
    8. +
  8. High-priority alerts now put the RPC into safe mode. (#1374)
    9. +
  9. We have updated the public parameters. (#1476)
    10. +

This release also makes reliability improvements in the wallet, however some work remains to be done around importing keys and rescanning after restarts. If you are encountering problems with the wallet, stop your node and restart it with the -reindex flag (Example: ./src/zcashd -reindex).

+

This release will reset our testnet, invalidating all previous coins and breaking backwards compatibility. To get connected to the new testnet, follow the instructions on the Beta Guide.

+

Additionally, you can now reach our main test network node through a Tor hidden service at zctestseie6wxgio.onion.

+

To follow our progress, watch the GitHub project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.

+
[1]For more specific detail, view our 1.0.0-beta2 release github milestone.
\ No newline at end of file diff --git a/_posts/2016-10-07-consensual-currency.md b/_posts/2016-10-07-consensual-currency.md new file mode 100644 index 0000000..52c17dd --- /dev/null +++ b/_posts/2016-10-07-consensual-currency.md @@ -0,0 +1,44 @@ +--- +ID: 1552 +post_title: Consensual Currency +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/consensual-currency/ +published: true +post_date: 2016-10-07 00:00:00 +--- +The Zcash cryptocurrency launch is approaching and we're making progress on our mission to create the first open financial system with zero-knowledge privacy. + +When we say open, we mean anyone in the world can use it. + +So… should they? + +In order to decide if they should they need to know not only how the current version works, but also the direction the community, technology, and ecosystem are headed. In this post we'd like to share our thoughts about how communities grow and evolve. +
+

How do cryptocurrency communities evolve?

+Like all cryptocurrencies so far, Zcash is a consensual currency: Nobody is ever going to force you to use a specific version or a specific fork of Zcash. It's all opt-in. + +It is also a community currency. Using a currency all by yourself is no fun. You need a bunch of other people to use it too. So any major upgrade to Zcash — or new fork, variant, or competitor — will be important to you ​only​ if a community of others is willing to adopt it along with you. + +Finally, it's a developer-supported currency. We, as developers, are going to be maintaining and upgrading Zcash for the forseeable future. If you use one of the versions or forks of Zcash that we support, you can benefit from our work. This is why the Founders' Reward ¹, ² is important in the long run. It provides both the incentives and the resources for developer support. + +
+
+

What happens when communities grow?

+As Zcash becomes successful, it will grow to support many different stakeholders, and an increasing variety of needs. Some of those needs will call for different design trade-offs than others. + +Since Zcash is a consensual currency, different sub-communities will always have the freedom to choose different variants or forks which offer different design trade-offs. + +When the time comes that you have multiple versions or forks of Zcash that you can use, we — the Zcash Founders — will not be able to dictate which ones you use. But, assuming we are still leading developers, what versions or forks of it we support will be an important factor to you. So in a future blog post, we will sketch out some of the versions and forks of Zcash we anticipate supporting in the future. + +(Teaser: we think the Zcash community can learn from the experiences of the pioneers — Bitcoin and Ethereum — and find a balance between Bitcoin's stability and Ethereum's agility.) + +
+
+

Summary

+Zcash is launching soon as an open financial system with zero-knowledge privacy. It is a consensual, community-based, and developer-supported cryptocurrency. + +If it thrives and grows big enough, it will eventually split into multiple sub-communities that share and use multiple technologies. This will probably include forks of the original Zcash blockchain. Don't be scared — that's a good thing. + +
\ No newline at end of file diff --git a/_posts/2016-10-14-slow-start-and-mining-ecosystem.md b/_posts/2016-10-14-slow-start-and-mining-ecosystem.md new file mode 100644 index 0000000..f9cee04 --- /dev/null +++ b/_posts/2016-10-14-slow-start-and-mining-ecosystem.md @@ -0,0 +1,35 @@ +--- +ID: 1623 +post_title: 'User Expectations at Sprout Pt. 1: Slow-Start Mining & Mining Ecosystem' +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/slow-start-and-mining-ecosystem/ +published: true +post_date: 2016-10-14 00:00:00 +--- +

Zcash Sprout represents the beginning of a global ecosystem focused on user privacy and secure consensus requiring the growing support of individuals all over the world to facilitate it. Equally important are the conservation tactics at the beginning stages of Sprout so any key early issues can be solved without affecting a large portion of users. This approach also allows for a period of early user and ecosystem experimentation. Sprout is only a milestone in the long-term mission for Zcash and as such, users should set their expectations appropriately especially during what we’re calling, the slow-start mining period.

+
+

Slow-start and ZEC scarcity

+

In order to give the network and its development some breathing room, Zcash is implementing a slow-start mechanism for the first 20,000 blocks (or about 34 days). In the event of a major bug or security vulnerability in the protocol, the slow-start will minimize the impact as initially, the block reward will be a fraction of the eventual 12.5 ZEC that will be created for each block for the first 850,000 blocks - at which point, the block reward halves. Over the slow-start period, the block reward will gradually and linearly increase until it reaches the full 12.5 ZEC at the 20,000th block.

+
+ZEC distribution rate for first 30,000 blocks

ZEC distribution rate for first 30,000 blocks

+
+

This linear rate increase effectively creates half as many ZEC in the 20,000 block period resulting in 125,000 ZEC mined instead of the expected 250,000 ZEC. For this reason, the first halving interval is 10,000 blocks longer so that the overall monetary curve is unchanged.

+
+Total ZEC distributed for first 30,000 blocks

Total ZEC distributed for first 30,000 blocks

+
+

Further, the impact of the slow-start distribution period on total ZEC becomes insignificant as time goes forward making it a consideration only initially and temporarily.

+
+Total ZEC distributed for first 190,000 blocks

Total ZEC distributed for first 190,000 blocks

+
+

While this is a supportive effort to aid initial scaling of the network in a technical sense, it is also necessary to set reliable expectations on how it could affect the value of the currency. The increased scarcity at the start of Sprout may be a cause for price volatility. The best thing the community can do here is be aware of this potential variance during and after the slow-start. Perhaps this is a good point to clarify that none of this should serve as investment advice but instead an effort to level the playing field and protect the earliest of adopters. And of course, at any time during and after slow-start, it’s important to never invest what you can’t afford to lose. When using any experimental technology, the best way to have a positive experience is to stay aware, be cautious and don't forget to have fun!

+
+
+

“Small” miners and early adoption

+

Slow-start mining also offers users and third-party developers time to experiment themselves, limiting any gold-rush effect that may occur otherwise. For users interested in mining, they can expect the launch of Sprout to be a good time to test their mining capabilities especially with regards to the differences from other proof-of-work mining algorithms. One of the great things about starting a new blockchain is being able to experiment with alternate decentralization metrics through other consensus models. One of the reasons we chose Equihash is for the ASIC-resistant properties which in theory make the network more accessible to “small” miners who are extremely valuable for providing a market balance to other miners with significantly more capabilities.

+

While the lasting effect of ASIC resistance is, at least at this stage, unpredictable, the more people participating in mining, the stronger the network will be against any future growing disparity and centralization in mining power. We fully anticipate a variety of mining abilities but hope for an improvement in previously implemented protocols such that the “small” miners can keep the “big” miners in check by experimenting early on in Sprout and contributing in the name of the network and community rather than the profit-driven motives of the larger miners. Previous proof-of-work based blockchains have exhibited a mining ecosystem where it's easier to contribute processing power in the early days and this could very well hold true for Zcash as well.

+

If this technology is important for you and you want to see it thrive as much as we do, consider experimenting with us during Sprout and share some computing power to the global consensus driving the Zcash blockchain.

+

At Sprout, users should keep an eye on potential volatility in the market and stay aware when investing in ZEC. Simultaneously, users should take advantage of the experimental period of slow-start mining by testing their mining capabilities in an effort to help reduce disparity of miners and prevent centralization. The next post in this series will focus on the software usability and hardware expectations users should have for Zcash core in which I’ll share my own experiences installing and using the Beta software.

+
\ No newline at end of file diff --git a/_posts/2016-10-17-deterministic-builds.md b/_posts/2016-10-17-deterministic-builds.md new file mode 100644 index 0000000..a464510 --- /dev/null +++ b/_posts/2016-10-17-deterministic-builds.md @@ -0,0 +1,45 @@ +--- +ID: 1557 +post_title: Deterministic Builds in Zcash +author: Kevin Gallagher +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/deterministic-builds/ +published: true +post_date: 2016-10-17 00:00:00 +--- +

As Mike Perry of Tor Project wrote back in 2013, while the Snowden revelations were ongoing, one of the most dreaded of scenarios is the so-called “watering hole" attack, where an adversary or malware “attacks the software development and build processes themselves to distribute copies of itself to tens or even hundreds of millions of machines in a single, officially signed, instantaneous update.”

+

Though the world hasn’t witnessed many such attacks yet, the Zcash blockchain and its user base could be considered a prime target, both since they might have an interest in retaining control over their own privacy, and because it’s expected that ZEC will acquire real-world monetary value.

+

We're keen on presenting verifiably secure and trustworthy software to the world, as demonstrated by the several audits we've commissioned. So for our version 1.0.0 release candidates, we have started following a deterministic build process, courtesy of Gitian.

+

Gitian is a method of secure software distribution which allows multiple developers to create identical binaries. It was originally developed by Bitcoin Core, and was subsequently adapted for use by the Tor Project. Cryptographic signatures and hashes are leveraged in order to ensure that the toolchain was not tampered with, and the same, official source was used to make the binaries that are eventually released.

+ +

How it works

+

In Gitian, you have a list containing a number of inputs, which all have hashes associated with them. These are the Zcash source code, its third-party dependencies, and the OS packages. There are also obvious outputs: the Zcash binaries, which will soon be available via a public apt package repository for Debian-based distributions. For each release, we have multiple people from our project build the binaries within a contained environment, and then sign the results with their GPG key, attesting to the inputs they used and the outputs that were generated. The manifest of hashes and corresponding signatures is then published on GitHub and compared with the others. If there is any difference present, then we will be aware that the inputs have been modified in some way, either maliciously or not.

+

We will never release a binary that was not built deterministically. We are also architecting a sophisticated security regime around protecting the master signing key used to verify downloads from our origins.

+

The most common source of indeterminism in software is timestamps. Therefore, during this whole process, timestamps and other metadata are either stripped from files, or various wrappers are used to make timestamps correspond to a reference date and time. This usually results in a build that is reproducible by anyone.

+

By way of illustration, when we first started using Gitian, we uncovered a single source of irreproducibility in libsnark, the library we use for zero-knowledge proving. Two of our developers compared their outputs and found a mismatch:

+
::
+
- 1edeaed33a85eef3e190160e781d3b0cc6e389eda53c382ccc555241fa0e1e51 x86_64-unknown-linux-gnu/libsnark/libsnark-0.1-a97aa3c0de8.tar.gz ++ cec7ca83f5767d8553891906953ffbe38935ecbc379971b6cb7e449467495c00 x86_64-unknown-linux-gnu/libsnark/libsnark-0.1-a97aa3c0de8.tar.gz
+

Drilling down into the diff, we found that the binary forms of the library differed. Using a tool called diffoscope, we discovered that there were timestamps encoded in the binary:

+
::
+
$ diffoscope libsnark-0.1-a97aa3c0de8.tar.gz libsnark-0.1-a97aa3c0de8.tar.gz.2 +--- libsnark-0.1-a97aa3c0de8.tar.gz ++++ libsnark-0.1-a97aa3c0de8.tar.gz.2 +├── libsnark-0.1-a97aa3c0de8.tar +│ ├── ./lib/libsnark.a +│ │ │ @@ -51,16 +51,16 @@ +│ │ │ - [ 74] 21:08:27 +│ │ │ - [ 7d] Oct 15 2016 +│ │ │ + [ 74] 03:30:18 +│ │ │ + [ 7d] Oct 16 2016 +│ │ ╵ +│ ╵
+

We quickly traced it to this function, which prints the date and time of compilation, and developed a fix.

+

We think that having deterministic builds is an exciting milestone for Zcash, and encourage other open-source projects to follow suit.

+ +

Technical details

+

The Zcash deterministic build environment, which runs Debian 8, is a virtual machine created with Vagrant, using VirtualBox for virtualization. It runs gitian-builder and Linux containers (LXC) as guests.

+

Ansible, a Python-based configuration management tool, is used to provision the initial environment. The script which interacts with gitian-builder, itself a Ruby-based tool, is written in Bash. Much of our tooling borrows from the fine work already done by Bitcoin Core, but we have automated away many of the steps required to bootstrap the system.

+

We welcome anyone who is technically inclined and enthusiastic about Zcash to help us produce more builds. If you’re interested, contact us on our community Slack #zcash-dev channel.

\ No newline at end of file diff --git a/_posts/2016-10-17-new-beta-release-fixes-packaging-and-launch-preparation.md b/_posts/2016-10-17-new-beta-release-fixes-packaging-and-launch-preparation.md new file mode 100644 index 0000000..7776c2d --- /dev/null +++ b/_posts/2016-10-17-new-beta-release-fixes-packaging-and-launch-preparation.md @@ -0,0 +1,27 @@ +--- +ID: 1586 +post_title: 'New Beta Release: Fixes, Packaging and Launch Preparation' +author: Simon Liu +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-beta-release-fixes-packaging-and-launch-preparation/ +published: true +post_date: 2016-10-17 00:00:00 +--- +

Today, we deployed the third beta release of the Zcash reference implementation, 1.0.0-rc1, to the testnet. This is the third release of the Zcash Beta Series. The new release includes the following changes [1]:

+
  1. We added a script to create a Zcash Debian package. (#1448)
    2. +
  2. We have published the first release of our Gitian-based deterministic build environment and updated libsnark to support it. (#1521, #1543, #1541)
    3. +
  3. We have renamed the client identifier from “Satoshi” to “Magic Bean”. (#1481)
    4. +
  4. We have made the 100kb transaction size limit a consensus rule, rather than a standard rule. (#1501)
    5. +
  5. Fixed UTXO selection and improved error reporting surrounding the consensus rule that coinbase UTXOs must be sent to a zaddr. (#1431)
    6. +
  6. Added JoinSplits to the JSON output of the RPC call gettransaction. (#1493)
    7. +
  7. The ‘account’ parameter in RPC calls is now deprecated. (#1490)
    8. +
  8. Debug log messages for z_* RPC calls can be viewed with option -debug=”zrpc”. (#1523)
    9. +
  9. Fixed a bug in encrypted wallets by caching nullifiers. (#1520)
    10. +
  10. Added fixes to address a bug with note witnesses in the wallet. (#1526, #1547)
    11. +
  11. Fixed an issue where some tests where outputting data to local directory. (#1506)
    12. +
  12. We have updated documentation related to Tor, the release process, security risks and wallet reindexing. (#1483, #1511, #1499, #1492)
    13. +

Note that this release does not reset the beta testnet and continues to uses the beta 2 proving and verify keys. NOTE: It does however make a change to the local block index format that will cause all upgraded nodes to fail to start (because they can’t parse the old block index format). As the error message will say, please start up your node once with the reindex flag after upgrading (ie. ./src/zcashd -reindex ) to resolve this issue.

+

To follow our progress, watch the GitHub project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.

+
[1]For more specific detail, view our 1.0.0-rc1 release github milestone.
\ No newline at end of file diff --git a/_posts/2016-10-17-open-source-miner-submissions.md b/_posts/2016-10-17-open-source-miner-submissions.md new file mode 100644 index 0000000..9f5c492 --- /dev/null +++ b/_posts/2016-10-17-open-source-miner-submissions.md @@ -0,0 +1,17 @@ +--- +ID: 1607 +post_title: Open Source Miner Submissions Are Live +author: Liz Steininger +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/open-source-miner-submissions/ +published: true +post_date: 2016-10-17 00:00:00 +--- +

The Zcash Open Source Miner Challenge launched on September 27 to enable a wider community to mine for Zcash coins and take collective ownership of the network as a public good. The more individuals who run a miner (whether GPU or CPU), the stronger the network. More than halfway through the challenge, we are thrilled to see many submissions.

+

Currently, the published submissions include: a sample Equihash solver submission, and four actual submissions to the Challenge, which are a (currently incomplete) would-be GPU miner (OpenCL), a CPU solver (x86_64 assembly), a GPU solver (CUDA), and CPU (C) and GPU (CUDA) solvers (both in one submission).

+

These submissions, along with links to the code hosted on GitHub, are on the Challenge website. Not all of the submissions we have received are listed. If a submission does not appear to include any Equihash code, then it is not published and will not be considered for judgment unless there is code added before the deadline. Submissions are listed in no particular order.

+

We expect there will be many more submissions before the October 27 deadline and we hope these midway submissions incentivize others to create open source miners and build off of the existing work (with proper attribution).

+

If you are interested in participating in the Challenge, please look at the timeline, read the rules and the judging criteria, before applying. The Zcash Company is sponsoring a prize fund of $30,000 for the winner(s) of the challenge. Note that the winning CPU entry will receive a $10,000 prize and the winning GPU entry will receive a $10,000 prize and the other $10,000 of prizes will be distributed to the Runners Up.

+

You can also participate in the discussions on the Zcash forum.

\ No newline at end of file diff --git a/_posts/2016-10-18-zcash-evolution.md b/_posts/2016-10-18-zcash-evolution.md new file mode 100644 index 0000000..b93d373 --- /dev/null +++ b/_posts/2016-10-18-zcash-evolution.md @@ -0,0 +1,89 @@ +--- +ID: 1652 +post_title: Zcash Evolution +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-evolution/ +published: true +post_date: 2016-10-18 00:00:00 +--- +We are on track to launch the Zcash currency on October 28th. Recently, we shared our vision of Zcash as a consensual currency: users are always free to run software from whichever developers they choose. Now, before Zcash launches, is a perfect time for us to share some of our visions for how we propose to evolve Zcash. +
+

Upgrade Strategy

+The most important overarching theme of our future protocol plans is that we intend to deprecate old protocol versions. This will allow us to introduce features that old clients do not recognize, as well as removing old behavior when it's no longer advantageous to retain. + +This is sometimes referred to as a hard forking upgrade although we prefer to avoid the term fork because it's both highly-conflated and often repeated in highly contentious debates. The term fork itself can mean at least any of the following: +
    +
  1. diverging software revisions,
    2. +
  2. persistently diverging blockchain histories,
    3. +
  3. diverging communities.
    4. +
+These are orthogonal to each other. For example, a single coherent community may maintain multiple divergent software codebases, or diverging blockchain histories might be supported by a single codebase (e.g. parity after the divergence of ETH and ETC). + +We believe that the protocol upgrades we propose will be acceptable to almost all participants. More importantly, the upgrades will not be unacceptable to a significant population. Whenever this is true, blockchain divergence will be short-lived and the community will continue undivided. + +At some point, a proposed upgrade may not be so clearly desired by all participants. Even in this scenario, a proposed upgrade may still provide benefits that outweight the drawbacks (e.g. confusion caused by diverging blockchains). If that's the case, we may still advocate for the upgrade and release software for it. Or, we may decide the risk of a blockchain divergence outweighs the benefit. + +One final note about our upgrade strategy: we believe it's possible to have a single coherent Zcash community even if the blockchain diverges, so if we forsee a blockchain divergence, one of our focuses will be in collaborating between the subcommunities participating in each side. + +
+
+

Potentially Surprising Upgrades

+Given that we plan to propose upgrades that will deprecate older protocol implementations, it's important to let people know what kinds of upgrades we plan well in advance, in order to set expectations appropriately. The following examples are not comprehensive, nor are they the coolest or most exciting upgrades on our radar. Rather they are a selection of upgrades we expect will surprise some fraction of potential users, and are thus the most important to communicate before Zcash launches. +
+

Mining

+We already intend to alter our mining system, at the very least by altering the Equihash parameters. In the future we may even advocate more drastic changes, such as moving to a different proof-of-work system or even proof-of-stake, if we believe those alternatives are feasible, secure, and have better economic effects. + +
+
+

Founders' Reward

+If the Founders' Reward were to suffer a severe flaw or if our keys were stolen or compromised, we would advocate an upgrade to repair the damage. + +
+
+

Counterfeit Detection

+Any currency with strong privacy carries a risk of undetected counterfeiting [1]. For any security system, a crucial complement to prevention is detection. We've started sketching out several potential protocol upgrades for counterfeit detection. These will allow all users to potentially detect, and in some cases to limit, counterfeiting due to security breakthroughs. + +Some of the counterfeit detection schemes we've considered rely on expiring old, abandoned funds (i.e. users might need to take action to ensure that their dormant funds are not flagged as expired). + +
+
+

Removing Technical Debt

+Zcash is derived from the Bitcoin Core code and design. We chose this implementation path in order to benefit from a battle-tested, conservative design and codebase. Because we will be proposing upgrades which deprecate features, we will have the opportunity to remove technical debt when it seems safe and beneficial to do so [2]. + +
+
+

…and More

+As mentioned earlier, this list is not comprehensive. We may advocate for other upgrades which may surprise some users, which aren't listed here. The ideas above are merely what we consider fairly likely and the most "surprising" potential upgrades. And remember, these aren't the coolest potential upgrades. ;-) + +
+
+
+

Future Evolution

+We've presented here a taste of the kinds of upgrades we may advocate for in the future. Keep in mind, we also plan to change our technical strategy appropriately as Zcash grows. + +For example, if the userbase remains relatively small with a few niche use cases, we may promote more rapid evolution of features. However, if Zcash were to grow to many stakeholders encompassing many different use cases, this would imply the design at that time was already successful at supporting economic weight, and we would likely adopt a more conservative strategy. + +One final thought: we've discussed here and in the consensual currency post how we intend to propose changes that anyone is free to adopt, but we haven't yet clarified how proposals will be made, what the decision process will look like, and how we'll solicit input from stakeholders. That's a topic for another post. + +—Nathan Wilcox, 2016-10-18 + +Footnotes: + + + + + + + +
[1]Different privacy systems have different attack surfaces which, if compromised, lead to counterfeiting. For Zcash the attack surfaces include the initial parameter setup, the security assumptions supporting soundness of zk-SNARK proofs, and the zk-SNARK circuit construction that maintains the currency balance rules for shielded transactions. When analyzing fungible currency systems, it is important to determine the attack surface for counterfeiting vulnerability.
+ + + + + + + +
[2]The Bitcoin community maintains a wishlist for just this purpose. We have the opportunity to test these clean-ups in our live network so that Bitcoin community can learn from our successes and mistakes.
+
\ No newline at end of file diff --git a/_posts/2016-10-19-software-usability-and-hardware-requirements.md b/_posts/2016-10-19-software-usability-and-hardware-requirements.md new file mode 100644 index 0000000..b87ac29 --- /dev/null +++ b/_posts/2016-10-19-software-usability-and-hardware-requirements.md @@ -0,0 +1,24 @@ +--- +ID: 1632 +post_title: 'User Expectations at Sprout Pt. 2: Software Usability and Hardware Requirements' +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/software-usability-and-hardware-requirements/ +published: true +post_date: 2016-10-19 00:00:00 +--- +

This is the second post in a two-part series about what users can expect from the launch of Zcash Sprout. The first post highlighted the effects of the slow-start mining period on the market, and accessibility to the overall mining ecosystem. Accessibility for Zcash end users, whether they participate in the mining ecosystem or not, is a critical aspect within the overall Zcash mission. While this initial release comes relatively limited in its mainstream usability, we anticipate core improvements and tools built by third-party developers (such as wallets with graphical interfaces and integrations with exchanges) in the days and months following the launch creating many more opportunities for Zcash users. In the meantime, early adopters should be aware of initial limitations and set expectations appropriately during the budding phase of Sprout.

+
+

Using Linux natively or through a virtual environment

+

Whether experienced with using the command-line install process, or simply curious to try, we encourage you to install Zcash Sprout on a Debian or Ubuntu based system (you can get a head start with the current Beta release). Users running other operating systems are similarly encouraged to run a Debian or Ubuntu based virtual environment for the install. We will have written and video documentation to walk you through the command-line instructions for a Debian package install (which is supported by Ubuntu). While we can’t officially give support to users on setting up a virtual environment, we can recommend looking into VirtualBox - and together with community support from the Zcash community and VirtualBox forums, there’s plenty of opportunity to receive guidance along the way.

+
+
+

Blockchain and zero-knowledge proof generation hardware requirements

+

The other half of accessibility considerations involves the optimal resources for running a Zcash node. First, it’s important to reiterate Zcash is a blockchain. While the storage requirements at first will be relatively low, the growth of the ledger is something to plan for. With a block size maximum of 2MB and average block time of 2.5 minutes, the maximum growth of the blockchain after one year is 420 GB. We don't anticipate blocks filling to their maximum (especially in this first year) and we cannot predict what the average blocksize will be but it's safe to assume that with increased adoption, the rate of growth for the Zcash blockchain will also increase.

+

Additionally, the process of creating transactions involving zero-knowledge proofs will occupy 4 GB of RAM for about a minute or two. While we hope to see improvements on this metric in future versions, this will be an important aspect of planning to send ZEC to a shielded address at launch. Sending ZEC using transparent addresses does not involve generating a zero-knowledge proof and requires very little memory (comparable to sending a bitcoin transaction).

+

On installing the Beta release (and again upgrading to Beta 2) on my own laptop which I restricted to 4 GB of memory for testing purposes, I had to shut down nearly every process while the zero-knowledge proof was generated for a testnet transaction. While I was successful, it was definitely pushing the upper limits and took almost 2 minutes to complete the operation. So if your computer has only 4 GB in available memory, you might want to consider upgrading. If your computer has less than that, you’ll be limited to transparent transactions unless you upgrade to at least 4 GB (preferably more).

+

The current state of zero-knowledge proof generation represents an initial implementation. Optimization is an open task within the core development roadmap, and centers around removing unnecessarily stored data throughout the proof generation process. There is no prediction yet for how much reduction in memory is possible, but we should have a better idea once additional research has been performed.

+

Overall, it has taken a lot of hard work to get to Sprout and it will take a lot more to get where we want to go. We encourage the Zcash community to experiment with us, and if you have the means, to prepare your system for the resource requirements. Use the Zcash community forum to discuss your findings, ideas, and work with others on support needs. Your active participation only makes this network stronger.

+
\ No newline at end of file diff --git a/_posts/2016-10-22-new-release-candidate-less-than-one-week.md b/_posts/2016-10-22-new-release-candidate-less-than-one-week.md new file mode 100644 index 0000000..19f637f --- /dev/null +++ b/_posts/2016-10-22-new-release-candidate-less-than-one-week.md @@ -0,0 +1,33 @@ +--- +ID: 1602 +post_title: 'New Release Candidate: Less than One Week to Launch' +author: Daira Hopwood +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-release-candidate-less-than-one-week/ +published: true +post_date: 2016-10-22 00:00:00 +--- +The Zcash team has been hard at work preparing for the launch, which is on track for the 28th October. Despite some hiccups due to the widespread DNS disruptions on Friday, today we deployed the fourth beta release of the Zcash reference implementation, 1.0.0-rc2, to the testnet. + +The new release includes the following user-visible changes: +
    +
  1. Wallet encryption has been disabled. The reasons for disabling this feature for the time being are explained in our security warnings document. We recommend using full disk encryption for now instead. (#1552)
    2. +
  2. We have included mitigations for security issues found by the NCC Group and Coinspect audits. (#1459, #1464, #1504)
    3. +
  3. We have merged some changes from Bitcoin to help address potential denial-of-service vulnerabilities. (#1588, #1589, #1591)
    4. +
  4. A bug that could cause assertion failures when restarting after a crash has been fixed. (#1378)
    5. +
  5. A more efficient CPU Equihash solver written by John Tromp has been integrated into the built-in miner. This is not used by default, but can be enabled by adding equihashsolver=tromp to zcash.conf. Thanks go to John Tromp, and to @sarath-hotspot for providing the impetus for this improvement. (#1570, #1578)
    6. +
  6. Running the node now displays a screen showing node metrics (and some pretty ASCII art ☺). (#1375)
    7. +
  7. The consensus rules have been tightened to reject block and transaction versions that were previously used by Bitcoin but are not valid for Zcash. (#1556, #1600)
    8. +
  8. The testnet now enforces the same rules on standard transactions as will be enforced on mainnet. (#1582, #1557)
    9. +
  9. We have made changes to the getblocktemplate RPC call to support mining pools. (#1424, #1602)
    10. +
  10. Improved support for deterministic builds. (#1549)
    11. +
  11. Build fixes for the musl C library used by Alpine Linux. (#1558)
    12. +
  12. Documentation improvements. (#1500, #1575)
    13. +
+For a more complete list of changes, see our 1.0.0-rc2 release github milestone. + +This release resets the beta testnet. It continues to use the beta 2 proving and verify keys. + +To follow our progress, watch the GitHub project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here. \ No newline at end of file diff --git a/_posts/2016-10-24-miner-challenge-deadline.md b/_posts/2016-10-24-miner-challenge-deadline.md new file mode 100644 index 0000000..e2f78d5 --- /dev/null +++ b/_posts/2016-10-24-miner-challenge-deadline.md @@ -0,0 +1,16 @@ +--- +ID: 1576 +post_title: 2 Days to Enter the Miner Challenge +author: Liz Steininger +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/miner-challenge-deadline/ +published: true +post_date: 2016-10-24 00:00:00 +--- +

The Zcash Open Source Miner Challenge deadline is just two days away! All submissions that want to be considered for the Challenge prizes need to be entered and finalized by 27 October at 23:59 UTC.

+

We’ll publish all viable submissions by the launch of Zcash on 28 October and the winners will be announced on 2 December. Submissions, along with links to the code hosted on GitHub, will be on the Challenge website. Anyone with a miner not participating in the Challenge, but still interested in having it listed should send information to challenge@zcashminers.org.

+

We encourage you to take a look at the current submissions and build upon them (and provide attribution). More miners enable a wider community to mine for Zcash coins and take collective ownership of the network as a public good. The more individuals who run a miner (whether GPU or CPU), the stronger the Zcash network.

+

If you are interested in participating in the Challenge, please look at the timeline, read the rules and the judging criteria, before applying. The Zcash Company is sponsoring a prize fund of $30,000 for the winner(s) of the challenge. Note that the winning CPU entry will receive a $10,000 prize and the winning GPU entry will receive a $10,000 prize and the other $10,000 of prizes will be distributed to the Runners Up.

+

You can also participate in the discussions on the Zcash Community Slack or the Zcash forum.

\ No newline at end of file diff --git a/_posts/2016-10-26-the-design-of-the-ceremony.md b/_posts/2016-10-26-the-design-of-the-ceremony.md new file mode 100644 index 0000000..300ad56 --- /dev/null +++ b/_posts/2016-10-26-the-design-of-the-ceremony.md @@ -0,0 +1,78 @@ +--- +ID: 1640 +post_title: The Design of the Ceremony +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/the-design-of-the-ceremony/ +published: true +post_date: 2016-10-26 00:00:00 +--- +

Update: Read our full summary of what took place in the Zcash Parameter Generation Ceremony.

+
+

The Toxic Waste, and Other Ways To Counterfeit Zcash

+

As we've mentioned in a previous blog post, the private transactions in Zcash “Sprout” 1.0 rely on SNARK public parameters for constructing and verifying zero-knowledge proofs. (When we upgrade the Zcash protocol and change the zero-knowledge proofs — which we intend to do within about a year — then we'll have to generate new SNARK public parameters from scratch.) Generating SNARK public parameters is basically equivalent to generating a public/private keypair, keeping the public key, and destroying the private key.

+

The problem is, if an attacker were to get a copy of that corresponding private key, they could use it to create counterfeit Zcash. That is the only harm they could do with it — they could not violate anyone else's privacy nor steal other people's Zcash.

+

We call the private key “the toxic waste”, and our protocol is designed to ensure that the toxic waste never comes into existence at all. Imagine having a bunch of different chemical byproducts in your factory, each of which is individually harmless, but if you let all of them mix together they will form a dangerous substance that's difficult to manage safely. Our approach is to keep the individually-harmless chemicals separate until they are destroyed, so the toxic waste never comes into existence at all.

+

Important note: destroying the private key doesn't guarantee that it's impossible to counterfeit Zcash! Every currency technology ever made has been vulnerable to counterfeiting. Bitcoin once had a bug which allowed the first person who discovered it to counterfeit 184 billion BTC. Zcash could turn out to have a similar flaw, totally unrelated to the toxic waste private key.

+

Bitcoin was able to detect this problem because it publicly exposes all transactions. Zcash won't have that ability. In fact, any system which shields the amounts of transactions risks losing the ability to detect such counterfeiting.

+

Zcash is not unique in the risk that it could be counterfeited, nor in the difficulty of detecting counterfeiting. We'll return to this fact at the end of this post.

+
+
+

The Design of a Secure Ceremony

+

In order to reduce the risk of an attacker acquiring the toxic waste, we developed a Multi-Party Computation (MPC) protocol in which a set of multiple participants in separate geographic locations cooperatively construct the public key. Each participant separately generates one shard of the public key, which requires them to temporarily use a corresponding private key shard. They all combine their public key shards to generate the final public parameters, and then each deletes their private key shard.

+

With the MPC protocol, as long as at least one of the participants successfully deletes their private key shard, then the toxic waste is impossible for anyone to reconstruct. The only way the toxic waste can be reconstructed is if every participant in the protocol were dishonest or compromised.

+

I myself, plus five people who I trust to be ethical and to have good information security practices, served as the operators and observers in the protocol. We call these people “Witnesses”, and we call the execution of the protocol a “Ceremony”.

+

The identities of three of the Witnesses were revealed to all of the participants and observers at the beginning of the Ceremony: Andrew Miller (computer scientist and Zcash technical advisor), Peter Van Valkenburgh, and yours truly.

+

I told these participants that their fellow witnesses were named “Moses Spears”, “Fabrice Renault”, and “John Dobbertin”, but in fact I made up those pseudonyms in order to temporarily hide the identities of those other Witnesses. I did this in order to hide their identities from any potential attacker who was able to eavesdrop on our (mostly encrypted) communications or to subvert one of our other Witnesses.

+

At the end of the Ceremony, on October 23, “Moses Spears” was revealed to be Derek Hinch of NCC Group. We had secretly hired NCC Group to be one of the Compute Node operators. Nobody other than Nathan Wilcox (ZcashCo CTO), myself, and NCC Group knew about this. NCC Group's task was both to protect their Compute Node during the ceremony (they hosted it in their secure facility in Austin), and to do forensic analysis during and after the Ceremony in order to attempt to detect whether there had been any cyber attack attempted against it. Additionally, they set up a redundant model Compute Node that wasn't used in the actual Ceremony, and attempted to hack into it to see how hard it would be for a Witness to steal the private key shard out of a Compute Node. NCC Group will write a tech report about what they did and observed.

+

On October 27, “Fabrice Renault” revealed himself to be Bitcoin Core developer Peter Todd. Peter had expressed skepticism about the Zcash Parameter Generation Ceremony, and I told him that serving as a Witness would give him the best vantage point from which to scrutinize and criticize it. Most importantly, I trust that Peter would never collude to attempt to steal the private key shards. Finally, I guessed that he would deploy creative and strong information security defenses. I do not yet know the details of those defenses, since he has not yet posted his report. We didn't pay Peter to do this, although we did agree to reimburse his expenses, such as buying a new computer from a random store and then a couple of days later completely destroying it.

+

The identity of “John Dobbertin” has not yet been revealed, and I don't yet know when John and I will be ready to do that.

+

Several of the Witnesses made photo, video, and/or audio recordings of the process, and we invited a journalist to observe one of the stations — Denver Station, where I was located. We'll publish these records as soon as we've organized, labeled, and hosted them and scanned for any private and personal information that we may have accidentally captured.

+

The Ceremony design we chose has three core defenses which work together: Multi-Party Computation, air gaps, and evidence trails.

+
+

Multi-Party Computation

+

The Multi-Party Computation effect is that it only takes one of these people to successfully delete their private key shard for us to succeed. As soon as any one of the Witnesses deleted their private key shard, then the toxic waste could never be created. This is the starting point of our design, and it dovetails well with the other defenses.

+
+
+

Air Gaps

+

Each participant's private key shard was used solely on an air-gapped machine. Air-gapping means that the computer is physically disconnected from all networks.

+

Each machine was bought new, exclusively for this purpose, and was never connected to any network during its entire life, from the moment that it was purchased at the store by the Witness. The Witness physically removed the radios (wifi and bluetooth) from the computer before first powering it on.

+

These air-gapped machines were called the “Compute Nodes”.

+

The air gap eliminated most of the attack surface that could allow an attacker to compromise the Compute Nodes, since the Compute Nodes were physically incapable of making or receiving network connections.

+an air-gapped Compute Node being set up
+
+

Evidence Trails

+

We needed to communicate messages back and forth between the Compute Nodes in order to perform the Multi-Party Computation protocol.

+

Each Witness had, in addition to the Compute Node, a separate machine which was connected to the Internet, which we called the “Network Node”. The Network Node received incoming messages and burned them to disc, and then the Witness moved the disc across the air gap to the Compute Node.

+

This replaced the attack surface that we had removed — networking — with a different attack surface — DVD reading. We hope that the new attack surface was harder to exploit, but it is difficult to be sure about such things. For example, if you could have put maliciously crafted data onto the discs (i.e. if you had already compromised the Network Node), then it may have been possible to exploit the Compute Node's DVD reader's firmware, or it may have been possible to exploit the userspace code on the Compute Node that read the messages.

+

A major advantage of using append-only optical discs is that they provide an indelible evidence trail of exactly what messages were passed during a particular Ceremony. For example, suppose that in the future someone discovers that there was an exploitable bug in the firmware of the DVD device that was used in one of the Compute Nodes. We can then ask: well, did the messages that were fed into that Compute Node exploit that bug? We can inspect the optical discs to see if any data were passed into the Compute Node that might have exploited such a vulnerability.

+

It is important that the optical discs are not overwriteable — they are DVD-R's, not DVD-RW's — because that way even if an attacker succeeded at taking over the Compute Node, that wouldn't have given them the ability to erase the evidence of them doing so.

+ceremony design
+
+
+

Additional Defenses

+

In addition to the triad of core defenses outlined above, we also used numerous additional techniques to make our jobs as defenders easier and to make any potential attacker's task harder. We kept the details of the Ceremony — when it was going to be executed, who the participants would be, what source code we would run, etc. — secret until after the Ceremony had been completed — until now! We used a security-hardened version of Linux on the Compute Nodes. We wrote all of the code we needed for the computation and the networking in Rust — a programming language which makes it easy to avoid writing the most common security bugs. We made a secure hash chain of all the messages that were passed, and we posted that hash chain to Twitter and the Internet Archive, and time-stamped it into the Bitcoin blockchain. In addition, each of the Witnesses chose their own additional local defenses, which we will describe in more detail in future documents.

+
+
+

Future Work

+

Our task is not yet done. Here are two important steps to take next:

+
+

Evidence Archiving and Independent Inspection

+

We will write more documentation explaining the details of the protocol and the Ceremony, including who the Witnesses were, when and where (six different locations!) the Ceremony was held, and extensive details about the process. We'll publish the video, audio, photographic, and textual evidence that we recorded. We are also asking each of the Witnesses to write an attestation about what they did and what they observed. We are working hard on writing, publishing, and archiving all of this material so that anyone can inspect it.

+

I think that this material will prove extremely interesting to our fellow paranoid infosec experts. I look forward to hearing their evaluation of our security precautions and what we observed during the execution of the Ceremony. As far as I know, the Zcash Parameter Generation Ceremony is the most remarkable and sophisticated cryptographic ceremony that has ever been executed!

+

We have already begun this process by publishing the source code of the network process and the computation process. Please read it and let us know right away if you find any exploitable flaws in it.

+
+
+

A Proposed Counterfeiting-Detection Feature for Zcash

+

Although we are currently satisfied that the toxic waste private key corresponding to these Zcash 1.0 public parameters never came into existence, and can never come into existence, I am not sure that counterfeiting Zcash is impossible. This is because, as I wrote above, there may be other ways to create counterfeit Zcash coins besides reconstructing the toxic waste private key.

+

Also, people who did not have the opportunity to witness the Ceremony first-hand may still have doubts that it was executed honestly and safely. There is no way that we can actually prove that we really did what we said we did. We could have all six colluded to perform the whole process — making video footage and all — as a stage-magic trick, and we could have actually secretly copied the private key shards and combined them to form the toxic waste. I chose the other five Witnesses to be people who I personally trusted never to do such a thing, but if you don't know these people as I do, then you may require additional safeguards.

+

Therefore, I intend to advocate for a Zcash protocol upgrade in the future — after the launch of Zcash 1.0 “Sprout” — which adds a counterfeiting-detection feature. This will provide a way for anyone (i.e. the general public) to measure the total monetary base of Zcash coins in circulation. This will allow us to determine whether counterfeiting — whether by exploiting the toxic waste private key or by any other mechanism — has occurred.

+

I will write more on this in a future blog post.

+
+
+
+

The Bottom Line

+

We have performed a remarkable feat of cryptographic and infosec engineering in order to generate SNARK public parameters for Zcash 1.0 “Sprout”. The general design of this Ceremony was based on Multi-Party Computation, air-gaps, and indelible evidence trails. Six different people each took one part of the Ceremony. The Multi-Party Computation ensures that even if all five of the others were compromised, or were secretly colluding, to try to reconstruct the toxic waste, one single Witness behaving honestly and deleting their shard of the toxic waste would prevent it from ever being reconstructable. Despite the remarkable strength of this Ceremony, I intend to advocate for a major upgrade to the Zcash protocol next year which will add a layer of detection in addition to the current layer of prevention.

+
\ No newline at end of file diff --git a/_posts/2016-10-27-audit-results.md b/_posts/2016-10-27-audit-results.md new file mode 100644 index 0000000..3162402 --- /dev/null +++ b/_posts/2016-10-27-audit-results.md @@ -0,0 +1,74 @@ +--- +ID: 1546 +post_title: Zcash Audit Results +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/audit-results/ +published: true +post_date: 2016-10-27 00:00:00 +--- +

Maureen Walsh and Nathan Wilcox

+As a security-focused team, made up of world-class talent, we prioritize the security of Zcash users. True security comes from empowering users directly, and to that end, we will always disclose vulnerabilities we find (as soon as we're certain such disclosure won't harm live users), and describe how we have fixed them or how we intend to fix them. + +In keeping with that value, and with our launch imminent, it's important to share the full details of our commissioned audits. +
+

Security Recap

+To give context, in April we highlighted a few vulnerabilities in our code that our team found and fixed. In August, we announced our work with two top security auditing teams, and we're presenting those security audit results in this post [1]. + +We maintain a security page on this site with up-to-date security information about Zcash. We also maintain a security warnings document for each release. + +
+
+

Security Audits

+Today we are publishing the final reports of each external security auditor we contracted this summer to review our code. We've triaged the issues found and addressed any we considered severe (e.g. could compromise user privacy, lose funds, break consensus, etc...). + +Additionally, we've kept in touch with Bitcoin Core developers to ensure any findings relating to our codebase (which is derived from Bitcoin Core v0.11.2) does not present any substantial risk to Bitcoin users. We also sent private notifications to developers of Bitcoin Unlimited, Bitcoin XT, and Bitcoin Classic. We did not contact developers of any other projects derived from the Bitcoin Core codebase. + +Each of the auditors have prepared reports of their work and findings. They are all hosted on their respective websites. Here we present links to those reports, our issue tracker searches to track their audit work, and their project summaries: +
+

NCC Group

+
+ +Report URL: https://www.nccgroup.trust/us/our-research/zcash-cryptography-and-code-review/?research=Public+Reports + +Zcash Issue Tracking: NCC findings + +Their Summary: +
“NCC Group performed a two-part targeted review of the Zcash cryptocurrency implementation. The first part, performed by the Group's Cryptography Services practice, focused on validating that Zcash's implementation adhered to the Zcash Protocol Specification. An assessment looking for security errors within the cryptographic implementation was also performed. The second part was a C++ source code review for vulnerabilities using static and dynamic analysis and fuzz testing. The review also included a cursory assessment of dependent libraries and recommendations for improving software assurance practices at Zcash. + +NCC Group identified an issue that would allow an adversary to tamper with the verification and proving keys used by the Zcash daemon as well as a number of C++ coding errors that could result in stack-based buffer overflows, data races, memory use-after-free issues, memory leaks, and other potentially exploitable runtime error conditions. Additionally, most, if not all, third-party open source library dependencies were identified as being out-of-date. In the end, NCC Group did not find any critical severity issues that would undermine the integrity of the Zcash blockchain or undermine the security of confidential transactions during the time that the review was conducted (from August 8 – September 2, 2016).”
+
+
+
+

Coinspect

+
+ +Report URL: https://coinspect.com/doc/CoinspectReportZcash2016.pdf + +Their Announcement: https://coinspect.com/zcash-security-audit-results + +Zcash Issue Tracking: Coinspect findings + +Their Summary: +
“Coinspect reviewed Zcash's innovations over the Bitcoin Core source code, focused on evaluating its resistance against specific threats to cryptocurrencies. Coinspect identified high-risk and moderate-risk issues during the assessment that affected the performance and availability of the Zcash p2p network. The security issues identified did not allow remote code execution nor allowed an attacker to steal funds or compromise the privacy of Zcash users. However we found exploitable 51% and isolation attacks with minimum resources. + +It is an honor for Coinspect to contribute with our cryptocurrency security experience to the exceptional team behind this exciting project.”
+
+
+
+
+

Conclusion

+We are committed to serving our users and community, and one of the best ways we can do that is to provide transparency. Zcash is still in a nascent stage, it is experimental and new; users are encouraged to educate themselves about the risks involved in being a direct part of the Zcash protocol and network. + +Please join the Zcash developers and community in our Slack and Forum conversations. + + + + + + + +
[1]Our blog post also described our work with Solar Designer who is analyzing our Equihash Proof-of-Work system. We focus on security audits and mitigations in this post, and we'll post the Equihash analysis in a later post.
+
+  \ No newline at end of file diff --git a/_posts/2016-10-27-new-release-candidate-final-snark-parameters.md b/_posts/2016-10-27-new-release-candidate-final-snark-parameters.md new file mode 100644 index 0000000..78a1c71 --- /dev/null +++ b/_posts/2016-10-27-new-release-candidate-final-snark-parameters.md @@ -0,0 +1,53 @@ +--- +ID: 1601 +post_title: 'New Release Candidate: Final zk-SNARK parameters' +author: Daira Hopwood +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-release-candidate-final-snark-parameters/ +published: true +post_date: 2016-10-27 00:00:00 +--- +The Zcash team has been working to finalize the software for the launch of the Zcash blockchain. We are planning to make the launch release available on the morning (PDT) of 28th October, subject to any last-minute technical hitches. + +Over last weekend the final zk-SNARK parameters were created in the Parameter Generation Ceremony. The transcripts and software used for the ceremony have been published, and we'll be making another post with more information on that very soon. + +We encourage everyone to test this latest 1.0.0-rc4 release by following the Beta Guide. That will also make sure that you are able to run the software on your system, and have the zk-SNARK parameters (a ~910 MB download) ready for launch. +
+

Two Releases

+As part of a strategy to reduce technical risk and to ensure auditability, we have made two releases within a day of each other. Most users should skip from 1.0.0-rc2 directly to 1.0.0-rc4. +
+

1.0.0-rc3 - bug fixes and dependency upgrades

+The intermediate 1.0.0-rc3 release included only bug fixes, and updates of libraries that Zcash depends on: +
    +
  1. The node metrics screen added in the rc2 release caused a bug when the output was not directed to a terminal, which has been corrected. (#1612)
    2. +
  2. The version of Berkeley DB has been updated to 6.2.23. (#1637)
    3. +
  3. The tinyformat library was updated in order to mitigate a potential buffer overflow vulnerability. (#1640, #1349)
    4. +
  4. A fix for a minor potential race condition was backported from Bitcoin. (#1634)
    5. +
  5. A couple of portability problems with the fetch-params.sh script and the Debian packages have been fixed. (#1053, #1537, #1613)
    6. +
  6. We have eliminated an error-prone case and a confusing error message when spending part of a coinbase output (e.g. mining reward). As a consequence it is now necessary to spend coinbase outputs exactly so that there is no change; the node will not implicitly select a change address. (#1616)
    7. +
  7. Updates to documentation and examples. (#826, #965, #1152, #1154, #1643)
    8. +
  8. Network bootstrapping for mainnet. (#1369)
    9. +
+
+
+

1.0.0-rc4 - zkSNARK Params and Founders' Reward Addresses

+The 1.0.0-rc4 release, which is the one now deployed on the testnet, made some final updates in preparation for the Zcash launch: +
    +
  1. The zk-SNARK parameters have been updated to the ones created by the ceremony performed last weekend.
    2. +
  2. The Founders' Reward addresses for mainnet have also been updated.
    3. +
+For a more complete list of changes, see our 1.0.0-rc3 and 1.0.0-rc4 release github milestones. + +
+
+
+

Imminent Launch

+In the remaining time before launch, we will only make further changes if they are necessary to correct critical problems that would be an obstacle to Zcash launching successfully. If all goes to plan, the only thing remaining is the mainnet genesis block — the code is done! + +It takes some time to generate the genesis block, and build the binaries. We're going to mint the genesis block and prepare binaries etc. the night before (i.e. this evening, Thursday, Oct 27), and then go to sleep. Then we will get up and release it the next morning, San Francisco time. Keep an eye on our Twitter feed! + +To follow our progress, watch the GitHub project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here. + +
\ No newline at end of file diff --git a/_posts/2016-10-28-zcash-begins.md b/_posts/2016-10-28-zcash-begins.md new file mode 100644 index 0000000..989e0d5 --- /dev/null +++ b/_posts/2016-10-28-zcash-begins.md @@ -0,0 +1,22 @@ +--- +ID: 1650 +post_title: Zcash begins +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-begins/ +published: true +post_date: 2016-10-28 00:00:00 +--- +

The Zcash blockchain is live! We released the genesis block this morning, and people all around our planet have begun mining and transacting on it.

+

Our homepage links to a download page where you can find instructions on installing the Zcash software; an explainer video will be posted there shortly. If you feel confident using this kind of Linux command-line tool, then dive in! The more people who do so the better.

+

Our blog hosts a number of articles that Zcash users should read, including User Expectation of our Slow Start Mining, the Distribution of Zcash, and how we think the Zcash Evolution might happen. This technology is still an experiment and it is not yet shown to be safe and stable.

+

This is the first protocol of its kind. It is the product of years of scientific research, advanced engineering, and diligent security work. Zcash is a group of scientists and hackers who came up with a way to combine blockchains for immutability with encryption for data security. These two things are separately well understood, important, and widely used, but they’ve never been put together before now.

+

We encourage the Zcash community to experiment with us, and to mine, run a node, and join the growing and friendly community. Zcash is a consensual currency, a community network, and developer-supported cryptocurrency; your active participation makes the network stronger.

+
+

Why We've Come Together

+

Zcash is a technology, and like any technology it has multiple uses. I suspect that many of the best applications of this technology haven't been conceived of yet.

+

But, the reason we in the Zcash Company have poured years of our lives into this project, and the reason so many people around the planet have stepped forward to join us, is that we believe this technology holds the potential to empower and uplift billions of people. We believe that Zcash and other similar technologies can, with years more evolution and hard work, enable anyone, anywhere to cooperate and to share resources, and to construct more efficient and more humane social organizations. This can unlock the nearly limitless potential of people to help themselves and to help each other.

+

This technology can do for cooperation what the Internet did for communication two decades ago.

+

As we enter the next phase of this experiment, let's remember why we began, and try to help everyone to learn from our experiment and to benefit from it.

+
\ No newline at end of file diff --git a/_posts/2016-10-29-third-party-support.md b/_posts/2016-10-29-third-party-support.md new file mode 100644 index 0000000..cc49a4f --- /dev/null +++ b/_posts/2016-10-29-third-party-support.md @@ -0,0 +1,75 @@ +--- +ID: 1643 +post_title: Third Party Support at Launch +author: Maureen Walsh +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/third-party-support/ +published: true +post_date: 2016-10-29 00:00:00 +--- +

Update: 2017-09-25 - This article is left as-is for posterity. The list of supporting services and vendors for Zcash is constantly evolving. See ZcashCommunity.com's lists of markets and wallets for up-to-date community-curated lists.

+

The Zcash core team is thrilled to have many supporters at launch. It is a sign of a robust and diverse ecosystem already beginning to grow.

+

Zcash is an experimental new technology and external support is highly valuable at this nascent stage. As a science-based team, we are focusing our energies on building and engineering the protocol, and we do not have current plans to build a GUI wallet. There are multiple developers in our community who have stepped up to do so.

+

What follows is a list of some of the wallets and exchange that we currently know about.

+

A word of caution: there have already been multiple scams and fraudulent projects, so we suggest researching any third-party application well before using.

+

This post is intended for Zcash users who want to involve themselves in the early phase of the ecosystem but do not know how to install and run the Zcash software (Linux-only, command-line tool). This post is not an endorsement of any wallet or exchange. Rather it’s a listing of current providers – that we know about – who already support Zcash.

+

We hope that as this community grows, other individuals will take on the responsibility of maintaining a repository or lists of Zcash providers. For example, Zcash contributor @vaklinov has begun hosting a list of wallets here: https://zcashblog.wordpress.com/zcash-gui-wallets/.

+

We have not yet written down our thoughts about the privacy consequences of using Zcash via third-party service providers. For the time being, you could probably just simplify by assuming that when you use a third-party service provider, the metadata about your transactions will be visible to others — at least to that provider and probably also to others who can see the transactions associated with your address, in the blockchain.

+

However, if the people you are transacting with use Zcash’s shielded addresses, then that may give you a degree of privacy even if you are not yet using shielded addresses yourself. We will write more to explain the way this works in the future.

+
+

WALLETS

+
+
Cockpit UI Wallet - https://github.com/hellcatz/zcash-cli-cockpit
+
From the Cockpit site, “This wallet allows users to access their ZCash wallet remotely via a Web UI. This makes it ideal for managing multiple systems mining ZCash. The complete information on how to install the ZCash Cockpit UI Wallet may be found on GitHub.”
+

+
Desktop GUI Wallet - https://github.com/vaklinov/zcash-swing-wallet-ui
+
From an official representative, “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.”
+

+
Jaxx - https://jaxx.io/
+
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.”
+

+
TREZOR - http://bitcointrezor.com/
+
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.”
+

+
Waterhole GUI mobile wallet - https://waterhole.io/
+
From the waterhole.io site, “This is a trading platform and a wallet provider for multiple crypto-currencies. It already supports ZCash.”
+
+
+ +
+

EXCHANGES

+
+
Bitfinex - https://www.bitfinex.com/
+
From the Bitfinex website: “This is one of the leading cryptocurrency exchanges, and the world’s largest exchange by volume for trading bitcoin against the US Dollar.”
+

+
Bittrex - https://bittrex.com/
+
From the Bittrex website, “Based and fully regulated in the USA, Bittrex is the go-to spot for traders who demand lightning fast trade execution, stable wallets, and industry-best security practices.”
+

+
Bitnow - https://bitnow.co.nz/
+
New Zealand
+

+
Bitsquare - https://bitsquare.io/bitsquare.pdf
+
From the Bitsquare whitepaper, “This is an open source peer-to-peer application that allows anyone to buy and sell Bitcoin in exchange to national currencies or alternative crypto currencies.”
+

+
Changelly - https://changelly.com/
+
From a Changelly representative, “Changelly is an instant cryptocurrency exchange.”
+

+
HitBTC - https://hitbtc.com/
+
From an HitBTC representative, “This is a global platform dealing with virtual currencies, providing advanced exchange and clearing technologies. HitBTC is operated by Beta Business Solutions Inc.”
+

+
Kraken - https://www.kraken.com/
+
From the Kraken website, “Mainly a Euro and US Dollar exchange for Bitcoin and Litecoin, but also offers markets for several other cryptocurrencies and fiat currencies.”
+

+
Poloniex - https://poloniex.com/
+
From the Poloniex website, “A US-based cryptocurrency exchange offering maximum security and advanced trading features, trading in numerous virtual currencies, including Bitcoin, Ethereum, Litecoin and Dogecoin.”
+

+
ShapeShift - https://shapeshift.io
+
From a ShapeShift representative, “This is a crucial piece of infrastructure in the world of Bitcoin. From start to finish, users can exchange blockchain tokens in seconds, with no account required. No emails or passwords. No lengthy sign up process. No accounts. No bid and ask orders. No friction. ShapeShift's goal is the fastest, safest, and most convenient way to swap digital assets.
+

+
YUNBI - https://yunbi.com
+
From the YUNBI website, “Formerly Peatio Exchange, YUNBI is an open source cryptocurrency exchange cofunded by BitFundPE.”
+
+

There are many more discussions open on the Forum. Join the community to contribute and participate!

+

If you are interested in providing external support by creating a wallet or supporting Zcash on your exchange, please view the Zcash Integration Guide, and contact info@z.cash to reach a real-live human for further discussion. If you want favorite exchange or wallet to support Zcash, we encourage you to reach out to them and ask!

+
\ No newline at end of file diff --git a/_posts/2016-10-31-state-of-the-network-2016-10-31.md b/_posts/2016-10-31-state-of-the-network-2016-10-31.md new file mode 100644 index 0000000..f5ba7a7 --- /dev/null +++ b/_posts/2016-10-31-state-of-the-network-2016-10-31.md @@ -0,0 +1,36 @@ +--- +ID: 1636 +post_title: State of the Network +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/state-of-the-network-2016-10-31/ +published: true +post_date: 2016-10-31 00:00:00 +--- +

The launch of Zcash 1.0 “Sprout” worked! The blockchain is live. Mining and transactions are working. This is a brief round-up of news from the network.

+

I found this explorer that shows recent blocks, transactions, and statistics. (I have no idea who runs it, and they, of course, don't require our permission to set up such a service. That's just one example of the permissionless innovation that permeates cryptocurrencies.)

+

There is one known bug, which causes private transactions (those in which all of the inputs and outputs are shielded addresses) to not get mined. We're going to release v1.0.1 shortly to fix it. In the meantime, if you're running a miner, please add blockminsize=300000 to your zcash.conf and restart your miner. You can track the progress on this at issue #1705.

+

There was a brief DDoS attack yesterday. Our web site (https://z.cash) was down for a bit while we engaged DDoS defenses. You should be aware of our security page on which we'll log such events.

+

The supply of ZEC units began at zero on October 28, and it is currently around 1900 ZEC. Currently every block (which arrives, on average, every two and a half minutes) adds about 1.2 ZEC to the supply. However, the amount of newly-generated ZEC which comes in every block is increasing. Therefore, not only is the supply growing, but it is growing faster and faster over time. Here's a graph of the rate at which the supply is increasing during the first couple of months:

+
+ZEC distribution rate for first 30,000 blocks

ZEC distribution rate for first 30,000 blocks

+
+

So in a few weeks, the supply will be increasing at a rate of 12.5 ZEC per block, compared to the current rate of 1.2 ZEC per block. This mechanism — the rate of ZEC creation being lower at the beginning — is called Mining Slow Start.

+

And here is a graph of the total supply over the first couple of months:

+
+Total ZEC distributed for first 30,000 blocks

Total ZEC distributed for first 30,000 blocks

+
+

So in a few weeks the total supply will be around 125,000 ZEC, compared to the current supply of 1900 ZEC.

+

Here is a graph of the total supply over the first half year:

+
+Total ZEC distributed for first 190,000 blocks

Total ZEC distributed for first 190,000 blocks

+
+

So in about half a year, the total supply will be around 1,250,000 ZEC.

+

(Historical note: these graphs are from our blog post of October 14.)

+

The first 500 or so blocks came out much faster than one block per two-and-a-half minutes. This is because the amount of mining power that was applied in the first couple of hours was much higher than we anticipated, and the difficulty adjustment algorithm needs a series of time measurements of blocks before it can kick in.

+

Fortunately, Mining Slow Start means that the first 500 blocks generated only 78 ZEC out of the 1900 ZEC that have been generated so far.

+

The Founders' Reward (which is going to eventually — after four years — amount to 2,100,000 ZEC) is built into the source code. You can see the addresses that the Founders' Reward will be sent to. You can also use the aforementioned block explorer to see the history of the first such address, which (as of the time of this writing) shows that no Zcash has yet been moved out of the Founders' Reward address.

+

No individual, including me (Zooko), is getting more than 0.5% of the total supply of ZEC, or about 105,000 ZEC, once the entire Founders' Reward has been distributed. (Previously mentioned in our blog post Continued Funding and Transparency.)

+

Okay, that's the round-up! Stay tuned for more exciting announcements. ☺

\ No newline at end of file diff --git a/_posts/2016-11-03-new-release-minor-bugfixes.md b/_posts/2016-11-03-new-release-minor-bugfixes.md new file mode 100644 index 0000000..c2e6a8b --- /dev/null +++ b/_posts/2016-11-03-new-release-minor-bugfixes.md @@ -0,0 +1,21 @@ +--- +ID: 1604 +post_title: 'New Release: 1.0.1' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-release-minor-bugfixes/ +published: true +post_date: 2016-11-03 00:00:00 +--- +

Today we're announcing the release of Zcash 1.0.1, which fixes a few bugs and improves diagnostics:

+
  1. Fixed a bug where transactions that contain shielded payments were not being mined in some circumstances. (#1718)
    2. +
  2. Invalid arguments passed when building JoinSplits now produce more descriptive errors. (#1752)
    3. +
  3. Added new RPC call, z_validateaddress (#1748)
    4. +
  4. The friendly metrics screen has improved accuracy and additional information. (#1735)
    5. +
  5. A consensus rule improperly applied to the genesis block was adjusted. (#1754)
    6. +
  6. fetch-params.sh has been improved and is included in the gitian build. (#1758, #1759)
    7. +
  7. A checkpoint was added for block 2500. (#1750)
    8. +

We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information.

+

For a more complete list of changes, see our 1.0.1 github milestone. To follow our progress, watch the GitHub project and join the forum.

\ No newline at end of file diff --git a/_posts/2016-11-07-new-release-fix-joinsplits.md b/_posts/2016-11-07-new-release-fix-joinsplits.md new file mode 100644 index 0000000..fd74d58 --- /dev/null +++ b/_posts/2016-11-07-new-release-fix-joinsplits.md @@ -0,0 +1,22 @@ +--- +ID: 1603 +post_title: 'New Release: 1.0.2' +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-release-fix-joinsplits/ +published: true +post_date: 2016-11-07 00:00:00 +--- +

Today we're announcing the release of Zcash 1.0.2 which fixes a bug that prevented creating transactions to multiple shielded recipient addresses. This is an implementation bug in the zcashd wallet which does not impact the consensus protocol.

+

The list of changes included in this release:

+
  1. We fixed a bug to ensure that JoinSplit transactions to multiple z-addresses will succeed. (#1790)
    2. +
  2. We changed z_sendmany to check if the size of a transaction for a given number of outputs will be valid. (#1808)
    3. +
  3. We fixed a bug that could crash the miner when it was interrupted. (#1778)
    4. +
  4. Community contributors helped improve our documentation. (#1765, #1763)
    5. +

We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information.

+

For a more complete list of changes, see our 1.0.2 github milestone. To follow our progress, watch the GitHub project and join the forum.

+
+

Background

+

JoinSplits encapsulate zero-knowledge value transfer and have two private inputs and two private outputs. Multiple JoinSplits may be chained into a single transaction in order to spend more than two private inputs and/or send to more than two private outputs. The order of inputs and outputs can be a subtle information leak to private recipients (see #778). A patch to fix this information leak (#1561) in our 1.0.0-rc2 release randomizes the input and output orderings, but in doing so failed to permute the necessary commitment witnesses in the same manner as the private inputs. In this release we’ve temporarily disabled input/output order randomization (#1790).

\ No newline at end of file diff --git a/_posts/2016-11-15-founders-reward-transfers.md b/_posts/2016-11-15-founders-reward-transfers.md new file mode 100644 index 0000000..9cf8282 --- /dev/null +++ b/_posts/2016-11-15-founders-reward-transfers.md @@ -0,0 +1,60 @@ +--- +ID: 1562 +post_title: 'Founders’ Reward Transfers' +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/founders-reward-transfers/ +published: true +post_date: 2016-11-15 00:00:00 +--- +

With the Zcash launch of October 28th, 2016, a couple weeks behind us, and a couple of bugfix releases out, we're beginning to turn our focus to the coming year. The last lingering task to complete our MVP goal is to begin the Founders' Reward transfers.

+

We will begin initiating transfers of the Founders' Reward funds sometime on or after November 28th, 2016, a month after our launch. Recipients of the Founders' Reward may independently use these funds as they see fit. Additionally the end of the mining slow start is predicted to be roughly around the same time after which the rate of ⓩ production over time will become constant for approximately the following four years.

+
+

Background

+

The rest of this post presents a technical background on the Founders' +Reward and the Miners' Reward, and how the mining slow start +interacts with them. Finally, some of the links provided allow you to +observe up-to-date details for these kinds of funds.

+

For further background, please see our prior blog posts:

+
+

Monetary Base and Founders' Reward

+

The Founders' Reward is the cornerstone of our funding and developer incentives model, and allocates 10% of all tokens created to a Founders' Reward fund, with the remaining 90% allocated to miners eventually.

+
+Zcash Distribution

Source: Continued Funding and Transparency

+
+

The 10% of the total supply that makes up the Founders' Reward is distributed between launch and the first halving (at block 850,000). During this period (which will last approximately four years), half of the total monetary base will be generated. After the first halving, there will be no more Founders' Reward, and all newly-created ⓩ will be received by miners. The following figure shows the monetary base and Founders' Reward plotted over time:

+
+Founders Reward Graph

Source: Funding

+
+
+
+

Block Subsidies

+

When a new valid block is discovered, the special coinbase transaction is permitted to create new ⓩ tokens according to the monetary base growth schedule. The total number of ⓩ created per block in this beginning stage of the network follow the slow start rule: for the first 20,000 blocks, the number of ⓩ grows linearly from 0 ⓩ towards 12.5 ⓩ (which is approximately ~34 days). Thus the 20,000th block is the first block with a 12.5 ⓩ subsidy. As of this writing we are around block 11034, or about 55% through the slow-start period. This figure shows the rate per block as a function of block height:

+
+ZEC distribution rate for first 30,000 blocks

ZEC distribution rate for first 30,000 blocks. Source: User Expectations at Sprout Pt. 1: Slow-Start Mining & Mining Ecosystem

+
+

This block subsidy is split between the Miners' Reward (80%) and the Founders' Reward (20%) during the halving interval. After that the entire block subsidy will go to the Miners' Reward. You can see an example by viewing any coinbase transaction, such as this example from block 8086:

+
  • Address t1XepX38RxS3o5hLioLbaNb6Fa2Y2Be55xw, the miner's address, receives 4.0431 ⓩ, and
    • +
  • Address t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd, which collects the Founders' Reward, receives 1.01075 ⓩ.
    • +
+
+

Founders' Reward Addresses

+

The miner's address is chosen by the miner at the time they created the block, whereas the founders' Reward address, t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd seen above, is specified in the consensus rules (specifically in this source code). Throughout the approximately four years of Founders' Reward distribution, the specific addresses used will change, a measure to improve our operational security.

+

You can see that as of this writing (around block 8775), no funds have moved from the Founders' Reward address t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd (link to zcha.in explorer). Once we begin transfering funds out of that address, the URL should reflect those transfers out.

+
+
+
+

Conclusion

+

Once Founders' Reward transfers begin, on or around November 28th, and the slow start completes the Zcash network will be in the basic post-launch steady state. We designed the Founders' Reward as the best practical structure to make Zcash a reality, both in its launch and it's continued evolution. We're avidly preparing for that evolution!

+
+

Resources

+

To learn about the current public state of Founders' Reward funds or Miners' reward funds, you can use the following resources:

+

Note: The last two links are to the zcha.in explorer which is not operated by the Zcash Company. Any blockchain explorer will provide the same information.

. \ No newline at end of file diff --git a/_posts/2016-11-17-new-release-1-0-3.md b/_posts/2016-11-17-new-release-1-0-3.md new file mode 100644 index 0000000..d7cbd67 --- /dev/null +++ b/_posts/2016-11-17-new-release-1-0-3.md @@ -0,0 +1,22 @@ +--- +ID: 1593 +post_title: 'New Release: 1.0.3' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-3/ +published: true +post_date: 2016-11-17 00:00:00 +--- +

Today we're announcing the release of Zcash 1.0.3 which fixes several crashes and security bugs, improves performance, and adjusts relay policies.

+

We strongly recommend users and miners update to this version, as it fixes a cache invalidation bug that could be used by an attacker to disrupt the network. (See #1874.)

+

Other changes in this release include:

+
  1. We fixed a bug that caused the wallet to crash during startup in some situations, such as when the wallet is not synchronized properly with the blockchain. (#1858)
    2. +
  2. We re-enabled note randomization that was temporarily disabled in 1.0.2. (#1814)
    3. +
  3. We adjusted fee policies to reflect changes made in Bitcoin Core and encourage relaying of transactions containing JoinSplits. (#1855)
    4. +
  4. We improved diagnostics and strengthened testing for the merkle tree's interaction with the constraint system. (#1797)
    5. +
  5. We disabled RPC keepalive features temporarily to avoid deadlocks. (#1847)
    6. +
  6. We adjusted our use of the libsnark verification API to improve zk-SNARK verification performance by 10%. (#1760, stats)
    7. +
  7. We changed the error message format for z_sendmany so that amounts are displayed in units of ZEC. (#1838)
    8. +

We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information.

+

For a more complete list of changes, see our 1.0.3 github milestone. To follow our progress, watch the GitHub project and join the forum.

\ No newline at end of file diff --git a/_posts/2016-11-18-the-zcash-equihash-analysis.md b/_posts/2016-11-18-the-zcash-equihash-analysis.md new file mode 100644 index 0000000..9a5b3d4 --- /dev/null +++ b/_posts/2016-11-18-the-zcash-equihash-analysis.md @@ -0,0 +1,29 @@ +--- +ID: 1642 +post_title: The Zcash Equihash Analysis +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/the-zcash-equihash-analysis/ +published: true +post_date: 2016-11-18 00:00:00 +--- +As we announced back in August, we commissioned two security audits of the Zcash codebase and an analysis of our proof-of-work algorithm. We published the two security audits shortly before Zcash’s launch. Today, we are pleased to share the analysis from Solar Designer of the Zcash Equihash proof-of-work scheme. + +

Solar Designer’s Report

+Report URL: http://www.openwall.com/articles/Zcash-Equihash-Analysis +
+
Solar’s summary:
+
+

“I was tasked with analyzing Zcash’s choice and use of the Equihash proof-of-work scheme, including its potential for future optimizations on both commodity and custom hardware. Also in-scope were the choice of and potential changes to Equihash parameters that Zcash uses.

+

“A conclusion is that while Equihash is not among the most ASIC-resistant known PoW schemes, its choice by Zcash may pose a reasonable tradeoff considering Zcash’s multiple goals and depending on which properties of the PoW turn out to be actually most important to users of Zcash. Another conclusion is that Zcash’s current n=200, k=9 Equihash parameters are suboptimal and may need to be changed.”

+
+
+ +

Related Work

+In addition to the analysis presented here, Solar Designer is one of three judges evaluating the first Zcash Mining Competition, which we announced previously on this blog. + +The Zcash Company dev team and community are using this analysis, the mining competition, and input from the community to inform potential future proposals to change the consensus protocol. If you’re interested in contributing please join the #zcash-miner-dev community chat channel. + +To keep up in general with the Zcash Company, read this blog, follow our @zcashco Twitter handle, and join our forum. \ No newline at end of file diff --git a/_posts/2016-11-22-security-announcement-2016-11-22.md b/_posts/2016-11-22-security-announcement-2016-11-22.md new file mode 100644 index 0000000..2ee45e9 --- /dev/null +++ b/_posts/2016-11-22-security-announcement-2016-11-22.md @@ -0,0 +1,75 @@ +--- +ID: 1617 +post_title: Security Announcement 2016-11-22 +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/security-announcement-2016-11-22/ +published: true +post_date: 2016-11-22 00:00:00 +--- +Synopsis: A cache invalidation bug may allow an attacker to trigger a chain fork causing pre-1.0.3 nodes to follow an invalid chain. A fix is implemented in zcashd release 1.0.3. + +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 only when two conditions are met simultaneously: +
    +
  1. They rely on zcashd releases older than 1.0.3, including 1.0.0, 1.0.1, and 1.0.2, AND
    2. +
  2. A network-wide attack is executed to trigger a chain fork. This requires a majority of miners to run vulnerable software.
    3. +
+Users who rely on third party services should inquire if those services have mitigated this issue. 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 meet either of the following two conditions are not at risk: +
    +
  1. they have upgraded to zcashd 1.0.3, or rely on a service which has done so, OR
    2. +
  2. no network-wide attack has succeeded (for example, because a sufficient portion of miners have mitigated the vulnerability).
    3. +
+In other words: individuals and services are protected as soon as they upgrade, and the entire network is protected as soon as a sufficient portion of miners upgrade. + +How can at-risk users protect themselves? +
    +
  1. Upgrading to zcashd release 1.0.3 is the most certain protection.
    2. +
  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.3. If it hasn't, consider pausing use of that service until they announce an upgrade.
    3. +
+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 a network attack is successfully executed (which requires a majority of mining capacity to be vulnerable) then only users running vulnerable clients will follow a chain fork that is invalid. Transactions on that fork will be rolled back as more miners upgrade to the valid fork. + +Technical Background: Due to a cache invalidation bug, some nodes on the Zcash network will accept particular invalid transactions as valid [1]. If a majority of the network hashrate accepts an invalid transaction as valid, there could be a chain fork. + +Followup Announcements: +
    +
  • See the security notifications page for further updates on this issue, and any future security issue.
    • +
  • Continue to check this blog.
    • +
+ + + + + + + +
[1]Note that transaction validity is well specified by our protocol specification, Zcash protocol specification, v2016.0-beta-1.10; It is unambiguous that this security flaw is an implementation bug.
\ No newline at end of file diff --git a/_posts/2016-11-23-anatomy-of-zcash.md b/_posts/2016-11-23-anatomy-of-zcash.md new file mode 100644 index 0000000..35d01ac --- /dev/null +++ b/_posts/2016-11-23-anatomy-of-zcash.md @@ -0,0 +1,43 @@ +--- +ID: 1541 +post_title: Anatomy of A Zcash Transaction +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/anatomy-of-zcash/ +published: true +post_date: 2016-11-23 00:00:00 +--- +

Since the successful launch of the Zcash network on October 28th, we've had an outpouring of interest from miners and users who want to take advantage of the confidentiality and privacy properties enabled in the protocol. When sending or receiving ZEC, the added choice of using shielded or transparent addresses is an important factor for those users. Understanding how these two types are used in a transaction is a suitable place to start to make the most informed choices.

+
+

The Building Blocks of A Transaction

+

The user-facing building blocks of a Zcash transaction can be broken down into sending and receiving addresses, account balances and transaction fees. More complex transaction components are explored in our protocol specification so we'll avoid those concepts for now. For sending to shielded addresses, an additional “memo field” component is available but that will be a topic for a future post.

+
+A high-level skeleton diagram of a Zcash transaction

A high-level view of a Zcash transaction

+
+

The diagram above shows the process of sending and receiving ZEC as part of a transaction. The use of shielded addresses - whether sending or receiving - requires the generation of a zero-knowledge proof which allows others to verify a transaction's encrypted data without it being revealed. (More detail on how this works will be discussed in an upcoming post on the inner workings of transactions between shielded addresses.) These addresses always start with a “z” and are sometimes referred to as “z-addrs”. Similarly, the use of transparent addresses require interaction with what is known as a “Transparent Value Pool” (or TVP) and publicly reveals transaction data. These addresses always start with a “t” and are sometimes referred to as “t-addrs”. The transaction fee also passes through the TVP and is therefore always visible on the blockchain. Even though fees are always revealed in a transaction, shielded addresses and value are not affected as shown in the following real Zcash transaction.

+
+A screenshot from Zchain block explorer showing sending ZEC between shielded addresses

A screenshot from the Zchain block explorer of a transaction between shielded addresses

+
+
+
+

Change Addresses

+

Like other blockchain protocols, spending from a balance in an address requires sending all of the balance. Therefore, unless you want to send the exact balance to another party, you must split the balance by including a second receiving address you control to accept any balance change. It is possible to simply use the sending address as the change address to prevent the added management of multiple addresses. This, however, is not normally recommended since it would be trivial for someone to build an identity profile based off of transactions sent to and from that single public address. Creating a new address for each transaction has become recommended standard practice in order to obfuscate a user's transactions. Since public transactions link sending and receiving addresses, however, this level of obfuscation is still quite trivial to navigate around and does not provide a meaningful level of privacy.

+

Thankfully, when sending ZEC from a shielded address, that data is kept private so sending change back to the sending address is permissible. In Zcash, all transactions between shielded addresses look identical so the reuse of shielded addresses is not vulnerable in the same way that transparent addresses are.

+
+
+

Sending Between Shielded and Transparent Addresses

+
+A diagram showing differences between sending ZEC to and from shielded and transparent addresses

Properties of sending ZEC between shielded and transparent addresses

+
+

In Zcash, ZEC is the balance unit for how much value an address contains. It differs from purely public blockchain currencies in that a ZEC balance has a different set of properties depending on what address type it is currently held in and the previous address(es) it was sent from. If ZEC is held in a transparent address, its unspent balance is publicly viewable. Regardless of that balance being sent to one or more transparent addresses, shielded addresses or a combination of these types, the output ZEC from a transparent address will be visible. A benefit of sending transparent ZEC to a shielded address is breaking the linkability between future transparent addresses if that's where it ends up again. The action of shielding ZEC is particularly important at these early stages where many wallets (such as mobile wallets) may not yet support shielded addresses due to the resource requirements as explained in a previous blog post on user expectations for hardware and software limitations.

+
+A screenshot from Zchain block explorer showing sending ZEC from a transparent address to a shielded address

A screenshot from the Zchain block explorer of a transaction shielding ZEC

+
+

In the transaction above where a transparent address sends to a shielded address, you can see that this process of shielding ZEC reveals the balance sent and that it is held by shielded addresses. The shielded addresses involved and whether it was sent to one or two shielded addresses remains confidential.

+

To contrast, a ZEC balance in a shielded address keeps the balance and account address private. If spending to one or more shielded addresses, the value stays private but any transparent addresses on the receiving end will deshield the ZEC and reveal the value received on the blockchain. When deshielding ZEC, the input shielded addresses and whether the value was sent from one or two of these remains confidential.

+
+
+

Further Notes on More Complex Transactions and Privacy Implications

+

It should be noted that these examples do not detail the properties of more complex transactions where both transparent and shielded addresses are sending or receiving. With this overview on the basic properties of addresses and spending ZEC balances, however, users can hopefully gain a better perspective on how the transactions work when transacting between any two addresses. Expect future posts on the inner workings of shielded addresses, further considerations on linkability and privacy implications, and details on the more complex transactions. We are eager to promote shielded addresses to improve stats on their use. While transactions involving shielded addresses require more resources than those with strictly transparent addresses, the improved privacy provided when using them is a clear benefit for financial freedom and is the core improvement Zcash brings as a cryptocurrency.

+
\ No newline at end of file diff --git a/_posts/2016-11-29-zcash-private-transactions.md b/_posts/2016-11-29-zcash-private-transactions.md new file mode 100644 index 0000000..be98459 --- /dev/null +++ b/_posts/2016-11-29-zcash-private-transactions.md @@ -0,0 +1,123 @@ +--- +ID: 1660 +post_title: > + How Transactions Between Shielded + Addresses Work +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/zcash-private-transactions/ +published: true +post_date: 2016-11-29 00:00:00 +--- +In 'Anatomy of A Zcash Transaction' we gave a general overview of Zcash Transactions. The purpose of this post is to provide a simplified explanation of how privacy-preserving transactions work in Zcash, and where exactly Zero-Knowledge proofs come into the picture. In the terminology of that post, we are focusing exclusively here on transactions between shielded addresses (commonly referred to as z-addrs). + +To focus on understanding the privacy-preserving aspect, let's put aside everything having to do with reaching consensus using Proof of Work and the blockchain, and focus on a particular node that has obtained the correct list of unspent transaction outputs. + +Let's recall first how this list looks on the bitcoin blockchain. Each unspent transaction output (UTXO) can be thought of as an unspent 'note' that is described by the address/public key of its owner and the amount of BTC it contains. For simplicity of presentation, let's assume each such note contains exactly 1 BTC, and there is at most one note per address. Thus, at a given time, a node's database consists of a list of unspent notes, where each note can be described simply by the address of the owner. For example, the database may look like this. + +:math:`\mathsf{Note}_1=` :math:`(\mathsf{PK}_1)`, :math:`\mathsf{Note}_2=` :math:`(\mathsf{PK}_2)`, :math:`\mathsf{Note}_3=` :math:`(\mathsf{PK}_3)` + +Suppose :math:`\mathsf{PK}_1` is Alice's address and she wishes to send her 1 BTC note to Bob's address :math:`\mathsf{PK}_4.` She sends a message which essentially says "Move 1 BTC from :math:`\mathsf{PK}_1` to :math:`\mathsf{PK}_4`" to all nodes. She signs this message with the secret key :math:`\mathsf{sk}_1` corresponding to :math:`\mathsf{PK}_1,` and this convinces the node she has the right to move money from :math:`\mathsf{PK}_1.` After the node checks the signature, and checks that there is indeed a 1 BTC note with address :math:`\mathsf{PK}_1,` it will update its database accordingly: + +:math:`\mathsf{Note}_4=` :math:`(\mathsf{PK}_4)`, :math:`\mathsf{Note}_2=` :math:`(\mathsf{PK}_2)`, :math:`\mathsf{Note}_3=` :math:`(\mathsf{PK}_3)` + +Now suppose each note also contains a random 'serial number' (aka unique identifier) :math:`r.` We will soon see this is helpful for obtaining privacy. Thus, the database may look like this. + +:math:`\mathsf{Note}_1=` :math:`(\mathsf{PK}_1,r_1)`, :math:`\mathsf{Note}_2=` :math:`(\mathsf{PK}_1,r_1)`, :math:`\mathsf{Note}_3=` :math:`(\mathsf{PK}_2,r_2)` + +A natural first step towards privacy would be to have the node store only "encryptions", or simply hashes, of the notes, rather than the notes themselves. + +:math:`\mathsf{H}_1=` :math:`\mathbf{HASH}(\mathsf{Note}_1)`, :math:`\mathsf{H}_2=` :math:`\mathbf{HASH}(\mathsf{Note}_2)`, :math:`\mathsf{H}_3=` :math:`\mathbf{HASH}(\mathsf{Note}_3)` + +As a second step to preserve privacy, the node will continue to store the hash of a note even after it has been spent. Thus, it is no longer a database of unspent notes, but rather a database of all notes that ever existed. + +The main question now is how to distinguish, without destroying privacy, between notes that have been spent and notes that haven't. This is where the nullifier set comes in. This is a list of hashes of all serial numbers of notes that have been spent. Each node stores the nullifier set, in addition to the set of hashed notes. For example, after :math:`\mathsf{Note}_2` has been spent, the node's database might look like this. + + + + + + + + + + + + + + + + + + + + + +
Hashed notesNullifier set
:math:`\mathsf{H}_1=` :math:`\mathbf{HASH}(\mathsf{Note}_1)`:math:`\mathsf{nf}_1=` :math:`\mathbf{HASH}(\mathsf{r}_2)`
:math:`\mathsf{H}_2=` :math:`\mathbf{HASH}(\mathsf{Note}_2)`
:math:`\mathsf{H}_3=` :math:`\mathbf{HASH}(\mathsf{Note}_3)`
+

How a transaction is made

+Now suppose Alice owns :math:`\mathsf{Note}_1` and wishes to send it to Bob, whose public key is :math:`\mathsf{PK}_4.` We will assume for simplicity that Alice and Bob have a private channel between them although this is not actually necessary in Zcash. Basically, Alice will invalidate her note by publishing its nullifier, and at the same time create a new note that is controlled by Bob. + +More precisely, she does the following. +
    +
  1. She randomly chooses a new serial number :math:`r_4` and defines the new note :math:`\mathsf{Note}_4=` :math:`(\mathsf{PK}_4,r_4).`
    2. +
  2. She sends :math:`\mathsf{Note}_4` to Bob privately.
    3. +
  3. She sends the nullifier of :math:`\mathsf{Note}_1,` :math:`\mathsf{nf}_2=` :math:`\mathbf{HASH}(\mathsf{r}_1)` to all nodes.
    4. +
  4. She sends the hash of the new note :math:`\mathsf{H}_4=,` :math:`\mathbf{HASH}(\mathsf{Note}_4)` to all nodes.
    5. +
+Now, when a node receives :math:`\mathsf{nf}_2` and :math:`\mathsf{H}_4,` it will check whether the note corresponding to :math:`\mathsf{nf}_2` has already been spent, simply by checking if :math:`\mathsf{nf}_2` already exists in the nullifier set. If it doesn't, the node adds :math:`\mathsf{nf}_2` to the nullifier set and adds :math:`\mathsf{H}_4` to the set of hashed notes; thereby validating the transaction between Alice and Bob. + + + + + + + + + + + + + + + + + + + + + + + + + +
Hashed notesNullifier set
:math:`\mathsf{H}_1=` :math:`\mathbf{HASH}(\mathsf{Note}_1)`:math:`\mathsf{nf}_1=` :math:`\mathbf{HASH}(\mathsf{r}_2)`
:math:`\mathsf{H}_2=` :math:`\mathbf{HASH}(\mathsf{Note}_2)`:math:`\mathsf{nf}_2=` :math:`\mathbf{HASH}(\mathsf{r}_1)`
:math:`\mathsf{H}_3=` :math:`\mathbf{HASH}(\mathsf{Note}_3)`
:math:`\mathsf{H}_4=` :math:`\mathbf{HASH}(\mathsf{Note}_4)`
+..but wait a second, we checked that :math:`\mathsf{Note}_1` wasn't spent before.. but we didn't check whether it belongs to Alice. Actually, we didn't check that it was a 'real' note at all, real in the sense that its hash was in the node's table of hashed notes. The simple way to fix this would be for Alice to simply publish :math:`\mathsf{Note}_1,` rather than its hash; but of course, this would undermine the privacy we are trying to achieve. + +This is where Zero-Knowledge proofs come to the rescue: + +In addition to the steps above, Alice will publish a proof-string :math:`\pi` convincing the nodes that whomever published this transaction knows values :math:`\mathsf{PK}_1,` :math:`\mathsf{sk}_1,` and :math:`r_1` such that +
    +
  1. +
      +
    1. The hash of the note :math:`\mathsf{Note}_1=` (:math:`\mathsf{PK}_1,` :math:`r_1)` exists in the set of hashed notes.
      2. +
    2. :math:`\mathsf{sk}_1` is the private key corresponding to :math:`\mathsf{PK}_1` (and thus, whomever knows it is the rightful owner of :math:`\mathsf{Note}_1`).
      3. +
    3. The hash of :math:`r_1` is :math:`\mathsf{nf}_2`, (and thus, if :math:`\mathsf{nf}_2` - that we now know is the nullifier of :math:`\mathsf{Note}_1` - is not currently in the nullifier set, :math:`\mathsf{Note}_1` still hasn't been spent).
      4. +
    +
    2. +
+The properties of Zero-Knowledge proofs will ensure no information about :math:`\mathsf{PK}_1,` :math:`\mathsf{sk}_1,` or :math:`r_1` are revealed by :math:`\pi`. +

The main places above where we cheated or omitted details

+We emphasize that this has been an oversimplified description, and recommend the protocol spec for full details. + +Here are some of the main things that were overlooked: +
    +
  1. +
      +
    1. The hashed notes need to be stored not just as a list, but in a Merkle tree. This plays an important role in making the Zero-Knowledge proofs efficient. Moreover, we need to store a computationally hiding and binding commitment of the note, rather than just its hash.
      2. +
    2. The nullifier needs to be defined in a slightly more complex way to ensure future privacy of the receiver in relation to the sender.
      3. +
    3. We did not go into details on how to eliminate the need for a private channel between sender and recipient.
      4. +
    +
    2. +
\ No newline at end of file diff --git a/_posts/2016-12-03-open-source-miner-winners.md b/_posts/2016-12-03-open-source-miner-winners.md new file mode 100644 index 0000000..4bad665 --- /dev/null +++ b/_posts/2016-12-03-open-source-miner-winners.md @@ -0,0 +1,22 @@ +--- +ID: 1608 +post_title: > + Announcing the Winners of the Open + Source Miner Challenge! +author: Liz Steininger +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/open-source-miner-winners/ +published: true +post_date: 2016-12-03 00:00:00 +--- +

A few months ago, we launched the Zcash Open Source Miner Challenge and today we are announcing the winners:

+

The judges: Jack Grigg, Solar Designer, and Dmitry Khovratovich, selected these submissions as the Winners and Runners Up based on the criteria, which included many factors of quality, community contributions, and performance.

+

The Zcash Company sponsored this challenge to help strengthen and decentralize the Zcash community, as well as contribute to the advancement of computer science. Least Authority, as a supporter of the Zcash Company, operated this challenge.

+

The Zcash Open Source Miner Challenge has made mining for ZEC accessible to more people and facilitated collaboration within the Zcash community. While the code available is off to a good start, we encourage everyone to continue improving and building upon each other's work. The challenge website will transition to repository of these open source miners… And we may even do another challenge in the future!

\ No newline at end of file diff --git a/_posts/2016-12-05-encrypted-memo-field.md b/_posts/2016-12-05-encrypted-memo-field.md new file mode 100644 index 0000000..2c2cee7 --- /dev/null +++ b/_posts/2016-12-05-encrypted-memo-field.md @@ -0,0 +1,54 @@ +--- +ID: 1558 +post_title: The Encrypted Memo Field +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/encrypted-memo-field/ +published: true +post_date: 2016-12-05 00:00:00 +--- +

As of October 28, 2016, Zcash is a reality! Anybody with Internet access can download the software, connect to the global decentralized network, and send and receive payments, without exposing their confidential transaction metadata to the world.

+

Note: we have not yet created a user-friendly wallet. The software we're distributing is only for command-line-wielding Linux users. Fortunately many other individuals and companies have already stepped forward to provide graphical user interfaces.

+

This blog post is about a little-known but potentially valuable feature of this new protocol.

+
+

The Encrypted Memo Field

+

When you receive a Zcash payment from someone else's shielded address to a shielded address of your own, you see the amount of Zcash received, and you see the transaction ID, which allows you to identify this transaction (in its encrypted form) in the blockchain.

+

You don't learn anything about the sender or about the history of the money you're receiving, and you don't see the sender's address. This is by design — the sender should be able to send you money without necessarily revealing other information about themselves.

+

However, we realized that senders would sometimes need to communicate information about a specific payment. For example an invoice number or account number that the payment is for, an address to which any refunds should be sent, a note to the recipient, etc.

+

So we implemented an additional field that is visible to the recipient of a payment, called the “encrypted memo field”. It is always present in every encrypted payment, and is always exactly 512 bytes long. If a sender doesn't specify a memo, then the memo that is sent is all zeroes (before encryption), and if the sender includes a memo shorter than 512 bytes, then the remaining space is padded with zeroes (before encryption).

+

This padding is necessary for privacy, so that an observer watching the blockchain can't detect differences between different usage patterns of the encrypted memos. It also means that you don't pay a higher transaction fee for including a memo — the cost is already baked in.

+

The encrypted memo is visible only the to recipient, unless the transaction view key for the transaction gets shared (by the sender or the recipient) with a third party. In that case, the third party who received the transaction view key would be able to see the memo, along with the amount and the recipient address of the transaction in the blockchain. Transaction view keys are already present in the protocol, but are not yet supported in the API.

+
+
+

What Will People Do With This

+
+a memo field. Remember those?
+

We conceived of the encrypted memo field as being basically like the memo space at the bottom of old-fashioned paper checks, but lately we've been wondering: what else will people use this for?

+

Zcash is the first system which combines the append-only property of blockchains with the selective disclosure property of encryption. Using the memo field you can enter arbitrary data (as long as it fits into 512 bytes) into the global, decentralized Zcash blockchain, and your data will become part of the immutable and append-only ledger, but it will not be visible to anyone else — yet. If you later disclose the transaction view key to someone, then the data will become visible to them in the blockchain. If you were to post the transaction view key publicly, then the data would become visible to the public, still embedded in its original place in the blockchain.

+

Could this feature be useful for private messaging? Time-stamping? Public records such as land title registries? Securely storing and sharing confidential data such as health records or business records?

+

I really don't know if the encrypted memo field would be appropriate and effective for those purposes, but as of now, the feature is live and nothing can stop you from experimenting with it. If you do, please let me know what you learn!

+
+
+

Return Addresses

+

One of the more obvious uses for an encrypted memo field sent within a ZEC payment between shielded addresses is a return or refund address. Merchants may prompt their customers to include a refund address along with a payment in the chance that the product must be returned or a service canceled early. Since the memo isn't required to hold the address from which the payment was sent, this feature could even be used as a cryptographically secured gift receipt. If someone buys their sister a birthday gift from a merchant, the gift giver can include their sister's shielded payment address in the memo field and share the transaction ID with her which holds the encrypted transaction details. She won't know the value of the bracelet but if she finds it doesn't fit right, she can return the product to the merchant with the transaction ID, which the merchant can associate with the product and initiate a refund to the address provided in the memo field.

+
+
+

The Travel Rule

+

Another specific use that we had in mind was satisfying The Travel Rule. The Travel Rule is a regulation of FinCEN which states that when one financial institution is sending a transaction to another, the sending institution is required to include the identifying information of the customer on whose behalf they are making the payment. It's called the Travel Rule because the identifying information is required to travel with the payment, rather than just being delivered out of band or kept in a database. Financial institutions using Bitcoin (e.g. exchanges like Kraken and Poloniex) face difficulty satisfying this regulation, because you can't really include your customer's personal information in a globally-transparent blockchain!

+

With Zcash, a financial institution can satisfy that rule, by putting the customer's personal information into the encrypted memo. This makes it visible to the receiving financial institution, but not to unauthorized third parties.

+
+
+

Love Notes In The Blockchain

+

Recently a young woman told me that she had received an encrypted Zcash transaction, and in the memo field, she found a merkletree hash which pointed to a file in the IPFS distributed file system. Following that link, she found that the file was a ticket to a special event, overseas, that she and her distant lover had been talking about attending together.

+

The memo was a love note. A love note which is permanently embedded somewhere in the first few blocks of the Zcash blockchain, but which is visible only to two people. I think that is beautiful.

+
+
+

zmsg

+

Here's a simple program to put memos into the encrypted memo field and to read them out again (if you are the recipient of the enclosing transaction): zmsg

+
+
+

Endless possibilities

+

While the examples listed in this post highlight some of the exciting ways users, developers and merchants can use the encrypted memo field in Zcash payments, it is only the beginning. We encourage everyone to experiment with this feature and the tools being built around it. You can share your findings and ideas for cool hacks in our online community.

+
\ No newline at end of file diff --git a/_posts/2016-12-15-new-release-1-0-4.md b/_posts/2016-12-15-new-release-1-0-4.md new file mode 100644 index 0000000..1316372 --- /dev/null +++ b/_posts/2016-12-15-new-release-1-0-4.md @@ -0,0 +1,29 @@ +--- +ID: 1594 +post_title: 'New Release: 1.0.4' +author: Jack Grigg +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-4/ +published: true +post_date: 2016-12-15 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.4, which fixes several bugs, improves performance, and adjusts mining policies. With this release, private payments will get relayed and mined faster. + +Summary of the changes in this release: +
    +
  1. We fixed a cache invalidation bug that caused some orphaned blocks to trigger node crashes. (#1928)
    2. +
  2. We fixed a race condition that inhibited creation of multi-JoinSplit transactions. (#1911)
    3. +
  3. We adjusted mining policies to encourage inclusion of transactions containing JoinSplits. (#1895, #1902)
    4. +
  4. We improved rescan and reindex performance. (#1892, #1904)
    5. +
  5. We improved zk-SNARK verification performance by 7%. (#1919, stats)
    6. +
  6. We added additional well-formedness checks for JoinSplit proofs. (#1938)
    7. +
  7. We added a fee parameter to z_sendmany. (#1907)
    8. +
  8. We added a getlocalsolps RPC method for obtaining the mining rate without the metrics screen. (#1642)
    9. +
  9. The Bash completion files were updated to work with zcashd. (#1909)
    10. +
  10. The build scripts were extended to make porting Zcash to other platforms easier. (#1905)
    11. +
  11. A checkpoint was added at block height 15,000. (#1865)
    12. +
+We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. + +For a more complete list of changes, see our 1.0.4 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2017-01-11-future-friendly-fork.md b/_posts/2017-01-11-future-friendly-fork.md new file mode 100644 index 0000000..7c30287 --- /dev/null +++ b/_posts/2017-01-11-future-friendly-fork.md @@ -0,0 +1,21 @@ +--- +ID: 1564 +post_title: A Future Friendly Fork +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/future-friendly-fork/ +published: true +post_date: 2017-01-11 00:00:00 +--- +

See also a related post: Consensual Currency.

+

“Forks” (or “hard-forks”) are a highly contentious topic in cryptocurrencies. You can analyze a fork with two questions:

+
  • Does it result in two (persistent) separate branches of the original blockchain?
    • +
  • Does it result in community schism?
    • +

In principle, any of the four combinations of these two consequences could happen.

+

Interestingly, three out of four of these combinations have already occurred in practice!

+
+A diagram depicting whether a fork resulted in a persistent branch of the blockchain and a schism in the community
+

In the future, as the Zcash community grows, there may come a time when we need multiple, distinct technologies, each one building on a different branch of the original blockchain. This is likely to happen, because different technologies offer different trade-offs to their users, and some uses of Zcash might benefit more from one technology, while other uses may benefit more from a different, incompatible design.

+

I hope that, when that time comes, the Zcash community fills in the unoccupied space in the matrix above, deploying different technologies, well-fitted to different needs, but continuing to be tolerant and cooperative with one another, to the benefit of all.

\ No newline at end of file diff --git a/_posts/2017-01-19-zcash-eth.md b/_posts/2017-01-19-zcash-eth.md new file mode 100644 index 0000000..025db82 --- /dev/null +++ b/_posts/2017-01-19-zcash-eth.md @@ -0,0 +1,74 @@ +--- +ID: 1651 +post_title: > + An Update on Integrating Zcash on + Ethereum (ZoE) +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-eth/ +published: true +post_date: 2017-01-19 00:00:00 +--- +Members of the Ethereum R&D team and the Zcash Company are collaborating on a research project addressing the combination of programmability and privacy in blockchains. This joint post is being concurrently posted on the Ethereum blog, and is coauthored by Ariel Gabizon (Zcash) and Christian Reitwiessner (Ethereum). + +Ethereum’s flexible smart contract interface enables a large variety of applications, many of which have probably not yet been conceived. The possibilities grow considerably when adding the capacity for privacy. + +Imagine, for example, an election or auction conducted on the blockchain via a smart contract, such that the result can be verified by any observer of the blockchain, but the individual votes or bids are not revealed. Another setting is that of selective disclosure; for example, providing users the ability to prove they are in a certain city without disclosing their exact location. + +The key to adding such capabilities to Ethereum is zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs) - precisely the cryptographic engine underlying Zcash. + +One of the goals of the Zcash company, codenamed Project Alchemy, is to enable a direct decentralized exchange between Ethereum and Zcash. Connecting these two blockchains and teams, one focusing on programmability, and the other on privacy, seems the natural way to bring to life applications requiring both. + +As part of the Zcash/Ethereum-collaborative effort, Ariel Gabizon from Zcash visited Christian Reitwiessner from the Ethereum hub at Berlin a few weeks ago. The highlight of the visit is a proof of concept implementation of a zk-SNARK verifier written in Solidity, based on pre-compiled Ethereum contracts implemented for the Ethereum C++ client. This complements Baby ZoE where a zk-SNARK precompiled contract was written for Parity - the Ethereum Rust client. The difference is that we only added tiny cryptographic primitives (elliptic curve multiplication, addition and pairing) and did the rest in Solidity. This allows for a much greater flexibility and enables using a variety of zk-SNARK constructions without requiring a hard fork (see more details later on). We tested this code by successfully verifying a real privacy-preserving Zcash transaction, on a testnet of the Ethereum blockchain. The verification took only 42 milliseconds, which shows that such precompiled contracts can be added and the gas costs for using them can be made to be quite affordable. +
+

What can be done with such a system

+The Zcash system can be reused on Ethereum to create shielded custom tokens. Such tokens already allow many applications like voting (more on that later) or a simple auction where buyers do not learn the others’ bids. + +If you want to try compiling the proof of concept, you can use the following commands. If you need help, hop on to https://gitter.im/ethereum/privacy-tech +
git clone https://github.com/scipr-lab/libsnark.git
+
+cd libsnark
+sudo PREFIX=/usr/local make NO_PROCPS=1 NO_GTEST=1 NO_DOCS=1 CURVE=ALT_BN128 \
+   FEATUREFLAGS="-DBINARY_OUTPUT=1 -DMONTGOMERY_OUTPUT=1 -DNO_PT_COMPRESSION=1" \
+   lib install
+cd ..
+git clone --recursive -b snark https://github.com/ethereum/cpp-ethereum.git
+cd cpp-ethereum
+./scripts/install_deps.sh && cmake . -DEVMJIT=0 -DETHASHCL=0 && make eth
+cd ..
+git clone --recursive -b snarks https://github.com/ethereum/solidity.git
+cd solidity
+./scripts/install_deps.sh && cmake . && make soltest
+cd ..
+./cpp-ethereum/eth/eth --test -d /tmp/test
+# And on a second terminal:
+./solidity/test/soltest -t "*/snark" -- --ipcpath   /tmp/test/geth.ipc  --show-messages
+
+We also discussed various aspects of integrating zk-SNARKs into the Ethereum blockchain, on which we now expand. + +

Deciding what precompiled contracts to define

+Recall that a SNARK is a short proof of some property, and what is needed for adding the privacy features to the Ethereum blockchain is that clients have the ability to verify such a proof. + +In all recent constructions, the verification procedure consists solely of operations on elliptic curves. Specifically, the verifier requires scalar multiplication and addition on an elliptic curve group; but also, a heavier operation called a bilinear pairing. + +As mentioned here, implementing these operations directly in EVM is too costly. Thus, we want to implement pre-compiled contracts that perform these operations. Now, the question we debated was - what level of generality these pre-compiled contracts should aim for. + +The security level of the SNARK corresponds to the parameters of the curve. Roughly, the larger the curve order is, and the larger something called the embedding degree is, the more secure the SNARK based on this curve. On the other hand, naturally, the larger these quantities are, the more costly the operations on the corresponding curve. Thus, a contract designer using SNARKs may wish to choose these parameters according to their own desired efficiency/security tradeoff. This is one argument for implementing a pre-compiled contract with a high level of generality, where the contract designer can choose from a large family of curves. We indeed began by shooting for a high level of generality - where the description of the curve is given as part of the input to the contract. In such a case, a smart contract would be able, for example, to perform addition in any elliptic curve group. + +A complication with this approach is assigning gas cost to the operation - you must assess, merely from the description of the curve, and with no access to a specific implementation, how expensive a group operation on that curve would be (in the worst case). A somewhat less general approach is to allow all curves from a given family. We noticed that when working with the Barreto-Naehrig (BN) family of curves, one can assess roughly how expensive the pairing operation will be given the curve parameters, as all such curves support a specific kind of optimal Ate pairing. Here's a sketch of how such a precompile would work and how the gas cost would be computed. + +We learned a lot from this debate, but ultimately, decided to "keep it simple" for this proof of concept; and to implement contracts for operations on the specific curve currently used by Zcash. We did this by using wrappers of the corresponding functions in the libsnark library, also used by Zcash. We note that we could have simply used a wrapper for the entire SNARK verification function currently used by Zcash - as was done in the above mentioned Baby ZoE project. However, the advantage of explicitly defining elliptic curve operations is enabling using a wide variety of SNARK constructions, which, again, all have a verifier working by some combination of the three mentioned elliptic curve operations. + +

Reusing the Zcash setup for new anonymous tokens and other applications

+As you might have heard, using SNARKs requires a complex setup phase in which the so-called public parameters of the system are constructed. The fact that these public parameters need to be generated in a secure way every time we want to use a SNARK for a particular circuit significantly hinders the usability of SNARKs. (Simplifying this setup phase is an important goal that we gave some thought to but didn’t have any success in so far). + +On the other hand, the good news is that someone desiring to issue a token supporting privacy-preserving transactions can simply reuse the public parameters that have already been securely generated by Zcash. The reason for this is that the Zcash circuit which is used to verify privacy-preserving transactions is not inherently tied to one currency or blockchain. Rather, one of its explicit inputs is the root of a Merkle tree that contains all the valid notes of the currency; and so, this input can be changed according to the currency one wishes to work with. Moreover, if it is rather easy to start a new anonymous token, you can already accomplish many tasks that do not look like tokens at a first glance. For example, suppose we wish to conduct an anonymous election to choose a preferred option amongst two. We can issue an anonymous custom token for the vote, and send one coin to each voting party. Since there is no “mining”, it will not be possible to generate tokens in any other way. Now each such party sends their coin to one of two addresses according to their vote. The address with a larger final balance corresponds to the election result. + +

Other applications

+A non-token-based system that is rather simple to build allows for “selective disclosure”: You can, for example, constantly post an encrypted message containing your physical location to the blockchain (perhaps with other people’s signatures to prevent spoofing). If you use a different key for each message, you can reveal your location only at a certain time by revealing the key. With zk-SNARKs, though, you can prove that you were in a certain area without revealing where exactly you have been: Inside the zk-SNARK, you decrypt your location and show that it is inside the area. Because of the zero-knowledge property, everyone can verify that fact but nobody can retrieve your actual location. + +

The work ahead

+Truly achieving the mentioned functionalities - creating anonymous tokens and verifying Zcash transactions on the Ethereum blockchain, will require implementing other elements used by Zcash in Solidity. For the first, we must have an implementation of tasks performed by nodes on the Zcash network such as updating the note commitment tree. For the second, we need an implementation of the equihash proof of work algorithm used by Zcash in Solidity. Otherwise, transactions can be verified as valid in themselves, but we do not know whether the used notes existed on the Zcash blockchain or whether the transaction was actually sent to the Zcash blockchain. Fortunately, such an implementation was written; however, its efficiency needs to be improved in order to be used in practical applications. + +Acknowledgement: We thank Sean Bowe for technical assistance. We also thank Sean and Vitalik Buterin for helpful comments, and Ming Chan for editing. \ No newline at end of file diff --git a/_posts/2017-01-23-new-release-1-0-5.md b/_posts/2017-01-23-new-release-1-0-5.md new file mode 100644 index 0000000..d3ca223 --- /dev/null +++ b/_posts/2017-01-23-new-release-1-0-5.md @@ -0,0 +1,30 @@ +--- +ID: 1595 +post_title: 'New Release: 1.0.5' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-5/ +published: true +post_date: 2017-01-23 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.5, which includes a variety of bugfixes and usability improvements. + +Summary of the changes in this release: +
    +
  1. The chain is now fully rescanned when keys are imported that are older than the wallet. (#1978)
    2. +
  2. The number of commitments in the note commitment tree is now displayed by getblockchaininfo. (#1946)
    3. +
  3. zcash.conf now must exist in order to start zcashd. (#2013)
    4. +
  4. Fixed a bug where z_sendmany logged incorrect txid fragments when sending from transparent addresses. (#1980)
    5. +
  5. We integrated upstream's cookie-based RPC authentication. (#1999)
    6. +
  6. We added a restriction to wallet export paths to protect user security. (#2006)
    7. +
  7. z_getoperationstatus is now sorted chronologically. (#2015)
    8. +
  8. Messages containing newlines are now rendered properly by the metrics UI. (#1972)
    9. +
  9. We added more tools for benchmarking JoinSplit creation. (#1953)
    10. +
  10. We now show serialized transaction size in listtransactions, more operation details in z_getoperationstatus, and the age of the note being spent in z_sendmany logging. (#2001, #1976, #1977)
    11. +
  11. We now instruct users to run fetch-params if the parameters could not be found locally. (#1979)
    12. +
  12. We handle exceptions better in some situations for more user-friendly error messages. (#1976)
    13. +
+We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. + +For a more complete list of changes, see our 1.0.5 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2017-01-25-transaction-linkability.md b/_posts/2017-01-25-transaction-linkability.md new file mode 100644 index 0000000..e982359 --- /dev/null +++ b/_posts/2017-01-25-transaction-linkability.md @@ -0,0 +1,47 @@ +--- +ID: 1644 +post_title: Transaction Linkability +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/transaction-linkability/ +published: true +post_date: 2017-01-25 00:00:00 +--- +

Having the two types of addresses within Zcash (transparent and shielded) is an advantage which allows users to have more flexibility with how they store and transact ZEC. The dynamic between transparent and shielded addresses, however, presents a level of increased complexity for transactions containing both types (i.e. shielding ZEC by sending from a transparent to a shielded address or deshielding ZEC by sending from a shielded to a transparent address).

+

If all Zcash transactions used shielded addresses (which we hope will someday become the norm), then the complexities introduced with the two types of addresses disappear and privacy would strengthen for everyone in the ecosystem. Until then, understanding privacy implications such as transaction linking will be helpful for users interested in maintaining maximum control over the visibility of their transaction details.

+

This post will outline some privacy considerations while using Zcash with its current support for both transparent and shielded addresses and some solutions users can employ in such situations.

+
+

Where does Zcash introduce linkability?

+
+

Transparent Addresses

+

Knowing that transparent addresses publicly disclose transaction details on the Zcash blockchain, we can assume a degree of linkability between a string of transactions using this type of address, similar to the linkability seen in bitcoin transactions.

+

But what happens when shielded addresses are sprinkled into the mix? Thankfully, shielded addresses in Zcash indeed break linkability when used properly.

+
+Comparing transaction series: three transparent addresses vs a shielded address sandwiched between two transparent addresses

Shielded addresses can de-link transparent addresses [1]

+
+

The mere use of shielded addresses by merchants accepting ZEC payments and by your friends provides an increased level of privacy for you, too! In the above example, the transaction series where Bob uses a shielded address (b) breaks the link between Alice and Carol. To help understand these properties, we created the following transactions which mimic the examples above: Alice sends 15 ZEC (minus fee) to transparent Bob and transparent Bob sends 10 ZEC to Carol compared with Alice sends 15 ZEC (minus fee) to shielded Bob and shielded Bob sends 10 ZEC to Carol.

+

So even if you or your friends must use transparent addresses for one reason or another, others using shielded addresses (whether they mean to or not) break down the direct linkability that would otherwise exist with exclusively transparent addresses.

+
+
+

Linking Values

+

The above method where Bob de-links Alice and Carol simply by using a shielded address isn’t 100% reliable for every situation, however.

+

To explain why, let’s first highlight a property of transactions which include both address types: when transparent addresses shield ZEC (t → z) or when shielded addresses deshield ZEC (z → t), the values sent to or received from transparent addresses are public even though those values are masked in the shielded address part of the transaction. We can observe this property in the transaction series above where Bob uses a shielded address but the transparent addresses used by Alice and Carol still reveal the value sent and received.

+
+A diagram showing the possibile value linkability in a transaction series even when a shielded address is used in between transparent addresses

A shielded address might not protect against value linkability in some cases

+
+

Now, let’s consider the condition where Bob sends the full balance received from Alice to Carol and therefore has no change output. If Alice’s public output X and Carol’s public input Y are equal (or X equals Y minus two standard transaction fees) and that value is unique enough to other public values stored in the Zcash blockchain, there is a degree of association between Alice and Carol. You can see this example in the following transactions: Alice sends 15 ZEC (minus .0001 ZEC fee) to shielded Bob and shielded Bob sends 14.9999 ZEC (minus .0001 ZEC fee) to Carol.

+

Further, this association increases the closer in blocktime Alice’s public output and Carol’s public input are recorded. For example, in the above transactions, Alice sends ZEC to Bob in block number 50374 and Bob sends ZEC to Carol in block number 50378. This makes it easier to link the values than if Bob instead transacted with Carol in block number 111583.

+

To mitigate this, Bob should be aware when deshielding a value equal to one recently received from a transparent address. Zcash wallets might even consider implementing a feature to allow automatic detection of potential of linking past and future transactions when deshielding ZEC. [2]

+
+
+

Unique Transaction Fees

+

Another linking possibility regards the use of transaction fees. Most wallets use a standard fee to pay miners (.0001 ZEC). In a previous post covering basic Zcash transaction anatomy, we showed how fee outputs are always transparent even with shielded addresses. While this doesn’t reveal much to the public if a standard fee value is used, addresses which consistently pay unique fees could be linked.

+

The solution here is to simply use standard transaction fees!

+
+
+
+

Reducing Linkability By Reducing Complexity

+

While the advantages of supplying both transparent and shielded addresses to users allows for more options [3], there is no doubt that sending ZEC between them introduces complexities which affect individual’s financial privacy. The most concrete solution to avoiding transaction linkability is simply using and requesting others use shielded addresses, which in turn strengthens the community’s overall privacy. The Zcash core development team has priorities to support growth in shielded address use and call on third party services to consider ways which make shielded addresses easier to use as well. We’re just at the beginning of this exciting new ecosystem and are looking forward to seeing privacy for all strengthen over time.

+
[1]In transaction series b, we use a question mark to indicate the value received by Bob's shielded address even though it seems exactly 14.9999 ZEC would have been received. This is because it's possible that an additional shielded input and/or output was included in the transfer but we would not be able to see this on the blockchain.
[2]This value linkability is much more likely in situations where users are sending between their own addresses rather than between different users. In the example used, Alice and Bob might actually be the same person sending between their own transparent and shielded addresses.
[3]While shielded addresses offer the privacy features which distinguish Zcash from purely public blockchain networks, the transparent addresses provide (at least for now) a relief in resource requirements along with familiar functionality to previously launched cryptocurrencies.
\ No newline at end of file diff --git a/_posts/2017-02-13-new-release-1-0-6.md b/_posts/2017-02-13-new-release-1-0-6.md new file mode 100644 index 0000000..647f540 --- /dev/null +++ b/_posts/2017-02-13-new-release-1-0-6.md @@ -0,0 +1,28 @@ +--- +ID: 1596 +post_title: 'New Release: 1.0.6' +author: Simon Liu +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-6/ +published: true +post_date: 2017-02-13 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.6. This release focuses on improving functionality and usability of low-level interfaces used by external software interfacing with Zcash, and on bolstering several security components. + +Summary of the changes in this release: +
    +
  1. Users can now mine to a single address by using new zcashd options -mineraddress and -minetolocalwallet (#1965, #2081)
    2. +
  2. Updated RPC calls getrawtransaction and decoderawtransaction to display all fields of a JoinSplit. Now includes the zk-proof, ephemeral key, random seed and encrypted ciphertexts (#2054)
    3. +
  3. Updated logging in RPC call z_sendmany for the debug categories zrpc and zrpcunsafe (#2058)
    4. +
  4. Fixed a bug which prevented passing a fee parameter of zero to RPC call z_sendmany (#2068)
    5. +
  5. Added build option --disable-mining to zcutil/build.sh to allow removal of mining code when compiling (#1836)
    6. +
  6. ZeroMQ notification support has been backported (#2050)
    7. +
  7. Upgraded OpenSSL to 1.1.0d (#2051). We now also use libsodium’s CSPRNG instead of OpenSSL’s (#1706)
    8. +
  8. Backported and updated Univalue library to replace usage of json spirit library (#1990, #2082)
    9. +
  9. Removed unnecessary exceptions from libsnark (#2080)
    10. +
  10. Added zcashd option flag -experimentalfeatures (#2056), fixed a bug in a test (#2078) and updated documentation (#2069, #2077)
    11. +
+We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. + +For a more complete list of changes, see our 1.0.6 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2017-02-21-the-near-future-of-zcash.md b/_posts/2017-02-21-the-near-future-of-zcash.md new file mode 100644 index 0000000..b99dc1b --- /dev/null +++ b/_posts/2017-02-21-the-near-future-of-zcash.md @@ -0,0 +1,50 @@ +--- +ID: 1641 +post_title: The Near Future of Zcash +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/the-near-future-of-zcash/ +published: true +post_date: 2017-02-21 00:00:00 +--- +

Our Mission is to make Zcash the premier platform for commerce — secure, borderless, and available equally to every person on our planet. We believe that Zcash can do for resource sharing and coordination what the Internet did for communication.

+
+

the story so far

+

Zcash first launched on October 28, 2016. During the first few months of its life, we focused on stabilization and incremental improvement.

+

We delivered a series of improvements (the “Zcash Sprout” series of releases) which fix bugs and improve usability based on iterative feedback from our lovely users. Our users are the best! ❤

+

At the same time, we've been monitoring and supporting the continuous reliable operation of the global Zcash network. So far, the network has experienced zero downtime, and no security breaches.

+

Now we are announcing our development priorities for the next stage of Zcash's growth.

+ +
+
+

stability

+

Our first and second priorities will always be:

+
  1. Security and reliability, and
    2. +
  2. Iterative improvement in response to demand from our users.
    3. +

We will continue to vigilantly guard the security of the system, support our users, and deliver regular stable releases as we have been doing.

+
+
+

innovation

+

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

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

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

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

  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)

    +
    6. +

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.

+
+Zcash Sprout to Sapling logo transition
+
+
+

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.

+
\ No newline at end of file diff --git a/_posts/2017-02-24-hash-functions.md b/_posts/2017-02-24-hash-functions.md new file mode 100644 index 0000000..5d33428 --- /dev/null +++ b/_posts/2017-02-24-hash-functions.md @@ -0,0 +1,19 @@ +--- +ID: 1568 +post_title: History of Hash Function Attacks +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/hash-functions/ +published: true +post_date: 2017-02-24 00:00:00 +--- +

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 invulnerable to collision attacks is much safer than one that is vulnerable to collision attacks (regardless of whether it is vulnerable to pre-image 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.

+
+chronological view of collision attacks +
+

Thanks to Andreas Hülsing, Samuel Neves, and Zcash engineer Daira Hopwood for their input on this investigation.

\ No newline at end of file diff --git a/_posts/2017-02-28-shielded-ecosystem.md b/_posts/2017-02-28-shielded-ecosystem.md new file mode 100644 index 0000000..4f8c431 --- /dev/null +++ b/_posts/2017-02-28-shielded-ecosystem.md @@ -0,0 +1,32 @@ +--- +ID: 1622 +post_title: A Shielded Ecosystem +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/shielded-ecosystem/ +published: true +post_date: 2017-02-28 00:00:00 +--- +

In Zcash, users have the option to employ transparent or shielded addresses for sending, receiving and storing their ZEC. While this decision might initially seem like a choice that only affects the visibility of a single user’s personal finances, the greater ecosystem is affected by the overall trend of users choosing one or the other. In our Transaction Linkability blog post, we explained how a user's financial privacy is strengthened by the use of shielded addresses by friends and businesses they transact with. This post explains why an increase in shielded address use supports overall ecosystem privacy.

+
+

Strength In Numbers and Diversity

+

To better understand the ecosystem-wide effects of shielding in Zcash, first consider the more common privacy practice of mailing documents and letters in envelopes. The documents on their own are a set of unique objects but once sealed inside an envelope, look relatively similar to other mailed documents.

+

Now, imagine a world where most people mail non-sensitive messages on postcards and save the masking feature of envelopes for more classified information such as tax and bank documents. Even though the contents of the more sensitive documents remain sealed in envelopes, the smaller set of envelopes and narrowed use-case makes envelopes an easier target for someone like an identity thief on the hunt for personal information. The decreased use of envelopes for non-sensitive correspondence creates a higher chance that envelopes will contain classified information and a higher rate of success for bad actors.

+

Now compare that to the current world where people use envelopes for a wider range of purposes, even mundane correspondences. The increased quantity of sealed messages forms a larger set of similar-looking objects, when in fact, their contents are diverse. This might force an identity thief to reconsider their risk to reward ratio for targeting envelopes.

+
+
+

Shielding The Zcash Ecosystem

+

In the Zcash ecosystem, the number of shielded addresses and diversity of use has a similar effect on the ability to analyze sensitivity of transactions.

+
+A depiction of a transaction graph with a smaller number of shielded addresses
+

When a smaller number of shielded addresses are used in transactions, the diversity of use is limited. So in a situation where the value held in shielded addresses is 50% of all ZEC but the number of shielded addresses is 10%, then it's relatively trivial to assume that shielded addresses on average have a higher balance, making them a higher target for attempts at theft. This smaller shielded set can also provide an easier time for an observer of the Zcash blockchain to build identity profiles for users of shielded addresses. Public data like the timestamps associated with transactions sent from shielded addresses is one way that those users might be at risk for loss of privacy.

+
+A depiction of a transaction graph with a larger number of shielded addresses
+

On the other hand, in a Zcash ecosystem with a larger set of transactions between shielded addresses, analysis of those transactions and the individuals behind them is less effective. Even better, if all Zcash users employ shielded addresses including for the more mundane purchases, then a bad actor’s rationale to attempt a targeted attack for theft or profiling becomes unreliable.

+
+
+

A Community Effort For A Shielded Ecosystem

+

Thankfully, unlike other methods by cryptocurrencies to provide user privacy, all shielded addresses look the same to observers of the Zcash blockchain, and therefore the quantity of shielded addresses in use directly correlates to the privacy of the ecosystem as a whole. At the time of this post, the number of Zcash transactions involving a shielded address is just above 29%, however the number of fully shielded transactions (strictly between shielded addresses) is a subset of this. Fortunately, this percentage has been moving in an upward trend.

+

As development continues and the ecosystem grows, we expect the above percentage to continue to rise in addition to the subset of fully shielded transactions. Support for shielded addresses in third-party services will be an important factor to this growth. Core development to reduce resource requirements and improve usability of shielded addresses is another key component towards a larger privacy pool and thriving shielded ecosystem. We continue to encourage the community to utilize shielded addresses for sending and receiving ZEC to strengthen the privacy for everyone.

+
\ No newline at end of file diff --git a/_posts/2017-02-28-snark-explain.md b/_posts/2017-02-28-snark-explain.md new file mode 100644 index 0000000..b40b201 --- /dev/null +++ b/_posts/2017-02-28-snark-explain.md @@ -0,0 +1,66 @@ +--- +ID: 1624 +post_title: 'Explaining SNARKs Part I: Homomorphic Hidings' +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/snark-explain/ +published: true +post_date: 2017-02-28 00:00:00 +--- +Constructions of zk-SNARKs involve a careful combination of several ingredients; fully understanding how these ingredients all work together can take a while. + +If I had to choose one ingredient whose role is most prominent, it would be what I will call here Homomorphic Hiding (HH) [1]. In this post we explain what an HH is, and then give an example of why it is useful and how it is constructed. + +An HH :math:`E(x)` of a number :math:`x` is a function satisfying the following properties: +
    +
  • For most :math:`x`'s, given :math:`E(x)` it is hard to find :math:`x.`
    • +
  • Different inputs lead to different outputs - so if :math:`x\neq y,` then :math:`E(x)\neq E(y).`
    • +
  • If someone knows :math:`E(x)` and :math:`E(y),` they can generate the HH of arithmetic expressions in :math:`x` and :math:`y.` For example, they can compute :math:`E(x+y)` from :math:`E(x)` and :math:`E(y).`
    • +
+Here's a toy example of why HH is useful for Zero-Knowledge proofs: Suppose Alice wants to prove to Bob she knows numbers :math:`x,y` such that :math:`x+y=7` (Of course, it's not too exciting knowing such :math:`x,y,` but this is a good example to explain the concept with). +
    +
  1. Alice sends :math:`E(x)` and :math:`E(y)` to Bob.
    2. +
  2. Bob computes :math:`E(x+y)` from these values (which he is able to do since :math:`E` is an HH).
    3. +
  3. Bob also computes :math:`E(7),` and now checks whether :math:`E(x+y)=E(7).` He accepts Alice's proof only if equality holds.
    4. +
+As different inputs are mapped by :math:`E` to different hidings, Bob indeed accepts the proof only if Alice sent hidings of :math:`x,y` such that :math:`x+y=7.` On the other hand, Bob does not learn :math:`x` and :math:`y,` as he just has access to their hidings [2]. + +Now let's see an example of how such hidings are constructed. We actually cannot construct them for regular integers with regular addition, but need to look at finite groups: + +Let :math:`n` be some integer. When we write :math:`A\;\mathrm{mod}\;n` for an integer :math:`A,` we mean taking the remainder of :math:`A` after dividing by :math:`n.` For example, :math:`9\;\mathrm{mod}\; 7 = 2` and :math:`13\; \mathrm{mod}\;12 = 1.` We can use the :math:`\mathrm{mod}\; n` operation to define an addition operation on the numbers :math:`\{0,\ldots,n-1\}:` We do regular addition but then apply :math:`(\mathrm{mod}\; n)` on the result to get back a number in the range :math:`\{0,\ldots,n-1\}.` We sometimes write :math:`(\mathrm{mod}\; n)` on the right to clarify we are using this type of addition. For example, :math:`2+3 = 1\; (\mathrm{mod} \;4).` We call the set of elements :math:`\{0,\ldots,n-1\}` together with this addition operation the group :math:`\mathbb{Z}_n`. + +For a prime :math:`p`, we can use the :math:`\mathrm{mod}\;p` operation to also define a multiplication operation over the numbers :math:`\{1,\ldots,p-1\}` in a way that the multiplication result is also always in the set :math:`\{1,\ldots,p-1\}` - by performing regular multiplication of integers, and then taking the result :math:`\mathrm{mod}\;p.` [3] For example, :math:`2\cdot 4=1\; (\mathrm{mod}\; 7).` + +This set of elements together with this operation is referred to as the group :math:`\mathbb{Z}_p^*`. :math:`\mathbb{Z}_p^*` has the following useful properties: +
    +
  1. It is a cyclic group; which means that there is some element :math:`g` in :math:`\mathbb{Z}_p^*` called a generator such that all elements of :math:`\mathbb{Z}_p^*` can be written as :math:`g^a` for some :math:`a` in :math:`\{0,..,p-2\}`, where we define :math:`g^0=1.`
    2. +
  2. The discrete logarithm problem is believed to be hard in :math:`\mathbb{Z}_p^*`. This means that, when p is large, given an element :math:`h` in :math:`\mathbb{Z}_p^*` it is difficult to find the integer :math:`a` in :math:`{0,..,p-2}` such that :math:`g^a=h\;(\mathrm{mod}\;p).`
    3. +
  3. As ''exponents add up when elements are multiplied'', we have for :math:`a,b` in :math:`{0,..,p-2}` :math:`g^a\cdot g^b = g^{a+b\;(\mathrm{mod}\;p-1)}.`
    4. +
+Using these properties, we now construct an HH that ''supports addition'' - meaning that :math:`E(x+y)` is computable from :math:`E(x)` and :math:`E(y).` We assume the input :math:`x` of :math:`E` is from :math:`\mathbb{Z}_{p-1}`, so it is in the range :math:`\{0,\ldots,p-2\}.` We define :math:`E(x)=g^x` for each such :math:`x`, and claim that :math:`E` is an HH: The first property implies that different :math:`x`'s in :math:`\mathbb{Z}_{p-1}` are mapped to different outputs. The second property implies that given :math:`E(x)=g^x` it is hard to find :math:`x`. Finally, using the third property, given :math:`E(x)` and :math:`E(y)` we can compute :math:`E(x+y)` as :math:`E(x+y) = g^{x+y\;\mathrm{mod}\; p-1} = g^x\cdot g^y = E(x)\cdot E(y).` + + + + + + + +
[1]Homomorphic hiding is not a term formally used in cryptography, and is introduced here for didactic purposes. It is similar to but weaker than the well-known notion of a computationally hiding commitment. The difference is that an HH is a deterministic function of the input, whereas a commitment uses additional randomness. As a consequence, HHs essentially ''hide most x's'' whereas commitments ''hide every x''.
+ + + + + + + +
[2]Bob does learn some information about x and y. For example, he can choose a random x', and check whether x=x' by computing E(x'). For this reason the above protocol is not really a Zero-Knowledge protocol, and is only used here for explanatory purposes. In fact, as we shall see in later posts, HH is ultimately used in snarks to conceal verifier challenges rather than prover secrets.
+ + + + + + + +
[3]When p is not a prime it is problematic to define multiplication this way. One issue is that the multiplication result can be zero even when both arguments are not zero. For example when p=4, we can get 2*2=0 (mod 4).
+

Part II >>

\ No newline at end of file diff --git a/_posts/2017-03-06-new-release-1-0-7.md b/_posts/2017-03-06-new-release-1-0-7.md new file mode 100644 index 0000000..c1b87ff --- /dev/null +++ b/_posts/2017-03-06-new-release-1-0-7.md @@ -0,0 +1,26 @@ +--- +ID: 1597 +post_title: 'New Release: 1.0.7' +author: Jay Graber +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-7/ +published: true +post_date: 2017-03-06 00:00:00 +--- +

Today we're announcing the release of Zcash 1.0.7. This release focuses on updating Zcash to be compatible with upstream changes, fixing bugs, and adding alerts, tests, and checkpoints.

+
+

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 should be sure to update their version to 1.0.7, or a chain fork may occur as a result of these changes.

+

Summary of the changes in this release:

+
  1. Pull in upstream changes related to testing, the RPC interface, as well as others. (#2099, #2100, #2101)
    2. +
  2. Keep a record of alerts sent to mainnet. (#2093)
    3. +
  3. Pause mining during joinsplit creation. (#1932)
    4. +
  4. Fix bug in testnet and update Founder’s Reward addresses. (#2114)
    5. +
  5. Large shielded transactions using the default fee are no longer treated as "free" transactions. (#2141)
    6. +
  6. Improve auto-generated manpages. (#2124)
    7. +
  7. Add checkpoint on testnet and mainnet. (#2128, #2126)
    8. +

We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information.

+

Testnet users must upgrade to 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.

+

For a more complete list of changes, see our 1.0.7 GitHub milestone. To follow our progress, watch the GitHub project and join the forum.

+
\ No newline at end of file diff --git a/_posts/2017-03-08-r3-blockchain-report.md b/_posts/2017-03-08-r3-blockchain-report.md new file mode 100644 index 0000000..cf2e5c1 --- /dev/null +++ b/_posts/2017-03-08-r3-blockchain-report.md @@ -0,0 +1,17 @@ +--- +ID: 1612 +post_title: 'R3 Report on Confidentiality & Privacy for Blockchains' +author: Jack Gavigan +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/r3-blockchain-report/ +published: true +post_date: 2017-03-08 00:00:00 +--- +

Last year, R3 commissioned us to co-author (along with Danny Yang, founder of blockchain analytics company Blockseer) 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 Corda and JP 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.

\ No newline at end of file diff --git a/_posts/2017-03-11-new-snark-curve.md b/_posts/2017-03-11-new-snark-curve.md new file mode 100644 index 0000000..ade4606 --- /dev/null +++ b/_posts/2017-03-11-new-snark-curve.md @@ -0,0 +1,51 @@ +--- +ID: 1605 +post_title: 'BLS12-381: New zk-SNARK Elliptic Curve Construction' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-snark-curve/ +published: true +post_date: 2017-03-11 00:00:00 +--- +Our team is continually working to improve the security, performance and usability of our privacy-preserving shielded transactions. As we mentioned in our near 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. +
The BLS12-381 curve.
+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-friendly elliptic curve constructions built over a base field :math:`\mathbb{F}_q` of order :math:`r`, where :math:`r \approx q`. Our current curve construction has :math:`q \approx 2^{254}`. 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 :math:`q \approx 2^{384}`. However, the larger group order :math:`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 :math:`\mathbb{F}_r` 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 :math:`q \approx 2^{384}`, and with an embedding degree of 12, these curves target the 128-bit security level. Conveniently, the group order for these curves is :math:`r \approx 2^{256}`, which allows us to avoid the performance and usability drawbacks that accompany a larger scalar field. +

BLS12-381

+In zk-SNARK schemes, we need to manipulate very large polynomials over the scalar field :math:`\mathbb{F}_r`. We can perform efficient multi-point evaluation/interpolation with fast fourier transforms, so long as we ensure :math:`\mathbb{F}_r` is equipped with a large :math:`2^s` 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 :math:`r \approx 2^{255}` so that the most significant bit of :math:`r` (and :math:`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 :math:`q \approx 2^{381}`. + +
+
u = -0xd201000000010000
+
k = 12
+
q = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
+
r = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001
+
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 pairing library. 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. + + + + + + + + +
[1]Menezes, 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.)
\ No newline at end of file diff --git a/_posts/2017-03-13-snark-explain2.md b/_posts/2017-03-13-snark-explain2.md new file mode 100644 index 0000000..2857d08 --- /dev/null +++ b/_posts/2017-03-13-snark-explain2.md @@ -0,0 +1,64 @@ +--- +ID: 1625 +post_title: 'Explaining SNARKs Part II: Blind Evaluation of Polynomials' +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/snark-explain2/ +published: true +post_date: 2017-03-13 00:00:00 +--- +<< Part I + +In this post, we recall the notion of a polynomial, and explain the notion of "blind evaluation" of a polynomial, and how it is implemented using Homomorphic Hiding (HH). (See Part I for an explanation of HH. ) In future posts, we will see that blind evaluation is a central tool in SNARK constructions. + +We denote by :math:`\mathbb{F}_p` the field of size :math:`p`; that is, the elements of :math:`\mathbb{F}_p` are :math:`\{0,\ldots,p-1\}` and addition and multiplication are done :math:`\mathrm{mod}\;p` as explained in Part I. +

Polynomials and linear combinations

+Recall that a polynomial :math:`P` of degree :math:`d` over :math:`\mathbb{F}_p` is an expression of the form + +:math:`P(X) = a_0 + a_1\cdot X + a_2\cdot X^2 + \ldots + a_d\cdot X^d` + +, for some :math:`a_0,\ldots,a_d\in\mathbb{F}_p.` + +We can evaluate :math:`P` at a point :math:`s\in {\mathbb{F}_p}` by substituting :math:`s` for :math:`X`, and computing the resultant sum + +:math:`P(s) = a_0 + a_1\cdot s + a_2\cdot s^2 + \ldots + a_d\cdot s^d` + +For someone that knows :math:`P,` the value :math:`P(s)` is a linear combination of the values :math:`1,s,\ldots,s^d` - where linear combination just means "weighted sum", in the case of :math:`P(s)` the "weights" are :math:`a_0,\ldots,a_d.` + +In the last post, we saw the HH :math:`E` defined by :math:`E(x)=g^x` where :math:`g` was a generator of a group with a hard discrete log problem. We mentioned that this HH "supports addition" in the sense that :math:`E(x+y)` can be computed from :math:`E(x)` and :math:`E(y)`. We note here that it also "supports linear combinations"; meaning that, given :math:`a,b,E(x),E(y),` we can compute :math:`E(ax+by)`. This is simply because + +:math:`E(ax+by)=g^{ax+by}=g^{ax}\cdot g^{by} = (g^x)^a\cdot (g^y)^b = E(x)^a\cdot E(y)^b.` +

Blind evaluation of a polynomial

+Suppose Alice has a polynomial :math:`P` of degree :math:`d`, and Bob has a point :math:`s\in\mathbb{F}_p` that he chose randomly. Bob wishes to learn :math:`E(P(s))`, i.e., the HH of the evaluation of :math:`P` at :math:`s.` Two simple ways to do this are: +
    +
  • Alice sends :math:`P` to Bob, and he computes :math:`E(P(s))` by himself.
    • +
  • Bob sends :math:`s` to Alice; she computes :math:`E(P(s))` and sends it to Bob.
    • +
+However, in the blind evaluation problem we want Bob to learn :math:`E(P(s))` without learning :math:`P` - which precludes the first option; and, most importantly, we don't want Alice to learn :math:`s`, which rules out the second [1]. + +Using HH, we can perform blind evaluation as follows. +
    +
  1. Bob sends to Alice the hidings :math:`E(1),E(s),\ldots,E(s^d).`
    2. +
  2. Alice computes :math:`E(P(s))` from the elements sent in the first step, and sends :math:`E(P(s))` to Bob. (Alice can do this since :math:`E` supports linear combinations, and :math:`P(s)` is a linear combination of :math:`1,s,\ldots,s^d.)`
    3. +
+Note that, as only hidings were sent, neither Alice learned :math:`s` [2], nor Bob learned :math:`P`. +

Why is this useful?

+Subsequent posts will go into more detail as to how blind evaluation is used in SNARKs. The rough intuition is that the verifier has a "correct" polynomial in mind, and wishes to check the prover knows it. Making the prover blindly evaluate their polynomial at a random point not known to them, ensures the prover will give the wrong answer with high probability if their polynomial is not the correct one. This, in turn, relies on the Schwartz-Zippel Lemma stating that "different polynomials are different at most points". + + + + + + + +
[1]The main reason we don't want to send :math:`P` to Bob, is simply that it is large - (d+1) elements, where, for example, d~2000000 in the current Zcash protocol; this ultimately has to do with the "Succinct" part of SNARKs. It is true that the sequence of hidings Bob is sending to Alice above is just as long, but it will turn out this sequence can be "hard-coded" in the parameters of the system, whereas Alice's message will be different for each SNARK proof.
+ + + + + + + +
[2]Actually, the hiding property only guarantees :math:`s` not being recoverable from :math:`E(s)`, but here we want to claim it is also not recoverable from the sequence :math:`E(s),\ldots,E(s^d)` that potentially contains more information about :math:`s`. This follows from the d-power Diffie-Hellman assumption, which is needed in several SNARK security proofs.
+Part III >> \ No newline at end of file diff --git a/_posts/2017-03-17-announcing-the-zcash-foundation.md b/_posts/2017-03-17-announcing-the-zcash-foundation.md new file mode 100644 index 0000000..cf988c2 --- /dev/null +++ b/_posts/2017-03-17-announcing-the-zcash-foundation.md @@ -0,0 +1,20 @@ +--- +ID: 1544 +post_title: Announcing the Zcash Foundation +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/announcing-the-zcash-foundation/ +published: true +post_date: 2017-03-17 00:00:00 +--- +

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 initial Board 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's Hello World blog post to see their initial plans and how you can get involved and help make Zcash live up to its potential!

\ No newline at end of file diff --git a/_posts/2017-03-20-spinning-off-our-sibling-company.md b/_posts/2017-03-20-spinning-off-our-sibling-company.md new file mode 100644 index 0000000..48331fd --- /dev/null +++ b/_posts/2017-03-20-spinning-off-our-sibling-company.md @@ -0,0 +1,24 @@ +--- +ID: 1633 +post_title: Spinning Off Our Sibling Company +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/spinning-off-our-sibling-company/ +published: true +post_date: 2017-03-20 00:00:00 +--- +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 Ethereum and several other successful security audits (CryptoCat, GlobalLeaks, SpiderOak, 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.) \ No newline at end of file diff --git a/_posts/2017-03-23-zsl.md b/_posts/2017-03-23-zsl.md new file mode 100644 index 0000000..2d6f3c3 --- /dev/null +++ b/_posts/2017-03-23-zsl.md @@ -0,0 +1,91 @@ +--- +ID: 1664 +post_title: 'ZSL: zk-SNARKs for the Enterprise' +author: Jack Gavigan +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zsl/ +published: true +post_date: 2017-03-23 00:00:00 +--- +The Zerocoin Electric Coin Company’s primary focus is - and always will be - developing and supporting Zcash. + +However, as a startup that needs to generate revenue in order to survive, it would be remiss of us to ignore the potential revenue stream represented by the enterprise market for distributed ledger technology (DLT), which has generated intense interest from a range of industry sectors, including financial services, healthcare, and sectors that seek to benefit from the full potential of connected and IoT-enabled devices. + +There are a plethora of potential use cases for blockchain technology where confidentiality and privacy are prerequisites, for a variety of reasons, ranging from standard commercial confidentiality to legal and regulatory requirements. In the US, the Gramm-Leach-Bailey Act mandates privacy for consumer financial information, and the HIPAA security rule establishes a standard for protecting individuals’ personal health information; the EU’s Data Protection Directive (soon to be replaced by the General Data Protection Regulation) mandates that personal data must be protected from unauthorised disclosure; and commercial confidentiality requirements transcend both borders and industries. + +We believe that Zcash’s privacy-preserving technology can meet many of the confidentiality and privacy requirements for enterprise distributed ledgers. + +To understand how the technology that underpins Zcash can meet these types of requirements, it helps to understand Zcash’s architecture. +
+

Zcash’s Layered Architecture

+On the Bitcoin blockchain, creating a valid transaction involves proving three things: +
    +
  1. that the coins have not been spent previously,
    2. +
  2. that the Sender is authorised to transfer “ownership” of the coins in question, and
    3. +
  3. that the transaction’s inputs equal its outputs.
    4. +
+Proof that the coins have not been spent previously is obtained from the ledger itself, and requires no effort by the Sender. + +The Sender proves ownership of the coins he wants to transfer by digitally signing the transaction using the secret key that corresponds to the address that currently holds the coins. To allow this signature to be verified, the Sending address must be disclosed. In turn, the Recipient will only be able to spend the coins, if his address is also disclosed. + +With Bitcoin, verifying that the transaction’s inputs equal its outputs is trivial because the amount being transferred is disclosed. +
A high-level skeleton diagram of a Bitcoin transaction
+Zcash uses zero-knowledge proofs (specifically, zk-SNARKs) to prove the same three facts, without revealing any information about the Sender, Recipient or the assets that are being transferred. Each valid transaction is accompanied by a zk-SNARK which proves that: the Input assets exist and have not been spent previously, the creator of the transaction has authority to spend the Input assets, and the quantity and type of the Inputs equals the quantity and type of the Outputs. + +The information required to spend the Outputs (by creating a new zk-SNARK) is attached to the transaction, encrypted using the Recipient’s public key, and can only be used by the Recipient. +
A high-level skeleton diagram of a zero-knowledge proof transaction
+The result is effectively a new type of distributed ledger, which we call the zero-knowledge security layer, or ZSL. + +Zcash is an implementation of ZSL, using a fork of the Bitcoin codebase to enable transparent transactions. +
A high-level skeleton diagram of a Zcash transaction
+In building Zcash, we could have implemented ZSL by itself (i.e. without support for transparent transactions) but we believe that users were more likely to be comfortable with a cryptocurrency that also supports the sort of transparent transactions they’re already familiar with. Enabling Bitcoin-style transparent transactions also makes it simple to integrate with Zcash using existing tools and infrastructure that were built to support Bitcoin. + +ZSL can be layered on top of any distributed ledger solution, adding support for shielded transactions to the underlying ledger’s featureset. However, it does not automatically follow that all of the underlying ledger’s functionality will benefit from the added privacy and confidentiality. For example, integrating ZSL with the Ethereum codebase would make it possible to use shielded transactions to protect users’ privacy, but smart contracts would still need to be executed transparently. We are still in the early stages of researching how programmability can be implemented within ZSL in an efficient manner. + +ZSL can also be integrated with any consensus mechanism; instead of proof of work, an enterprise ledger could use round-robin, proof of stake, or new consensus mechanisms like Tendermint. It could even be integrated into a MySQL database, where a schema plugin requires valid proofs for table inserts but the database administrator cannot see account balances. + +This approach gives a huge amount of flexibility when it comes to enterprise use cases. It means that confidentiality and privacy can be achieved while maintaining fungibility of the digital assets being transacted, without compromising the fully-decentralised nature of the distributed ledger. This is a key advantage over privacy techniques that use traditional encryption to protect transaction details - fungibility of the assets transferred in such transactions can only be achieved if the details of past transactions are revealed to the next recipient (which compromises confidentiality and privacy), or if a trusted third party is used to verify the validity of transactions (which compromises the fully-decentralised nature of a distributed ledger). + +Another advantage of the layered architecture is that it allows us to focus on what we do best. We’re a small company, and we plan to remain tightly focused on developing innovative cryptographic technologies (as opposed to building a full enterprise distributed ledger solution). By delivering those technologies as an “add-on” layer, we can partner with solution providers to offer end users zk-SNARKs-based confidentiality and privacy on their DLT platform of choice. + +At the risk of sounding clichéd, we want to grow the pie through collaboration instead of competing for as big a slice as possible. + +
+
+

Improving Zcash’s (and ZSL’s) functionality

+Zcash has already set the gold standard for privacy but we’re not resting on our laurels. We recently announced our development priorities for 2017, including support for user-issued tokens (which will allow anyone to issue and transact digital assets on the Zcash platform with the same confidentiality and privacy that protects ZEC transactions) and cross-chain interoperability with Bitcoin and Ethereum, which will allow users to exchange ZEC for bitcoins and ether without the need to go through a centralised exchange. + +Our primary objective in developing these features is to enhance Zcash’s utility for its early adopters and attract new users. However, there’s also a key side-benefit: these features are also of use to potential enterprise users. + +The Payment Disclosure feature we’re working on is the first step towards allowing users to disclose details of their shielded transactions to a third party, while keeping them secret from everyone else. For Zcash, this can be used to create the equivalent of a payment receipt, to help resolve disputes and troubleshoot problems. For enterprise use cases, it can also be leveraged to enable users to give a third party such as an auditor, regulator or arbitrator the ability to view the details of specific transactions (or be able to monitor all their transactions, in real-time), while keeping them confidential from other blockchain users. + +Adding support for User-Issued Tokens to ZSL will enable the dynamic issuance and trading of different digital assets on the same blockchain. This has obvious applications in the financial sector, which is already exploring the use of blockchain technology for trading securities. By using ZSL, the details of such trades can be kept confidential, and the identities of the counterparties can be kept private, without compromising the fungibility of the assets being traded. + +Furthermore, giving blockchain participants the ability to dynamically issue their own digital assets opens up a wide range of use cases such as blockchain issuance and trading of commercial paper, discounted invoices, syndicated loans, corporate bonds, and a variety of derivatives (which we refer to as “blockchain-traded derivatives”, to differentiate from the more traditional exchange-traded derivatives). + +In the interoperability space, we’re working on implementing support for cross-chain atomic transactions (XCAT), which will make it possible to exchange assets across different blockchains, and enable interoperability between different types of blockchain, optimised for transacting different types of assets, and operating under different governance models and regulatory regimes. For example, a blockchain-traded derivative traded on a blockchain operating under the CFTC’s oversight could be settled by the delivery of shares on a ledger regulated by the SEC. A securities trade on a blockchain operated by NYSE or the DTCC could be settled, DvP-style, using CBDC or commercial bank money (“b-money”) on a ledger operated by the Federal Reserve. + +Efficiency, performance and scalability are key areas of focus for us. Currently, generating the zk-SNARK for a shielded Zcash transaction takes just over 40 seconds on a typical desktop CPU. While we’re delivering incremental performance improvements over time, we’re also conducting research into how to improve the core cryptographic circuit, which could enable significant efficiency improvements, unlocking the use of ZSL for use cases that require low latency and high-throughput. + +In the meantime, Payment Offloading will make it possible for clients running on low-powered devices to offload the more computationally-intensive elements of zk-SNARK proof generation to a more powerful server. + +
+
+

Looking to the Future

+Blockchains and distributed ledgers are an emergent technology. To my mind, it’s at a similar level of maturity as the Internet and the “World Wide Web” were in 1996. Back then, it was clear that the Internet had the potential to change the world but it took time for the technology to mature and achieve widespread adoption, and for our understanding of its potential to develop to the point where we could begin to exploit it fully. + +Distributed ledger technology - and our understanding of it - also needs to develop, evolve and mature before many of the potential use cases can be realised, especially those which require large-scale or widespread deployment and adoption. + +We expect that exploring enterprise uses for zk-SNARKs will help us improve the public Zcash network, by exposing us to ideas and use cases that expand our understanding of potential applications, and through the creation of tools and features that can be backported to Zcash. + +We recognise that there is a potential conflict of interest between our role as the primary drivers behind the Zcash cryptocurrency and our desire to generate revenue by selling ZSL-enabled solutions to enterprises. To ensure independence and objectivity, we have established an independent, non-profit Zcash Foundation to represent the interests of the Zcash community and the general public as users of the Zcash protocol and blockchain. + +In the longer term, we believe that widespread adoption and use of the technologies that underpin Zcash will benefit all its users, in the same way that adoption of Linux by enterprise users has benefited personal and hobbyist Linux users. + +Ultimately, our goal is a future in which everyone who uses distributed ledger technology, from individuals to enterprises, can benefit from the full potential of the most advanced privacy technologies. + +Edit: February 5th, 2018 +In October 2017, Zerocoin Electric Coin Company announced integration of Zero-knowledge Security Technology on J.P. Morgan’s Quorum + +
\ No newline at end of file diff --git a/_posts/2017-03-27-new-release-1-0-8.md b/_posts/2017-03-27-new-release-1-0-8.md new file mode 100644 index 0000000..f148863 --- /dev/null +++ b/_posts/2017-03-27-new-release-1-0-8.md @@ -0,0 +1,23 @@ +--- +ID: 1599 +post_title: 'New Release: 1.0.8' +author: Simon Liu +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-8/ +published: true +post_date: 2017-03-27 00:00:00 +--- +

Today we're announcing the release of Zcash 1.0.8. This release focuses on backporting features from upstream Bitcoin and usability improvements to the RPC interface.

+

Summary of the changes in this release:

+
  1. The z_importkey RPC call now lets the user specify the number of blocks to rescan when importing keys (#2052).
    2. +
  2. The getblock RPC call now returns an anchor field (the anchor is the Merkle tree root of the note commitment tree) (#2168) and also lets the user specify a block by height, as well as block hash (#2187).
    3. +
  3. Backported a libevent-based HTTP server to improve JSON-RPC handling (#2176).
    4. +
  4. Backported Tor ephemeral hidden service support, making it easier for users to run Zcash over Tor (#2177).
    5. +
  5. Backported improvements to the getmempoolinfo RPC call (#2175).
    6. +
  6. Cleaned up the source tree by removing 181,000 lines of redundant QT code (#1636).
    7. +
  7. Introduced the Rust language to the Zcash build system (#2183), in preparation for writing parts of future Zcash versions in Rust.
    8. +
  8. Updated the metrics screen (#2198) and minor UI tweak (#2203).
    9. +
  9. Updated documentation (#2157, #2161, #2184).
    10. +

We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information.

+

For a more complete list of changes, see our 1.0.8 GitHub milestone. To follow our progress, watch the GitHub project and join the forum.

\ No newline at end of file diff --git a/_posts/2017-03-28-snark-explain3.md b/_posts/2017-03-28-snark-explain3.md new file mode 100644 index 0000000..31c2ccc --- /dev/null +++ b/_posts/2017-03-28-snark-explain3.md @@ -0,0 +1,91 @@ +--- +ID: 1626 +post_title: 'Explaining SNARKs Part III: The Knowledge of Coefficient Test and Assumption' +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/snark-explain3/ +published: true +post_date: 2017-03-28 00:00:00 +--- +

<< Part II

+ +In Part II, we saw how Alice can blindly evaluate the hiding :math:`E(P(s))` of her polynomial :math:`P` of degree :math:`d`, at a point :math:`s` belonging to Bob. We called this "blind" evaluation, because Alice did not learn :math:`s` in the process. + +However, there was something missing in that protocol - the fact that Alice is able to compute :math:`E(P(s))` does not guarantee she will indeed send :math:`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 :math:`g` a generator of a group :math:`G` of order :math:`|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 :math:`\alpha\in\mathbb{F}_p`, :math:`\alpha\cdot g` denotes the result of summing :math:`\alpha` copies of :math:`g`. + +

The KC Test

+ +For :math:`\alpha\in\mathbb{F}_p^*` [1], let us call a pair of elements :math:`(a,b)` in :math:`G` an :math:`\alpha`-pair if :math:`a,b \neq 0` and :math:`b=\alpha\cdot a.` + +The KC Test proceeds as follows. +
    +
  1. Bob chooses random :math:`\alpha\in\mathbb{F}_p^*` and :math:`a\in G.` He computes :math:`b=\alpha\cdot a.`
    2. +
  2. He sends to Alice the "challenge" pair :math:`(a,b).` Note that :math:`(a,b)` is an :math:`\alpha`-pair.
    3. +
  3. Alice must now respond with a different pair :math:`(a',b')` that is also an :math:`\alpha`-pair.
    4. +
  4. Bob accepts Alice's response only if :math:`(a',b')` is indeed an :math:`\alpha`-pair. (As he knows :math:`\alpha` he can check if :math:`b'=\alpha\cdot a'.)`
    5. +
+ +Now, let's think how Alice could successfully respond to the challenge. Let's assume for a second that she knew :math:`\alpha.` In that case, she could simply choose any :math:`a'` in :math:`G,` and compute :math:`b'=\alpha\cdot a';` and return :math:`(a',b')` as her new :math:`\alpha`-pair. + +However, as the only information about :math:`\alpha` she has is :math:`\alpha\cdot a` and :math:`G` has a hard discrete log problem, we expect that Alice cannot find :math:`\alpha.` + +So how can she successfully respond to the challenge without knowing :math:`\alpha?` + +Here's the natural way to do it: Alice simply chooses some :math:`\gamma\in\mathbb{F}_p^*,` and responds with :math:`(a',b')=(\gamma\cdot a,\gamma\cdot b).` + +In this case, we have: + +:math:`b'=\gamma \cdot b = \gamma \alpha \cdot a = \alpha (\gamma\cdot a) =\alpha \cdot a',` + +so indeed :math:`(a',b')` is an :math:`\alpha`-pair as required. + +Note that if Alice responds using this strategy, she knows the ratio between :math:`a` and :math:`a'`. That is, she knows the coefficient :math:`\gamma` such that :math:`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 :math:`(a',b')` to Bob's challenge :math:`(a,b)` with non-negligible probability over Bob's choices of :math:`a,\alpha`, then she knows :math:`\gamma` such that :math:`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 :math:`\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 :math:`\alpha`-pair :math:`(a',b'),` Alice's Extractor outputs :math:`\gamma` such that :math:`a'=\gamma\cdot a.` [3] + + + + + + + + + +
[1]:math:`\mathbb{F}_p^*` denotes the non-zero elements of :math:`\mathbb{F}_p`. It is the same as :math:`\mathbb{Z}_p^*` described in Part I.
+ + + + + + +
[2]This is typically called the Knowledge of Exponent Assumption in the literature, as traditionally it was used for groups written multiplicatively.
+ + + + + + + + + +
[3]The fully formal definition needs to give the Extractor "a little slack" and states instead that the probability that Alice responds successfully but the Extractor does not output such :math:`\gamma` is negligible.
+ +

Part IV >>

\ No newline at end of file diff --git a/_posts/2017-03-29-htlc-bip.md b/_posts/2017-03-29-htlc-bip.md new file mode 100644 index 0000000..4e93756 --- /dev/null +++ b/_posts/2017-03-29-htlc-bip.md @@ -0,0 +1,41 @@ +--- +ID: 1571 +post_title: BIP199 for Hashed Timelocked Contracts +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/htlc-bip/ +published: true +post_date: 2017-03-29 00:00:00 +--- +

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 year at FC'16, and in our XCAT project that 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/bips/blob/master/bip-0199.mediawiki

+
+

Overview of HTLC

+

HTLC scripts look like this:

+
1
+2
+3
+4
+5
+6
+7
OP_IF
+    [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
+OP_ELSE
+    <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
+OP_ENDIF
+OP_EQUALVERIFY
+OP_CHECKSIG
+
+

HASHOP is a hashing algorithm (RIPEMD, SHA256), and TIMEOUTOP is either OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY. This script allows the "buyer" to purchase the preimage to <digest> by forcing the seller to reveal it when they claim their funds. If the seller doesn't reveal it, the buyer can get their money back after the timeout period.

+

It's easy to see how cross-chain atomic swaps can be built with this mechanism:

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

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.

+
\ No newline at end of file diff --git a/_posts/2017-04-02-state-of-the-network-2017-04-03.md b/_posts/2017-04-02-state-of-the-network-2017-04-03.md new file mode 100644 index 0000000..15ba6f7 --- /dev/null +++ b/_posts/2017-04-02-state-of-the-network-2017-04-03.md @@ -0,0 +1,21 @@ +--- +ID: 1637 +post_title: 'State of the Network: 1,000,000 ZEC Edition' +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/state-of-the-network-2017-04-03/ +published: true +post_date: 2017-04-02 00:00:00 +--- +

The Zcash blockchain has completed the distribution of the first 1,000,000 Zcash coins. Only 20,000,000 more to go! Now's a good time for your irregularly scheduled “State of the Network” update.

+

It has been five months since the beginning of the blockchain. The network has been running more smoothly than we expected. Like any software project, there have been bugs, but all have been relatively minor issues, quickly fixed, and most importantly none have led to loss of funds or loss of privacy (although be aware of the known issues). If you are aware of any security or privacy problems, please contact us. Also keep an eye on the Zcash Security Information page.

+

Despite the good track record so far, Zcash remains an experimental and unproven technology. Nobody should risk more money on Zcash than they can afford to lose. Even though we invested substantially in getting independent security audits before launch, it is always possible that they overlooked bugs, and it is always possible that the changes we've made since launch have inadvertently introduced new bugs.

+

We have delivered — as planned — a steady sequence of stable software updates every three weeks. I'm proud of the engineering team for consistently delivering new releases on time. Going forward, we'll probably reduce the frequency of our stable releases, and focus instead on researching and developing more significant improvements to functionality and efficiency.

+

We've announced our priorities for new improvements, “The Sapling Roadmap”. I'm excited about the improvements that we're working on. If you have uses for any of these upcoming new features, please contact us so that we can make sure the design and the interface fit your needs.

+

The Zcash Foundation was announced, with an initial endowment of 273,000 Zcash coins (over the first four years of mining). It will serve the greater good: education, science, public infrastructure, and consumer protection. If our company were ever to fail, pivot away from Zcash, or turn evil, the Zcash Foundation would carry on, because the Foundation is neither reliant upon nor subject to the company.

+

In the long run, I hope The Zcash Foundation will serve as an inclusive governance structure for everyone in the large and growing Zcash ecosystem to coordinate.

+

There are about 90,000 transactions — 23,000 of which involve shielded addresses — sent over the Zcash network each month! That is what is important about Zcash — that it can serve as a fast, cheap, safe medium of exchange that reaches anywhere the Internet reaches. Try it out by installing a Zcash wallet and buying some Zcash from a market. Then get a friend to install a Zcash wallet and send them some of your Zcash. ☺

+

Stay tuned! There is going to be a lot of good news coming. Watch this blog, the community forum, the company twitter, and (for programmers) the github repo.

+

Remember, we developers started the Zcash project, but its destiny is in your hands.

\ No newline at end of file diff --git a/_posts/2017-04-04-bellman-zksnarks-in-rust.md b/_posts/2017-04-04-bellman-zksnarks-in-rust.md new file mode 100644 index 0000000..8ce2dd4 --- /dev/null +++ b/_posts/2017-04-04-bellman-zksnarks-in-rust.md @@ -0,0 +1,317 @@ +--- +ID: 1548 +post_title: 'Bellman: zk-SNARKs in Rust' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/bellman-zksnarks-in-rust/ +published: true +post_date: 2017-04-04 00:00:00 +--- +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 a couple weeks ago, which will appear in an upcoming paper by our 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 :math:`\mathbb{F}_r`), and asked to produce an assignment to the variables which satisfies the constraints. + +

Overview of Bellman

+Bellman is currently in its infancy, but we can already use it to construct these kinds of proofs. Currently, only a very low level API is available, upon which we can construct DSLs and various abstractions for synthesizing circuits. If you want to experiment with it, grab the bellman crate from crates.io. + +All of our circuit abstractions are written generically over an Engine trait that handles the elliptic curve and finite field arithmetic. Central to circuit synthesis is the ConstraintSystem trait: + + + + + + + +
+
+
 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
+12
+13
+
 +
+
pub trait ConstraintSystem<E: Engine> {
+    /// Allocate a private variable in the constraint system, setting it to
+    /// the provided value.
+    fn alloc(&mut self, value: E::Fr) -> Variable;
+
+    /// Enforce that `A` * `B` = `C`.
+    fn enforce(
+        &mut self,
+        a: LinearCombination<E>,
+        b: LinearCombination<E>,
+        c: LinearCombination<E>
+    );
+}
+
+
+There are two important design decisions here: +
    +
  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. +
  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.
    3. +
+As an example of a kind of gadget implementation, here's how a boolean constrained variable could be implemented, along with XOR: + + + + + + + +
+
+
 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
+12
+13
+14
+15
+16
+17
+18
+19
+20
+21
+22
+23
+24
+25
+26
+27
+28
+29
+30
+31
+32
+33
+34
+35
+36
+37
+38
+39
+40
+41
+42
+43
+44
+45
+46
+47
+48
+49
+50
+51
+52
+53
+54
+55
+
 +
+
#[derive(Clone)]
+pub struct Bit {
+    var: Variable,
+    value: bool
+}
+
+impl Bit {
+    pub fn alloc<E, CS>(e: &E,
+                        cs: &mut CS,
+                        value: bool) -> Bit
+        where E: Engine, CS: ConstraintSystem<E> + ?Sized
+    {
+        // Allocate the variable
+        let var = cs.alloc(
+            if value { E::Fr::one(e) } else { E::Fr::zero() }
+        );
+
+        // Enforce (1 - var) * var = 0, which requires
+        // var to be either 0 or 1
+        cs.enforce(
+            LinearCombination::one(e) - var,
+            LinearCombination::zero(e) + var,
+            LinearCombination::zero(e)
+        );
+
+        Bit {
+            var: var,
+            value: value
+        }
+    }
+
+    pub fn xor<E, CS>(&self,
+                      e: &E,
+                      cs: &mut CS,
+                      other: &Bit) -> Bit
+        where E: Engine, CS: ConstraintSystem<E>
+    {
+        let new_value = self.value ^ other.value;
+        let new_var = cs.alloc(
+            if new_value { E::Fr::one(e) } else { E::Fr::zero() }
+        );
+
+        // 2a * b = a + b - c
+        cs.enforce(
+            LinearCombination::zero(e) + self.var + self.var,
+            LinearCombination::zero(e) + other.var,
+            LinearCombination::zero(e) + self.var + other.var - new_var
+        );
+
+        Bit {
+            var: new_var,
+            value: new_value
+        }
+    }
+}
+
+
+Building a circuit is a matter of implementing the Circuit and Input traits: + + + + + + + +
+
+
 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
+
 +
+
pub trait Circuit<E: Engine> {
+    type InputMap: Input<E>;
+    fn synthesize<CS: ConstraintSystem<E>>(self,
+                                           engine: &E,
+                                           cs: &mut CS)
+                                           -> Self::InputMap;
+}
+
+pub trait Input<E: Engine> {
+    fn synthesize<CS: PublicConstraintSystem<E>>(self, engine: &E, cs: &mut CS);
+}
+
+
+This design splits up circuits into a Circuit implementation, which provers instantiate to construct proofs, and a Input implementation, which provers and verifiers use to perform input allocation and related circuit synthesis. This differs from libsnark, where these code paths are redundant, use different utility functions and require careful code review to ensure consistency. + +Once we actually do have an implementation of Circuit and Input, we can use the functions provided in the groth16 module: create a keypair (with some randomly selected trapdoors), construct a proof, and perform verifications: + + + + + + + +
+
+
 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
+12
+13
+14
+15
+16
+17
+18
+19
+20
+21
+22
+23
+24
+25
+26
+27
+28
+29
+
 +
+
// Create a proving key and verifying key
+let (pk, vk) = {
+    let tau = E::Fr::random(e, rng);
+    let alpha = E::Fr::random(e, rng);
+    let beta = E::Fr::random(e, rng);
+    let gamma = E::Fr::random(e, rng);
+    let delta = E::Fr::random(e, rng);
+    let c = DummyCircuit;
+
+    groth16::keypair(e, c, &tau, &alpha, &beta, &gamma, &delta)
+};
+
+// Construct a proof
+let proof = {
+    let r = E::Fr::random(e, rng);
+    let s = E::Fr::random(e, rng);
+
+    let c = DummyCircuit;
+
+    groth16::prove(e, c, &r, &s, &pk).unwrap()
+};
+
+// Prepare the verifying key
+let pvk = groth16::prepare_verifying_key(e, &vk);
+
+// Verify proof
+assert!(groth16::verify(e, |cs| {
+    DummyInput
+}, &proof, &pvk));
+
+
+ +

Future work

+These lower level foundations are all that is available in Bellman right now. In the future we will be writing tools which allow us to build things like hash functions and stream ciphers. + +Bellman is still under development and shouldn’t be used in production software yet. In fact, its API deliberately does not expose anything that would allow you to actually use it! It currently serves as an excellent learning opportunity for constructing 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 multi-party computation ceremony code. \ No newline at end of file diff --git a/_posts/2017-04-11-snark-explain4.md b/_posts/2017-04-11-snark-explain4.md new file mode 100644 index 0000000..85a54ad --- /dev/null +++ b/_posts/2017-04-11-snark-explain4.md @@ -0,0 +1,85 @@ +--- +ID: 1627 +post_title: 'Explaining SNARKs Part IV: How to make Blind Evaluation of Polynomials Verifiable' +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/snark-explain4/ +published: true +post_date: 2017-04-11 00:00:00 +--- +<< Part III + +In this part, we build on Part II and III to develop a protocol for verifiable blind evaluation of polynomials, which we will define shortly. In Part V we'll start to see how such a protocol can be used for constructing SNARKs, so bear with me a little bit longer for the connection to SNARKs :). + +Suppose, as in Part II, that Alice has a polynomial :math:`P` of degree :math:`d` and Bob has a point :math:`s\in\mathbb{F}_p` that he chose randomly. We want to construct a protocol that allows Bob to learn :math:`E(P(s))`, i.e. the hiding of :math:`P` evaluated at :math:`s`, with two additional properties: + +
    +
  1. Blindness: Alice will not learn :math:`s` (and Bob will not learn :math:`P`).
    2. +
  2. Verifiability: The probability that Alice sends a value not of the form :math:`E(P(s))` for :math:`P` of degree :math:`d` that is known to her, but Bob still accepts - is negligible.
    3. +
+ +This is what we call verifiable blind evaluation of a polynomial. The protocol in Part II gave us the first item but not the second. To get verifiability we need an extended version of the Knowledge of Coefficient Assumption (KCA) that was presented in Part III. + +The verifiability and blindness properties are useful together because they make Alice decide what polynomial :math:`P` she will use without seeing :math:`s`. [1] This, in a sense, commits Alice to an "answer polynomial" without seeing the "challenge point" :math:`s`. This intuition will become more clear in the next parts of the series. + +

An Extended KCA

+ +The KCA as we defined it in Part III essentially said something like this: If Bob gives Alice some :math:`\alpha`-pair :math:`(a,b = \alpha\cdot a)` and then Alice generates another :math:`\alpha`-pair :math:`(a',b')`, then she knows :math:`c` such that :math:`a'=c\cdot a`. In other words, Alice knows the relation between :math:`a'` and :math:`a`. + +Now, suppose that instead of one, Bob sends Alice several :math:`\alpha`-pairs :math:`(a_1,b_1),\ldots,(a_d,b_d)` (for the same :math:`\alpha`); and that again, after receiving these pairs, Alice is challenged to generate some other :math:`\alpha`-pair :math:`(a',b')`. Recall that the main point is that Alice must do so although she does not know :math:`\alpha`. + +As we saw in Part III, a natural way for Alice to generate such an :math:`\alpha`-pair, would be to take one of the pairs :math:`(a_i,b_i)` she received from Bob, and multiply both elements by some :math:`c\in\mathbb{F}^*_p`; if :math:`(a_i,b_i)` was an :math:`\alpha`-pair, then :math:`(c\cdot a_i,c\cdot b_i)` will be one too. But can Alice generate :math:`\alpha`-pairs in more ways now that she's received multiple :math:`\alpha`-pairs? Perhaps using several of the received :math:`\alpha`-pairs simultaneously to get a new one? + +The answer is yes: For example, Alice can choose two values :math:`c_1,c_2\in \mathbb{F}_p` and compute the pair :math:`(a',b')=(c_1\cdot a_1 + c_2\cdot a_2, c_1\cdot b_1 + c_2\cdot b_2)`. An easy computation shows that, as long as :math:`a'` is non-zero, this is also an :math:`\alpha`-pair: + +:math:`b' = c_1\cdot b_1 + c_2 \cdot b_2 = c_1 \alpha \cdot a_1 + c_2\alpha\cdot a_2 = \alpha (c_1\cdot a_1 + c_2\cdot a_2) = \alpha\cdot a'.` + +More generally, Alice can take any linear combination of the given :math:`d` pairs - that is choose any :math:`c_1,\ldots,c_d\in\mathbb{F}_p` and define :math:`(a',b')=(\sum_{i=1}^d c_i a_i,\sum_{i=1}^d c_ib_i)`. + + +Note that, if Alice uses this strategy to generate her :math:`\alpha`-pair she will know some linear relation between :math:`a'` and :math:`a_1,\ldots,a_d`; that is, she knows :math:`c_1,\ldots,c_d` such that :math:`a'=\sum_{i=1}^d c_i\cdot a_i`. + +The extended KCA states, essentially, that this is the only way Alice can generate an :math:`\alpha`-pair; that is, whenever she succeeds, she will know such a linear relation between :math:`a'` and :math:`a_1,\ldots,a_d`. More formally, suppose that :math:`G` is a group of size :math:`p` with generator :math:`g` written additively as in Part III. The d-power Knowledge of Coefficient Assumption (d-KCA) [2] in :math:`G` is as follows: + +d-KCA: Suppose Bob chooses random :math:`\alpha\in\mathbb{F}_p^*` and :math:`s\in\mathbb{F}_p`, and sends to Alice the :math:`\alpha`-pairs :math:`(g,\alpha\cdot g), (s\cdot g,\alpha s\cdot g),\ldots,(s^d\cdot g,\alpha s^d\cdot g)`. Suppose that Alice then outputs another :math:`\alpha`-pair :math:`(a',b')`. Then, except with negligible probability, Alice knows :math:`c_0,\ldots,c_d\in\mathbb{F}_p` such that :math:`\sum_{i=0}^d c_i s^i\cdot g = a'`. + +Note that in the d-KCA Bob does not send an arbitrary set of :math:`\alpha`-pairs, but one with a certain "polynomial structure". This will be useful in the protocol below. + +

The Verifiable Blind Evaluation Protocol

+ +Assume that our HH is the mapping :math:`E(x)=x\cdot g` for a generator :math:`g` of :math:`G` as above. + +For simplicity, we present the protocol for this particular :math:`E`: + +
    +
  1. Bob chooses a random :math:`\alpha\in\mathbb{F}_p^*`, and sends to Alice the hidings :math:`g,s\cdot g,\ldots,s^d\cdot g` (of :math:`1,s,\ldots,s^d`) and also the hidings :math:`\alpha\cdot g,\alpha s \cdot g,\ldots,\alpha s^d\cdot g` (of :math:`\alpha,\alpha s,\ldots,\alpha s^d`).
    2. +
  2. Alice computes :math:`a=P(s)\cdot g` and :math:`b=\alpha P(s)\cdot g` using the elements sent in the first step, and sends both to Bob.
    3. +
  3. Bob checks that :math:`b=\alpha \cdot a`, and accepts if and only if this equality holds.
    4. +
+ +First, note that given the coefficients of :math:`P`, :math:`P(s)\cdot g` is a linear combination of :math:`g,s\cdot g,\ldots,s^d\cdot g`; and :math:`\alpha P(s)\cdot g` is a linear combination of :math:`\alpha\cdot g,\alpha s \cdot g,\ldots,\alpha s^d\cdot g`. Thus, similarly to the protocol of Part II, Alice can indeed compute these values from Bob's messages for a polynomial :math:`P` that she knows. + +Second, by the d-KCA if Alice sends :math:`a`, :math:`b` such that :math:`b=\alpha \cdot a` then almost surely she knows :math:`c_0,\ldots,c_d\in\mathbb{F}_p` such that :math:`a=\sum_{i=0}^d c_is^i\cdot g`. In that case, :math:`a=P(s)\cdot g` for the polynomial :math:`P(X)=\sum_{i=0}^d c_i\cdot X^i` known to Alice. In other words, the probability that Bob accepts in Step 3 while at the same time Alice does not know such a :math:`P` is negligible. + +To summarize, using the d-KCA we've developed a protocol for verifiable blind evaluation of polynomials. In the next posts, we will see how this building block comes to play in SNARK constructions. + + + + + + + + +
[1]In the fully formal proof, things are somewhat more subtle, as Alice does see some information about :math:`s` before deciding on her :math:`P` - for example, the hidings of :math:`s,\ldots,s^d`.
+ + + + + + + + +
[2]The d-KCA was introduced in a paper of Jens Groth.
+ +

Part V >>

\ No newline at end of file diff --git a/_posts/2017-04-12-security-announcement-2017-04-12.md b/_posts/2017-04-12-security-announcement-2017-04-12.md new file mode 100644 index 0000000..d194747 --- /dev/null +++ b/_posts/2017-04-12-security-announcement-2017-04-12.md @@ -0,0 +1,32 @@ +--- +ID: 1618 +post_title: Security Announcement 2017-04-12 +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/security-announcement-2017-04-12/ +published: true +post_date: 2017-04-12 00:00:00 +--- +Full announcement + +Please see the disclosure announcement. + +
+ +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. \ No newline at end of file diff --git a/_posts/2017-04-13-new-release-1-0-8-1.md b/_posts/2017-04-13-new-release-1-0-8-1.md new file mode 100644 index 0000000..371e052 --- /dev/null +++ b/_posts/2017-04-13-new-release-1-0-8-1.md @@ -0,0 +1,18 @@ +--- +ID: 1598 +post_title: 'New Release: 1.0.8-1' +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-8-1/ +published: true +post_date: 2017-04-13 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.8-1. This release fixes a security vulnerability detected in versions starting with 1.0.4 up to and including 1.0.8. More information on this vulnerability and risks to users are detailed in the related security announcement. + +Summary of the changes in this release: +
    +
  1. Fix a Denial of Service vulnerability that could cause nodes receiving a specially crafted transaction into their mempool to crash.
    2. +
  2. Simplify the calculation of priority for shielded transactions.
    3. +
+We highly encourage all users and miners to update to this new version as soon as possible. See our download page and the 1.0 User Guide for more information. \ No newline at end of file diff --git a/_posts/2017-04-13-security-announcement-2017-04-13.md b/_posts/2017-04-13-security-announcement-2017-04-13.md new file mode 100644 index 0000000..c93dabf --- /dev/null +++ b/_posts/2017-04-13-security-announcement-2017-04-13.md @@ -0,0 +1,64 @@ +--- +ID: 1619 +post_title: Security Announcement 2017-04-13 +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/security-announcement-2017-04-13/ +published: true +post_date: 2017-04-13 00:00:00 +--- +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. +
  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.
    3. +
+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.
    • +
+Acknowledgements + +The Zcash Company would like to thank Juliano Rizzo from Coinspect and @movcrx from the Zclassic project for collaborating with us in analyzing and mitigating this issue. \ No newline at end of file diff --git a/_posts/2017-04-14-zcash-on-ios.md b/_posts/2017-04-14-zcash-on-ios.md new file mode 100644 index 0000000..a53cb0c --- /dev/null +++ b/_posts/2017-04-14-zcash-on-ios.md @@ -0,0 +1,18 @@ +--- +ID: 1659 +post_title: Zcash on iOS +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-on-ios/ +published: true +post_date: 2017-04-14 00:00:00 +--- +

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 email or by joining our community chat, we'd be happy to help!

+

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

\ No newline at end of file diff --git a/_posts/2017-04-17-zcash-1-0-9-postponed.md b/_posts/2017-04-17-zcash-1-0-9-postponed.md new file mode 100644 index 0000000..06a230a --- /dev/null +++ b/_posts/2017-04-17-zcash-1-0-9-postponed.md @@ -0,0 +1,16 @@ +--- +ID: 1649 +post_title: Zcash 1.0.9 Postponed +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/zcash-1-0-9-postponed/ +published: true +post_date: 2017-04-17 00:00:00 +--- +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! \ No newline at end of file diff --git a/_posts/2017-04-18-zcash-in-brazil-and-south-africa.md b/_posts/2017-04-18-zcash-in-brazil-and-south-africa.md new file mode 100644 index 0000000..717e2b1 --- /dev/null +++ b/_posts/2017-04-18-zcash-in-brazil-and-south-africa.md @@ -0,0 +1,19 @@ +--- +ID: 1653 +post_title: Zcash in Brazil and South Africa +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/zcash-in-brazil-and-south-africa/ +published: true +post_date: 2017-04-18 00:00:00 +--- +

Today, we are telling the story of a company in Brazil who started a venture mining Bitcoin. With this revenue the company, coinBR, grew their business to build a money application for Brazilians.

+

This application, SmartWallet, allows their users to pay utility bills, buy pre-paid credit for phones and even pay taxes.

+

We are delighted to hear that their most recent update includes support for Zcash! Now, users of SmartWallet can use the application or any one of the thousands of participating bank branches to purchase Zcash with Brazilian Reals. Users can also exchange Zcash back into Reals, which is a great opportunity to earn ZEC for income and use that income to pay utilities and taxes all within the same service.

+

Over the years, efficiently exchanging cryptocurrency into local fiat currencies has been one of the challanges of all blockchain ecosystems, but coinBR has provided a solution to this in Brazil. When considering the global, borderless properties of Zcash and ongoing demand for remittance markets, this is a key feature we hope to see addressed in more parts of the world.

+

Rocelo Lopes of coinBR says, "We chose Zcash to be the first new cryptocurrency added to our SmartWallet due to the technology behind it and as it is one of the fastest growing cryptocurrencies."

+

In order to have the ZEC on hand to exchange for their customers, coinBR also added Zcash to their mining portfolio.

+

SmartWallet has 3000 users in Brazil and are expanding their services to South Africa on May 4th with more regions planned for launch later this year. We are excited about the growth of the Zcash ecosystem as a way to make fast, secure payments anywhere around the world. We welcome SmartWallet users into the Zcash community!

+

SmartWallet joins a growing list of third-party GUI applications supporting Zcash for users to choose from. Wallets considering adding Zcash support should reach out to us in email or by joining our community chat, we'd be happy to help!

\ No newline at end of file diff --git a/_posts/2017-04-19-shielded-address-contexts.md b/_posts/2017-04-19-shielded-address-contexts.md new file mode 100644 index 0000000..34ded93 --- /dev/null +++ b/_posts/2017-04-19-shielded-address-contexts.md @@ -0,0 +1,30 @@ +--- +ID: 1621 +post_title: 'Payment Contexts & Reusing Shielded Addresses' +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/shielded-address-contexts/ +published: true +post_date: 2017-04-19 00:00:00 +--- +

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

+
+Data revealed for a single shielded 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.

+
\ No newline at end of file diff --git a/_posts/2017-04-25-snark-explain5.md b/_posts/2017-04-25-snark-explain5.md new file mode 100644 index 0000000..cd8584f --- /dev/null +++ b/_posts/2017-04-25-snark-explain5.md @@ -0,0 +1,97 @@ +--- +ID: 1628 +post_title: 'Explaining SNARKs Part V: From Computations to Polynomials' +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/snark-explain5/ +published: true +post_date: 2017-04-25 00:00:00 +--- +<< 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 :math:`c_1,c_2,c_3 \in \mathbb{F}_p` such that :math:`(c_1\cdot c_2)\cdot (c_1 + c_3) = 7`. The first step is to present the expression computed from :math:`c_1,c_2,c_3` 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: + +
An example of an arithmetic circuit
+ +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 :math:`\mathsf{w_1}` 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 :math:`\mathsf{w_1}` and :math:`\mathsf{w_3}` as both being right inputs of :math:`\mathsf{g_2}`.
    • + +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: :math:`(c_1,\ldots,c_5)` where :math:`c_4=c_1\cdot c_2` and :math:`c_5=c_4\cdot (c_1+c_3)`. + + +In this terminology, what Alice wants to prove is that she knows a legal assignment :math:`(c_1,\ldots,c_5)` such that :math:`c_5=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: :math:`\mathsf{g_1}` will be associated with :math:`1\in\mathbb{F}_p` and :math:`\mathsf{g_2}` with :math:`2\in\mathbb{F}_p`. We call the points :math:`\{1,2\}` our target points. Now we need to define a set of "left wire polynomials" :math:`L_1,\ldots,L_5`, "right wire polynomials" :math:`R_1,\ldots,R_5` and "output wire polynomials" :math:`O_1,\ldots,O_5`. + +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 :math:`\mathsf{w_1},\mathsf{w_2},\mathsf{w_4}` are, respectively, the left, right and output wire of :math:`\mathsf{g_1}`; we define :math:`L_1=R_2=O_4=2-X`, as the polynomial :math:`2-X` is one on the point :math:`1` corresponding to :math:`\mathsf{g_1}` and zero on the point :math:`2` corresponding to :math:`\mathsf{g_2}`. + +Note that :math:`\mathsf{w_1}` and :math:`\mathsf{w_3}` are both right inputs of :math:`\mathsf{g_2}`. Therefore, we define similarly :math:`L_4=R_1=R_3=O_5=X-1` - as :math:`X-1` is one on the target point :math:`2` corresponding to :math:`\mathsf{g_2}` and zero on the other target point. + +We set the rest of the polynomials to be the zero polynomial. + +Given fixed values :math:`(c_1,\ldots,c_5)` we use them as coefficients to define a left, right, and output "sum" polynomials. That is, we define + +:math:`L:=\sum_{i=1}^5 c_i\cdot L_i, R:=\sum_{i=1}^5 c_i\cdot R_i, O:=\sum_{i=1}^5 c_i\cdot O_i`, + +and then we define the polynomia :math:`P:=L\cdot R -O`. + +Now, after all these definitions, the central point is this: :math:`(c_1,\ldots,c_5)` is a legal assignment to the circuit if and only if :math:`P` vanishes on all the target points. + +Let's examine this using our example. Suppose we defined :math:`L,R,O,P` as above given some :math:`c_1,\ldots,c_5`. Let's evaluate all these polynomials at the target point :math:`1`: + +Out of all the :math:`L_i`'s only :math:`L_1` is non-zero on :math:`1`. So we have :math:`L(1)=c_1\cdot L_1(1)=c_1`. Similarly, we get :math:`R(1)=c_2` and :math:`O(1)=c_4`. + +Therefore, :math:`P(1)=c_1\cdot c_2-c_4`. A similar calculation shows :math:`P(2)= c_4\cdot (c_1+c_3) - c_5`. + +In other words, :math:`P` vanishes on the target points if and only if :math:`(c_1,\ldots,c_5)` is a legal assignment. + +Now, we use the following algebraic fact: For a polynomial :math:`P` and a point :math:`a\in\mathbb{F}_p`, we have :math:`P(a)=0` if and only if the polynomial :math:`X-a` divides :math:`P`, i.e. :math:`P=(X-a)\cdot H` for some polynomial :math:`H`. + +Defining the target polynomial :math:`T(X):=(X-1)\cdot (X-2)`, we thus have that :math:`T` divides :math:`P` if and only if :math:`(c_1,\ldots,c_5)` is a legal assignment. + +Following the above discussion, we define a QAP as follows: + +A Quadratic Arithmetic Program :math:`Q` of degree :math:`d` and size :math:`m` consists of polynomials :math:`L_1,\ldots,L_m`, :math:`R_1,\ldots,R_m`, :math:`O_1,\ldots,O_m` and a target polynomial :math:`T` of degree :math:`d`. + +An assignment :math:`(c_1,\ldots,c_m)` satisfies :math:`Q` if, defining :math:`L:=\sum_{i=1}^m c_i\cdot L_i, R:=\sum_{i=1}^m c_i\cdot R_i, O:=\sum_{i=1}^m c_i\cdot O_i` and :math:`P:=L\cdot R -O`, we have that :math:`T` divides :math:`P`. + +In this terminology, Alice wants to prove she knows an assignment :math:`(c_1,\ldots,c_5)` satisfying the QAP described above with :math:`c_5=7`. + +To summarize, we have seen how a statement such as "I know :math:`c_1,c_2,c_3` such that :math:`(c_1\cdot c_2)\cdot (c_1 + c_3) = 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. + +>> Part VI + + + + + + + + + +
    [1]In this post we tried to give the most concise example of a reduction to QAP; we also recommend Vitalik Buterin's excellent post for more details on the transformation from a program to a QAP.
    \ No newline at end of file diff --git a/_posts/2017-04-28-internet-money.md b/_posts/2017-04-28-internet-money.md new file mode 100644 index 0000000..cbf1f27 --- /dev/null +++ b/_posts/2017-04-28-internet-money.md @@ -0,0 +1,23 @@ +--- +ID: 1573 +post_title: Internet Money +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/internet-money/ +published: true +post_date: 2017-04-28 00:00:00 +--- +

    Six months ago today we launched an ambitious attempt to create 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.

    +
    +Sprout thriving
    +

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

    +
    +Chart of Zcash market cap history and growth to 100 million USD

    The history of the Zcash market cap, from Coinmarketcap.com.

    +
    +

    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 wallets and 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.

    \ No newline at end of file diff --git a/_posts/2017-05-01-release-cycle-and-lifetimes.md b/_posts/2017-05-01-release-cycle-and-lifetimes.md new file mode 100644 index 0000000..c4b77d9 --- /dev/null +++ b/_posts/2017-05-01-release-cycle-and-lifetimes.md @@ -0,0 +1,68 @@ +--- +ID: 1613 +post_title: Release Cycle and Lifetimes +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/release-cycle-and-lifetimes/ +published: true +post_date: 2017-05-01 00:00:00 +--- +Starting in May the Zcash development effort will institute 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 chat or if preferred, reach out directly via email. + + + + + + + +
    [1]We're still determining when and how to deprecate releases before 1.0.9.
    +
    +
    +
    \ No newline at end of file diff --git a/_posts/2017-05-10-snark-explain6.md b/_posts/2017-05-10-snark-explain6.md new file mode 100644 index 0000000..2b8d4ce --- /dev/null +++ b/_posts/2017-05-10-snark-explain6.md @@ -0,0 +1,96 @@ +--- +ID: 1629 +post_title: 'Explaining SNARKs Part VI: The Pinocchio Protocol' +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/snark-explain6/ +published: true +post_date: 2017-05-10 00:00:00 +--- +<< Part V + +In part V we saw how a statement Alice would like to prove to Bob can be converted into an equivalent form in the "language of polynomials" called a Quadratic Arithmetic Program (QAP). + +In this part, we show how Alice can send a very short proof to Bob showing she has a satisfying assignment to a QAP. We will use the Pinocchio Protocol of Parno, Howell, Gentry and Raykova. But first let us recall the definition of a QAP we gave last time: + +A Quadratic Arithmetic Program :math:`Q` of degree :math:`d` and size :math:`m` consists of polynomials :math:`L_1,\ldots,L_m`, :math:`R_1,\ldots,R_m`, :math:`O_1,\ldots,O_m` and a target polynomial :math:`T` of degree :math:`d`. + +An assignment :math:`(c_1,\ldots,c_m)` satisfies :math:`Q` if, defining +:math:`L:=\sum_{i=1}^m c_i\cdot L_i, R:=\sum_{i=1}^m c_i\cdot R_i, O:=\sum_{i=1}^m c_i\cdot O_i` and :math:`P:=L\cdot R -O`, we have that :math:`T` divides :math:`P`. + +As we saw in Part V, Alice will typically want to prove she has a satisfying assignment possessing some additional constraints, e.g. :math:`c_m=7`; but we ignore this here for simplicity, and show how to just prove knowledge of some satisfying assignment. + +If Alice has a satisfying assignment it means that, defining :math:`L,R,O,P` as above, there exists a polynomial :math:`H` such that :math:`P=H\cdot T`. In particular, for any :math:`s\in\mathbb{F}_p` we have :math:`P(s)=H(s)\cdot T(s)`. + +Suppose now that Alice doesn't have a satisfying assignment, but she still constructs :math:`L,R,O,P` as above from some unsatisfying assignment :math:`(c_1,\ldots,c_m)`. Then we are guaranteed that :math:`T` does not divide :math:`P`. This means that for any polynomial :math:`H` of degree at most :math:`d`, :math:`P` and :math:`L,R,O,H` will be different polynomials. Note that :math:`P` and :math:`L,R,O,H` here are both of degree at most :math:`2d`. + +Now we can use the famous Schwartz-Zippel Lemma that tells us that two different polynomials of degree at most :math:`2d` can agree on at most :math:`2d` points :math:`s\in\mathbb{F}_p`. Thus, if :math:`p` is much larger than :math:`2d` the probability that :math:`P(s)=H(s)\cdot T(s)` for a randomly chosen :math:`s\in\mathbb{F}_p` is very small. + +This suggests the following protocol sketch to test whether Alice has a satisfying assignment. + +
      +
    1. Alice chooses polynomials :math:`L,R,O,H` of degree at most :math:`d`.
      2. +
    2. Bob chooses a random point :math:`s\in\mathbb{F}_p`, and computes :math:`E(T(s))`.
      3. +
    3. Alice sends Bob the hidings of all these polynomials evaluated at :math:`s`, i.e. :math:`E(L(s)),E(R(s)),E(O(s)),E(H(s))`.
      4. +
    4. Bob checks if the desired equation holds at :math:`s`. That is, he checks whether :math:`E(L(s)\cdot R(s)-O(s))=E(T(s)\cdot H(s))`.
      5. +
    + +Again, the point is that if Alice does not have a satisfying assignment, she will end up using polynomials where the equation does not hold identically, and thus does not hold at most choices of :math:`s`. Therefore, Bob will reject with high probability over his choice of :math:`s` in such a case. + +The question is whether we have the tools to implement this sketch. The most crucial point is that Alice must choose the polynomials she will use, without knowing :math:`s`. But this is exactly the problem we solved in the verifiable blind evaluation protocol, that was developed in Parts II-IV. + +Given that we have that, there are four main points that need to be addressed to turn this sketch into a zk-SNARK. We deal with two of them here, and the other two in the next part. + +

    Making sure Alice chooses her polynomials according to an assignment

    + +Here is an important point: If Alice doesn't have a satisfying assignment, it doesn't mean she can't find any polynomials :math:`L,R,O,H` of degree at most :math:`d` with :math:`L\cdot R-O=T\cdot H`, it just means she can't find such polynomials where :math:`L,R` and :math:`O` were "produced from an assignment"; namely, that :math:`L:=\sum_{i=1}^m c_i\cdot L_i, R:=\sum_{i=1}^m c_i\cdot R_i, O:=\sum_{i=1}^m c_i\cdot O_i` for the same :math:`(c_1,\ldots,c_m)`. + +The protocol of Part IV just guarantees she is using some polynomials :math:`L,R,O` of the right degree, but not that they were produced from an assignment. This is a point where the formal proof gets a little subtle; here we sketch the solution imprecisely. + +Let's combine the polynomials :math:`L,R,O` into one polynomial :math:`F` as follows: + +:math:`F=L+X^{d+1}\cdot R+X^{2(d+1)}\cdot O` + +The point of multiplying :math:`R` by :math:`X^{d+1}` and :math:`O` by :math:`X^{2(d+1)}` is that the coefficients of :math:`L,R,O` "do not mix" in :math:`F`: The coefficients of :math:`1,X,\ldots,X^d` in :math:`F` are precisely the coefficients of :math:`L`, the next :math:`d+1` coefficients of :math:`X^{d+1},\ldots,X^{2d+1}` are precisely the coefficients of :math:`R`, and the last :math:`d+1` coefficients are those of :math:`O`. + +Let's combine the polynomials in the QAP definition in a similar way, defining for each :math:`i\in \{1,\ldots,m\}` a polynomial :math:`F_i` whose first :math:`d+1` coefficients are the coefficients of :math:`L_i`, followed be the coefficients of :math:`R_i` and then :math:`O_i`. That is, for each :math:`i\in \{1,\ldots,m\}` we define the polynomial + +:math:`F_i=L_i+X^{d+1}\cdot R_i+X^{2(d+1)}\cdot O_i` + +Note that when we sum two of the :math:`F_i`'s the :math:`L_i`, :math:`R_i`, and :math:`O_i` "sum separately". For example, :math:`F_1+F_2 = (L_1+L_2)+X^{d+1}\cdot (R_1+R_2)+X^{2(d+1)}\cdot(O_1+O_2)`. + +More generally, suppose that we had :math:`F=\sum_{i=1}^mc_i\cdot F_i` for some :math:`(c_1,\ldots,c_m)`. Then we'll also have :math:`L=\sum_{i=1}^m c_i\cdot L_i, R=\sum_{i=1}^m c_i\cdot R_i, O=\sum_{i=1}^m c_i\cdot O_i` for the same coefficients :math:`(c_1,\ldots,c_m)`. In other words, if :math:`F` is a linear combination of the :math:`F_i`'s it means that :math:`L,R,O` were indeed produced from an assignment. + +Therefore, Bob will ask Alice to prove to him that :math:`F` is a linear combination of the :math:`F_i`'s. This is done in a similar way to the protocol for verifiable evaluation: + +Bob chooses a random :math:`\beta\in\mathbb{F}^*_p`, and sends to Alice the hidings :math:`E(\beta\cdot F_1(s)),\ldots,E(\beta\cdot F_m(s))`. He then asks Alice to send him the element :math:`E(\beta\cdot F(s))`. If she succeeds, an extended version of the Knowledge of Coefficient Assumption implies she knows how to write :math:`F` as a linear combination of the :math:`F_i`'s. + +

    Adding the zero-knowledge part - concealing the assignment

    + +In a zk-SNARK Alice wants to conceal all information about her assignment. However the hidings :math:`E(L(s)),E(R(s)),E(O(s)),E(H(s))` do provide some information about the assignment. + +For example, given some other satisfying assignment :math:`(c'_1,\ldots,c'_m)` Bob could compute the corresponding :math:`L',R',O',H'` and hidings :math:`E(L'(s)),E(R'(s)),E(O'(s)),E(H'(s))`. If these come out different from Alice's hidings, he could deduce that :math:`(c'_1,\ldots,c'_m)` is not Alice's assignment. + +To avoid such information leakage about her assignment, Alice will conceal her assignment by adding a "random :math:`T`-shift" to each polynomial. That is, she chooses random :math:`\delta_1,\delta_2,\delta_3\in\mathbb{F}^*_p`, and defines :math:`L_z:=L+\delta_1\cdot T,R_z:=R+\delta_2\cdot T,O_z:=O+\delta_3\cdot T`. + +Assume :math:`L,R,O` were produced from a satisfying assignment; hence, :math:`L\cdot R-O = T\cdot H` for some polynomial :math:`H`. As we've just added a multiple of :math:`T` everywhere, :math:`T` also divides :math:`L_z\cdot R_z-O_z`. Let's do the calculation to see this: + +:math:`L_z\cdot R_z-O_z = (L+\delta_1\cdot T)(R+\delta_2\cdot T) - O-\delta_3\cdot T` :math:`= (L\cdot R-O) + L\cdot \delta_2\cdot T + \delta_1\cdot T\cdot R + \delta_1\delta_2\cdot T^2 - \delta_3\cdot T\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;` :math:`=T\cdot (H+L\cdot \delta_2 + \delta_1\cdot R + \delta_1 \delta_2\cdot T - \delta_3)` + +Thus, defining :math:`H_z=H+L\cdot\delta_2 + \delta_1\cdot R + \delta_1\delta_2\cdot T-\delta_3`, we have that :math:`L_z\cdot R_z-O_z=T\cdot H_z`. Therefore, if Alice uses the polynomials :math:`L_z,R_z,O_z,H_z` instead of :math:`L,R,O,H`, Bob will always accept. + +On the other hand, these polynomials evaluated at :math:`s\in\mathbb{F}_p` with :math:`T(s)\neq 0` (which is all but :math:`d` :math:`s`'s), reveal no information about the assignment. For example, as :math:`T(s)` is non-zero and :math:`\delta_1` is random, :math:`\delta_1\cdot T(s)` is a random value, and therefore :math:`L_z(s)=L(s)+\delta_1\cdot T(s)` reveals no information about :math:`L(s)` as it is masked by this random value. + +

    What's left for next time?

    + +We presented a sketch of the Pinocchio Protocol in which Alice can convince Bob she possesses a satisfying assignment for a QAP, without revealing information about that assignment. There are two main issues that still need to be resolved in order to obtain a zk-SNARK: + +
      +
    • In the sketch, Bob needs an HH that "supports multiplication". For example, he needs to compute :math:`E(H(s)\cdot T(s))` from :math:`E(H(s))` and :math:`E(T(s))`. However, we have not seen so far an example of an HH that enables this. We have only seen an HH that supports addition and linear combinations.
      • +
    • Throughout this series, we have discussed interactive protocols between Alice and Bob. Our final goal, though, is to enable Alice to send single-message non-interactive proofs, that are publicly verifiable - meaning that anybody seeing this single message proof will be convinced of its validity, not just Bob (who had prior communication with Alice).
      • +
    + +Both these issues can be resolved by the use of pairings of elliptic curves, which we will discuss in the next and final part. + +

    >> Part VII

    \ No newline at end of file diff --git a/_posts/2017-05-11-getting-started-developing.md b/_posts/2017-05-11-getting-started-developing.md new file mode 100644 index 0000000..eebb204 --- /dev/null +++ b/_posts/2017-05-11-getting-started-developing.md @@ -0,0 +1,28 @@ +--- +ID: 1566 +post_title: Getting Started Developing with Zcash +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/getting-started-developing/ +published: true +post_date: 2017-05-11 00:00:00 +--- +

    Over the short history of Zcash, we've seen a substantial growth in the ecosystem from wallets and exchanges to more experimental applications like zmsg. As the Zcash core development team continues to improve the underlying Zcash protocol, we encourage more developers to join the community!

    +

    You can easily integrate Zcash into your existing cryptocurrency app, or you can use Zcash to build something new. There's plenty of opportunity to become part of the roots growing the Zcash ecosystem.

    +
    +

    Level 1 Support (Transparent addresses)

    +

    Supporting transparent addresses in Zcash is a very similar process to supporting bitcoin. Implementing these addresses is the simplest way to get started and this is by far the most popular way we've seen third-parties make use of Zcash in their applications, at least for now.

    +

    While transparent addresses don't allow users to send privately, in many cases the mere existence and use of shielded addresses by others provides protection from linkability.

    +
    +
    +

    Level 2 Support (Shielded addresses)

    +

    Supporting shielded addresses requires more work but we encourage those interested to take advantage of their added capabilities. ShapeShift and Keybase are two examples of services which work with shielded addresses.

    +

    We're doing a lot of work to make shielded addresses easier to support and more useful. For example, some near future priorities for Zcash development include payment disclosure and payment offloading which open up a lot of opportunities for third-parties. If you're interested in being one of the first to implement these when they're released as experimental features, get in touch (see below)!

    +
    +
    +

    Getting Started with Zcash Integration

    +

    The quest to establish an Internet money ecosystem requires a variety of third-party services and we are here to help!

    +

    Please view the Zcash Integration Guide to get started with either Level 1 or Level 2 Zcash integration. You can get help by posting on our forum, joining us in the community chat or, if you prefer, sending us an email.

    +

    If you're not a developer but want your favorite wallet, payment processor or cryptocurrency service to support Zcash, we encourage you to reach out to them with the Zcash Integration Guide and tell them why you want them to support Zcash!

    \ No newline at end of file diff --git a/_posts/2017-05-22-zsl-quorum.md b/_posts/2017-05-22-zsl-quorum.md new file mode 100644 index 0000000..8b696d8 --- /dev/null +++ b/_posts/2017-05-22-zsl-quorum.md @@ -0,0 +1,32 @@ +--- +ID: 1663 +post_title: 'Press release: Zero-knowledge Security Layer to be Added to Quorum Blockchain Platform' +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zsl-quorum/ +published: true +post_date: 2017-05-22 00:00:00 +--- +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: press@z.cash + +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 at www.jpmorgan.com. \ No newline at end of file diff --git a/_posts/2017-05-24-new-release-1-0-9.md b/_posts/2017-05-24-new-release-1-0-9.md new file mode 100644 index 0000000..be7bc2b --- /dev/null +++ b/_posts/2017-05-24-new-release-1-0-9.md @@ -0,0 +1,29 @@ +--- +ID: 1600 +post_title: 'New Release: 1.0.9' +author: Nathan Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-9/ +published: true +post_date: 2017-05-24 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.9. This is our first release using our new release cycle and focused exclusively on improvements to testing, security, benchmarking, automation, and portability. + +This release is our first with the auto-deprecation feature described in our Release Cycles and Lifetimes post. It also introduces opt-in support for the AMQP protocol. + +We encourage all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. +
      +
    1. Implemented automatic deprecation shutdown. #2297
      2. +
    2. Added opt-in AMQP support. #2189, #2362, #2280
      3. +
    3. Performance benchmarking and testing improvements: fix hang in benchmarking CI automation, add connectblockslow benchmark, re-enabled miner tests, improved error reporting in rpc-tests framework, changed default regtest port. #2397, #2372, #2389, #2376, #2265, #2270
      4. +
    4. Automated the release process, added build diagnostics for better user support, and fixed versioning problems in debian packaging and manpages. #2393, #2369, #2281
      5. +
    5. Added test for pairing bug when G1 is infinity. #2399
      6. +
    6. Documentation: Clarify release policy, added wallet backup instructions, and fixed some incorrect references to "bitcoin". #2401, #2340, #2364, #2338
      7. +
    7. Added alert sources for 2017-04-13 security incident. #2293
      8. +
    +In addition to improvements to the Zcash codebase itself, we made substantial improvements to our continuous integration (CI) system: we upgraded the Buildbot framework, modularized the CI code for easier maintenance, introduced a 'supported vs unsupported' build worker framework, repaired coverage analysis, and added new benchmarks. + +These changes allow us to begin adding support for more platforms, to begin adding more benchmarks for judiciously selected optimization work, and to further improve the CI system with minimal disruption to future reference client releases. + +For a more complete list of changes, see our 1.0.9 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2017-06-07-snark-explain7.md b/_posts/2017-06-07-snark-explain7.md new file mode 100644 index 0000000..5dd9f38 --- /dev/null +++ b/_posts/2017-06-07-snark-explain7.md @@ -0,0 +1,142 @@ +--- +ID: 1630 +post_title: 'Explaining SNARKs Part VII: Pairings of Elliptic Curves' +author: Ariel Gabizon +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/snark-explain7/ +published: true +post_date: 2017-06-07 00:00:00 +--- +<< Part VI + +In Part VI, we saw an outline of the Pinocchio zk-SNARK. We were missing two things - an HH that supports both addition and multiplication that is needed for the verifier's checks, and a transition from an interactive protocol to a non-interactive proof system. + +In this post we will see that using elliptic curves we can obtain a limited, but sufficient for our purposes, form of HH that supports multiplication. We will then show that this limited HH also suffices to convert our protocol to the desired non-interactive system. + +We begin by introducing elliptic curves and explaining how they give us the necessary HH. + +

    Elliptic curves and their pairings

    + +Assume :math:`p` is a prime larger than :math:`3`, and take some :math:`u,v\in\mathbb{F}_p` such that :math:`4u^3+27v^2\neq 0`. We look at the equation + +:math:`Y^2=X^3 +u\cdot X +v` + +An elliptic curve :math:`{\mathcal C}` is the of set of points :math:`(x,y)` [1] that satisfy such an equation. These curves give us an interesting way to construct groups. The group elements will be the points :math:`(x,y)\in \mathbb{F}^2_p` that are on the curve, i.e., that satisfy the equation, together with a special point :math:`{\mathcal O}`, that for technical reasons is sometimes refered to as the "point at infinity", and serves as the identity element, i.e. the zero of the group. + +Now the question is how we add two points :math:`P=(x_1,y_1),Q=(x_2,y_2)` to get a third? The addition rule is derived from a somewhat abstract object called the divisor class group of the curve. For our purposes, all you have to know about this divisor class group is that it imposes the following constraint on the definition of addition: The sum of points on any line must be zero, i.e., :math:`{\mathcal O}`. + +Let's see how the addition rule is derived from this constraint. Look at a vertical line, defined by an equation of the form :math:`X=c`. Suppose this line intersects the curve at a point :math:`P=(x_1,y_1)`. Because the curve equation is of the form :math:`Y^2=f(X)`, if :math:`(x_1,y_1)` is on the curve, so is the point :math:`Q:=(x_1,-y_1)`. Moreover, since it's a vertical line and the curve equation is of degree two in :math:`Y`, we can be sure these are the only points where the line and curve intersect. + +
    +Test |P+Q=O --> P=-Q| +
    + +Thus, we must have :math:`P+Q={\mathcal O}` which means :math:`P=-Q`; that is, :math:`Q` is the inverse of :math:`P` in the group. + +Now let us look at points :math:`P` and :math:`Q` that have a different first coordinate - that is, :math:`x_1\neq x_2`, and see how to add them. We pass a line through :math:`P` and :math:`Q`. + +
    +Test |P+Q+R=0| +
    + +Since the curve is defined by a degree three polynomial in :math:`X` and already intersects this (non-vertical) line at two points, it is guaranteed to intersect the line at a third point, that we denote :math:`R=(x,y)`, and no other points. + +So we must have :math:`P+Q+R={\mathcal O}`, which means :math:`P+Q=-R`; and we know by now that :math:`-R` is obtained from :math:`R` by flipping the second coordinate from :math:`y` to :math:`-y`. + +Thus, we have derived the addition rule for our group: Given points :math:`P` and :math:`Q`, pass a line through them, and then take the "mirror" point of the third intersection point of the line as the addition result. [2] + +This group is usually called :math:`{\mathcal C}(\mathbb{F}_p)` - as it consists of points on the curve :math:`{\mathcal C}` with coordinates in :math:`\mathbb{F}_p`; but let's denote it by :math:`G_1` from now on. Assume for simplicity that the number of elements in :math:`G_1` is a prime number :math:`r`, and is different from :math:`p`. This is many times the case, for example in the curve that Zcash is currently using. In this case, any element :math:`g\in G_1` different from :math:`{\mathcal O}` generates :math:`G_1`. + +The smallest integer :math:`k` such that :math:`r` divides :math:`p^k-1` is called the embedding degree of the curve. It is conjectured that when :math:`k` is not too small, say, at least :math:`6`, then the discrete logarithm problem in :math:`G_1`, i.e. finding :math:`\alpha` from :math:`g` and :math:`\alpha \cdot g`, is very hard. (In BN curves [3] currently used by Zcash :math:`k=12`.) + +The multiplicative group of :math:`\mathbb{F}_{p^k}` contains a subgroup of order :math:`r` that we denote :math:`G_T`. We can look at curve points with coordinates in :math:`\mathbb{F}_{p^k}` and not just in :math:`\mathbb{F}_p`. Under the same addition rule, these points also form a group together with :math:`{\mathcal O}` called :math:`{\mathcal C}(\mathbb{F}_{p^k})`. Note that :math:`{\mathcal C}(\mathbb{F}_{p^k})` clearly contains :math:`G_1`. Besides :math:`G_1`, :math:`{\mathcal C}(\mathbb{F}_{p^k})` will contain an additional subgroup :math:`G_2` of order :math:`r` (in fact, :math:`r-1` additional subgroups of order :math:`r`). + +Fix generators :math:`g\in G_1,h\in G_2`. It turns out that there is an efficient map, called the Tate reduced pairing, taking a pair of elements from :math:`G_1` and :math:`G_2` into an element of :math:`G_T`, + +such that + +
      +
    1. :math:`\mathrm{Tate}(g,h)=\mathbf{g}` for a generator :math:`\mathbf{g}` of :math:`G_T`, and
      2. +
    2. given a pair of elements :math:`a,b \in \mathbb{F}_r`, we have :math:`\mathrm{Tate}(a\cdot g,b\cdot h)=\mathbf{g}^{ab}`.
      3. +
    + +Defining :math:`\mathrm{Tate}` is a bit beyond the scope of this series, and relies on concepts from algebraic geometry, most prominently that of divisors. Here's a sketch of :math:`\mathrm{Tate}`'s definition: [4] + +For :math:`a\in\mathbb{F}_p` the polynomial :math:`(X-a)^r` has a zero of multiplicity :math:`r` at the point :math:`a`, and no other zeroes. For a point :math:`P\in G_1`, divisors enable us to prove there exists a function :math:`f_P` from the curve to :math:`\mathbb{F}_p` that also has, in some precise sense, a zero of multiplicity :math:`r` at :math:`P` and no other zeroes. :math:`\mathrm{Tate}(P,Q)` is then defined as :math:`f_P(Q)^{(p^k-1)/r}`. + +It may not seem at all clear what this definition has to do with the stated properties, and indeed the proof that :math:`\mathrm{Tate}` has these properties is quite complex. + +Defining :math:`E_1(x) := x\cdot g, E_2(x):=x\cdot h, E(x):=x\cdot \mathbf{g}`, we get a weak version of an HH that supports both addition and multiplication: :math:`E_1,E_2,E` are HHs that support addition, and given the hidings :math:`E_1(x)`, :math:`E_2(y)` we can compute :math:`E(xy)`. In other words, if we have the ''right'' hidings of :math:`x` and :math:`y` we can get a (different) hiding of :math:`xy`. But for example, if we had hidings of :math:`x,y,z` we couldn't get a hiding of :math:`xyz`. + +We move on to discussing non-interactive proof systems. We begin by explaining exactly what we mean by 'non-interactive'. + +

    Non-interactive proofs in the common reference string model

    + +The strongest and most intuitive notion of a non-interactive proof is probably the following. In order to prove a certain claim, a prover broadcasts a single message to all parties, with no prior communication of any kind; and anyone reading this message would be convinced of the prover's claim. This can be shown to be impossible in most cases. [5] + +A slightly relaxed notion of non-interactive proof is to allow a common reference string (CRS). In the CRS model, before any proofs are constructed, there is a setup phase where a string is constructed according to a certain randomized process and broadcast to all parties. This string is called the CRS and is then used to help construct and verify proofs. The assumption is that the randomness used in the creation of the CRS is not known to any party - as knowledge of this randomness might enable constructing proofs of false claims. + +We will explain how in the CRS model we can convert the verifiable blind evaluation protocol of Part IV into a non-interactive proof system. As the protocol of Part VI consisted of a few such subprotocols it can be turned into a non-interactive proof system in a similar way. + +

    A non-interactive evaluation protocol

    + +The non-interactive version of the evaluation protocol basically consists of publishing Bob's first message as the CRS. Recall that the purpose of the protocol is to obtain the hiding :math:`E(P(s))` of Alice's polynomial :math:`P` at a randomly chosen :math:`s\in\mathbb{F}_r`. + +Setup: Random :math:`\alpha\in \mathbb{F}_r^*,s\in\mathbb{F}_r` are chosen and the CRS: + +:math:`(E_1(1),E_1(s),\ldots,E_1(s^d),` :math:`E_2(\alpha),E_2(\alpha s),\ldots,E_2(\alpha s^d))` + +is published. + +Proof: Alice computes :math:`a=E_1(P(s))` and :math:`b=E_2(\alpha P(S))` using the elements of the CRS, and the fact that :math:`E_1` and :math:`E_2` support linear combinations. + +Verification: Fix the :math:`x,y\in \mathbb{F}_r` such that :math:`a=E_1(x)` and :math:`b=E_2(y)`. Bob computes :math:`E(\alpha x)=\mathrm{Tate}(E_1(x),E_2(\alpha))` and :math:`E(y)=\mathrm{Tate}(E_1(1),E_2(y))`, and checks that they are equal. (If they are equal it implies :math:`\alpha x =y`.) + +As explained in Part IV, Alice can only construct :math:`a,b` that will pass the verification check if :math:`a` is the hiding of :math:`P(s)` for a polynomial :math:`P` of degree :math:`d` known to her. The main difference here is that Bob does not need to know :math:`\alpha` for the verification check, as he can use the pairing function to compute :math:`E(\alpha x)` only from :math:`E_1(x)` and :math:`E_2(\alpha)`. Thus, he does not need to construct and send the first message himself, and this message can simply be fixed in the CRS. + + + + + + + +
    [1]You may ask 'The set of points from where?'. We mean the set of points with coordinates in the algebraic closure of :math:`\mathbb{F}_p`. Also, the curve has an affine and projective version. When we are referring to the projective version we also include the "point at infinity" :math:`{\mathcal O}` as an element of the curve.
    + + + + + + + +
    [2]We did not address the case of adding :math:`P` to itself. This is done by using the line that is tangent to the curve at :math:`P`, and taking :math:`R` to be the second intersection point of this line with the curve.
    + + + + + + +
    [3]https://eprint.iacr.org/2005/133.pdf
    + + + + + + + +
    [4]The pairing Zcash actually uses is the optimal Ate pairing, which is based on the Tate reduced pairing, and can be computed more efficiently than :math:`\mathrm{Tate}`.
    + + + + + + + +
    [5]In computational complexity theory terms, one can show that only languages in BPP have non-interactive zero-knowledge proofs in this strong sense. The type of claims we need to prove in Zcash transactions, e.g. 'I know a hash preimage of this string', correspond to the complexity class NP which is believed to be much larger than BPP.
    + + + + + + +
    [6]The images used were taken from the following article and are used under the creative commons license.
    \ No newline at end of file diff --git a/_posts/2017-06-08-pay-to-sudoku-revisited.md b/_posts/2017-06-08-pay-to-sudoku-revisited.md new file mode 100644 index 0000000..a7eb952 --- /dev/null +++ b/_posts/2017-06-08-pay-to-sudoku-revisited.md @@ -0,0 +1,18 @@ +--- +ID: 1610 +post_title: Pay-to-sudoku Revisited +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/pay-to-sudoku-revisited/ +published: true +post_date: 2017-06-08 00:00:00 +--- +

    Last year, I created a project called pay-to-sudoku which was the world's first implementation of a zero-knowledge contingent payment (ZKCP). ZKCPs were invented in 2011 by Gregory Maxwell, and are a clever cryptographic trick that allows people to trade information and value atomically over a blockchain. Gregory was also kind enough to help me demonstrate it to Financial Cryptography 2016!

    +

    In pay-to-sudoku, one person (the "buyer") can pay another person (the "seller") to solve a Sudoku puzzle. The seller solves the puzzle and encrypts the solution with a key that is then hashed. Using a zero-knowledge proof ― in this case, a zk-SNARK using libsnark ― the seller constructs a proof that they have an encrypted solution to the puzzle, and that knowledge of a particular SHA256 hash will permit decryption.

    +

    The buyer proceeds to submit a payment to the blockchain that allows the seller to redeem some funds in exchange for revealing the SHA256 preimage (the key). When the seller does this, the buyer can decrypt.

    +

    In order to achieve this with a zk-SNARK, the buyer is responsible for constructing a common reference string (CRS) that allows the seller to evaluate a proof. Campanelli, Gennaro, Goldfeder and Nizzardo have just published a new paper that identifies a flaw in the way pay-to-sudoku uses the PGHR construction implemented in libsnark. In particular, it assumes that the CRS has correct algebraic structure. It also does not check that certain elements of the CRS that need to be non-zero for zero-knowledge to hold are indeed non-zero. This gives the buyer an opportunity to violate zero-knowledge and obtain information about the solution without paying for it. They also note that even if these checks were carried out it is still not completely clear that zero-knowledge holds.

    +

    Interestingly, Zcash's public parameters are not vulnerable to this kind of malicious setup because the multi-party computation transcript guarantees the correctness of the CRS structure, and enables proving that zero-knowledge holds even if all of the participants of the MPC were dishonest. See our whitepaper for details. This is pointed out by the paper as well.

    +

    There are several mitigating steps that can be taken when using a third-party CRS. The most secure way would be, just as we did with Zcash's public parameters, to generate the CRS using our multi-party computation protocol. This guarantees zero-knowledge even if this protocol is carried out by just one player; .e.g. the buyer in the case of ZKCP. Alternatively, simply not allowing incorrect structure in the CRS is sufficient to defend against the particular attacks described in the paper. As an additional precaution, verify the proof after you construct it!

    +

    The paper additionally proposes some other interesting ideas, such as an extension of the concept of a ZKCP to the purchase of digital services rather than digital goods (like sudoku solutions).

    \ No newline at end of file diff --git a/_posts/2017-06-21-global-growth.md b/_posts/2017-06-21-global-growth.md new file mode 100644 index 0000000..7ba6e22 --- /dev/null +++ b/_posts/2017-06-21-global-growth.md @@ -0,0 +1,35 @@ +--- +ID: 1567 +post_title: Zcash Global Growth +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/global-growth/ +published: true +post_date: 2017-06-21 00:00:00 +--- +

    Internet money enables people to send money anywhere in the world, cheaply [1], and in minutes. Zcash can be used for remittances and also expands job opportunities for remote knowledge workers — freelancers and employees. Furthermore, many countries are experiencing increasing instability of local currencies, prompting citizens to look into other options for storing and transferring value.

    +

    The rapid growth of Zcash into a global ecosystem highlights the many opportunities for Internet money. Below are some of the recent developments.

    +
    +

    Argentina

    +

    The newest expansion of the Zcash ecosystem comes from Argentina where Ripio has opted to include Zcash as the second cryptocurrency in its wallet. In addition to faster confirmation times and lower transaction fees, Ripio is excited about the enhanced privacy features that Zcash offers.

    +

    Sebastian Serrano, CEO of Ripio, says "For each transaction the user can choose to disclose the transaction to specific parties, whereas in Bitcoin all transactions are disclosed to all parties."

    +

    Now, Argentineans can load the Ripio wallet with their pesos from bank transfers, and through a network of thousands of locations where the unbanked can deposit cash. They can buy and sell Zcash for pesos, and send and receive Zcash anywhere around the world. This is a valuable opportunity for a country which suffers from inflation, low banking, and trade barriers.

    +

    Ripio will also soon expand its Zcash service to Brazil and Mexico.

    +
    +
    +

    South Africa

    +

    Not long ago, we wrote about the exciting story of CoinBR and their SmartWallet application which allows Brazilians to buy, sell and make phone credit or tax payments with Zcash. They're now launching similar services in South Africa which offer users support for exchanging between Zcash and the South African rand, in addition to paying utility bills and making traffic ticket payments.

    +

    In a recent demo the CEO of CoinBR, Rocelo Lopes, used Zcash to pay a ticket for a South African user from his home in Brazil. This simple demo illustrated the simplicity of using Zcash for cross-border payments and demonstrated the limitless potential of Internet money.

    +

    At the same time, another cryptocurrency exchange, AltCoinTrader, has added support for Zcash, providing the region's cryptocurrency users more options for exchanging to and from South African rands.

    +

    To South Africans, we say “Zcash is not government money. Zcash is Internet money.”

    +
    +
    +

    China

    +

    Chinese markets have driven a large portion of cryptocurrency investments in recent years. An announcement by Chinese exchange viaBTC to include support for exchanging between Zcash and yuan means that there are now many different options for Chinese people to buy and sell Zcash for yuan.

    +
    +
    +

    And beyond

    +

    To all the new users introduced to Zcash by these recent developments: Welcome! As interest in Internet money continues to gain momentum, we're excited to hear about the other regions joining this expansion.

    +

    Please reach out to let the Zcash community know about any new support that we may not be aware of, especially in underserved areas. Wallets and exchanges considering adding Zcash support should reach out to us in email or by joining our community chat, we'd be happy to help!

    +
    [1]It currently costs $0.04 (4¢ U.S.) to send a Zcash transaction — containing any amount of money — anywhere in the world, in minutes. Cryptocurrency enthusiasts are well aware that it is a challenge to scale up a cryptocurrency to serve billions of people without causing the costs to rise precipitously. We at the Zcash team, along with many other researchers in academia and industry, are tackling that challenge. We hope to scale up Zcash to serve all humans while keeping costs as low as possible.
    \ No newline at end of file diff --git a/_posts/2017-06-22-new-release-1-0-10.md b/_posts/2017-06-22-new-release-1-0-10.md new file mode 100644 index 0000000..61b0118 --- /dev/null +++ b/_posts/2017-06-22-new-release-1-0-10.md @@ -0,0 +1,24 @@ +--- +ID: 1589 +post_title: 'New Release: 1.0.10' +author: Jack Grigg +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-10/ +published: true +post_date: 2017-06-22 00:00:00 +--- +UPDATE: We are aware of an issue that causes nodes running v1.0.10 to be unable to connect to other nodes, and vice versa. Users are advised to upgrade to v1.0.10-1, which fixes the issue. + +Today we're announcing the release of Zcash 1.0.10, which includes privacy and performance improvements, as well as bug fixes. + +Summary of the changes included in this release: +
      +
    1. We improved the privacy of transactions created by our wallet that pay from shielded addresses to transparent addresses. The new version conceals more information about shielded note values in chained JoinSplit transactions. (#2440)
      2. +
    2. We improved reindexing and block download performance by switching to libsecp256k1 for transparent signature validation. (#2335, stats)
      3. +
    3. We added a config parameter to reject transactions from the mempool by number of transparent inputs. This is a short-term workaround to handle periods of high network load, and will be replaced in the future by a more comprehensive mechanism. (#2342)
      4. +
    4. We merged several build system portability fixes. (#2412, #2420, #2436)
      5. +
    +We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. + +For a more complete list of changes, see our 1.0.10 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2017-06-24-new-release-1-0-10-1.md b/_posts/2017-06-24-new-release-1-0-10-1.md new file mode 100644 index 0000000..4229e33 --- /dev/null +++ b/_posts/2017-06-24-new-release-1-0-10-1.md @@ -0,0 +1,21 @@ +--- +ID: 1588 +post_title: 'New Release: 1.0.10-1' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-release-1-0-10-1/ +published: true +post_date: 2017-06-24 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.10-1, a hotfix release that all users are encouraged to upgrade to, especially users who updated to 1.0.10 in the last 48 hours. + +Summary of the changes included in this release: +
      +
    1. We reverted a change to version negotiation for the peer-to-peer protocol that caused degraded networking behavior. (#2473)
      2. +
    2. We disabled Proton building in Gitian. (#2462)
      3. +
    +We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. + +For a more complete list of changes, see our 1.0.10 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2017-07-26-cultivating-sapling-new-crypto-foundations.md b/_posts/2017-07-26-cultivating-sapling-new-crypto-foundations.md new file mode 100644 index 0000000..20f5c69 --- /dev/null +++ b/_posts/2017-07-26-cultivating-sapling-new-crypto-foundations.md @@ -0,0 +1,47 @@ +--- +ID: 1556 +post_title: 'Cultivating Sapling: New Crypto Foundations' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/cultivating-sapling-new-crypto-foundations/ +published: true +post_date: 2017-07-26 00:00:00 +--- +Zcash's next major protocol upgrade, codenamed Sapling, will feature a number of improvements to the performance, security and usability of our shielded transactions. This is the first in a series of blog posts that will explore progress made in Sapling's development. +
    +

    BLS12-381: a new zk-SNARK curve

    +Zcash's zk-SNARKs currently rely on a pairing-friendly Barreto-Naehrig elliptic curve construction implemented inside of libsnark, which was designed by our scientists many years ago. In the time since, Kim–Barbulescu's optimization to the number field sieve algorithm reduced the conjectured security level of this curve to around 110 bits, though the curve's concrete security given current research still remains around 128-bits as originally intended. + +As an extra precaution, we're taking the opportunity to upgrade our elliptic curve in the Sapling upgrade. Earlier this year, I presented a new curve called BLS12-381. This curve targets 128-bit security using more conservative recommendations suggested by several recent papers. + +There is now a Rust-language implementation of this curve. It comes with strong memory-safety guarantees as it does not use any unsafe{} code or assembly optimizations. Despite being a larger curve, this new implementation is more efficient than the implementation of BN254 that we currently use in Zcash. +
    Pairing crate benchmarks
    + +The speedups are especially pronounced in pairing and :math:`\mathbb{G}_2` arithmetic, which increases the performance of zk-SNARK proving and verification. + +
    +
    +

    New multi-exponentiation algorithm

    + +The most expensive part of creating a zk-SNARK proof is the evaluation of large polynomials over the elliptic curve groups :math:`\mathbb{G}_1` and :math:`\mathbb{G}_2`. This is done with a so-called "multi-exponentiation" algorithm that computes :math:`\prod_{i=0}^{n}{b_{i}^{s_i}}` for some large number of exponents :math:`\vec{s}` which reside in memory, and a large number of bases :math:`\vec{b}` which reside on disk inside the zk-SNARK proving key. + +Currently, we use libsnark's implementation of the Bos-Coster algorithm. In the worst case, this algorithm uses as much memory as the number of bases being operated on, and so the only avenue for decreasing memory usage is working with smaller subsets of the bases at a time. As an example, Ariel Gabizon implemented this kind of an optimization in a change to libsnark. + +libsnark has recently implemented a variant of Pippenger's algorithm which splits the multi-exponentiation into bitwise regions of the exponent, accumulating bases into buckets and performing summation by parts. This algorithm is not only more efficient than Bos-Coster, but is very convenient in the context of streamed proving. With this algorithm, we can avoid loading the proving key into memory before constructing a proof, which is a primary source of memory usage in our system. + +
    +
    +

    New proving system

    +Of course, performing fewer multi-exponentiations would also be a nice way to improve runtime performance. We are strongly considering the use of a new zk-SNARK proving system, discovered by Jens Groth, to replace PGHR (Pinnochio). This proving system makes stronger cryptographic assumptions, but has smaller proofs and faster proving/verification. + +What’s more, Groth’s new proving system allows us to design cheaper multi-party computations and other really interesting features that we’ll talk about more in a future blog post. + +
    +
    +

    Next steps

    +Although the above efforts combined offer substantial improvements to memory usage and proving time, reducing the size of our zk-SNARK circuit will have a much more noticeable effect. We have built a number of new crytographic primitives on top of the BLS12-381 construction which allow us to shrink the size of our arithmetic circuits, reduce the size of Zcash addresses, and simplify the protocol. + +In our next blog post, we'll talk more about these primitives and how much all of these improvements will help performance of our zk-SNARKs. +
    \ No newline at end of file diff --git a/_posts/2017-08-16-new-release-1-0-11.md b/_posts/2017-08-16-new-release-1-0-11.md new file mode 100644 index 0000000..c2af7ed --- /dev/null +++ b/_posts/2017-08-16-new-release-1-0-11.md @@ -0,0 +1,23 @@ +--- +ID: 1590 +post_title: 'New Release: 1.0.11' +author: Jack Grigg +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-11/ +published: true +post_date: 2017-08-16 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.11, which includes bug fixes and usability improvements. + +Summary of the changes included in this release: +
      +
    1. We fixed a 401 Unauthorized bug encountered when using some JSON-RPC libraries. (#2529)
      2. +
    2. We changed z_sendmany to fail with an error if the user sets minconf=0 when sending from z-addresses. (#2525, #2526)
      3. +
    3. We extended the listunspent RPC method to specify whether outputs were from a coinbase transaction, to help users identify t-addresses that need to have their contents shielded. (#2522)
      4. +
    4. We added a block download progress indicator to the metrics UI. (#2484)
      5. +
    5. We removed UPnP support (which was already off by default) for security reasons. (#2504)
      6. +
    +We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. + +For a more complete list of changes, see our 1.0.11 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2017-08-21-ux-research.md b/_posts/2017-08-21-ux-research.md new file mode 100644 index 0000000..948c130 --- /dev/null +++ b/_posts/2017-08-21-ux-research.md @@ -0,0 +1,28 @@ +--- +ID: 1646 +post_title: > + A Preliminary UX Survey of the Zcash + Ecosystem +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/ux-research/ +published: true +post_date: 2017-08-21 00:00:00 +--- +

    Zcash hired a user experience specialist to study the Zcash ecosystem. Linda works to streamline UX in software, but had no experience with cryptocurrency before this project.

    +

    Below are the resulting reports: the first illustrates what it’s like to purchase something with Zcash for the first time, the second examples Jaxx and Cryptonator for usability issues and interaction-related bugs, and the third summarizes general UX challenges across cryptocurrencies.

    +
    +Intro slide to "What it's like to buy something with ZEC for the first time" +
    +

    Join Linda as she tries to buy a charger with Zcash online. She was able to find a great availability of car chargers through purse.io, found that altcoins were supported on purse.io through Shapeshift, and successfully paid for the charger with cryptonator--but encountered some issues along the way.

    +
    +Screenshots from +
    +

    This report shows the UI bugs in each application, and how each handles potential errors. Jaxx onboards its users well and is easy to set up and use, but she recommends handling some edge interaction cases. Cryptonator has lots of security measures and handles errors well, but is hard to set up and navigate.

    +

    This final report talks about why people can’t see the benefits of using cryptocurrency, why they are hard to use, and why using cryptocurrency requires knowledge of cryptocurrency--and what we can do about it.

    +

    We chose two widely used third-party wallets, Jaxx and Cryptonator for this case study. We regularly recommend both of these wallets to users especially for mobile platforms and make use of them ourselves so we appreciate their willingness to let us study and critique their UX.

    +

    The study was limited to transparent ZEC transactions on Android mobile versions of Jaxx and Cryptonator. This was done to focus on the usability without Zcash-specific properties and features, but we intend to extend this research onto shielded addresses and focus on other applications. We hope this project provide some great insight into what it’s like to be a Zcash user.

    \ No newline at end of file diff --git a/_posts/2017-09-01-community-projects.md b/_posts/2017-09-01-community-projects.md new file mode 100644 index 0000000..44e6cbc --- /dev/null +++ b/_posts/2017-09-01-community-projects.md @@ -0,0 +1,66 @@ +--- +ID: 1551 +post_title: > + Celebrating the Zcash Developer + Community +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/community-projects/ +published: true +post_date: 2017-09-01 00:00:00 +--- +

    Since the launch of Zcash about 10 months ago, we've seen a promising selection of support from a variety of third-party developers. New and existing businesses have adopted Zcash into their wallet and exchange platforms which has helped to create a strong start for the ecosystem.

    +

    However, in this post we'd like to celebrate another set of third-party developers who contribute not just to the ecosystem but also as part of the community. You'll find these community developers in the chat and forum discussing new ideas, connecting with collaborators and sharing the projects they've been building and experimenting on.

    +

    These open source community projects are the heart of the Zcash ecosystem. They include ports of the official Zcash client which support other operating systems, a messaging platform which leverages the shielded address encrypted memo field and a private, decentralized storage network that uses Zcash for payments. Most of the development for these projects is fueled by a love to create interesting and useful tools and donations from the community. While many are experimental in nature, we look forward to their continued maturation and evolution.

    +

    So without futher ado, let's look at some of the interesting development work brought to you by the talented developers in the Zcash community.

    +
    +

    Zchain

    +

    Zchain developed and maintained by lustro, is the first Zcash block explorer. It was released during the first days of the Zcash blockchain and continues to be a vital resource for transaction data details and usage statistics. It also provides an API for developers to interact with transparent blockchain data.

    +
    +Zchain network map (Asia) +
    +

    The network map on Zchain is another useful tool showing stats and a beautiful visualization of nodes connected to the Zcash network.

    +
    +
    +

    Insight for Zcash

    +

    Insight is another blockchain explorer based on the bitcore library originally built for Bitcoin and was forked for the Zcash blockchain. It is helpful as a redundant resource for users searching for transparent Zcash transaction data and for web app developers interested in building Zcash services. This explorer is maintained by community developer radix42.

    +
    +
    +

    zcash-vanity

    +

    The zcash-vanity tool is a Zcash vanity address generator for shielded addresses written in Rust and maintained by PlutoMonkey. It is high-throughput and can run on GPU devices for faster address discovery.

    +
    +
    +

    vanitygen_z

    +

    The vanitygen_z tool is a vanity address generator for Zcash transparent addresses by community developers exploitagency and Voluntary. It is a fork of the vanitygen tool built for Bitcoin and works for standard (t1...) and multi-sig (t3...) addresses. This implementation includes further modification to support GPU devices.

    +
    +
    +

    zcash-mini

    +

    The zcash-mini tool by zmanian and FiloSottile is a minimal portable Zcash shielded address generator for offline and paper wallets. It also offers a vanity address generator and the ability to create shielded Zcash addresses with associated mnemonic strings.

    +
    +
    +

    zcash4win & zcash4mac & Swing Wallet

    +

    The two earliest ports of the official Zcash client are zcash4win and zcash4mac. We featured these applications in the first episode of our Show & Tell series where the developer, radix42, walks through the features of the software. Both are GUI desktop clients forked from Swing Wallet which is a separately maintained GUI wrapper for Zcash command line clients by vaklinov.

    +
    +Screenshot of Zcash Swing Wallet UI
    +
    +
    +

    Zcash Apple

    +

    Another project to support macOS is Zcash Apple by kozyilmaz. While it only provides command line tools, it is also compatible with the Swing Wallet GUI software. As of now, it is kept more up-to-date than the zcash4mac software but installing requires building the software from source. Instructions for doing so are provided in the documentation.

    +
    +
    +

    Pyzcto & Zcash Pannel

    +

    Pyzcto is an alternative UI built for the official Zcash client. It additionally allows users to set up an Onion service on the Tor network which can be used with the Zcash Pannel Android application. The Android app gives users the option of managing the Linux Zcash client from your phone connecting through Tor for added privacy. This pair of projects is maintained by community developer miguelmarco.

    +
    +
    +

    zmsg

    +

    An interesting piece of software called zmsg leverages the encrypted memo field of Zcash shielded transactions to send messages to others. We featured the developer of zmsg, whyrusleeping on the second episode of our Show & Tell series.

    +
    +
    +

    ORC

    +

    And last but not least, a new project called ORC leverages Tor and Kademlia routing to create a private, peer-to-peer object storage platform. The project has plans to integrate Zcash for payments to incentivise network nodes to host content. The ORC Project consists of a small team of open source developers.

    +
    +
    +

    And more...

    +

    These projects are just a selection of the interesting and exciting tools the Zcash community has been building since the launch of Zcash last October. We encourage Zcash users to support these projects by trying them out, providing feedback and donating to the developers. As we mentioned, most of these projects are still in an experimental phase so please be cautious when trusting them with your money.

    +

    The Zcash Foundation has recently announced their first grant program which community developers looking for financial assistance should certainly consider applying for to support underserved public services in the Zcash ecosystem. We also encourage all developers to share their ideas in the community chat and official forum.

    \ No newline at end of file diff --git a/_posts/2017-09-11-atomic-trades.md b/_posts/2017-09-11-atomic-trades.md new file mode 100644 index 0000000..0eda33a --- /dev/null +++ b/_posts/2017-09-11-atomic-trades.md @@ -0,0 +1,18 @@ +--- +ID: 1545 +post_title: An Update on Atomic Trades +author: Jay Graber +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/atomic-trades/ +published: true +post_date: 2017-09-11 00:00:00 +--- +

    Decentralization is a key characteristic of cryptocurrencies because it removes dependence on trusting third parties in order to transact between individuals. However, exchanges between different cryptocurrencies typically still require trust in a centralized exchange or counterparty. Cross-chain atomic trades (for which we have coined the acronym “XCATs”) remove the need for a single point of trust for trades between different cryptocurrencies. They rely on clever protocols that automatically exchange funds across two chains only if both participants hold up their end of the deal, and refund both participants otherwise. To support the decentralization of cryptocurrency, one of our near-term goals is to develop tools that will help carry out atomic trades across blockchains. [1]

    +
    +

    Zcash <-> Bitcoin Atomic Trades

    +

    We are excited to announce that we have been working on a command-line tool that executes atomic trades between Zcash t-addrs and Bitcoin addresses (view our recent demo of the tool). Several people have come up with XCAT protocols. Loosely speaking, they all rely on a mechanism where for one side to obtain their coins, a secret must be revealed that will enable the second party to also redeem their coins. There are many variants of this basic idea; see our XCAT ZIP for a detailed description of the specific protocol we use. Meanwhile, you are encouraged to try the experimental version of our tool, ZBXCAT, and report problems or ask questions on the alchemy channel of our community chat. The current version requires the user to run Bitcoin and Zcash full nodes, but a light-client version is in progress.

    +

    The way that funds are locked up on the blockchain to do atomic trades relies on hash-time lock contracts (HTLC). Zcash engineer Sean Bowe has submitted a BIP and pull request to make HTLCs a part of the standard RPC interface in the Bitcoin core client. However, it is not necessary to wait for this PR to be merged, as raw HTLC transactions can be constructed by compiling non-standard pay-to-script-hash transactions. We used python-bitcoinlib and a variant of it modified for Zcash to construct these scripts: https://github.com/arcalinea/python-zcashlib

    +

    To see an example of the redeem scripts used, view the scriptsig of this bitcoin transaction. This was one of the four transactions in the first atomic trade performed on testnet using our script, with the participation of community volunteer Jason Davies:

    +

    https://www.blocktrail.com/tBTC/tx/a0a2079411d73ec056e6a4ca0c9f9046056e652eb173c28165fb665c81af98f2

    +
    [1]We note that other groups have done/are doing excellent work on cross-chain trades, for example, barterDEX.
    \ No newline at end of file diff --git a/_posts/2017-09-12-zcash-on-bitpie.md b/_posts/2017-09-12-zcash-on-bitpie.md new file mode 100644 index 0000000..4e52e38 --- /dev/null +++ b/_posts/2017-09-12-zcash-on-bitpie.md @@ -0,0 +1,18 @@ +--- +ID: 1657 +post_title: Zcash on Bitpie +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-on-bitpie/ +published: true +post_date: 2017-09-12 00:00:00 +--- +

    We have an exciting update for the Zcash ecosystem about Bitpie integration. Zcash on Bitpie is live! (Or read the announcement in English.)

    +

    Bitpie is a simple and secure wallet developed by the Bither team and has a growing active userbase of over 50,000. With the inclusion of Zcash, now many more users will have the ability to send and receive Zcash from their Android phones and iPhones not only in China, but all over the world.

    +

    We asked the CEO of Bitpie Wen Hao why he chose Zcash. He said: “because zero knowledge proofs bring greater privacy, which is very attractive. And Zcash acceptance for domestic miners is better”.

    +

    We then asked why he or his users valued privacy, “because privacy is good for decentralization.” We are firm believers that privacy and decentralization are intimately connected.

    +

    Bitpie is an easy to use application and supports not only sending and receiving cryptocurrency, but also has integrated trade functions. Adding trade functionality between ZEC and BTC is in the works and they are looking to provide more trading functions in the future.

    +

    Bitpie also confirmed their interest in supporting shielded addresses in the near future. With more with easy-to-use wallet interfaces introducing shielded addresses into their software, users of the applications will gain enhanced privacy for transactions. On a larger scale, the ecosystem as a whole will become more private.

    +

    With the delisting of ICOs in China and subsequent climate of fear and uncertainty for all cryptocurrencies, Zcash is forging ahead and we're excited to welcome Bitpie's 50,000 Chinese users into our ecosystem.

    +

    Bitpie joins a growing list of third-party GUI applications supporting Zcash. Wallets considering adding Zcash support should reach out to us in email or by joining our community chat, we'd be happy to help!

    \ No newline at end of file diff --git a/_posts/2017-09-13-cultivating-sapling-faster-zksnarks.md b/_posts/2017-09-13-cultivating-sapling-faster-zksnarks.md new file mode 100644 index 0000000..827777e --- /dev/null +++ b/_posts/2017-09-13-cultivating-sapling-faster-zksnarks.md @@ -0,0 +1,25 @@ +--- +ID: 1555 +post_title: 'Cultivating Sapling: Faster zk-SNARKs' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/cultivating-sapling-faster-zksnarks/ +published: true +post_date: 2017-09-13 00:00:00 +--- +

    Zcash's next major upgrade, codenamed Sapling, will feature a set of groundbreaking performance improvements for our shielded transactions. In the last blog post of this series, we talked about a new elliptic curve for zk-SNARKs called BLS12-381, as well as new proving systems and other algorithms.

    +

    Matthew Green, Ian Miers and I are happy to announce that we have made significant performance improvements to the zk-SNARKs that Zcash uses. These improvements are being published open source, free of patents, for the broader crypto community.

    +
    +

    Jubjub

    +

    We have designed an elliptic curve called Jubjub which is efficient to perform operations on inside of zk-SNARK circuits built over our new BLS12-381 curve. These kinds of "embedded" curves have been explored in previous works such as Kosba et al. . We achieve record-breaking performance for fixed-based exponentiation.

    +

    Fast elliptic-curve cryptography in this context allows us to use more efficient primitives for commitment schemes and collision-resistant hashes. Combining the various techniques we've discussed in previous posts, we can get a rough idea of the performance improvements:

    +
    +Jubjub benchmarks
    +

    This rough estimate indicates an 80% reduction of proving time, and a 98% reduction in memory usage which is a key requirement for opening up mobile support for Zcash shielded addresses.

    +

    What's more, there are more optimizations and improvements that reduce these costs further that we plan to explore in future blog posts.

    +
    +
    +

    Technical Details

    +

    If you're interested in how Jubjub works, we've written an explainer page. We have also written an early prototype to showcase and benchmark these new cryptographic primitives.

    \ No newline at end of file diff --git a/_posts/2017-09-20-ethereum-snarks.md b/_posts/2017-09-20-ethereum-snarks.md new file mode 100644 index 0000000..d411093 --- /dev/null +++ b/_posts/2017-09-20-ethereum-snarks.md @@ -0,0 +1,21 @@ +--- +ID: 1559 +post_title: Ethereum Adoption of zk-SNARK Technology +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/ethereum-snarks/ +published: true +post_date: 2017-09-20 00:00:00 +--- +The Ethereum Metropolis (Byzantium) upgrade adds a new cryptographic tool (zk-SNARKs) that was pioneered by Zcash. The addition of zk-SNARK technology into Ethereum is another validation, like the JP Morgan partnership, that privacy and auditability are important for business and for the economy, and that zk-SNARKs are the premier technology for privacy and auditability. + +We're happy to see the spread of this powerful technology, we're proud to have helped Ethereum with this project, and we're looking forward to seeing what the devs who program The Ethereum World Computer do with it. + +It's important to note that the addition of the zk-SNARK technology does not by itself provide privacy protection for Ethereum users. There is a new tool in the toolbox, but for now Ethereum transactions are no more private than before. + +With Zcash today, people are receiving, holding, and sending money under the protection of encryption. Zcash is like SSL was for the early World Wide Web — a way to protect your data from bad actors and enable commerce. Zcash has been serving an active and growing base of users for almost one year. + +Unlike Ethereum, Zcash is not a general-purpose World Computer; it is just a global, open payment network. + +We're already hard at work on our next generation cryptography, which greatly improves the efficiency, to enable smartphone users. Going forward, we'll continue to improve the technology, continue to provide a safe and useful network for our growing global community, and continue to cooperate with other projects like Ethereum that are contributing in their own way to the betterment of humanity. We'll also continue to work on new technologies that could connect the Ethereum and Zcash currencies and blockchains. \ No newline at end of file diff --git a/_posts/2017-09-21-ceremony-audit-results.md b/_posts/2017-09-21-ceremony-audit-results.md new file mode 100644 index 0000000..29158c8 --- /dev/null +++ b/_posts/2017-09-21-ceremony-audit-results.md @@ -0,0 +1,54 @@ +--- +ID: 1550 +post_title: Ceremony Audit Results +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/ceremony-audit-results/ +published: true +post_date: 2017-09-21 00:00:00 +--- +As a science-focused team, ensuring the security of the Zcash protocol and the users of the network is a natural part of our development process. We are committed to serving our users and community, and one of the best ways we can do that is to provide transparency. We've shared the results of previous security audits that we contracted expert teams to undertake, and we intend to continue doing so on a regular basis. + +Today, we're sharing the results of an audit reviewing the parameter generation ceremony which took place just before the launch of the network last year. We contracted with NCC Group to analyse artifacts gathered from the station they operated as part of the ceremony. As participants, they had access to the compute node used to generate their shard of the toxic waste private key and the commitment hashes created and transferred between the network and compute nodes. + +In addition to the production compute node, NCC Group set up a test compute node which was a copy of the production node but modified with forensics capabilities to detect vulnerabilities in the process. This investigation was a protected secret until after the Ceremony completed, as described below in Operational Security. + +The NCC Group investigation did not reveal any fatal vulnerabilities in the Ceremony. It is important to emphasize that audits and forensics investigation cannot prove the absence of compromise. However, these results are one more of a set of measures the Zcash team undertook to provide strong assurances against compromise. + +Remember that the first line of defense was the Multi-Party Computation: in order for an attack to succeed, the attackers would have had to compromise all of the participants in the Ceremony. +
    +

    Audit Results

    +
    + +Summary: +
    "To perform such attacks, NCC Group and Zcash architected an attack test bed that modeled the ceremony, and NCC Group would operate under the name 'Moses Spears.' NCC Group would (and did) remain in audio/visual contact with the other ceremony members throughout the ceremony. NCC Group performed the tests by setting up a third node that was a copy of the compute node being used in the ceremony. This system was air gapped and used an exact copy of the DVD-R that was used in ceremony. + +Each attack was performed by NCC Group and only the DMA attack was successful at extracting memory from the 'test' compute node. The DMA attack was only able to perform a partial extraction of memory. Based on this finding, it is our recommendation that the computation process perform a pre-compute validation step that audits any detected DMA surface areas, namely FireWire, for being present on the device. + +After the ceremony was completed, an audit was performed on all of the ceremony media used to boot the live environment. Throughout the audit, no malicious processes were identified and no network listeners, or network transmissions, were attempted by the compute node on boot. Video of the ceremony, when in action, was taken. The facility's closed-circuit video, alarms, and access control systems were operable throughout the ceremony and no anomalous activity was detected during the ceremony. + +Based upon the evidence examined by NCC Group, it is our expert opinion that the NCC Group compute node was not compromised throughout the duration of the event."
    +
    +You can also read the complete NCC Group report. + +
    +
    +

    Operational Security

    +The Zcash team made a best effort at operational security for this investigation. By limiting knowledge of this operation, we strove to maximize the chance of catching any attacker "red-handed". + +By intention, within the Zcash team, only Nathan and Zooko knew about this plan until after the Ceremony completed. Communication with NCC Group about this occurred over PGP encrypted emails and some Google Hangout conferences and phone calls. We requested that knowledge of this investigation remain limited within NCC Group, and their team has experience with such internal compartmentalization. + +Because the Zcash Company was already engaged with NCC Group for security audits of the Zcash codebase (see Audit Results), this provided useful cover for discovery of the operation. For example, we already had regular PGP-encrypted correspondence with NCC Group, and administrative issues like contracts and invoicing could be handled without revealing this operation to a wider audience. An attacker monitoring communication metadata such as would not see noticeable change in who we communicated with. + +Notably, Ceremony participants, designers, and engineers were unaware of this operation until after the Ceremony completed. NCC Group used a pseudonymous email address and identity for coordinating their participation in the Ceremony. + +Of course, none of this is a guarantee against a compromise, and our operational security wasn't perfect (for example we have no specific knowledge of Google Hangout content confidentiality). It was our best effort given our resources and expertise. + +
    +
    +

    Conclusion

    +Given that a single uncompromised participant in the ceremony suffices for security of the resulting parameters, NCC Group's findings reinforce our confidence in the integrity of the parameter generation ceremony. We will continue to commission independent audits and publish the results as we develop and improve Zcash, especially with the Sapling cryptography improvements and protocol upgrade. Keep an eye out on our blog for more information on future reports. + +
    \ No newline at end of file diff --git a/_posts/2017-09-22-release-cycle-update.md b/_posts/2017-09-22-release-cycle-update.md new file mode 100644 index 0000000..8d02344 --- /dev/null +++ b/_posts/2017-09-22-release-cycle-update.md @@ -0,0 +1,28 @@ +--- +ID: 1614 +post_title: Release Cycle Update +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/release-cycle-update/ +published: true +post_date: 2017-09-22 00:00:00 +--- +Ahead of the 1.0.9 release a few months ago, the Zcash development team announced a new monthly release cycle and deprecation policy. We learned a lot in the first month of the release cycle and decided to extend it to 6 weeks. We've discussed this openly in the community chat #zcash-dev channel and in the weekly forum developer updates. + +This cycle extension allows for several improvements: +
      +
    • better planning of in-progress and subsequent releases;
      • +
    • more time for pre-release testing and development infrastructure improvements;
      • +
    • less frequent updating for users and third-party services.
      • +
    +
    +

    Auto-senescence & 1.0.9 Deprecation

    +This change to the release cycle length affects how they line up with the auto-senescence feature we introduced in the 1.0.9 update and the 18 week schedule it runs on. We do not plan on updating the deprecation time frame so now a version will become deprecated at about the same time the 3rd subsequent version is released. For example, version 1.0.9 will be deprecated just as version 1.0.12 is released. A warning will appear for nodes running the official Zcash client about two weeks before the version they are running is set to become deprecated. + +As we stated previously, once a version is deprecated via the auto-senescence feature, nodes running that version will automatically exit when they detect they've reached their deprecation phase. This feature will always have the ability to opt-out but it's important to note that for deprecated releases, the only help the Zcash Company user support team promises is in upgrading to the latest release. + +At block 193076, all nodes running version 1.0.9 which do not have the -disabledeprecation=1.0.9 flag set to opt out of auto-senescence will automatically shut down. These nodes should already be receiving a related message about the upcoming version deprecation. + +Of course we recommend that instead of using the configuration to disable deprecation of 1.0.9 that node operators update to the most recent version of zcashd or another well-maintained implementation. Client and network security improvements are often addressed in releases so it's a good idea to always stay updated with the most recent version. If there is a particular reason why you cannot update or do not want to, please reach out to us in the community chat or by email so we can better understand your needs. We're also happy to answer any questions about the release cycle or deprecation policy and will communicate any future changes to these processes we deem beneficial. \ No newline at end of file diff --git a/_posts/2017-09-28-new-release-1-0-12.md b/_posts/2017-09-28-new-release-1-0-12.md new file mode 100644 index 0000000..9e1849a --- /dev/null +++ b/_posts/2017-09-28-new-release-1-0-12.md @@ -0,0 +1,28 @@ +--- +ID: 1591 +post_title: 'New Release: 1.0.12' +author: Jack Grigg +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-12/ +published: true +post_date: 2017-09-28 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.12, which includes bug fixes and usability improvements. It also adds a new RPC method z_shieldcoinbase as an experimental feature, for easily shielding coinbase UTXOs. We encourage mining pools and exchanges to test it out over the next few weeks, and give feedback, before we make it a fully-supported RPC method in an upcoming release. + +Summary of the changes included in this release: +
      +
    1. We added z_shieldcoinbase as an experimental feature. (#2615)
      2. +
    2. We changed the importprivkey RPC method to return the public address corresponding to the imported key. (#2616)
      3. +
    3. We fixed build issues encountered when using GCC 7. (#2545)
      4. +
    4. We added support for fetching the public network parameters from IPFS. (#2597)
      5. +
    +We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. + +For a more complete list of changes, see our 1.0.12 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. + +REMINDER: The 1.0.9 release will reach deprecation in the next day or so, and 1.0.9 nodes will automatically shut down at that time. See our blog post last week for details. Users running 1.0.9 should take one of the following steps: +
      +
    • Upgrade to the latest release of zcashd.
      • +
    • Opt-out of deprecation by using the -disabledeprecation=1.0.9 config flag.
      • +
    \ No newline at end of file diff --git a/_posts/2017-09-28-zcash-on-bithumb.md b/_posts/2017-09-28-zcash-on-bithumb.md new file mode 100644 index 0000000..2d4b257 --- /dev/null +++ b/_posts/2017-09-28-zcash-on-bithumb.md @@ -0,0 +1,19 @@ +--- +ID: 1656 +post_title: Zcash on Bithumb +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-on-bithumb/ +published: true +post_date: 2017-09-28 00:00:00 +--- +

    We are very pleased to announce the addition of Zcash to the highest-volume cryptocurrency exchange in the world — Bithumb of South Korea. With the evolving regulatory situation in China for all cryptocurrencies, it's promising to see the Zcash ecosystem continuing to grow in the greater Asian market and around the world.

    +

    This announcement not only opens up access to Zcash for more people but also allows users to benefit from Bithumb's listing of ZEC through a promotional "cash back" program. Users who trade with ZEC before the promotion concludes will earn additional ZEC. You can find more details on the program on the cash back announcement page.

    +

    The VP of Bithumb, Jung-A Lee, expressed four reasons to support Zcash:

    +
    • Strong, stable network.
      • +
    • Tons of transactions already sent.
      • +
    • World-wide mining and trading.
      • +
    • Zero-knowledge proof technology.
      • +

    Bithumb's Korean customers are some of the most eager traders in the world creating exceptional liquidity for the cryptocurrencies listed on Bithumb's platform. The improved access to ZEC and the subsequent increase in exchange volume are important for Zcash's global, long-term market presence. Bithumb's Zcash support introduces the opportunity for one million new users to join the Zcash ecosystem.

    +

    Bithumb joins a growing list of exchanges supporting Zcash in different regions around the world. Exchanges considering adding Zcash support should reach out to us via email or by joining our community chat, we'd be happy to help!

    \ No newline at end of file diff --git a/_posts/2017-09-29-crypto-is-currency.md b/_posts/2017-09-29-crypto-is-currency.md new file mode 100644 index 0000000..1cb3022 --- /dev/null +++ b/_posts/2017-09-29-crypto-is-currency.md @@ -0,0 +1,27 @@ +--- +ID: 1554 +post_title: 'Crypto is currency: spend your ZEC!' +author: Linda Lee +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/crypto-is-currency/ +published: true +post_date: 2017-09-29 00:00:00 +--- +

    The best way to promote cryptocurrencies is by using them as currency. Join Zcash in spending some ZEC today, September 29th for #CryptoIsCurrency Day!

    +

    For this day, we partnered with OpenBazaar, a decentralized marketplace whose mission is to allow its users to buy products and services in a secure, private, decentralized, and uncensored way from anywhere in the world, using money that shares their values.

    +

    OpenBaazar’s default currency is BTC, but you can now use ZEC to fund your OpenBaazar wallet via Shapeshift, and can pay with funds from your OpenBaazar wallet during checkout. This is a great option if you have ZEC to spend but not BTC, or if you would like to use Zcash’s shielded addresses to encrypt your transaction’s metadata for extra privacy.

    +
    +A screenshot showing the ability to fund an OpenBazaar wallet with Zcash
    +

    We took the opportunity to send some physical goods to a Zcash supporter in Venezuela. The Zcash Foundation recently published a guide to Zcash for Venezuelans and as of this week, 1 Bolivar is equal to one satoshi (the smallest unit in bitcoin) marking the rate of the country’s hyperinflation at 2000%.

    +

    Unlike Amazon or other big companies, OpenBaazar’s decentralized marketplace ships to countries that are in conditions of political and economic distress. Had we not used OpenBazaar, shipping to Venezuela would have required a complicated re-mailing service. When you use OB1 as your search provider, you can filter your search results by where items can be shipped to.

    +
    +A screenshot of item listings on OpenBazaar
    +

    There are thousands of items available for purchase, and more listings are added every day. Some of the things currently available for purchase include: cryptocurrency consulting, chocolate, silverware, and jewelry!

    +

    We would love to personally see more household items and shelf-stable foods in the marketplace and shipping for countries all around the world. Economically unstable regions like Venezuela really need our help. It's become more and more difficult to ship basic resources into the country due to major players like Amazon restricting their shipping there. With a decentralized marketplace like OpenBazaar, vendors can use their own methods of shipping to Venezuela and even help each other navigate the best ways to send things into the country.

    +

    Of course, crypto is currency everyday so we encourage using Zcash for purchases beyond this campaign, but today, we call on the Zcash community to celebrate cryptocurrencies as currencies and buy something on OpenBaazar for #CryptoIsCurrency Day! Here are some resources:

    +
    • Get started with Zcash.
      • +
    • Download link to OpenBazaar 2.0 .
      • +
    • A video tutorial covering download, installation, purchasing, setting up a store, and more.
      • +
    • A special video covering how to fund your OB wallet with altcoins, like ZEC.
      • +

    Keep an eye out here for a comprehensive UX report on using OpenBazaar for the first time and how it compares to centralized marketplaces. Overall, we're very excited for the potential of these tools and are excited about working with OpenBazaar to improve usability and experience in the Zcash and cryptocurrency ecosystems.

    \ No newline at end of file diff --git a/_posts/2017-10-02-zcash-on-cexio.md b/_posts/2017-10-02-zcash-on-cexio.md new file mode 100644 index 0000000..c13e1b4 --- /dev/null +++ b/_posts/2017-10-02-zcash-on-cexio.md @@ -0,0 +1,17 @@ +--- +ID: 1658 +post_title: Zcash on CEX.IO +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-on-cexio/ +published: true +post_date: 2017-10-02 00:00:00 +--- +

    We're happy to announce that CEX.IO is the newest exchange to list Zcash trading!

    +

    CEX.IO is a multi-functional cryptocurrency exchange serving a range of users from beginners to institutional traders. Now with the inclusion of Zcash, not only is trading ZEC more accessible to UK and European markets but CEX.IO is also unique amongst the large exchanges to offer funding to and withdrawing from accounts using credit or debit cards. This feature provides a quick, simple and therefore important on-ramp for new and existing users to acquire Zcash.

    +

    From CEX.IO CEO Alex Lutskevych: +"We at CEX.IO are strict in terms of choosing cryptocurrencies for our markets. Zcash functionality and the technology standing behind the coin are a strong background promising the growth. We see it as a successful example of a service built using Bitcoin protocol and adding extra privacy. To meet the strong demand of our users, Zcash market on CEX.IO will be launched with 4 trading pairs: ZEC/USD, ZEC/EUR, ZEC/GBP, and ZEC/BTC”.

    +

    Established in 2013 and with over one million registered users, CEX.IO serves consumers with bank accounts and credit/debit cards in many countries and, at the time of this post, 24 US states.

    +

    Additionally, with consumer demand CEX.IO will add Zcash bundles to their platform, providing a fast way to purchase fixed amounts of ZEC with a card or bank account.

    +

    CEX.IO joins a growing list of markets supporting Zcash. Other exchanges considering adding Zcash support should check out our integration guide and reach out to us in email or by joining our community chat, we'd be happy to help!

    \ No newline at end of file diff --git a/_posts/2017-10-17-jpm-quorum-integration.md b/_posts/2017-10-17-jpm-quorum-integration.md new file mode 100644 index 0000000..bfe3a93 --- /dev/null +++ b/_posts/2017-10-17-jpm-quorum-integration.md @@ -0,0 +1,30 @@ +--- +ID: 1574 +post_title: > + Zerocoin Electric Coin Company + Integrates Zero-knowledge Security + Technology on J.P. Morgan’s Quorum +author: Jack Gavigan +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/jpm-quorum-integration/ +published: true +post_date: 2017-10-17 00:00:00 +--- +

    New York, October 17, 2017 - The Zerocoin Electric Coin Company and J.P. Morgan today announced the integration, and initial release of, zero-knowledge security layer (ZSL) technology on Quorum, J.P. Morgan’s enterprise, smart contract blockchain platform. The combination further unlocks the potential of blockchain technology for enterprise use cases.

    +

    “The momentum that is growing behind enterprise blockchain adoption is one of the most exciting trends in technology,” said Zooko Wilcox, CEO of The Zerocoin Electric Coin Company. “This latest development ensures confidentiality, while supporting regulatory disclosure, both of which are key requirements for financial industry applications.”

    +

    J.P. Morgan and the Zerocoin Electric Coin Company announced a technology partnership earlier this year in an effort to combine talents in developing distributed ledger financial technology. Microsoft has also lent its support to the effort. All three companies are members of the Enterprise Ethereum Alliance.

    +

    "Today’s announcement is a prime example of how big banks and fintechs can work side-by-side to build ground breaking technology for the financial markets,” said Umar Farooq, head of Blockchain Initiatives at J.P. Morgan.

    +

    "The implementation of ZSL for Quorum represents an important application of zero-knowledge proofs to the challenge of building a distributed trust infrastructure for enterprises” says Marley Gray, Principal Program Manager for Blockchain at Microsoft. “I expect that this is merely the first of many applications for this exciting technology."

    +

    The ZSL technology is being released as open source software, meaning that interested organizations can immediately download and begin experimenting with it to assess its capabilities and suitability for specific use cases.

    +

    J.P. Morgan and the Zerocoin Electric Coin Company will continue to work with the broader enterprise blockchain community to integrate their feedback and ideas into future versions.

    +

    Zerocoin Electric Coin Company Media Contact: press@z.cash

    +
    +

    About The 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 $22.7 trillion of assets under custody and $421.6 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 at www.jpmorgan.com.

    +
    \ No newline at end of file diff --git a/_posts/2017-10-28-state-of-the-network-1-year.md b/_posts/2017-10-28-state-of-the-network-1-year.md new file mode 100644 index 0000000..57278ba --- /dev/null +++ b/_posts/2017-10-28-state-of-the-network-1-year.md @@ -0,0 +1,20 @@ +--- +ID: 1635 +post_title: 'State of the Network: 1 Year' +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/state-of-the-network-1-year/ +published: true +post_date: 2017-10-28 00:00:00 +--- +

    One year ago, we published our very first State of the Network announcing the successful launch of Zcash 1.0 “Sprout”. Much of the Zcash team were gathered in the livingroom of an Airbnb in Pacifica, California to see the project we had dedicated many months of effort to build finally reach genesis. And many of you watched.

    +

    Since then, the Zcash ecosystem has experienced radical growth, the Zcash network has been pushed to limits and the Zcash zk-SNARK technology has gained substantial notoriety in the greater cryptocurrency and privacy communities. In one year, we've seen adoption of Zcash into wallets developed by both individuals in the community and established companies. We've seen adoption into markets all around the world.

    +

    Since the launch of Zcash, we've released 12 software updates for the official Zcash client and have additionally maintained a regular schedule of weekly developer updates.

    +

    We've improved internal procedures including the official client release cycle and a security procedure for investigating potential vulnerabilities to users. We're proud to be able to state that no bugs in the code have caused loss of funds or loss of privacy.

    +

    During this year, the Zcash Foundation established itself as an entity distinct from the Zcash Company with it's own executive board and regular weekly office hours. Some of their first projects include distributing pioneer awards to key contributors in the Zcash community, helping organizations accept Zcash donations and establishing a Grant program to fund ideas and projects improving the Zcash ecosystem. More recently, the Foundation was granted 501(c)3 status.

    +

    Research and development for Zcash 2.0 "Sapling" is well underway. We are planning the roadmap documenting what the steps will be to get there with a goal to have it ready by the end of 2018. Sapling will bring with it substantial improvements to the security and efficiency of the cryptography used by Zcash shielded addresses.

    +

    While we wait for Sapling, however, other previously mentioned features will be introduced into Sprout which improve usability of shielded addresses.

    +

    The future year has a lot more in store for Zcash and we look forward to sharing those achievements in the 2 year anniversary State of the Network.

    +

    Happy Birthday Zcash Community! <3

    \ No newline at end of file diff --git a/_posts/2017-10-31-new-mpc-protocol.md b/_posts/2017-10-31-new-mpc-protocol.md new file mode 100644 index 0000000..669f7a4 --- /dev/null +++ b/_posts/2017-10-31-new-mpc-protocol.md @@ -0,0 +1,36 @@ +--- +ID: 1587 +post_title: > + Improved zk-SNARK Multi-party + Computation Protocol +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-mpc-protocol/ +published: true +post_date: 2017-10-31 00:00:00 +--- +

    zk-SNARKs – the zero-knowledge proofs at the core of Zcash – require a parameter generation ceremony to take place for every statement that you wish to create proofs about. Although privacy is protected by zk-SNARKs unconditionally, if this ceremony is compromised it becomes possible to counterfeit Zcash. It is thus important for us to ensure these parameters are created securely.

    +

    Last year, Zcash performed such a ceremony using a multi-party computation (MPC) protocol. These protocols have the property that only one party needs to be uncompromised for the resulting parameters to be secure. In other words, in order to compromise the ceremony, every participant needed to be compromised.

    +

    However, the protocol we used for the ceremony could not scale beyond a handful of participants. As we continue to upgrade Zcash, we will need to perform more of these setups, so improving the scalability and performance of this protocol is important to us. Also, projects outside Zcash that wish to use zk-SNARKs may need to perform their own setups, so we'd like to make it cheaper and easier for them as well.

    +

    Ariel Gabizon, Ian Miers and I have just published a paper detailing a new MPC protocol which can scale to a practically unbounded number of participants. The paper also includes the strengthened elliptic curve construction, BLS12-381, which we've blogged about before.

    +
    +

    Player-exchangeable MPC

    +

    In the original MPC protocol, all participants needed to commit to their share of the "toxic waste" in advance in order to protect against adaptive attacks. This meant that all of the participants needed to be available for the entire duration of the protocol, and nobody could abort without causing the entire protocol to abort. Participants needed to maintain custody of their hardware throughout the process, so this meant the ceremony could not scale beyond a handful of people.

    +

    Our new protocol is what we like to call a player-exchangeable MPC. As before, only one participant needs to be honest for the ceremony to be secure. But unlike before, participants join the protocol, do their part and leave immediately. This allows the ceremony to scale to a large number of participants and take place over a longer period of time. It also decreases the surface area of attack for participants and avoids the need for expensive synchronization.

    +
    +
    +

    Two phases

    +

    The original MPC protocol involved three phases of computation. Participants needed to act and then wait for their turn in the next phase. In between the first and second phase, we needed to perform very expensive fast-fourier transforms. As a result of all this, performance of the original MPC was poor.

    +

    In the new protocol, we’ve managed to reduce the MPC to two phases. What's more, the first phase is agnostic to the precise zk-SNARK circuit, and so a large communal ceremony can be performed which evaluates this phase for all projects that wish to use zk-SNARKs. The second phase does not involve fast-fourier transforms, which means that MPCs for Zcash and other projects can scale to an unbounded number of participants without overly expensive computations.

    +

    We have begun an implementation of this first phase of the multi-party computation ceremony, written in Rust, which uses the new BLS12-381 elliptic curve.

    +
    +
    +

    Summary

    +

    This new protocol allows for far more secure zk-SNARK parameter generation ceremonies:

    +
    • It allows the ceremony to involve a larger number of participants, with the same property that only one of them needs to be honest to guarantee the parameters are secure.
      • +
    • It allows us to give participants significant flexibility in the hardware and operating system they use to participate. As a result, it allows us to reduce the number of dependencies and code that we must audit.
      • +
    • It greatly reduces the time participants must spend in the ceremony, reducing the surface area of attacks and allowing a broader set of participants to contribute.
      • +
    • It uses a stronger elliptic curve construction which improves security.
      • +

    We look forward to sharing more details about zk-SNARK parameter generation ceremonies in the near future.

    +
    \ No newline at end of file diff --git a/_posts/2017-11-09-zcash-investment-trust.md b/_posts/2017-11-09-zcash-investment-trust.md new file mode 100644 index 0000000..c1de203 --- /dev/null +++ b/_posts/2017-11-09-zcash-investment-trust.md @@ -0,0 +1,15 @@ +--- +ID: 1654 +post_title: > + Grayscale Launches Zcash Investment + Trust +author: Zerocoin Electric Coin Company +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/zcash-investment-trust/ +published: true +post_date: 2017-11-09 00:00:00 +--- +

    This morning, Grayscale Investments launched the Zcash Investment Trust. Grayscale, a trusted authority on digital currency investments, has $1.2 billion in assets under management. The Zcash Investment Trust is its third investment vehicle, following the Bitcoin Investment Trust (OTCQX: GBTC) and the Ethereum Classic Investment Trust.

    +

    The Trust’s shares are the first securities solely invested in Zcash. The investment objective of the Trust is for the shares to reflect the value of the ZEC held by the Trust, determined by reference to the TradeBlock ZEC Composite Reference Rate at 4:00 p.m. New York time, less the Trust’s expenses and other liabilities. The Trust is a passive investment vehicle that is not actively managed. The Sponsor believes that, for many investors, the shares will represent a cost-effective and convenient investment relative to a direct investment in ZEC.

    \ No newline at end of file diff --git a/_posts/2017-11-13-ux-evaluation-openbazaar.md b/_posts/2017-11-13-ux-evaluation-openbazaar.md new file mode 100644 index 0000000..08c164e --- /dev/null +++ b/_posts/2017-11-13-ux-evaluation-openbazaar.md @@ -0,0 +1,50 @@ +--- +ID: 1645 +post_title: UX evaluation of OpenBazaar +author: Linda Lee +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/ux-evaluation-openbazaar/ +published: true +post_date: 2017-11-13 00:00:00 +--- +

    We believe that the usability of wallets and services that accept cryptocurrencies make a huge impact on user adoption and motivation to use cryptocurrencies. For this reason, we're continuing our process of evaluating various services in the Zcash ecosystem.

    +

    For a previous blog post about Crypto Is Currency Day we used OpenBazaar to purchase a tshirt for a Zcash user living in Venezuela. This evaluation dives deeper into analysis of their getting started tutorial, the software's search function, the built-in wallet and seller tools.

    +

    Even if you haven’t heard of or use OpenBazaar, we hope that this evaluation provides insights on how to build a seamless user experience for a crypto-based service. OpenBazaar has recently released OpenBazaar 2.0 so to express our support, we’d like to highlight some good decisions and offer some suggestions to improve the user experience in a transparent and open process.

    +
    +

    Onboarding new users

    +

    How we felt supported while onboarding: OpenBazaar has a very thorough video tutorial that walks through the installation, signup, buying, and selling process. It provides technical support to users before they ask for it, anticipating the potential points where users would struggle. It also highlights all their features, which acts as a guide and onboarding process as well. The video format is very accessible to non-technical users who wouldn’t want to read a text-heavy manual.

    +
    +Screenshot of the OpenBazaar 2.0 Tutorial video +
    +

    Our suggestion to engage users faster: decrease the time between installation and what users want to do. We believe that this is showing what’s currently listed on OpenBazaar (like the cover shot for the tutorial on youtube!). Currently, users need to create an account and configure settings before they can see those listings, which creates a bit of friction. Showing people enticing listings that they can buy will get them excited, and when they want to buy something, they are more cheerfully willing to invest in the effort to create an account.

    +
    +
    +

    Searching and filtering items

    +

    What we loved about the search function: OpenBazaar lets you search for items by condition, content, rating, shipping availability, and type of item. We especially like the idea of being able to search only through highly rated listings, or browsing digital goods.

    +
    +Screenshots of OpenBazaar 2.0 Search UI
    +

    Our suggestion for streamlining the search process: inform the users about the different search engines and how they differ from each other. For instance, using the different search engines results in different default listings, and different number of total items, but it’s not quite clear why.

    +
    +Screenshots of OpenBazaar 2.0 Search UI
    +
    +
    +

    Using the built-in wallet

    +

    Why we appreciated a built-in wallet: currently, OpenBazaar only works with wallets that support Segregated Witness (SegWit). To provide users with a way to purchase items without hunting for a compatible wallet, OpenBazaar provided their own.

    +
    +Screenshots of OpenBazaar 2.0 Search UI
    +

    Our suggestion to highlight this as a feature, not an afterthought: inform users up front that there are two ways to purchase items--with an external wallet and an internal wallet. When we first used OpenBazaar, we found that we needed to use the internal wallet when we got to the checkout screen.

    +
    +
    +

    Engaging vendors

    +

    How we think the client supports vendors well: the store setup and item listing interfaces are modern, feature-rich, and easy to use. And with the update, vendors now have more tools to help them manage their stores, such as inventory management, variants, coupon codes, and detailed shipping options.

    +
    +Screenshots of OpenBazaar 2.0 Search UI
    +

    Our suggestion for additional vendor engagement: highlight the benefits of using OpenBazaar in a that will resonate with them. For instance, highlighting the fact that there are no fees to list items, no fees when an item is sold, and no middleman in the transaction would really motivate vendors to set up stores on OpenBazaar, but it doesn’t say this anywhere in the application!

    +
    +
    +

    Try OpenBazaar and stay tuned for more UX reviews

    +

    OpenBazaar is an online, decentralized marketplace whose mission is to allow its users to buy products and services in a secure, private, decentralized, and uncensored way, from anywhere in the world, using money that shares their values. We are big fans of OpenBazaar at Zcash, and encourage you to check out OpenBazaar 2.0!

    +

    We'll continue to post user experience evaluations as we engage in more studies of services within the Zcash ecosystem. If you'd like to stay updated on our UX research, be sure to stay tuned to this blog.

    +
    \ No newline at end of file diff --git a/_posts/2017-11-20-new-release-1-0-13.md b/_posts/2017-11-20-new-release-1-0-13.md new file mode 100644 index 0000000..6caa25a --- /dev/null +++ b/_posts/2017-11-20-new-release-1-0-13.md @@ -0,0 +1,28 @@ +--- +ID: 1592 +post_title: 'New Release: 1.0.13' +author: Simon Liu +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-13/ +published: true +post_date: 2017-11-20 00:00:00 +--- +Today we're announcing the release of Zcash 1.0.13, introducing new features, performance improvements and bug fixes. Our new low-memory prover reduces memory usage by 43% when generating a shielded transaction, from 3 GB to 1.7 GB. An experimental feature, payment disclosure, can help services better manage their shielded payments. We also now fully support the z_shieldcoinbase RPC call to help miners sweep up and shield their coinbase rewards. + +Summary of the changes included in this release: +
      +
    1. Auto-senescence cycle has been reduced from 18 to 16 weeks. (#2733)
      2. +
    2. Low-memory prover reduces JoinSplit creation memory usage from 3 GB to 1.7GB. (#2670, stats)
      3. +
    3. Payment disclosure has been added as an experimental feature with new RPC calls z_getpaymentdisclosure and z_validatepaymentdisclosure (#2159). This feature enables a sender to prove that a payment was made to a recipient, which can help services better manage their shielded payments. See the documentation for a full explanation of this new feature.
      4. +
    4. z_shieldcoinbase is now a fully supported RPC call (#2692). See an explanation of this command here .
      5. +
    5. Libsnark has been brought into the source repository tree. (#2652)
      6. +
    6. Potential shutdown errors have been fixed. (#2555)
      7. +
    7. User interface messages have been cleaned up. (#2548, #2150, #2649)
      8. +
    8. The extended QA tests have been migrated to Zcash. (#2533)
      9. +
    9. A workaround has been implemented in the test wallet_protectcoinbase, which was previously failing on some platforms. (#2698)
      10. +
    10. Benchmarking has been updated with new performance measurements and fixes. (#2645, #2659, #2377, #2687, #2665)
      11. +
    +We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. + +For a more complete list of changes, see our 1.0.13 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2017-11-27-new-hires-2017.md b/_posts/2017-11-27-new-hires-2017.md new file mode 100644 index 0000000..e02f91d --- /dev/null +++ b/_posts/2017-11-27-new-hires-2017.md @@ -0,0 +1,67 @@ +--- +ID: 2152 +post_title: New Zcash Team Member Announcement +author: Ryan Taylor +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-hires-2017/ +published: true +post_date: 2017-11-27 00:00:12 +--- +The Zcash team grows, once again, in the continuing pursuit of its mission to set a new standard for privacy on the Internet and around the world. As such, we proudly announce new team members hired in 2017. +
    +

    Jonathas Carrijo

    +
    +

    Latin America Community and Business Development

    +Jonathas has about 15 years experience as a software engineer and 9 as an entrepreneur. He was abducted into the cryptocurrencies sphere 3 years ago, and since then has been enthusiastic about onboarding people into this decentralized, open and unstoppable movement. + +
    +
    + +
    + +
    +

    Linda Naeun Lee

    +
    +

    User Experience Researcher

    +Linda is a user-focused crypto evangelist with a mission to make encryption technologies widely adopted and easier to use. Outside of her main job as the UX team lead at Tor, she evaluates Zcash-related applications. She has a master's degree in Computer Science with an emphasis on security and user research from UC Berkeley. + +
    +
    + +
    + +
    +

    Zirui Zhang

    +
    +

    Asia/Pacific Community and Business Development

    +Zirui cares deeply about privacy and internet security, and has spent over five years working in the digital currency space. She is thoroughly connected with the Asian cryptocurrency community. + +
    +
    + +
    + +
    +

    Ryan Taylor

    +
    +

    Web Developer and Translations Coordinator

    +Ryan has several years of experience as a freelance web developer and livestream video producer with a focus on open source and decentralization technologies. In the cryptocurrency industry specifically, his experience includes Bitcoin Magazine, Ethereum and Alexandria. Operating as a remote contractor for open source projects and as an autonomous media node satisfies his craving to create and share information about new communication ideas and tools while supporting the projects that inspire him. + +
    +
    + +
    + +
    +

    Hugh Khan

    +
    +

    Engineering Manager

    +Hugh has extensive experience in scaling startups into global technology firms. He has been building high functioning software development teams for over 25 years. Hugh has been either a founding member or a key contributor for technology startups his whole career. Startup areas included AI, mobile computing, Enterprise Content Management, business process automation, vertical online communities, e-commerce, DRM, insuretech and fintech. Hugh believes that decentralization, AI, IoT and AR together are quickly reaching a critical mass which will lead to an utter disruption of every industry in the global economic system. In such a highly dynamic business environment, winning strategies are those that are formed on a continuous basis, resulting from every team member taking an active part in the creation and execution of supporting strategic activities. Hugh firmly holds that hiring well is the single most important strategy; even above strategic positioning. + +
    + +Zcash continues to value our contributors and the positive, enthusiastic community of fans. Please join the Zcash community by contributing to our Slack or Forum conversations. + +
    +
    \ No newline at end of file diff --git a/_posts/2017-12-04-new-research-on-shielded-ecosystem.md b/_posts/2017-12-04-new-research-on-shielded-ecosystem.md new file mode 100644 index 0000000..cd7516e --- /dev/null +++ b/_posts/2017-12-04-new-research-on-shielded-ecosystem.md @@ -0,0 +1,32 @@ +--- +ID: 2154 +post_title: > + New Empirical Research into Zcash + Privacy +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/new-research-on-shielded-ecosystem/ +published: true +post_date: 2017-12-04 00:00:31 +--- +A researcher from University of Michigan-Dearborn, Jeffrey Quesnelle, published a paper and blog today about the effective privacy on the Zcash blockchain over the first year of its existence. No vulnerabilities in Zcash were uncovered in this research. However, the research underscores a specific way that Zcash — like any other financial privacy technology — can fail to protect you if you use it the wrong way. + +To recap, in Zcash there are both “shielded” and “transparent” addresses. Zcash stored in transparent addresses is visible in the blockchain to everyone. Zcash stored in shielded addresses is not. + +The way that you can use this the wrong way is to move a certain amount of money into a shielded address, and then move that same amount out again. As we described in a blog post in January: +
    A diagram showing the possibile value linkability in a transaction series even when a shielded address is used in between transparent addresses
    +An observer can deduce the money that Alice sent must have been transferred to Carol. This same issue can arise with any financial privacy technique, for example if you have some Bitcoin, and you Shapeshift it to a privacy coin and then Shapeshift it back to Bitcoin. + +Jeffrey Quesnelle’s paper examined the Zcash blockchain to search for patterns of usage like this. To summarize the findings, he identified a total of 10,946 transaction pairs appearing to be this pattern, accounting for 31.9% of coins being shielded. Our analysis of the list of transactions he published indicates that 84.64% of the transactions were shielding newly-mined coins, meaning that the first transaction of the pair was sent by a miner or mining pool. The Zcash protocol requires that newly-mined coins must be shielded before they can be sent to a transparent address. The fact that these coins were subsequently deshielded suggests that the recipients opted to receive their mining payouts at a transparent address. + +In other words, it’s not that these coins were being shielded because the sending user sought privacy but because they are forced to shield and deshield the coins by the Zcash protocol in order to send them to another transparent address. The paper rightly cautions against users expecting strong privacy when they receive funds sent from a z-address into their t-address. If users want the best privacy, they should always receive and store funds in a z-address. + +The other 15.36% of the observed pattern of usage are potentially by people who didn’t understand that shielding and then deshielding your Zcash doesn’t provide strong privacy. + +To protect yourself from this sort of exposure, don’t think of shielded addresses as something you pass money through, think of them as something you store money in. Storing money in a shielded address and sending a portion of it out as needed gives you very strong privacy. Moving money into it and then immediately moving that money out again does not. (The same goes for using other financial privacy technologies such as the aforementioned example of Shapeshifting to a privacy coin and back.) + +This kind of empirical scientific research is absolutely necessary to help scientists and creators learn what works and what doesn’t, and how to protect users. Previous examples of this kind of scientific research include the Monerolink paper and the paper from the National University of Singapore. The Zcash Foundation has recently awarded a grant to a team of scientists from the University of Luxemborg to further study the Zcash blockchain. This new paper by Jeffrey Quesnelle is an excellent piece of research, which adds significantly to the scientific understanding of the real-world effects of privacy technologies. We'd like to express our thanks to him for doing this research. + +We welcome and encourage this kind of research into Zcash’s privacy properties, and encourage anyone who is undertaking it to reach out to us if we can assist in any way. Also, please notify us in case your results might imperil users and notifying us about them in advance can help us protect Zcash users. \ No newline at end of file diff --git a/_posts/2017-12-08-roadmap-update-2017-12.md b/_posts/2017-12-08-roadmap-update-2017-12.md new file mode 100644 index 0000000..12ec906 --- /dev/null +++ b/_posts/2017-12-08-roadmap-update-2017-12.md @@ -0,0 +1,47 @@ +--- +ID: 2157 +post_title: Zcash for Everyone +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/roadmap-update-2017-12/ +published: true +post_date: 2017-12-08 00:00:11 +--- +Since Zcash launched a little more than a year ago, our world-class engineering team has executed beautifully: on-boarding countless new users and businesses from around the world, supporting the global network with zero downtime and zero security breaches, at the same time as delivering high-quality software upgrades. + +We've delivered fourteen software releases of the zcashd “Magic Bean” reference client, and implemented all of our stated priorities (except that we tabled the User Issued Tokens feature). We've seen strong early adoption in our first year with large portions of exchange volume directly to the top national fiat currencies, multiple hardware and software wallets, and strong interest from the traditional finance industry such as the Zcash Investment Trust and a technology partnership with J.P. Morgan +
    Transactions per day, source `bitinfocharts.com <https://bitinfocharts.com/comparison/zcash-transactions.html>`_
    +
    Marketcap, source `bitinfocharts.com <https://bitinfocharts.com/comparison/zcash-marketcap.html`_
    +In 2018 we're going to further upgrade Zcash's performance, security, and usability (the new Sapling cryptographic technology), bringing our unique encrypted cryptocurrency technology to smartphones and thus available to 2 billion users worldwide. + +Our team of scientists and engineers is focused on safely and seamlessly deploying this breakthrough cryptographic innovation to the world-wide Zcash network, even while that network grows and supports an increasing load of usage. + +The first, preparatory, network upgrade will go live June 2018. The Sapling network upgrade will go live September, 2018. + +All of our current users and use-cases will be supported through this transition. We'll be available to answer any questions. You do not need to do anything at this time to prepare for this upgrade, but stay tuned for more information, instructions, and user support. You can also read the Weekly Dev Updates for visibility in the development process. +
    +

    Roadmap

    +
    +

    Network Upgrade 0 - Overwinter

    +Activation Schedule: June, 2018 + +Network Upgrade 0 - Overwinter is focused entirely on making itself and future network upgrades safer for users, even in the case of governance contention. We'll describe more of its design and features in an upcoming post. + +
    +
    +

    Network Upgrade 1 - Sapling

    +Activation Schedule: September, 2018 + +Network Upgrade 1 - Sapling will activate the Sapling protocol update, bringing orders of magnitude improvements in both time and memory to shielded transactions, making mobile wallet support feasible. Additionally, Sapling will rely on the Powers of Tau open-participation parameter setup, largely mitigating concerns about the parameter setup risks for zkSNARK applications (including other applications outside of Zcash). + +
    +
    +

    Beyond Sapling

    +An open community of scientists and engineers world-wide is already at work exploring what other improvements are technologically possible for Zcash and other such open cryptocurrencies. Possibilities include scalability improvements to allow practically unlimited numbers of transactions, novel consensus algorithms such as Proof-of-Stake, and private and scalable smart contracts. Join the discussion on the Zcash Community Chat (note: not owned or operated by the Zcash Company — it is an independent community-operated chatroom). + +Whatever improvements Zcash adds beyond Sapling, you can rest assured that we’ll honor our tradition of providing both stability and valuable innovation for our users. + +
    +
    \ No newline at end of file diff --git a/_posts/2017-12-29-zcash-in-2017.md b/_posts/2017-12-29-zcash-in-2017.md new file mode 100644 index 0000000..f35cf6a --- /dev/null +++ b/_posts/2017-12-29-zcash-in-2017.md @@ -0,0 +1,25 @@ +--- +ID: 2343 +post_title: A Look Back on 2017 +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-in-2017/ +published: true +post_date: 2017-12-29 00:00:57 +--- +2017 has been a year of many firsts for Zcash. Having launched only a couple months before the start of the year, the opportunities for growth and development were already flooding in. The foundations of a global Zcash ecosystem were being put into place by not only the Zcash Company engineers but also by businesses and individuals involved in the Zcash and greater cryptocurrency ecosystems. + +For much of this year, our development team has been focused on security and stability of the Zcash network while third party developers continued to add support for Zcash to existing wallets and exchanges. + +We've put out several State of the Network posts throughout the year which marked milestones like the distribution of the first 1 million ZEC (now approaching 3 million), the market cap reaching 100 million USD (now well over 1 billion USD) on the 6 month anniversary and Zcash's first birthday. + +Rounding out 2017, we put out a plan of action for upcoming network upgrades, Overwinter and Sapling. To meet this aggressive schedule, the Zcash Company has been in a hiring frenzy for engineers. And thoughout 2017, we've learned a lot about the variety of interests in Zcash from communities all around the world like Asia and Latin America. For 2018, we're looking forward to establishing a development hub in Denver while expanding community outreach to new regions. + +This has been a big year for many cryptocurrencies as a surge of interest drove up asset values exponentially. Several mainstream outlets like NPR's Radiolab and Fortune put out in-depth stories on Zcash, introducing the technology and the founders behind it to millions of people. And enterprise partnerships like the Zcash collaboration with JP Morgan further fueled a wider interest in blockchains and zk-SNARKs. + +In addition to work the Zcash Company and the Zcash community have put forth in 2017, Zcash Foundation established a list of values and a set mission for serving the users of Zcash. They were recently granted 501(c)3 status and successfully awarded grants to several well deserving projects. They also have been helping charities and organizations get set up accepting Zcash donations (so go ahead and use some of your Zcash towards organizations you support especially if you haven't done so already!) + +We're excited about the prospects for Zcash in 2018: the Sapling usability and security improvements, further support and adoption of Zcash by third-parties, and future collaborations promoting more research around zero-knowledge proofs and utility behind the privacy they enable. + +Happy New Year! \ No newline at end of file diff --git a/_posts/2018-01-04-new-release-1-0-14.md b/_posts/2018-01-04-new-release-1-0-14.md new file mode 100644 index 0000000..81d9084 --- /dev/null +++ b/_posts/2018-01-04-new-release-1-0-14.md @@ -0,0 +1,58 @@ +--- +ID: 2347 +post_title: 'New Release: 1.0.14' +author: Jack Grigg +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-14/ +published: true +post_date: 2018-01-04 15:06:18 +--- +

    Today we're announcing the release of Zcash 1.0.14, which contains new features, bug fixes, and documentation improvements.

    + +

    Notable changes

    + +

    Incoming viewing keys

    +

    Support for incoming viewing keys, as described in the Zcash protocol spec, has been added to the wallet.

    +

    Use the z_exportviewingkey RPC method to obtain the incoming viewing key for a z-address in a node's wallet. For Sprout z-addresses, these always begin with "ZiVK" (or "ZiVt" for testnet z-addresses). Use z_importviewingkey to import these into another node.

    +

    A node that possesses an incoming viewing key for a z-address can view all past +transactions received by that address, as well as all future transactions sent +to it, by using z_listreceivedbyaddress. They cannot spend any funds from the +address. This is similar to the behaviour of "watch-only" t-addresses.

    +

    z_gettotalbalance now has an additional boolean parameter for including the +balance of "watch-only" addresses (both transparent and shielded), which is set +to false by default. z_getbalance has also been updated to work with +watch-only addresses.

    +
      +
    • Caution: for z-addresses, these balances will not be accurate if any +funds have been sent from the address. This is because incoming viewing keys +cannot detect spends, and so the "balance" is just the sum of all received +notes, including ones that have been spent. Some future use-cases for incoming +viewing keys will include synchronization data to keep their balances accurate +(e.g. #2542).
      • +
    + +

    Sprout circuit value tracking

    +

    Nodes can now track the total amount of shielded ZEC inside the Sprout circuit. +This is measured by adding up the ZEC moving between the Transparent Value Pool +and JoinSplits (see Anatomy of a Zcash Transaction). +getblockchaininfo shows the total for the entire chain, while getblock +will show the total as of a specific block.

    +

    To enable this monitoring on a specific node, it must be re-indexed. This will +take several hours to complete, but otherwise will not affect any other node +data.

    + +

    Summary of the changes included in this release

    +
      +
    1. We fixed a non-exploitable buffer overflow in libsnark. (#2800)
      2. +
    2. We added support for incoming viewing keys. (#2143)
      3. +
    3. We added tracking of the total shielded value inside the Sprout circuit, which can be enabled by re-indexing. (#2795)
      4. +
    4. We modified dumpwallet and z_exportwallet to prevent them overwriting existing files. (#2741)
      5. +
    5. We fixed bugs on several unsupported platforms. (#2700, #2752, #2786)
      6. +
    6. We improved various parts of the help text and documentation. (#2724, #2744)
      7. +
    +

    We're encouraging all users and miners to update to this new version. See our download +page and the 1.0 User Guide for more information.

    +

    For a more complete list of changes, see our 1.0.14 +GitHub milestone. To follow our progress, watch the GitHub project +and join the forum.

    \ No newline at end of file diff --git a/_posts/2018-01-16-ux-guidelines-for-wallet-developers.md b/_posts/2018-01-16-ux-guidelines-for-wallet-developers.md new file mode 100644 index 0000000..a0161e9 --- /dev/null +++ b/_posts/2018-01-16-ux-guidelines-for-wallet-developers.md @@ -0,0 +1,28 @@ +--- +ID: 2353 +post_title: > + Introducing Our UX Guidelines for Wallet + Developers +author: Linda Lee +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/ux-guidelines-for-wallet-developers/ +published: true +post_date: 2018-01-16 15:35:43 +--- +We believe that improving the user experience for wallets will be a huge step in making cryptocurrencies more usable, as users need to interact with a wallet in order to store, send, and use any digital currency. + +We have compiled a checklist of good practices that can be applied to any cryptocurrency wallet with a graphic user interface. If you’re building a wallet that supports Zcash, we encourage that you use this checklist to catch common usability problems before launch or user testing. + +Go over and have a look here. We have a succinct yet comprehensive checklist covering user interaction, user interface design, navigation, content, styling, errors, security, user support, and more. For instance, does your wallet: +
      +
    1. Explain why a permission is needed before the mobile OS prompts asks the user?
      2. +
    2. Notify of events with in app notifications or push notifications, depending on if the user is currently using the wallet or not?
      3. +
    3. Show error notifications or messages next to the relevant input field (not just at the top or bottom of the screen) to show users what they need to fix without searching for it?
      4. +
    +Head on over to look at the full checklist! It’s not exhaustive, but we hope that this adds value by helping Zcash wallet developers catch common usability problems! + +Cryptocurrencies and, therefore, the wallets that support them, are still a relatively new technology. There isn’t yet a standard layout, user flow, or feature set. We are constantly evaluating wallets that try new flows and interfaces, and encourage such experimentation. A future goal as we approach the Sapling network upgrade is to further research shielded address UX and the properties of transactions which involve them. + +Zcash does not have an official GUI wallet, just the Linux CLI client. You can find a community maintained list of the wallets that support Zcash. \ No newline at end of file diff --git a/_posts/2018-01-22-viewing-keys-selective-disclosure.md b/_posts/2018-01-22-viewing-keys-selective-disclosure.md new file mode 100644 index 0000000..c4c8a7f --- /dev/null +++ b/_posts/2018-01-22-viewing-keys-selective-disclosure.md @@ -0,0 +1,45 @@ +--- +ID: 2355 +post_title: 'Selective Disclosure & Shielded Viewing Keys' +author: Paige Peterson +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/viewing-keys-selective-disclosure/ +published: true +post_date: 2018-01-22 15:42:39 +--- +Encryption is an important tool to control access to personal and business data. In many cases where private data must be shared with select people such as a long distance family member or business associate, employing simple document encryption allows securely sharing private data in less private forms of communication like email. Commonly, one party will encrypt the documents with a password that is also used to decrypt the document by the second party. This password is either already known by everyone who requires access or is shared via a different channel like a phone call or more secure messaging platform. +
    +

    Viewing Keys & Selective Disclosure Granularity

    +The encrypted contents of shielded transactions in Zcash have a similar property that individuals can selectively disclose the data from a specific transfer. More broadly, a viewing key may also be provided to disclose all transactions for a given shielded address. + +The context of the data disclosure can determine which method someone may prefer to use. For example, the owner of a yoga studio may prefer to disclose their payment address's viewing key to their accountant for keeping track of all revenue while disclosing individual transactions involving merchandise sales to the employee in charge of inventory. Like sharing passwords to decrypt sensitive documents, the channel in which a user shares viewing keys and transaction disclosures is important to consider to make sure only the intended parties gain access. Additionally, anyone you share viewing keys or transaction disclosures with can share further or even make them public so it's important that you trust who you give access to. + +
    +
    +

    Watch addresses

    +
    +  +
    + + + +Some Zcash users prefer to store their private spending keys offline for increased security. That way even if their accounts get hacked or their online devices get stolen, their Zcash is still safe. However, it also prevents them from being able to see incoming transactions going to the address associated with that spending key. With viewing keys, they can keep the viewing key online so that they can see the transaction activity, while keeping the spending key safely offline. + +
    +
    +

    Current implementation and future plans

    +What the public sees + +What data the owner of a viewing key for a specific address sees + +What data the owner of a payment disclosure for a specific transaction sees + +At version 1.0.14, Zcash supports viewing key capability for tracking incoming transactions. Tracking outgoing transactions introduces a slightly trickier problem which is proposed to be addressed in the Sapling network upgrade. + +Additionally at version 1.0.14, Zcash supports the creation of payment disclosures for transactions sent from a wallet. This can be beneficial when proving that a payment to an address was sent. The current implementation is an experimental feature which means a user must explicitly turn it on. You can check out the payment disclosure documentation for more information about usability and security considerations of this feature and for instructions on how to use it. + +We look forward to offering more complete implementations of viewing keys and selective dislosure in the coming releases and upgrades. We're excited to hear about how third-parties are using these features so please let us know how you're working with them. Developers or users with questions can reach out in the community chat. + +
    \ No newline at end of file diff --git a/_posts/2018-02-14-shielded-pia.md b/_posts/2018-02-14-shielded-pia.md new file mode 100644 index 0000000..389bf20 --- /dev/null +++ b/_posts/2018-02-14-shielded-pia.md @@ -0,0 +1,52 @@ +--- +ID: 2473 +post_title: > + Pay for Private Internet Access Using + Shielded Transactions +author: Linda Lee +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/shielded-pia/ +published: true +post_date: 2018-02-14 19:44:28 +--- +Private Internet Access has added support for shielded addresses! Private Internet Access protects your privacy by encrypting your connection and providing an alternate IP address to browse the web. + +

    + + +You can now use your favorite privacy-preserving cryptocurrency to purchase a privacy-enhancing service. + +

    Purchasing process

    + +To purchase their services via a Zcash shielded transaction, ensure that your wallet supports shielded transactions. There is a community maintained list of them here. Once you have your wallet set up and funded, head over to www.privateinternetaccess.com and choose the plan you wish to purchase. + + + +As your payment method, choose to pay with ZEC by clicking the button that says “pay anonymously with our Zcash z-address” option. + + + +You’ll need to enter in an email as a part of the purchase. If you don’t feel comfortable with providing your real email, use a temporary email services like dispostable, fakeinbox, or guerillamail. Make sure you are able to access the inbox, since that’s where they send credentials. + + + +Then, follow the instructions on the popup dialogue to send the payment to Private Internet Access’ shielded address. + + + +You’ll need to wait for a couple minutes for your payment to be detected and confirmed. + + + +Once your payment is confirmed, you should see this popup! + + + +Congratulations! You’ve purchased a privacy-enhancing technology with a privacy-preserving cryptocurrency. Check your email for the activation code and follow the instructions in the email to set up your VPN service. + +

    More to come

    + +In addition to shielded address support, the Private Internet Access team has expressed intent to support VPN service activation without an email requirement using the Zcash encrypted memo field as a way to further enhance customer privacy.  Learn more about Zcash support at Private Internet Access here. We’re very enthusiastic about how third-parties are using Zcash in new and interesting ways, so please let us know how you are implementing Zcash. + +You’ll be hearing a lot more about shielded address soon, as we launch groundbreaking performance improvements for shielded addresses that make them more feasible to use on mobile devices. \ No newline at end of file diff --git a/_posts/2018-03-02-new-release-1-0-15.md b/_posts/2018-03-02-new-release-1-0-15.md new file mode 100644 index 0000000..2ae7aeb --- /dev/null +++ b/_posts/2018-03-02-new-release-1-0-15.md @@ -0,0 +1,41 @@ +--- +ID: 2604 +post_title: 'New Release: 1.0.15' +author: Jack Grigg +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-1-0-15/ +published: true +post_date: 2018-03-02 00:41:45 +--- +Today we're announcing the release of Zcash 1.0.15, which contains the Overwinter consensus rules with a testnet activation height. It also includes various bug fixes, and adds an experimental RPC method for merging UTXOs and notes. +

    Notable changes

    +

    Overwinter network upgrade

    +The code preparations for the Overwinter network upgrade, as described in ZIP 200, ZIP 201, ZIP 202, ZIP 203, and ZIP 143 are finished and included in this release. Overwinter will activate on testnet at height 207500, and can also be activated at a specific height in regtest mode by setting the config option -nuparams=5ba81b19:HEIGHT. + +However, because the Overwinter activation height is not yet specified for mainnet, version 1.0.15 will behave similarly as other pre-Overwinter releases even after a future activation of Overwinter on the network. Upgrading from 1.0.15 will be required in order to follow the Overwinter network upgrade on mainnet. +

    Overwinter transaction format

    +Once Overwinter has activated, transactions must use the new v3 format (including coinbase transactions). All RPC methods that create new transactions (such as createrawtransaction and getblocktemplate) will create v3 transactions once the Overwinter activation height has been reached. +

    Overwinter transaction expiry

    +Overwinter transactions created by zcashd will also have a default expiry height set (the block height after which the transaction becomes invalid) of 20 blocks after the height of the next block. This can be configured with the config option -txexpirydelta. +

    UTXO and note merging

    +In order to simplify the process of combining many small UTXOs and notes into a few larger ones, a new RPC method z_mergetoaddress has been added as an experimental feature. It merges funds from t-addresses, z-addresses, or both, and sends them to a single t-address or z-address. To test it out, set the config option -zmergetoaddress (as well as enabling experimental features). We encourage mining pools and exchanges to test it out over the next few weeks, and give feedback, before we make it a fully-supported RPC method in an upcoming release. + +Unlike most other RPC methods, z_mergetoaddress operates over a particular quantity of UTXOs and notes, instead of a particular amount of ZEC. By default, it will merge 50 UTXOs and 10 notes at a time; these limits can be adjusted with the parameters transparent_limit and shielded_limit. + +z_mergetoaddress also returns the number of UTXOs and notes remaining in the given addresses, which can be used to automate the merging process (for example, merging until the number of UTXOs falls below some value). +

    UTXO memory accounting

    +The default -dbcache has been changed in this release to 450MiB. Users can set -dbcache to a higher value (e.g. to keep the UTXO set more fully cached in memory). Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter. + +Additional information relating to running on low-memory systems can be found here: reducing-memory-usage.md. +

    Summary of the changes included in this release

    +
      +
    1. We implemented the Overwinter network upgrade consensus rules and transaction version. (#2874, #2898, #2903, #2925, #3002)
      2. +
    2. We added logic to the mempool to evict transactions that can't be mined into the current branch. (#2940)
      3. +
    3. We added logic to preferentially evict pre-Overwinter nodes shortly before activation, and disconnect from them after activation. (#2919)
      4. +
    4. We added information about network upgrades and version deprecation to the RPC interface. (#2808, #2839)
      5. +
    5. We fixed a bug where a block index field was not being read from disk. (#2931, #2977, #2993)
      6. +
    6. We implemented a roll-back limit for reorganization and branch rewinding of 100 blocks. (#2463)
      7. +
    7. We added z_mergetoaddress as an experimental feature. (#2797)
      8. +
    8. We increased the default value of -dbcache. (#2873)
      9. +
    \ No newline at end of file diff --git a/_posts/2018-03-02-overwinter.md b/_posts/2018-03-02-overwinter.md new file mode 100644 index 0000000..5588353 --- /dev/null +++ b/_posts/2018-03-02-overwinter.md @@ -0,0 +1,23 @@ +--- +ID: 2529 +post_title: Overwinter +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/overwinter/ +published: true +post_date: 2018-03-02 11:30:29 +--- +Announcing Zcash Overwinter, the first "software-updates-required" network upgrade for Zcash. + +The purpose of Overwinter is to strengthen the protocol for future network upgrades, paving the way for the Zcash Sapling network upgrade later this year. Overwinter includes versioning, replay protection for network upgrades, performance improvements for transparent transactions, a new feature of transaction expiry, and more. + +Keep your Zcash software updated, and you'll be on the newly-upgraded main chain along with everyone else. You will not miss the network upgrade, unless you are running your own full node and have manually configured your client to continue running the old code. There is no need to do anything else besides keep your Zcash software up to date. This network update is not expected to result in a fork of the blockchain or the creation of a new currency. + +The first version of zcashd that supports Overwinter will be 1.1.0, which is planned for release in April. This release will set the Overwinter activation block height on the main network, currently targeted for June 25th, 2018. Once activated, the main chain will start enforcing the new consensus rules. + +We have begun reaching out to third-party developers for their feedback and to offer any support needed for a smooth Overwinter activation. The network upgrade guidelines list what is necessary (if anything) from third-parties to get ready for Overwinter. + +If you have any questions, see the network upgrade FAQ and the Overwinter information portal, and join the forum. For more information on our plans to test Overwinter, check out the 1.0.15 release announcement. + +We're excited about taking this next step into the future together with you! \ No newline at end of file diff --git a/_posts/2018-03-23-zcash-team-grows-with-new-hires-in-q1-2018.md b/_posts/2018-03-23-zcash-team-grows-with-new-hires-in-q1-2018.md new file mode 100644 index 0000000..2a04a7a --- /dev/null +++ b/_posts/2018-03-23-zcash-team-grows-with-new-hires-in-q1-2018.md @@ -0,0 +1,95 @@ +--- +ID: 2676 +post_title: > + Zcash Team Grows with New Hires in Q1 + 2018 +author: Zerocoin Electric Coin Company +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/zcash-team-grows-with-new-hires-in-q1-2018/ +published: true +post_date: 2018-03-23 09:19:55 +--- +The first round of hiring in 2018 has brought many skilled individuals to the Zcash team. We are excited to announce this group of passionate new hires who share the Zcash philosophy and possess the integrity and character that inspire us. + +
    + +
    +

    Brad Miller

    +
    +

    Engineer

    +Brad is a generalist engineer with a background in software engineering, mechanical design, and engineering physics. He is excited about the abundance of opportunities in the cryptocurrency space and their potential for massive impact. Brad is most passionate about bringing cryptocurrency to the masses by solving the challenges around usability and user experience. He holds a B.S. in Engineering Science and Mechanics from Virginia Tech and is currently working on an M.S. in Computer Science from Georgia Tech focusing on Machine Learning. He lives in Fort Collins, Colorado. + +
    +
    + +
    + +
    +

    Marshall Gaucher

    +
    +

    Engineer

    +As a Software Engineer, Marshall has primarily worked with RF4CE technologies to develop some of the first voice recognition products in the broadband industry. He also brings a strong academic foundation with studies ranging from Mobile Computing to Robotics. Now, he is eager to pioneer new frontiers in the “Wild West” of Cryptocurrency. + +
    +
    + +
    + +
    +

    Ian Munoz

    +
    +

    Engineer

    +Ian is an economist & developer with a background in high performance research computing, infrastructure, and reproducible software. He is passionate about encryption, privacy & decentralization. In his free time he dabbles in the linux kernel, works on containerization, and plays in the outdoors! + +
    +
    + +
    + +
    +

    Charlie O'Keefe

    +
    +

    Engineer

    +Charlie has been programming since fourth grade, majored in math and computer science at the Colorado School of Mines, and has worked in the defense, education, health care, and energy industries. Throughout all of that, his interests gravitated to decentralization and privacy technologies, and he is very excited by the opportunity to contribute in those areas at Zcash! + +
    +
    + +
    + +
    +

    Eirik Ogilvie-Wigley

    +
    +

    Engineer

    +Eirik graduated from CU Boulder in 2012 with a degree in mathematics. He has several years experience developing software in a professional setting, and has been a hobbyist programmer since he was a child. In his spare time Eirik enjoys doing abstract algebra, and is excited to bring his skills, experience, and enthusiasm to the Zcash team. + +
    +
    + +
    + +
    +

    Josh Swihart

    +
    +

    Marketing Director

    +Josh does technology and marketing, mostly. Prior to Zcash, he served as the SVP of Global Marketing for K2, a high-growth tech company. He has also served as a global practice principal for EMC, the CEO of Aspenware, and was the co-founder of a couple other companies with exits to Accenture and EMC. He began his career as a software developer, data recovery specialist and BBS sysop while in high school. Josh has received numerous global and national awards for leadership, marketing and solution delivery. + +
    +
    + +
    + +
    +

    George Tankersley

    +
    +

    Engineer

    +George is a cryptography engineer at Zcash, where he now works on turning math into magic Internet money. He's spent the last few years deploying cryptography at Internet scale, contributing to the design of new protocols and to open source ecosystem projects like Certificate Transparency and Kubernetes. Prior to that he worked on a Linux distro, ran a small startup, worked as a pentester, and briefly took up blacksmithing. + +
    +
    + +
    + +Zcash continues to value our contributors and the positive, enthusiastic community of fans. Keep an eye on the Zcash Jobs page for open positions on the team. Please join the Zcash community by contributing to our Slack or Forum conversations. \ No newline at end of file diff --git a/_posts/2018-03-27-2018-security-audits.md b/_posts/2018-03-27-2018-security-audits.md new file mode 100644 index 0000000..9acb94e --- /dev/null +++ b/_posts/2018-03-27-2018-security-audits.md @@ -0,0 +1,26 @@ +--- +ID: 2524 +post_title: 2018 Zcash Security Audit Overview +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/2018-security-audits/ +published: true +post_date: 2018-03-27 19:51:55 +--- +Our mission is to empower everyone with economic freedom and opportunity. In the service of that mission, we have published numerous scientific discoveries and deployed one of the most advanced cryptographic protocols ever created. + +Risks are inherent to all cryptocurrency software. Many other cryptocurrencies have already shown vulnerabilities that could allow theft, destruction or counterfeiting of money. Zcash has not suffered any such failure but we refuse to take anything for granted. + +To that end, we employ a complementary set of interlocking engineering practices including three different kinds of peer review: scientific, community and professional. + +Scientific: Zcash publishes papers for peer review by other scientists to ensure we are held to the highest standard and consistent with current academic research. Examples of these papers can be found here (Zerocash, Satisfying simulation extractability in Groth’s zk-SNARKs, Multi-party Protocol for zk-SNARK Parameters, Scalable Multi-party Computation for zk-SNARK Parameters). + +Community: We work in public, allowing the open source community to see, review, and contribute to source code, issue tracking, pull requests, and design discussions. + +Professional: We commission third-party experts to perform a rigorous investigation of the software and publish those results. Prior to launching Zcash, we commissioned a batch of security audits and design evaluations. + +Today we have announced the engagement of five leading industry experts to conduct comprehensive security and design audits in support of the upcoming Overwinter and Sapling releases. The detail of those audits, including scope and the auditors selected are available here. + +We believe that any system intended to withstand the demands of world-wide economic infrastructure needs ongoing comprehensive peer reviews. But even the most comprehensive reviews conducted but the industry’s best cannot guarantee safety. The science is new. The technology is complex. Changes are rapid. Proceed with caution. \ No newline at end of file diff --git a/_posts/2018-03-27-2018-zcash-security-audit-details.md b/_posts/2018-03-27-2018-zcash-security-audit-details.md new file mode 100644 index 0000000..50925bd --- /dev/null +++ b/_posts/2018-03-27-2018-zcash-security-audit-details.md @@ -0,0 +1,54 @@ +--- +ID: 2704 +post_title: 2018 Zcash Security Audit Details +author: Zooko Wilcox +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/2018-zcash-security-audit-details/ +published: true +post_date: 2018-03-27 19:52:16 +--- +We at Zcash are committed to the security and safety of our user community as we seek to empower everyone with economic freedom and opportunity. + +Zcash has engaged five leading industry experts to conduct comprehensive security and design audits in support of the Overwinter and Sapling in line with our approach to comprehensive peer reviews. +

    Audit Scope

    +The audits will focus on changes to Zcash since our prior reviews, including security analysis of protocol design, cryptographic constructions, consensus rules, and implementation. We have also engaged with cryptographic scientists to analyze security arguments, proofs, and constructions. + +All Overwinter changes will be audited and are presented in five Zcash Improvement Proposals (ZIPs): + +The Sapling libraries to be audited are: +
      +
    • An implementation of a new pairing-friendly elliptic curve in the Rust pairing library
      • +
    • The Rust library for building zk-SNARKs called Bellman
      • +
    • Various components as part of the Sapling-crypto implementation
      • +
    +As with the previous audit, we are also commissioning a review of the C++ code including race conditions, networking, buffer overflows and dependency management. + +We will bring forward previous audit assumptions and assume that previous security audits were accurate and truthful. +

    Auditors

    +All audits will be performed by top security, cryptology and technology professionals. Each auditor will have a specific focus and scope. + +NCC Group: The NCC Group is a leading cybersecurity firm. They have prior experience with the Zcash through their audit of the initial Zcash protocol implementation, source code and ceremony artifacts. + +Coinspect: Coinspect provides Bitcoin security services. As with their previous audit, they will place specific emphasis on Zcash additions over the Bitcoin Core source code. + +Least Authority - Recently spun off as a sibling company of Zcash Company, the Least Authority team is highly experienced in security audits and design analysis including Ethereum’s gas model. + +Kudelski Security - Kudelski is a highly regarded international cybersecurity company. The specific auditor engaged, Jean-Philippe Aumasson, is a accomplished cryptographer, having written numerous papers analyzing cryptographic algorithms, and authored several important cryptographic algorithms, including BLAKE2, SipHash, and Gravity-SPHINCS. + +Mary Maller - As a PhD candidate in the area of cryptography at the University of London under the supervision of Dr Sarah Meiklejohn and Dr Jens Groth, Maller is studying the formal design and analysis of cryptographic protocols including different types of signature schemes and how they can be used in blockchain technologies. +

    Understanding Risk

    +Zcash is sophisticated and novel technology. While security audits help reduce risk, they cannot eliminate them entirely. Additionally, each auditor is focused on a specific kind of analysis and cannot vouch for the entire system, nor do they necessarily endorse Zcash as a product. +

    Schedule

    +The audits are underway. Final reports of all Overwinter and Sapling related audits will be completed before code is activated in the main Zcash network. + +As stated in the 1.0.15 release announcement, the scheduled activation for Overwinter on testnet went live at block 207500. The upcoming 1.1.0 release will set an activation block height on the main network. + +While we intend to release these upgrades according to our current schedule, the security and stability of the Zcash network is our priority. Any unforeseen issues arising from our testing or these audits may delay releases. \ No newline at end of file diff --git a/_posts/2018-04-10-updated-zcash-ux-guidelines-for-wallet-developers.md b/_posts/2018-04-10-updated-zcash-ux-guidelines-for-wallet-developers.md new file mode 100644 index 0000000..858c505 --- /dev/null +++ b/_posts/2018-04-10-updated-zcash-ux-guidelines-for-wallet-developers.md @@ -0,0 +1,25 @@ +--- +ID: 2730 +post_title: > + Updated Zcash UX Guidelines for Wallet + Developers +author: Linda Lee +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/updated-zcash-ux-guidelines-for-wallet-developers/ +published: true +post_date: 2018-04-10 14:10:12 +--- +We have updated our checklist of good UX practices with specific advice on handling Zcash features. Our intent is to provide Zcash wallet developers with guidance on making design decisions and catch common usability problems. + +[caption id="attachment_2731" align="aligncenter" width="232"]UX Checklist UX Checklist for Wallet Developers[/caption] + +The updated content addresses how to: +
      +
    • Support transparent and shielded addresses
      • +
    • Set various transaction parameters
      • +
    • Use viewing keys for selective disclosure
      • +
    • Use memo fields for bookkeeping
      • +
    +We believe that improving the user experience for wallets will be a huge step in making cryptocurrencies accessible. Zcash provides a Linux client but has not released an official wallet. A community maintained list of Zcash wallets is here. \ No newline at end of file