mirror of https://github.com/zcash/zcash-blog.git
Full export from WordPress at https://blog.z.cash (Zcash Blog) - wpghs
This commit is contained in:
Ryan Taylor
parent
99c5a5c8fc
commit
b724b6c208
|
|
@ -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]
|
||||
|
|
@ -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 <em>open</em> 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 <em>open</em> 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 <em>privacy</em>. We have assembled a <a class="reference external" href="https://z.cash/team.html">world-class team</a> of cryptographers and engineers, made scientific advances in the underlying mathematics, and built a working, <em>privacy-preserving</em> variant of the Bitcoin software.
|
||||
<div id="what-we-ve-done" class="section">
|
||||
<h2>What we've done</h2>
|
||||
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.
|
||||
|
||||
</div>
|
||||
<div id="why-do-we-do-this" class="section">
|
||||
<h2>Why do we do this?</h2>
|
||||
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: <em>Why?</em>.
|
||||
<div id="because-privacy-is-a-human-right" class="section">
|
||||
<h3>Because privacy is a human right</h3>
|
||||
We believe that personal privacy is necessary for core human values like dignity, intimacy, and morality.
|
||||
|
||||
Privacy is about <em>consent</em>. 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.
|
||||
|
||||
</div>
|
||||
<div id="because-privacy-is-necessary-for-businesses" class="section">
|
||||
<h3>Because privacy is necessary for businesses</h3>
|
||||
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 <em>positive</em> 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.
|
||||
|
||||
</div>
|
||||
<div id="because-privacy-is-necessary-for-commerce" class="section">
|
||||
<h3>Because privacy is necessary for commerce</h3>
|
||||
A currency needs privacy to be long-term viable as a medium of exchange, because of <em>fungibility</em>. “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 <em>doesn't matter</em> 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 <em>this</em> 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.
|
||||
|
||||
</div>
|
||||
<div id="because-privacy-is-a-social-value" class="section">
|
||||
<h3>Because privacy is a social value</h3>
|
||||
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.
|
||||
|
||||
</div>
|
||||
<div id="but-but-won-t-bad-guys-use-it" class="section">
|
||||
<h3>But… but… won't bad guys use it?</h3>
|
||||
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.
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<div id="join-us" class="section">
|
||||
<h2>Join us!</h2>
|
||||
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 <a class="reference external" href="https://z.cash/buzz.html">their support</a>. We welcome your help and support. You can find our conversations at <a class="reference external" href="https://forum.z.cash">the Zcash forum</a>.
|
||||
|
||||
Coming soon: How is the Zcash project funded?
|
||||
|
||||
— Zooko Wilcox, Jan 20, 2016
|
||||
|
||||
</div>
|
||||
|
|
@ -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: <a class="reference external" href="/helloworld/">our values</a>. 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 <a class="reference external" href="https://z.cash/team.html">Zcash Electric Coin Company</a>), nothing in Zcash is proprietary or closed. Zcash is a fully open system:
|
||||
<ul class="simple">
|
||||
<li>We've published our scientific advances in a series of peer-reviewed articles in the public science literature: [<a class="reference external" href="http://zerocoin.org/media/pdf/ZerocoinOakland.pdf">1</a>, <a class="reference external" href="https://eprint.iacr.org/2013/507.pdf">2</a>, <a class="reference external" href="http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf">3</a>, <a class="reference external" href="http://www.ieee-security.org/TC/SP2015/papers-archived/6949a287.pdf">4</a>].</li>
|
||||
<li>We've released <a class="reference external" href="https://github.com/zcash/zcash">the source code</a> that implements Zcash under an open source licence.</li>
|
||||
<li>We've launched <a class="reference external" href="http://coin.cell.systems/">a Zcash blockchain</a> (for now just a “testnet” blockchain <a class="reference external" href="https://z.cash/support/faq.html">without real monetary value</a>) that anyone on the Internet can connect to without requiring permission from us or from anyone else.</li>
|
||||
</ul>
|
||||
All of this is necessary for Zcash to be an <em>open system</em> 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 <a class="reference external" href="https://z.cash/team.html">such a high-powered team</a> afford to devote years of our lives to this project when everything we're producing is public, open, and permissionless?
|
||||
<div id="founders-reward" class="section">
|
||||
<h2>Founders Reward</h2>
|
||||
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 — <a class="reference external" href="https://z.cash/team.html">founders, investors, employees, and advisors</a>. We call this the “Founders Reward”.
|
||||
|
||||
<img src="/wp-content/uploads/2016/11/foundersreward.png" alt="Founders Reward Graph" />At 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.
|
||||
|
||||
</div>
|
||||
<div id="our-investors" class="section">
|
||||
<h2>Our Investors</h2>
|
||||
With the plan above, a <a class="reference external" href="https://z.cash/team.html#investors">dream team of investors</a> 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.
|
||||
|
||||
</div>
|
||||
<div id="the-zcash-foundation" class="section">
|
||||
<h2>The Zcash Foundation</h2>
|
||||
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.
|
||||
|
||||
</div>
|
||||
<div id="conclusion" class="section">
|
||||
<h2>Conclusion</h2>
|
||||
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 <a class="reference external" href="https://forum.z.cash/">join the Zcash community</a>.
|
||||
|
||||
Coming soon: Zcash and Bitcoin
|
||||
|
||||
— Zooko Wilcox, Feb 1, 2016
|
||||
|
||||
</div>
|
||||
|
|
@ -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 <a class="reference external" href="https://z.cash/team.html#engineers">our engineering team</a>: 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: <a class="reference external" href="https://github.com/str4d">str4d</a>.
|
||||
<div class="figure align-center"><img class="zecc-blog-standard-image" src="http://blog.z.cash/wp-content/uploads/2016/02/jack.jpg" alt="Jack Grigg aka str4d"" alt="Jack Grigg aka str4d" />
|
||||
<p class="caption">Jack Grigg aka str4d</p>
|
||||
|
||||
</div>
|
||||
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 <a class="reference external" href="https://torproject.org/">Tor</a> and <a class="reference external" href="https://geti2p.net/">I2P</a> into <a class="reference external" href="http://foolscap.lothar.com/trac">foolscap</a>, a capabilities-secure remote procedure call <a class="reference external" href="https://www.python.org/">Python</a> library and protocol. Under this pseudonym, Jack actively contributes to or leads development on <a class="reference external" href="https://geti2p.net/">I2P</a>, <a class="reference external" href="https://github.com/i2p/i2p.android.base">I2P Android</a>, and the <a class="reference external" href="https://github.com/str4d/txi2p">txi2p</a> endpoint for <a class="reference external" href="https://twistedmatrix.com/trac/">Twisted</a>, as well as <a class="reference external" href="https://github.com/str4d/ed25519-java">ed25519-java</a>.
|
||||
|
||||
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 <a class="reference external" href="https://github.com/str4d/zcash-pow">mining prototype</a> for Zcash <a id="id1" class="footnote-reference" href="#id2">[*]</a>. 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
|
||||
<table id="id2" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id1">[*]</a></td>
|
||||
<td>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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>There are a lot of cryptographic challenges to making a fully secure and reliable open financial system.</p>
|
||||
<p>Our current top priority in the Zcash development process is to securely generate “SNARK public parameters”.</p>
|
||||
<div class="section" id="what-s-the-problem">
|
||||
<h2>What's the problem?</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>The obvious way to construct SNARK public parameters is just to have someone generate a public/private keypair, similar to an ECDSA keypair <a class="footnote-reference" href="#id2" id="id1">[*]</a>, and then destroy the private key.</p>
|
||||
<p>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.)</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="what-can-we-do-about-it">
|
||||
<h2>What can we do about it?</h2>
|
||||
<p>We’ve devised a <em>secure multiparty computation</em> 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 <em>at least one</em> of the participants successfully destroys their private key shard — then the toxic waste byproduct never comes into existence at all.</p>
|
||||
<p>We wrote <a class="reference external" href="http://diyhpl.us/~bryan/papers2/bitcoin/snarks/Secure%20sampling%20of%20public%20parameters%20for%20succinct%20zero%20knowledge%20proofs.pdf">a paper on the cryptographic science</a> behind that process, which we presented at the IEEE “Oakland” Security and Privacy conference in 2015.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="what-else-can-we-do">
|
||||
<h2>What else can we do?</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>Therefore, we're also exploring long-range ideas which — if they work out — could further mitigate this risk and other risks like it.</p>
|
||||
<ul class="simple"><li>Perhaps we could leverage the modern <a class="reference external" href="https://en.wikipedia.org/wiki/Trusted_execution_environment">“Trusted Execution Environments”</a> like Intel SGX and ARM TrustZone so that even if a participant — or a compromised computer that the participant is using — tries to extract their shard of the private key, they can’t. Perhaps we could make it so that some participants use Intel SGX, others use ARM TrustZone, and others use neither, so that even if Intel SGX <em>and</em> ARM TrustZone were both compromised, the attacker would still fail to create the toxic waste byproduct because at least one of the other participants successfully destroyed their shard of it.</li>
|
||||
<li>Perhaps there could be a way to repeatedly <em>extend</em> the SNARK public parameters with newly generated public key shards made by new participants, so that an attacker would fail unless they exploited not only all of the original participants but all of the new participants as well.</li>
|
||||
<li>Perhaps there could be a way to audit the size of the Zcash monetary base, without compromising the privacy of any users. That way, people could at least say “Well, we can't be 100% sure that someone didn't steal the toxic waste private key, but at least we can tell that they have not (yet) used it to counterfeit money.”.</li>
|
||||
<li>Perhaps there could be a new form of SNARK which has public parameters unrelated to any toxic waste private key. Nobody knows for sure if such a thing is possible, but scientists, including some of those from our team, are continuing to <a class="reference external" href="http://eprint.iacr.org/2016/116">actively investigate</a> the boundaries of what kinds of proof systems are possible.</li>
|
||||
</ul></div>
|
||||
<div class="section" id="the-bottom-line">
|
||||
<h2>The Bottom Line</h2>
|
||||
<p>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 <em>secure multiparty computation</em> in which a set of well-known people each contribute, in such a way that if <em>any one of them</em> 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.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[*]</a></td><td>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.</td></tr></tbody></table></div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<div class="section" id="zero-knowledge-contingent-payments">
|
||||
<h2>Zero-Knowledge Contingent Payments</h2>
|
||||
<img alt="ZKCP Demo at FC16 Bitcoin Workshop" src="http://blog.z.cash/wp-content/uploads/2016/03/zkcp-demo.png"/><p>Zcasher <em>Sean Bowe</em>, 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 <em>atomically</em>.</p>
|
||||
<p>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.</p>
|
||||
<p>Such an atomic swap of money for information <em>without either party being vulnerable to someone else</em> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="https://github.com/scipr-lab/libsnark">libsnark</a>.</p>
|
||||
<p>Sean also submitted a <a class="reference external" href="https://github.com/bitcoin/bitcoin/pull/7601">pull-request to Bitcoin Core</a> which provides support for HTLC (Hashed Timelock Contracts) used by ZKCP and other protocols like Paypub and Lightning.</p>
|
||||
<p>For more details, please read <a class="reference external" href="https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/">Greg's blog post</a> on the Bitcoin Core blog.</p>
|
||||
</div>
|
||||
<div class="section" id="remote-key-extraction-via-side-channel-attacks">
|
||||
<h2>Remote Key Extraction via Side Channel Attacks</h2>
|
||||
<div class="align-left figure" style="width: 25%">
|
||||
<img alt="don't let this guy stand next to your laptop or phone" src="http://blog.z.cash/wp-content/uploads/2016/03/eran.jpg"/></div>
|
||||
<p>Zcasher <em>Eran Tromer</em> 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.</p>
|
||||
<p>The attacks were detailed in two papers, <a class="reference external" href="https://www.tau.ac.il/~tromer/mobilesc/">"ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels"</a> and <a class="reference external" href="https://www.tau.ac.il/~tromer/ecdh/">"ECDH Key-Extraction via Low-Bandwidth Electromagnetic Attacks on PCs"</a>.</p>
|
||||
<div class="align-right figure" style="width: 45%">
|
||||
<img alt="Phone Key Stealer" src="http://blog.z.cash/wp-content/uploads/2016/03/cheap-iphone4-glass-top-w600.jpg"/></div>
|
||||
<p>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.</p>
|
||||
<p>These are powerful, practical attacks that underscore that danger lies ahead for software vulnerable to side-channel attacks.</p>
|
||||
</div>
|
||||
<div class="section" id="honey-badger-bft">
|
||||
<h2>Honey Badger BFT</h2>
|
||||
<div class="align-left figure" style="width: 25%">
|
||||
<img alt="the friendly author for the latest and greatest BFT" src="http://blog.z.cash/wp-content/uploads/2016/03/amiller.png"/></div>
|
||||
<p>Zcasher <em>Andrew Miller</em> and his co-authors released a pre-print paper draft of <a class="reference external" href="https://eprint.iacr.org/2016/199">"The Honey Badger of Byzantine Fault Tolerance Protocols"</a>. 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.</p>
|
||||
<p>It also means that in case of a temporary network interruption, Honey Badger BFT recovers quickly compared to other Byzantine Fault Tolerance protocols.</p>
|
||||
<div class="align-right figure" style="width: 25%">
|
||||
<img alt="the friendly mascot for the latest and greatest BFT" src="http://blog.z.cash/wp-content/uploads/2016/03/honeybadgerbft.png"/></div>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="conclusion">
|
||||
<h2>Conclusion</h2>
|
||||
<p>That's just the most recent batch of science results from Zcashers. Stay tuned for the next batch!</p>
|
||||
<p>— Zooko Wilcox, March 18, 2016</p>
|
||||
</div>
|
||||
|
|
@ -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 <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <a class="reference external" href="https://github.com/zcash/zcash/releases/tag/v0.11.2.z2">v0.11.2.z2</a>, to the testnet. The new release includes the following changes <a id="id1" class="footnote-reference" href="/new-alpha-release-equihash-and-founders-reward/#id2">[1]</a>:
|
||||
<ol class="arabic simple">
|
||||
<li>We've added the <a class="reference external" href="https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf">Equihash</a> proof-of-work for block mining (<a class="reference external" href="https://github.com/zcash/zcash/issues/27">#27</a>).</li>
|
||||
<li>We've implemented the Founders' Reward as described in <a class="reference external" href="/funding/">our funding post</a> (<a class="reference external" href="https://github.com/zcash/zcash/issues/125">#125</a>).</li>
|
||||
<li>We've added a performance measurement system to improve performance in future releases (<a class="reference external" href="https://github.com/zcash/zcash/issues/748">#748</a>).</li>
|
||||
</ol>
|
||||
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 <a class="reference external" href="https://github.com/zcash/zcash/issues/762">#762</a> <em>Mining Slow Start</em>, <a class="reference external" href="https://github.com/zcash/zcash/issues/856">#856</a> <em>Select Equihash Parameters</em>, and <a class="reference external" href="https://github.com/zcash/zcash/issues/857">#857</a> <em>Optimize Equihash Implementation</em>.
|
||||
|
||||
To get connected to the new testnet, follow the instructions on the <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.
|
||||
<table id="id2" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id1">[1]</a></td>
|
||||
<td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/milestones/PoW%20Release">PoW Release</a> github milestone.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -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 <a class="reference external" href="/new-alpha-release-equihash-and-founders-reward/">last blog post</a>, we announced that we have started using Equihash as the proof-of-work for block mining in Zcash (<a class="reference external" href="https://github.com/zcash/zcash/issues/27">#27</a>).
|
||||
|
||||
<a class="reference external" href="https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf">Equihash</a> 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.
|
||||
<div id="why-are-we-using-it" class="section">
|
||||
<h2>Why are we using it?</h2>
|
||||
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 <a class="reference external" href="http://btcrelay.org/">BTC Relay</a>, 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.
|
||||
|
||||
</div>
|
||||
<div id="how-can-i-mine" class="section">
|
||||
<h2>How can I mine?</h2>
|
||||
The same way as before! Just add <tt class="docutils literal">gen=1</tt> to your config file, or run <tt class="docutils literal">./src/zcashd <span class="pre">-gen</span></tt>.
|
||||
|
||||
</div>
|
||||
<div id="what-are-the-mining-requirements" class="section">
|
||||
<h2>What are the mining requirements?</h2>
|
||||
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 (<a class="reference external" href="https://github.com/zcash/zcash/issues/857">#857</a>), we will bump up the memory requirements to around 1 GB of RAM (<a class="reference external" href="https://github.com/zcash/zcash/issues/856">#856</a>), so you will need that much free memory per mining thread.
|
||||
|
||||
</div>
|
||||
<div id="what-s-next" class="section">
|
||||
<h2>What's next?</h2>
|
||||
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!
|
||||
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<h2 style="margin-bottom:0;">Intro</h2>
|
||||
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 <a class="reference external" href="https://z.cash/team.html">team</a> 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 <a class="reference external" href="https://leastauthority.com/blog/least_authority_performs_security_audit_for_cryptocat.html">Cryptocat</a>, <a class="reference external" href="https://leastauthority.com/blog/least_authority_performs_security_audit_for_globaleaks.html">GlobaLeaks</a>, <a class="reference external" href="https://leastauthority.com/blog/least_authority_performs_security_audit_for_spideroak.html">SpiderOak</a>, and <a class="reference external" href="https://leastauthority.com/blog/least_authority_performs_incentive_analysis_for_ethereum.html">Ethereum</a>.
|
||||
|
||||
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 <a class="reference external" href="http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf">original Zerocash science paper</a>, with scientific peer review, in 2014. Recently, we have extended and improved the protocol, written a detailed new <a class="reference external" href="https://github.com/zcash/zips/raw/master/protocol/protocol.pdf">protocol specification</a>, and scoured it for security vulnerabilities.
|
||||
|
||||
To date, we've found and fixed three security vulnerabilities:
|
||||
<ol class="arabic simple">
|
||||
<li>Zooko Wilcox found the <a class="reference external" href="https://github.com/zcash/zcash/issues/98">Faerie Gold vulnerability</a>, 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.</li>
|
||||
<li>Taylor Hornby found the <a class="reference external" href="https://github.com/zcash/zcash/issues/738">InternalH Collision vulnerability</a>, which would let someone double-spend a specially-crafted note, if they have a computer powerful enough to find 128-bit hash collisions.</li>
|
||||
<li>Daira Hopwood found a non-exploitable <a class="reference external" href="https://github.com/zcash/zcash/issues/836">mistake in the security proof</a>, 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.)</li>
|
||||
</ol>
|
||||
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
|
||||
|
||||
<h2 style="margin-bottom:0;">The InternalH Collision Vulnerability</h2>
|
||||
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}` <a href="http://people.scs.carleton.ca/~paulv/papers/JoC97.pdf">parallelizable</a> 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.
|
||||
<h3>The Mistake</h3>
|
||||
The weakness was in the commitment scheme for notes. Commitment schemes are useful cryptographic tools because they let you publish a <em>commitment</em> to some information without revealing it. Then, at some later time, you can <em>open</em> 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:
|
||||
<ol class="arabic simple">
|
||||
<li><em>Hiding</em>: 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.</li>
|
||||
<li><em>Binding</em>: 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 <em>open</em> to one unique value, and it shouldn't be possible to open the commitment to any other value.</li>
|
||||
</ol>
|
||||
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 <em>binding</em> 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?
|
||||
<h3>The Attack</h3>
|
||||
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.
|
||||
<h3>The Fix</h3>
|
||||
If you read Section 5.1 of the <a class="reference external" href="http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf">original Zerocash science paper</a>, you'll find that :math:`InternalH` was chosen to be 128 bits in order to give the commitment scheme a very strong property called <em>statistical hiding</em>. 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 <em>even if you have an infinitely fast computer</em>, 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)`
|
||||
|
||||
<h3>Conclusion</h3>
|
||||
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 <em>more</em> 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 <a class="reference external" href="https://github.com/zcash/zips/raw/master/protocol/protocol.pdf">protocol specification</a>. 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
|
||||
|
|
@ -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
|
||||
---
|
||||
<div class="admonition admonition-update">
|
||||
<p class="first admonition-title"><strong>2016-09-27 Update:</strong></p>
|
||||
<p class="last">The schedule in this post is outdated. Please see our newer post <a class="reference external" href="/zcash-launch-and-roadmap/">Zcash Launch and Roadmap</a> for the up-to-date schedule for the Zcash launch and the Sprout release series.</p>
|
||||
</div>
|
||||
<div class="figure align-center">
|
||||
<img alt="Zcash Sprout Logo" class="zcash-launch-roadmap" src="http://blog.z.cash/wp-content/uploads/2016/05/zcash-sprout-launch.png"/><p class="caption">Zcash <cite>Sprout</cite> Series</p>
|
||||
</div>
|
||||
<p>In September 2016 the first <a class="reference external" href="/helloworld/">open, permissionless financial system</a> with zero-knowledge security will launch: the Zcash blockchain.</p>
|
||||
<p>Starting with version 1.0 of Zcash, we're launching the <cite>Sprout</cite> 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 <a class="reference external" href="/why-equihash/">new Proof-of-Work algorithm</a>, and an API.</p>
|
||||
<p>The Zcash core design is now in our <a class="reference external" href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol specification</a>. Our roadmap for the 1.0 launch has firmed up. It's embodied in our <a class="reference external" href="https://github.com/zcash/zcash/milestones/">github milestones</a>.</p>
|
||||
<p><cite>Sprout</cite> is only the beginning and there are exciting innovations to come.</p>
|
||||
<div class="section" id="get-involved">
|
||||
<h2>Get Involved</h2>
|
||||
<p>If you're interested in infrequent announcements, such as for our launch, <a class="reference external" href="/#launch-notification">sign up</a> for our email announcement list.</p>
|
||||
<p>Join <a class="reference external" href="https://forum.z.cash/">our forum</a> for user discussions, or our <a class="reference external" href="https://inviteme.z.cash/">Community Slack</a> if you want realtime developer chat.</p>
|
||||
<p>If you're the adventurous type who wants to play with our current alpha code, check out our <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.</p>
|
||||
<p>— Nathan Wilcox and Zooko Wilcox, 2016-05-09</p>
|
||||
</div>
|
||||
|
|
@ -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 <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <a class="reference external" href="https://github.com/zcash/zcash/releases/tag/v0.11.2.z3">v0.11.2.z3</a>, to the testnet. The new release includes the following changes <a id="id1" class="footnote-reference" href="#id2">[1]</a>:
|
||||
<ol class="arabic simple">
|
||||
<li>We've implemented the Zcash protocol in the form of <a class="reference external" href="https://github.com/zcash/zcash/tree/zc.v0.11.2.latest/src/zcash">libzcash</a>, including a rewrite of our zkSNARK circuit. (<a class="reference external" href="https://github.com/zcash/zcash/issues/908">#908</a>)</li>
|
||||
<li>We have a new implementation of our incremental merkle tree with better space efficiency and memory safety. (<a class="reference external" href="https://github.com/zcash/zcash/issues/889">#889</a>)</li>
|
||||
<li>We've replaced crypto++'s key-private encryption with NoteEncryption as defined in our protocol specification. (<a class="reference external" href="https://github.com/zcash/zcash/issues/888">#888</a>)</li>
|
||||
<li>We've added <a class="reference external" href="https://github.com/google/googletest">googletest</a> to our test suite for isolated unit testing of libzcash and other core components in our protocol. (<a class="reference external" href="https://github.com/zcash/zcash/issues/879">#879</a>)</li>
|
||||
</ol>
|
||||
We've been hard at work solidifying a <a class="reference external" href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">protocol specification</a> which addresses security and terminology issues in the original Zerocash design, some of which we mentioned in <a class="reference external" href="/fixing-zcash-vulns/">a previous blog post</a>. 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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.
|
||||
|
||||
To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the github project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.
|
||||
<table id="id2" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id1">[1]</a></td>
|
||||
<td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/issues?q=milestone%3A%22Protocol+2016.0-alpha-3+Implementation%22+is%3Aclosed">Zcash Protocol 2.0</a> github milestone.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<h2>Jobs at Zcash</h2>
|
||||
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.
|
||||
<div id="engineering" class="section">
|
||||
<h3>Engineering</h3>
|
||||
cryptography, cryptocurrencies, C++, distributed systems, secure coding, network protocols, test-driven development, Rust
|
||||
|
||||
</div>
|
||||
<div id="devops" class="section">
|
||||
<h3>Devops</h3>
|
||||
operational security, web site, backups, source code management, monitoring and alerting, continuous integration, measurement and visualization
|
||||
|
||||
</div>
|
||||
<div id="external-communications" class="section">
|
||||
<h3>External Communications</h3>
|
||||
writing, editing, social media, design, community relations, press relations, international relations, Chinese, Spanish, Portugese, Russian
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<div id="our-culture" class="section">
|
||||
<h2>Our culture</h2>
|
||||
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 <a class="reference external" href="mailto:info@z.cash">info@z.cash</a>.
|
||||
|
|
@ -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
|
||||
---
|
||||
<h3 class="author">Taylor Hornby, Sean Bowe</h3>
|
||||
<p>Today, we deployed a new alpha release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference
|
||||
implementation, <a class="reference external" href="https://github.com/zcash/zcash/releases/tag/v0.11.2.z4">v0.11.2.z4</a>, to the testnet. The new release includes the following changes <a class="footnote-reference" href="#id2" id="id1">[1]</a>:</p>
|
||||
<ol class="arabic simple"><li>We implemented a mining slow start to slowly ramp up the controlled currency supply after launch. (<a class="reference external" href="https://github.com/zcash/zcash/issues/762">#762</a>).</li>
|
||||
<li>We enabled binary serialization (<a class="reference external" href="https://github.com/zcash/zcash/issues/954">#954</a>) and multicore zkSNARK computation in libsnark (<a class="reference external" href="https://github.com/zcash/zcash/issues/957">#957</a>) which provide performance improvements visible on our new <a class="reference external" href="https://speed.z.cash/comparison/?exe=1%2B9%2C1%2B25&ben=7%2C2&env=1&hor=false&bas=none&chart=normal+bars">performance tracker</a>.</li>
|
||||
<li>We added cryptographic binding of transactions using Ed25519 (<a class="reference external" href="https://github.com/zcash/zcash/issues/976">#976</a>).</li>
|
||||
<li>We optimized the memory usage of our implementation of the Equihash proof of work (<a class="reference external" href="https://github.com/zcash/zcash/issues/921">#921</a>). The differences in running time and memory usage between the unoptimized and optimized versions are visualized <a class="reference external" href="https://speed.z.cash/comparison/?exe=1%2B9%2C1%2B25&ben=9%2C4&env=1&hor=false&bas=none&chart=normal+bars">in this chart</a>.</li>
|
||||
</ol><p>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.</p>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.</p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the github project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/issues?q=milestone%3A%22Protocol+2016.0-beta%22+is%3Aclosed">Protocol 2016.0-beta</a> github milestone.</td></tr></tbody></table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we deployed a new alpha release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <a class="reference external" href="https://github.com/zcash/zcash/releases/tag/v0.11.2.z5">v0.11.2.z5</a>, to the testnet. The new release includes the following changes <a class="footnote-reference" href="#id2" id="id1">[1]</a>:</p>
|
||||
<ol class="arabic simple"><li>The block interval target has been decreased to 2.5 minutes, without changing the monetary supply curve (<a class="reference external" href="https://github.com/zcash/zcash/pull/989">#989</a>).</li>
|
||||
<li>The difficulty adjustment has been changed to one based on DigiShield v3/v4 (<a class="reference external" href="https://github.com/zcash/zcash/issues/147">#147</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1004">#1004</a>).</li>
|
||||
<li>Coinbase rewards must be protected before they can be used in transparent transactions (<a class="reference external" href="https://github.com/zcash/zcash/pull/1017">#1017</a>).</li>
|
||||
<li>Upstream's soft forking rules now apply unconditionally to all blocks from the start (<a class="reference external" href="https://github.com/zcash/zcash/pull/1016">#1016</a>).</li>
|
||||
<li>The Equihash implementation has been optimized further (<a class="reference external" href="https://github.com/zcash/zcash/pull/988">#988</a>), enabling us to switch to more difficult (higher memory) parameters (<a class="reference external" href="https://github.com/zcash/zcash/pull/1003">#1003</a>). The difference can be seen <a class="reference external" href="https://speed.z.cash/comparison/?exe=1%2B25%2C1%2B43&ben=9%2C4&env=1&hor=false&bas=none&chart=normal+bars">on our performance tracker</a>.</li>
|
||||
<li>The <tt class="docutils literal"><span class="pre">-relaypriority</span></tt> default has been set to <tt class="docutils literal">false</tt>, to enable spending of low-value rewards during mining slow start (<a class="reference external" href="https://github.com/zcash/zcash/pull/1001">#1001</a>).</li>
|
||||
<li>The note commitment tree depth has been increased from 20 to 29 (<a class="reference external" href="https://github.com/zcash/zcash/pull/994">#994</a>). The resulting increase in memory usage when creating a JoinSplit is visible <a class="reference external" href="https://speed.z.cash/comparison/?exe=1%2B25%2C1%2B43&ben=7%2C2&env=1&hor=false&bas=none&chart=normal+bars">here</a>.</li>
|
||||
<li>Zcash addreses and spending keys are now encoded with Base58Check (<a class="reference external" href="https://github.com/zcash/zcash/pull/1026">#1026</a>).</li>
|
||||
</ol><p>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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.</p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the github project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/issues?q=milestone%3A%22Protocol+2016.1+Implementation%22+is%3Aclosed">Protocol 2016.1 Implementation</a> github milestone.</td></tr></tbody></table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<a class="reference external" href="https://en.wikipedia.org/wiki/Pairing-based_cryptography">Pairing cryptography</a> is an exciting area of research, and an essential component of Zcash's <strong>zkSNARKs</strong> — proofs that transactions are valid without requiring users to reveal private information. Earlier this year we also used zkSNARKs to make Bitcoin's <a class="reference external" href="https://z.cash/blog/science-roundup.html">first zero-knowledge contingent payment</a>!
|
||||
|
||||
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 <a class="reference external" href="https://en.wikipedia.org/wiki/Pairing-based_cryptography">pairing cryptography</a> library for Rust called "bn". Pairing cryptography is important for zkSNARKs, but what exactly is it?
|
||||
<h2>Elliptic Curves</h2>
|
||||
Regular <a class="reference external" href="https://en.wikipedia.org/wiki/Elliptic_curve_cryptography">elliptic curve</a> constructions like <a class="reference external" href="http://www.secg.org/sec2-v2.pdf">secp256k1</a> — used in Bitcoin — are designed for things like <a class="reference external" href="https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm">digital signatures</a>. The points on the curve form a <a class="reference external" href="https://en.wikipedia.org/wiki/Cyclic_group">cyclic group</a>: 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 <cite>A</cite>, <cite>B</cite>, and <cite>C</cite>, <cite>A</cite> obtains the shared secret by having <cite>B</cite> send his public key to <cite>C</cite>, who multiplies it by her private key and sends the result to <cite>A</cite>, who can then derive the shared secret by multiplying it by her private key.
|
||||
<h2>Pairing cryptography</h2>
|
||||
Pairing cryptography is an extension of these concepts. Now imagine that we have <em>two</em> 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 <em>bilinear</em>, 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.
|
||||
<h2>Joux's key agreement protocol</h2>
|
||||
Let's apply pairing cryptography to the three-party key exchange scenario above. Using pairings, we can perform the exchange in <em>one round</em>. 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:
|
||||
<table class="docutils" border="1"><colgroup> <col width="33%" /> <col width="33%" /> <col width="33%" /> </colgroup>
|
||||
<thead valign="bottom">
|
||||
<tr>
|
||||
<th class="head">Alice Computes</th>
|
||||
<th class="head">Bob Computes</th>
|
||||
<th class="head">Carol Computes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td>:math:`e(B_{1}^{pk}, C_{2}^{pk})^{A^{sk}}`</td>
|
||||
<td>:math:`e(C_{1}^{pk}, A_{2}^{pk})^{B^{sk}}`</td>
|
||||
<td>:math:`e(A_{1}^{pk}, B_{2}^{pk})^{C^{sk}}`</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3">All equivalent to :math:`e(g_{1}, g_{2})^{A^{sk} B^{sk} C^{sk}}`</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
Or, if you prefer code, check out an example from our new library:
|
||||
<table class="codehilitetable">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="linenos">
|
||||
<div class="linenodiv">
|
||||
<pre> 1
|
||||
2
|
||||
3
|
||||
4
|
||||
5
|
||||
6
|
||||
7
|
||||
8
|
||||
9
|
||||
10
|
||||
11
|
||||
12
|
||||
13
|
||||
14
|
||||
15
|
||||
16</pre>
|
||||
</div></td>
|
||||
<td class="code">
|
||||
<div class="codehilite">
|
||||
<pre><span class="c1">// Generate private keys</span>
|
||||
<span class="kd">let</span> <span class="n">alice_sk</span> <span class="o">=</span> <span class="n">Scalar</span>::<span class="n">random</span><span class="p">(</span><span class="n">rng</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="n">bob_sk</span> <span class="o">=</span> <span class="n">Scalar</span>::<span class="n">random</span><span class="p">(</span><span class="n">rng</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="n">carol_sk</span> <span class="o">=</span> <span class="n">Scalar</span>::<span class="n">random</span><span class="p">(</span><span class="n">rng</span><span class="p">);</span>
|
||||
|
||||
<span class="c1">// Generate public keys in G1 and G2</span>
|
||||
<span class="kd">let</span> <span class="p">(</span><span class="n">alice_pk1</span><span class="p">,</span> <span class="n">alice_pk2</span><span class="p">)</span> <span class="o">=</span> <span class="p">(</span><span class="n">G1</span>::<span class="n">one</span><span class="p">()</span> <span class="o">*</span> <span class="o">&</span><span class="n">alice_sk</span><span class="p">,</span> <span class="n">G2</span>::<span class="n">one</span><span class="p">()</span> <span class="o">*</span> <span class="o">&</span><span class="n">alice_sk</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="p">(</span><span class="n">bob_pk1</span><span class="p">,</span> <span class="n">bob_pk2</span><span class="p">)</span> <span class="o">=</span> <span class="p">(</span><span class="n">G1</span>::<span class="n">one</span><span class="p">()</span> <span class="o">*</span> <span class="o">&</span><span class="n">bob_sk</span><span class="p">,</span> <span class="n">G2</span>::<span class="n">one</span><span class="p">()</span> <span class="o">*</span> <span class="o">&</span><span class="n">bob_sk</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="p">(</span><span class="n">carol_pk1</span><span class="p">,</span> <span class="n">carol_pk2</span><span class="p">)</span> <span class="o">=</span> <span class="p">(</span><span class="n">G1</span>::<span class="n">one</span><span class="p">()</span> <span class="o">*</span> <span class="o">&</span><span class="n">carol_sk</span><span class="p">,</span> <span class="n">G2</span>::<span class="n">one</span><span class="p">()</span> <span class="o">*</span> <span class="o">&</span><span class="n">carol_sk</span><span class="p">);</span>
|
||||
|
||||
<span class="c1">// Each party computes the shared secret</span>
|
||||
<span class="kd">let</span> <span class="n">alice_ss</span> <span class="o">=</span> <span class="n">pairing</span><span class="p">(</span><span class="o">&</span><span class="n">bob_pk1</span><span class="p">,</span> <span class="o">&</span><span class="n">carol_pk2</span><span class="p">)</span> <span class="o">^</span> <span class="o">&</span><span class="n">alice_sk</span><span class="p">;</span>
|
||||
<span class="kd">let</span> <span class="n">bob_ss</span> <span class="o">=</span> <span class="n">pairing</span><span class="p">(</span><span class="o">&</span><span class="n">carol_pk1</span><span class="p">,</span> <span class="o">&</span><span class="n">alice_pk2</span><span class="p">)</span> <span class="o">^</span> <span class="o">&</span><span class="n">bob_sk</span><span class="p">;</span>
|
||||
<span class="kd">let</span> <span class="n">carol_ss</span> <span class="o">=</span> <span class="n">pairing</span><span class="p">(</span><span class="o">&</span><span class="n">alice_pk1</span><span class="p">,</span> <span class="o">&</span><span class="n">bob_pk2</span><span class="p">)</span> <span class="o">^</span> <span class="o">&</span><span class="n">carol_sk</span><span class="p">;</span>
|
||||
|
||||
<span class="n">assert</span><span class="o">!</span><span class="p">(</span><span class="n">alice_ss</span> <span class="o">==</span> <span class="n">bob_ss</span> <span class="o">&&</span> <span class="n">bob_ss</span> <span class="o">==</span> <span class="n">carol_ss</span><span class="p">);</span>
|
||||
</pre>
|
||||
</div></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>bn</h2>
|
||||
The "bn" crate is a <a class="reference external" href="https://www.rust-lang.org/">Rust language</a> library for performing these pairing operations using a cryptographic construction designed by our scientists in <a class="reference external" href="http://eprint.iacr.org/2013/879">[BCGTV14]</a>. 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 <a class="reference external" href="https://github.com/zcash/bn">on github</a> or <a class="reference external" href="https://crates.io/crates/bn">on crates.io</a>! And feel free to join <a class="reference external" href="https://inviteme.z.cash/">our Slack</a> or sign up for <a class="reference external" href="https://z.cash/#launch-notification">email notifications</a> from our team!
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we deployed a new alpha release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <a class="reference external" href="https://github.com/zcash/zcash/releases/tag/v0.11.2.z6">v0.11.2.z6</a>, to the testnet. The new release includes the following changes <a class="footnote-reference" href="#id2" id="id1">[1]</a>:</p>
|
||||
<ol class="arabic simple"><li>The block size limit has been increased to 2MB. (<a class="reference external" href="https://github.com/zcash/zcash/issues/765">#765</a>) We're tracking the worst-case verification costs in <a class="reference external" href="https://speed.z.cash/timeline/?exe=1&base=1%2B9&ben=time+validatelargetx&env=1&revs=10&equid=off&quarts=on&extr=on">some new performance measurements</a> and in <a class="reference external" href="https://github.com/zcash/zcash/issues/1077">#1077</a> in
|
||||
order to mitigate potential DoS attacks.</li>
|
||||
<li>Equihash nonces are now randomized to avoid duplicate effort by miners. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1060">#1060</a>)</li>
|
||||
<li>Equihash solving runs are now slightly more efficient. See <a class="reference external" href="https://github.com/zcash/zcash/pull/1049">#1049</a> and the <a class="reference external" href="https://speed.z.cash/timeline/?exe=1&base=1%2B9&ben=time+solveequihash&env=1&revs=10&equid=off&quarts=on&extr=on">change in performance measurements</a> on our tracker.</li>
|
||||
</ol><p>Unlike previous alpha releases, we have not reset the testnet in order to give our <a class="reference external" href="/new-alpha-release-mining-slow-start/">mining slow start</a> more time to run. Therefore, the block size limit change has been introduced as a (naive) hardfork.</p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the github project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/issues?q=milestone%3A%22Consensus+Parameter+Tuning+%2F+Optimization%22+is%3Aclosed">Consensus Parameter Tuning / Optimization</a> github milestone.</td></tr></tbody></table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>Zcash is a global company, interested in inviting all Zcash participants around the world to join the conversation!</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we deployed a new alpha release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <a class="reference external" href="https://github.com/zcash/zcash/releases/tag/v0.11.2.z7">v0.11.2.z7</a>, to the testnet. The new release includes the following changes <a class="footnote-reference" href="#id2" id="id1">[1]</a>:</p>
|
||||
<ol class="arabic simple"><li>The terminology of the RPC and internal code has been modified to reflect our
|
||||
protocol specification. (<a class="reference external" href="https://github.com/zcash/zcash/issues/1090">#1090</a>)</li>
|
||||
<li>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 <a class="reference external" href="https://speed.z.cash/timeline/?exe=1&base=1%2B9&ben=memory+createjoinsplit&env=1&revs=50&equid=off&quarts=on&extr=on">improved</a> by several hundred megabytes. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1104">#1104</a>)</li>
|
||||
<li>We have published <a class="reference external" href="https://github.com/zcash/zcash/blob/zc.v0.11.2.latest/doc/security-warnings.md">guidelines</a> about side-channel attacks and other security warnings.</li>
|
||||
<li>The alert key has been changed. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1105">#1105</a>)</li>
|
||||
<li>A bug in the difficulty adjustment algorithm has been fixed. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1124">#1124</a>)</li>
|
||||
</ol><p>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.</p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the github project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/milestone/26?closed=1">z7 release</a> github milestone.</td></tr></tbody></table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Side Channel Attacks on Everyday Applications</h2>
|
||||
<p>Zcasher Taylor Hornby will be presenting on <a class="reference external" href="https://www.blackhat.com/us-16/briefings.html#side-channel-attacks-on-everyday-applications">Side Channel Attacks on Everyday Applications</a> at the Black Hat conference on August 3.</p>
|
||||
<p>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.</p>
|
||||
<p>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 (<a class="reference external" href="http://cs.tau.ac.il/~tromer/cache/">http://cs.tau.ac.il/~tromer/cache/</a>).</p>
|
||||
<p>The event is in Las Vegas, USA from July 30-Aug 4, 2016. Full info here: <a class="reference external" href="https://www.blackhat.com/us-16/">https://www.blackhat.com/us-16/</a></p>
|
||||
|
||||
<h2>Image Authentication</h2>
|
||||
<p>Zcash scientist, Eran Tromer, presents an application of SNARKs in the area of image authentication.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>There is more information about this here: <a class="reference external" href="https://cs.tau.ac.il/~tromer/photoproof/">https://cs.tau.ac.il/~tromer/photoproof/</a></p>
|
||||
|
||||
<h2>Lawsuit on DMCA Section 1201: Research & Technology Restrictions Violate 1st Amendment</h2>
|
||||
<p>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 <a class="reference external" href="https://www.eff.org/press/releases/eff-lawsuit-takes-dmca-section-1201-research-and-technology-restrictions-violate">this blog post</a>.</p>
|
||||
<p>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.”</p>
|
||||
|
||||
<h2>Blind Off-Chain Lightweight Transactions</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Towards Trapdoor-Free Zero Knowledge Proving Systems</h2>
|
||||
<p>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).</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>In <a class="reference external" href="https://eprint.iacr.org/2016/646">a recent work</a>, 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 <a class="reference external" href="http://www.scipr-lab.org/team.html">team working on this</a> includes five Zcashers: Eli Ben-Sasson, Alessandro Chiesa, Ariel Gabizon, Eran Tromer and Madars Virza.</p>
|
||||
|
||||
<h2>Ciphertext Attacks on iMessage</h2>
|
||||
<p>The Washington Post published the story: "<a class="reference external" href="https://www.washingtonpost.com/world/national-security/johns-hopkins-researchers-discovered-encryption-flaw-in-apples-imessage/2016/03/20/a323f9a0-eca7-11e5-a6f3-21ccdbc5f74e_story.html">Johns Hopkins researchers poke a hole in Apple’s encryption</a>," 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: “<a class="reference external" href="https://isi.jhu.edu/~mgreen/imessage.pdf">Dancing on the Lip of the Volcano: Chosen Ciphertext Attacks on Apple iMessage.</a>”</p>
|
||||
<p>From Matthew Green’s blog post (<a class="reference external" href="http://blog.cryptographyengineering.com/2016/03/attack-of-week-apple-imessage.html">full text here</a>)...
|
||||
“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.”</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="iMessage research team" class="blog-imessage-research-team" src="http://blog.z.cash/wp-content/uploads/2016/07/imessage-research-team.png"/></div>
|
||||
<p>The research team. From left: Gabe Kaptchuk, Mike Rushanan, Ian Miers, Christina Garman</p>
|
||||
<p>Connect to the Zcash conversation by <a class="reference external" href="https://inviteme.z.cash/">joining our Slack channel</a> or get infrequent email notifications by <a class="reference external" href="https://z.cash/zh/#launch-notification">signing up</a>.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Over the last week, Zcashers Vitalik Buterin, Andrew Miller, Eran Tromer and myself have been at the <a class="reference external" href="http://initc3.org/events-bootcamp.php">Ethereum/IC3 Bootcamp</a> 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.</p>
|
||||
<div class="figure">
|
||||
<img alt="SNARKs in Ethereum Team Photo" src="http://blog.z.cash/wp-content/uploads/2016/07/bootcamp.jpg"/><p class="caption">(Left to Right) Yuncong Hu, Casey Detrio, Josh Gancher, Sean Bowe, Eran Tromer</p>
|
||||
</div>
|
||||
<div class="section" id="snarks">
|
||||
<h2>SNARKs</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>In our work this week, we extended the Ethereum contract language to efficiently support verification of zkSNARK proofs. Specifically, we added a <cite>snarkverify</cite> precompile (like an opcode) to a fork of <a class="reference external" href="https://github.com/ethcore/parity">Parity</a> which uses libsnark to verify generic proofs.</p>
|
||||
</div>
|
||||
<div class="section" id="zerocash-over-ethereum">
|
||||
<h2>Zerocash over Ethereum</h2>
|
||||
<img alt="Sean Bowe demonstrates the circuit." src="http://blog.z.cash/wp-content/uploads/2016/07/bootcamp_sean.jpg"/><p>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.</p>
|
||||
<p>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 <em>we know</em> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>The idea of integrating Zerocash into a currency using a SNARK verification opcode goes back to the original Zerocash paper (Section 6.3 in <a class="reference external" href="https://eprint.iacr.org/2014/349">Zerocash extended version</a>). Following this prescription, it is possible to extend the ZoE contract to work with the complete Zerocash protocol.</p>
|
||||
</div>
|
||||
<div class="section" id="conclusion">
|
||||
<h2>Conclusion</h2>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/babyzoe">here</a>.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="http://eprint.iacr.org/2016/701">http://eprint.iacr.org/2016/701</a>.</p>
|
||||
<div class="section" id="the-problem">
|
||||
<h2>The Problem</h2>
|
||||
<p>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 <em>you are recording every transaction in public on a blockchain</em>. 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.</p>
|
||||
</div>
|
||||
<div class="section" id="payment-channels">
|
||||
<h2>Payment channels</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="channels-are-not-private">
|
||||
<h2>Channels are not private</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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 <em>a priori</em> 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 <em>part</em> of the solution, but Zcash itself does not a private payment channel make.</p>
|
||||
</div>
|
||||
<div class="section" id="bolt-private-payment-channels">
|
||||
<h2>BOLT: Private Payment Channels</h2>
|
||||
<p>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 <em>all</em> payments made to that recipient.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<div class="figure align-right">
|
||||
<img alt="BOLT Diagram" src="http://blog.z.cash/wp-content/uploads/2016/08/bolt2.png"/></div>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<img alt="BOLT Diagram" src="http://blog.z.cash/wp-content/uploads/2016/08/bolt.png"/><p>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.</p>
|
||||
<p>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 <em>will</em> 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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="indirect-payment-channels">
|
||||
<h2>Indirect Payment Channels</h2>
|
||||
<p>So far, we require Alice and Bob to have a payment channel. But what if they don’t?</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="can-bolt-work-without-zcash">
|
||||
<h2>Can BOLT work without Zcash?</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we deployed a new alpha release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <a class="reference external" href="https://github.com/zcash/zcash/releases/tag/v0.11.2.z8">v0.11.2.z8</a>, to the testnet. The new release includes the following changes <a class="footnote-reference" href="#id2" id="id1">[1]</a>:</p>
|
||||
<ol class="arabic simple"><li>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. (<a class="reference external" href="https://github.com/zcash/zcash/issues/856">#856</a>)</li>
|
||||
<li>The Equihash miner will now interrupt and cancel an existing solution search when a new valid block arrives. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1055">#1055</a>)</li>
|
||||
<li>The Equihash miner will now check solutions as soon as they are found. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1143">#1143</a>)</li>
|
||||
<li>Transaction malleability has been fixed so that valid transactions can not be modified in-flight. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1144">#1144</a>)</li>
|
||||
<li>The SIGHASH_SINGLE bug has been fixed. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1078">#1078</a>)</li>
|
||||
<li>Compilation flags have been updated to harden security. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1064">#1064</a>)</li>
|
||||
</ol><p>The zcraw* RPC commands are still available for use but will be deprecated in a future release.</p>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.</p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the github project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/milestone/36?closed=1">z8 release</a> github milestone.</td></tr></tbody></table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Our <a class="reference external" href="/helloworld/">mission</a> 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.</p>
|
||||
<div class="section" id="audit-strategy">
|
||||
<h2>Audit Strategy</h2>
|
||||
<p>Zcash combines novel cryptography with blockchain consensus, and <a class="reference external" href="https://github.com/zcash/zcash">our reference implementation</a> 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.</p>
|
||||
</div>
|
||||
<div class="section" id="auditors-and-consultants">
|
||||
<h2>Auditors and Consultants</h2>
|
||||
<p>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.</p>
|
||||
<p><a class="reference external" href="https://www.nccgroup.trust/us/">NCC Group</a> - From working alongside NCC Group as the <a class="reference external" href="https://leastauthority.com">Least Authority</a> auditing team, we were impressed with their abilities as skilled security auditors for cryptographic software.</p>
|
||||
<p><a class="reference external" href="https://coinspect.com/">Coinspect</a> - When we wanted to find cryptocurrency specialists, Coinspect quickly came to mind. They've published many innovative protocol designs, as well as insightful analyses.</p>
|
||||
<p><a class="reference external" href="https://en.wikipedia.org/wiki/Solar_Designer">Solar Designer</a> - We chose Solar Designer because he is a famous <a class="reference external" href="http://phrack.org/issues/69/2.html">old school hacker</a>, 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).</p>
|
||||
<p>We are proud to work with teams that, like us, value open source, and aim to create accessible and secure systems for everyone.</p>
|
||||
</div>
|
||||
<div class="section" id="scope">
|
||||
<h2>Scope</h2>
|
||||
<p>We are focusing our audits on specific components:</p>
|
||||
<ul class="simple"><li>zkSNARK cryptography (eg: libsnark)</li>
|
||||
<li>Zcash cryptographic construction (our "zk-SNARK circuit")</li>
|
||||
<li>Proof of Work algorithm - Equihash</li>
|
||||
<li>Consensus changes (from Bitcoin)</li>
|
||||
<li>Specification adherence</li>
|
||||
<li>C++, race conditions, networking, buffer overflows, dependency management</li>
|
||||
</ul><p>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:</p>
|
||||
<ul class="simple"><li>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.</li>
|
||||
<li>The zkSNARK cryptographic technique is peer reviewed, so we won't look for breakthroughs there.</li>
|
||||
<li>We use only a subset of libsnark, so we'll ignore the parts we don't use <a class="footnote-reference" href="#id2" id="id1">[1]</a>.</li>
|
||||
<li>The Zcash circuit is modified from the peer-reviewed Zerocash circuit, so we will focus more on the changes than the whole construction.</li>
|
||||
</ul></div>
|
||||
<div class="section" id="schedule">
|
||||
<h2>Schedule</h2>
|
||||
<p>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 <a class="reference external" href="/zcash-launch-and-roadmap/">Zcash Sprout Launch post</a>.</p>
|
||||
</div>
|
||||
<div class="section" id="understanding-risk">
|
||||
<h2>Understanding Risk</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="conclusion">
|
||||
<h2>Conclusion</h2>
|
||||
<p>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.</p>
|
||||
<p>— Nathan Wilcox, 2016-08-17</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>We have created a libsnark fork which removed portions unused by Zcash.</td></tr></tbody></table></div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<div class="figure align-center">
|
||||
<img alt="Zcash Sprout Launch Logo" class="zcash-launch-roadmap" src="http://blog.z.cash/wp-content/uploads/2016/05/zcash-sprout-launch.png"/><p class="caption">Zcash <cite>Sprout</cite> Launch</p>
|
||||
</div>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="/helloworld/">open, permissionless financial system</a> 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.</p>
|
||||
<div class="section" id="audits">
|
||||
<h2>Audits</h2>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="beta">
|
||||
<h2>Beta</h2>
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="beta-phase-goals">
|
||||
<h2>Beta Phase Goals</h2>
|
||||
<p>Previously <a class="reference external" href="/sprout-roadmap/">we described</a> 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.</p>
|
||||
<p>We'll describe each of these Beta Phase goals in the coming months when the time is right. Stay tuned!</p>
|
||||
</div>
|
||||
<div class="section" id="the-launch-and-sprout-series">
|
||||
<h2>The Launch and Sprout Series</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="get-involved">
|
||||
<h2>Get Involved</h2>
|
||||
<p>The updated Zcash core design is in our <a class="reference external" href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash Protocol specification</a>. Our roadmap for the Beta and 1.0 launches is embodied in our <a class="reference external" href="https://github.com/zcash/zcash/milestones/">github milestones</a>.</p>
|
||||
<p>If you're interested in infrequent announcements, such as for our launch, <a class="reference external" href="https://z.cash/#launch-notification">sign up</a> for our email announcement list.</p>
|
||||
<p>Join <a class="reference external" href="https://forum.z.cash/">our forum</a> for user discussions, or our <a class="reference external" href="https://inviteme.z.cash/">Community Slack</a> if you want realtime developer chat.</p>
|
||||
<p>If you're the adventurous type who wants to play with our current alpha code, check out our <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.</p>
|
||||
<p>— Nathan Wilcox, 2016-08-15</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we deployed a new alpha release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <a class="reference external" href="https://github.com/zcash/zcash/releases/tag/v0.11.2.z9">v0.11.2.z9</a>, to the testnet. The new release includes the following changes <a class="footnote-reference" href="#id2" id="id1">[1]</a>:</p>
|
||||
<ol class="arabic simple"><li>Decreased block header size to address a bug interfering with the testnet (<a class="reference external" href="https://github.com/zcash/zcash/pull/1289">#1289</a>).</li>
|
||||
<li>Ensured that Zcash secrets are saved along with Bitcoin secrets in wallets (<a class="reference external" href="https://github.com/zcash/zcash/pull/1198">#1198</a>).</li>
|
||||
<li>Implemented more space-efficient encodings for Equihash solutions (<a class="reference external" href="https://github.com/zcash/zcash/pull/1175">#1175</a>).</li>
|
||||
<li>Implemented more space-efficient encodings for zk-SNARK proofs following an IEEE standard (<a class="reference external" href="https://github.com/zcash/zcash/pull/1262">#1262</a>).</li>
|
||||
<li>Increased the size of the memo field sent with notes, to 512 bytes (<a class="reference external" href="https://github.com/zcash/zcash/pull/1187">#1187</a>).</li>
|
||||
<li>Merged in upstream Bitcoin patches related to Denial-of-Service protection (<a class="reference external" href="https://github.com/zcash/zcash/pull/1251">#1251</a>).</li>
|
||||
<li>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 (<a class="reference external" href="https://github.com/zcash/zcash/issues/701">#701</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/756">#756</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1197">#1197</a>).</li>
|
||||
<li>Began addressing issues found by NCC Group as part of our <a class="reference external" href="/auditing-zcash/">security audits</a> (<a class="reference external" href="https://github.com/zcash/zcash/pull/1214">#1214</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1215">#1215</a>).</li>
|
||||
</ol><p>We do not expect to make any other changes to the consensus protocol, except for possible security fixes, until after 1.0.</p>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Alpha-Guide">Public Alpha Guide</a>.</p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the github project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To
|
||||
get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address
|
||||
<a class="reference external" href="https://z.cash/#launch-notification">in here</a>.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/milestone/27?closed=1">z9 release</a> github milestone.</td></tr></tbody></table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="https://www.youtube.com/watch?v=nl5dlbCh8lY">Carl Sagan</a> and <a class="reference external" href="https://www.youtube.com/watch?v=FjHJ7FmV0M4">Richard Feynman</a> 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 <a class="reference external" href="https://bqp.io/">BQP.io</a>.</p>
|
||||
<p>I'm saddened to be leaving an amazing <a class="reference external" href="https://z.cash/team.html">team</a> 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.</p>
|
||||
<p>The great team makes me confident Zcash will be a success, and I'm super excited for the production blockchain to launch this Fall!</p>
|
||||
<p>Stay tuned for our next blog post about the new hires.</p>
|
||||
<p>— Taylor Hornby, Aug 26, 2016</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki">here</a>. 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.</p>
|
||||
<p>Although such modifications are often thought to be just a <a class="reference external" href="https://cointelegraph.com/news/the-ongoing-bitcoin-malleability-attack">nuisance</a>, 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 <a class="reference external" href="https://lightning.network/">Lightning</a> and <a class="reference external" href="/bolt-private-payment-channels/">BOLT</a>, are more practical if transaction malleability is first solved.</p>
|
||||
<p>So how to fix malleability? One solution proposed to us has been to back-port <a class="reference external" href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/">Segregated Witness</a> (segwit) which addresses a range of issues including malleability. However, <a class="reference external" href="https://github.com/zcash/zcash/issues/451">it was decided</a> 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 <a class="reference external" href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013098.html">mostly complete</a>, but it has yet to be deployed and activated across the Bitcoin network.</p>
|
||||
<p>Our own attempt at a smaller and more focused solution was released a few weeks ago as part of the <a class="reference external" href="/new-alpha-release-optimization-and-nonmalleability/">z8 alpha release</a> 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 <a class="reference external" href="/auditing-zcash/">security audit</a> of Zcash. Although the fix itself is fairly simple, the ensuing <a class="reference external" href="https://github.com/zcash/zcash/issues/1304">discussion</a> raised a number of issues for the team to evaluate in order to provide a comprehensive and robust solution.</p>
|
||||
<p>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 <a class="reference external" href="http://coinspect.com/">Coinspect</a> for helping us to catch some butterflies!</p>
|
||||
<p>Please help us by running the latest <a class="reference external" href="/new-alpha-release-solidifying-the-consensus-protocol/">z9 alpha release</a> of Zcash and letting us know of any bugs, issues and usability problems you come across. You can reach the team by filing a <a class="reference external" href="https://github.com/zcash/zcash/issues">GitHub issue</a> or visiting the <a class="reference external" href="https://zcashcommunity.slack.com/messages/zcash/">Zcash Community Slack</a> channel. Thank you.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<div class="new-hire-post section" id="ariel-gabizon">
|
||||
<h2>Ariel Gabizon</h2>
|
||||
<div class="section" id="cryptographic-engineer">
|
||||
<h3>Cryptographic Engineer</h3>
|
||||
<p>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.</p>
|
||||
<blockquote>
|
||||
“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.”</blockquote>
|
||||
</div>
|
||||
</div>
|
||||
<hr class="docutils"/><div class="new-hire-post section" id="kevin-gallagher">
|
||||
<h2>Kevin Gallagher</h2>
|
||||
<div class="section" id="devops-engineer">
|
||||
<h3>Devops Engineer</h3>
|
||||
<p>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.</p>
|
||||
<blockquote>
|
||||
<em>"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."</em></blockquote>
|
||||
</div>
|
||||
</div>
|
||||
<hr class="docutils"/><div class="new-hire-post section" id="jay-graber">
|
||||
<h2>Jay Graber</h2>
|
||||
<div class="section" id="web-developer">
|
||||
<h3>Web Developer</h3>
|
||||
<p>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.</p>
|
||||
<blockquote>
|
||||
<em>“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.”</em></blockquote>
|
||||
</div>
|
||||
</div>
|
||||
<hr class="docutils"/><div class="new-hire-post section" id="simon-liu">
|
||||
<h2>Simon Liu</h2>
|
||||
<div class="section" id="senior-software-engineer">
|
||||
<h3>Senior Software Engineer</h3>
|
||||
<p>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.</p>
|
||||
<blockquote>
|
||||
<em>“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."</em></blockquote>
|
||||
</div>
|
||||
</div>
|
||||
<hr class="docutils"/><div class="new-hire-post section" id="paige-peterson">
|
||||
<h2>Paige Peterson</h2>
|
||||
<div class="section" id="communication-design">
|
||||
<h3>Communication/Design</h3>
|
||||
<p>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.</p>
|
||||
<blockquote>
|
||||
<em>“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."</em></blockquote>
|
||||
<hr class="docutils"/><p>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.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Last week Coin Center <a class="reference external" href="http://coincenter.org/entry/celebrating-two-years-of-fighting-for-sane-bitcoin-policy">celebrated</a> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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. ❤</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we deployed the first beta release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <cite>v1.0.0-beta1</cite>, to the testnet. This release, <cite>Beta 1</cite>, is the first release of the Zcash <cite>Beta Series</cite> and represents a new phase of development.</p>
|
||||
<p><em>Note: the official Zcash currency is non-existent until our October 28th launch. Only testnet coins exist and they carry no value.</em></p>
|
||||
<div class="section" id="zcash-beta-series">
|
||||
<h2>Zcash Beta Series</h2>
|
||||
<p>The Beta series is the final phase of development prior to the launch of Zcash 1.0.0, which begins the <a class="reference external" href="/sprout-roadmap/">Sprout Series</a>. The Beta Series is notably different from our earlier alpha releases in several ways:</p>
|
||||
<ul class="simple"><li>We're using a new versioning scheme, the first beta release is <cite>v1.0.0-beta1</cite>, the next <cite>v1.0.0-beta2</cite> and so on.</li>
|
||||
<li>Starting with <cite>v1.0.0-beta1</cite> the new high level <a class="reference external" href="https://github.com/zcash/zcash/blob/v1.0.0-beta1/doc/payment-api.md">RPC interface</a> is in place. The early RPC interface is deprecated and will be removed.</li>
|
||||
<li>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.</li>
|
||||
</ul><p>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.</p>
|
||||
<p><em>The Zcash Beta Series is a good time for integration work for third party services and products interested in deploying Zcash support.</em></p>
|
||||
<p>As the Beta Series matures, we'll enter a <cite>pre-release phase</cite> during which we'll publish several essential items:</p>
|
||||
<ul class="simple"><li>security audit reports</li>
|
||||
<li>proof-of-work analysis</li>
|
||||
<li>source code and security proof of our secure parameter setup</li>
|
||||
<li>securely generated parameters</li>
|
||||
</ul><p>Stay tuned for those publications.</p>
|
||||
</div>
|
||||
<div class="section" id="about-beta-1-release">
|
||||
<h2>About Beta 1 release</h2>
|
||||
<p>Today we've released Zcash Beta 1, aka <cite>v1.0.0-beta1</cite>. Building on the <a class="reference external" href="/new-alpha-release-solidifying-the-consensus-protocol/">previous alpha release</a> which finalized consensus changes (unless we discover critical flaws) this release adds the new high level <a class="reference external" href="https://github.com/zcash/zcash/blob/v1.0.0-beta1/doc/payment-api.md">RPC interface</a>. The <cite>v1.0.0-beta1</cite> release includes these major changes:</p>
|
||||
<ul class="simple"><li>Wallet support for the high-level interface, including detecting received notes, selecting notes for transfers, listing transactions, getting balances, and calculating block subsidies. See <a class="reference external" href="https://github.com/zcash/zcash/blob/v1.0.0-beta1/doc/payment-api.md">RPC interface</a>. [<a class="reference external" href="https://github.com/zcash/zcash/pull/1355">#1355</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1323">#1323</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1315">#1315</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1233">#1233</a>]</li>
|
||||
<li>We rolled back a "stable txid" feature intended to fix malleability issues, see <a class="reference external" href="/metamorphosis-of-malleable-transactions/">our post about the rollback</a>. [<a class="reference external" href="https://github.com/zcash/zcash/pull/1316">#1316</a>]</li>
|
||||
<li>We tweaked the difficulty adjustment algorithm. [<a class="reference external" href="https://github.com/zcash/zcash/pull/1338">#1338</a>]</li>
|
||||
<li>Several other security and other bug fixes and cleanups, full details on the <a class="reference external" href="https://github.com/zcash/zcash/milestone/28?closed=1">Beta 1 github milestone</a>.</li>
|
||||
</ul><p><strong>Caution:</strong> In the interest of getting user feedback we're releasing <cite>v1.0.0-beta1</cite> 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.</p>
|
||||
<p>Additionally, every release moving forward will contain a document with security warnings. For this release, see <a class="reference external" href="https://github.com/zcash/zcash/blob/v1.0.0-beta1/doc/security-warnings.md">security-warnings.md</a>. <strong>Important:</strong> Please also regularly check out website for security issues discovered after a release is deployed to users.</p>
|
||||
</div>
|
||||
<div class="section" id="stay-involved">
|
||||
<h2>Stay Involved</h2>
|
||||
<p>Try out the Beta series releases by following the <a class="reference external" href="https://github.com/zcash/zcash/wiki/Beta-Guide">Beta Guide</a>.</p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the github project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when Zcash <a class="reference external" href="/sprout-roadmap/">Sprout Series</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>. We tweet <a class="reference external" href="https://twitter.com/zcashco">@ZcashCo</a>.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>Please use the “language” button in the top right corner to toggle between languages.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>Please email <a class="reference external" href="mailto:press@z.cash">press@z.cash</a> if you have questions or would like to participate in future translations of Zcash content.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<div class="figure align-center">
|
||||
<img alt="Bridging Zcash and Ethereum" class="zecc-blog-standard-image" src="http://blog.z.cash/wp-content/uploads/2016/09/zec-eth.png"/><p class="caption">Bridging Zcash and Ethereum</p>
|
||||
</div>
|
||||
<p>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.</p>
|
||||
<p>One of the projects we're looking forward to working on is codenamed <cite>Project Alchemy</cite>. 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 <cite>Order</cite> that will allow decentralized order execution.</p>
|
||||
<p>Here’s the basic outline of how it would work: Sellers will be able to publish an Ethereum contract called an <cite>Order</cite>, 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.</p>
|
||||
<p>An implementation of a bridge for Bitcoin-to-Ether exchange already exists in <a class="reference external" href="https://github.com/ethereum/btcrelay">BTC Relay</a>, so we are planning to model an exchange for Zcash along these lines <a class="footnote-reference" href="#id2" id="id1">[1]</a>. 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 <a class="reference external" href="https://github.com/tjade273/eth-blake2">has already been written</a>. 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 <cite>Order</cite> logic. From there, we would need UI components to place, discover, and fulfill orders on the two blockchains.</p>
|
||||
<p>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.</p>
|
||||
<p>Please join us in discussing projects like this on our <a class="reference external" href="https://forum.z.cash/">Forum</a> or <a class="reference external" href="https://inviteme.z.cash/">Slack</a> channels (including <tt class="docutils literal">#alchemy</tt> for this project).</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>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.</td></tr></tbody></table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<div class="figure align-center">
|
||||
<img alt="Cartoon of pickaxe mining ZEC" class="zecc-blog-standard-image" src="http://blog.z.cash/wp-content/uploads/2016/09/mine-zec.png"/><p class="caption">Mining ZEC ;)</p>
|
||||
</div>
|
||||
<p>All coins are created equal. All coins should be equally accessible.</p>
|
||||
<p>On October 28, 2016, the <a class="reference external" href="/zcash-launch-and-roadmap/">launch of Zcash</a> 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.</p>
|
||||
<p>To achieve this, we need open source miners for anyone to use. <a class="reference external" href="https://leastauthority.com/">Least Authority</a>, 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.</p>
|
||||
<p>The Least Authority team will be operating the contest and more information will be posted next week on the official website for the contest: <a class="reference external" href="http://zcashminers.org">http://zcashminers.org</a> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="http://zcashminers.org/">Zcash Open Source Miner Contest</a>.</p>
|
||||
<p>Join in the mining conversations on the <a class="reference external" href="https://forum.z.cash/">Zcash Forum</a> or the <a class="reference external" href="https://inviteme.z.cash/">Zcash Slack</a> <tt class="docutils literal">#mining</tt> channel.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<a class="reference external" href="/helloworld/">Our mission</a> is to create open financial technology with zero-knowledge privacy, for everyone in the world to use. The first application of that technology is <em>Zcash</em>, a cryptocurrency and blockchain with privacy built in.
|
||||
<div id="continued-funding" class="section">
|
||||
<h2>Continued funding</h2>
|
||||
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 <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a>.
|
||||
|
||||
We are using the money to <a class="reference external" href="/september-2016-new-hire-post/">hire several awesome new people</a> for our team, to further invest in security assurance such as by hiring <a class="reference external" href="/auditing-zcash/">independent security auditors</a>, to fund the <a class="reference external" href="http://zcashminers.org/">Zcash Open Source Miner Contest</a>, and to lay plans for several more projects.
|
||||
|
||||
Stay tuned to this blog to hear more about all of these exciting developments!
|
||||
|
||||
</div>
|
||||
<div id="continued-transparency" class="section">
|
||||
<h2>Continued transparency</h2>
|
||||
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.
|
||||
<div id="pricing" class="section">
|
||||
<h3>Pricing</h3>
|
||||
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 <em>only</em> 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 <a class="reference external" href="/funding/">Funding, Incentives, and Governance</a> for why the Founders' Reward is on this four-year schedule.)
|
||||
</div>
|
||||
|
||||
<div id="the-distribution-of-zcash" class="section">
|
||||
<h3>The distribution of Zcash</h3>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center" style="width: 75%;"><img class="zecc-blog-inline-image" src="http://blog.z.cash/wp-content/uploads/2016/09/founders-reward-1-v3.png" alt="Zcash Distribution" /></div>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Mining-Guide">Zcash Mining Guide</a>.</p>
|
||||
</div>
|
||||
|
||||
<div id="the-distribution-of-the-founders-reward" class="section">
|
||||
<h3>The distribution of the Founders' Reward</h3>
|
||||
<p>10% of the Zcash monetary base goes to the “Founders' Reward”.</p>
|
||||
<div class="figure align-center" style="width: 75%;"><img class="zecc-blog-inline-image" src="http://blog.z.cash/wp-content/uploads/2016/09/founders-reward-2-v7.png" alt="Zcash Distribution, The Founders' Reward" /></div>
|
||||
|
||||
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.
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<div id="recap" class="section">
|
||||
<h2>Recap</h2>
|
||||
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.
|
||||
<table id="id1" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label">[1]</td>
|
||||
<td>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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
|
@ -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 <a href="https://en.wikipedia.org/wiki/Zero-knowledge_proof">zero-knowledge proof</a> 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 <em>destroyed</em>. Indeed, it will be essential for the integrity of the system that after the setup phase <em>nobody</em> 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" <a href="/snark-parameters/">here</a>, 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 <em>all</em> 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.
|
||||
<h2>What :math:`\mathsf{pubkey}` looks like</h2>
|
||||
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
|
||||
<blockquote>:math:`\mathsf{pubkey}=` :math:`(g,s\cdot g, s^2\cdot g,\ldots, s^d\cdot g)`</blockquote>
|
||||
Above, :math:`\mathbb{F}^*` denotes the set of all non-zero elements of :math:`\mathbb{F}.`
|
||||
<h2>How :math:`\mathsf{pubkey}` is generated</h2>
|
||||
We'll say a few words later about <em>why</em> :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:
|
||||
<ol>
|
||||
<li>Alice chooses a random :math:`a\in \mathbb{F}^*`, and sends :math:`M_1:= a\cdot g` to Bob.</li>
|
||||
<li>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.</li>
|
||||
</li>
|
||||
</ol>
|
||||
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
|
||||
|
||||
<ul>
|
||||
<li>Bob does not learn :math:`a` from the message :math:`M_1,` as we are assuming the discrete log is hard in :math:`G`. Same for Alice and :math:`b.` In particular, neither knows :math:`s` which is the product of :math:`a` and :math:`b`.</li>
|
||||
<li>For any fixed :math:`a\in \mathbb{F}^*`, :math:`a b` is a random element of :math:`\mathbb{F}^*` when :math:`b` is random. So even if Alice cheats in the sense that she didn't choose :math:`a` randomly as she was supposed to, e.g. she always chooses :math:`a=4`, :math:`s` will be random. Same is true for Bob cheating and not choosing a random :math:`b.`</li>
|
||||
</ul>
|
||||
|
||||
So as long as <em>one of them</em> 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)`:
|
||||
|
||||
<ul>
|
||||
<li>Alice chooses a random :math:`a\in \mathbb{F}^*,` and sends :math:`(A,B)` where :math:`A:= a\cdot g` and :math:`B := a^2\cdot g.`</li>
|
||||
<li>Bob chooses a random :math:`b\in \mathbb{F}^*,` and sends :math:`M=(b\cdot A, b^2\cdot B).`</li>
|
||||
</ul>
|
||||
|
||||
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 <em>is</em> 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 <em>bilinear pairing</em>. 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.
|
||||
<h2>How :math:`\mathsf{pubkey}` is used</h2>
|
||||
Recall that a <em>polynomial</em> :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 <em>evaluate</em> 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` <em>not known by the sender</em>. 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.
|
||||
|
||||
<h2>Disclaimer</h2>
|
||||
Please note, this post is a significantly simplified presentation of the underlying protocol. A detailed description can be found in the <a class="reference external" href="https://github.com/zcash/mpc/blob/master/whitepaper.pdf">whitepaper</a>.
|
||||
|
||||
<h2>References</h2>
|
||||
Our zkSNARKS use SCIPR Lab's <a class="reference external" href="https://github.com/scipr-lab/libsnark">implementation</a> of the <a class="reference external" href="https://eprint.iacr.org/2013/279.pdf">Pinnochio protocol</a>, which in turn is based on the <a class="reference external" href="https://eprint.iacr.org/2012/215.pdf">work</a> of Gennaro, Gentry, Parno and Raykova. Our protocol for parameter generation builds on a <a class="reference external" href="http://www.ieee-security.org/TC/SP2015/papers-archived/6949a287.pdf">previous work</a> of Ben-Sasson, Chiesa, Green, Tromer and Virza.
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>All coins are created equal. All coins should be equally accessible.</p>
|
||||
<p>Last week, <a class="reference external" href="/announcing-miner-contest/">we announced</a> our dedication to incentivize more open source miners to be available to the Zcash community, through the <a class="reference external" href="http://zcashminers.org/">Zcash Open Source Miner Challenge</a>. We believe that mining for ZEC is an important way to contribute to our growing and enthusiastic community.</p>
|
||||
<p>The Challenge is now live and we are accepting submissions until 27 October at 23:59 UTC. All details are now available on the <a class="reference external" href="http://zcashminers.org/">Zcash Open Source Miner Challenge</a> website; there you can also find <a class="reference external" href="http://zcashminers.org/apply">the form</a> 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.</p>
|
||||
<p>The technical guidelines for this challenge are:</p>
|
||||
<ul class="simple"><li>Submissions must be or must include an Equihash solver. Full Zcash miner submissions are also acceptable, provided that their Equihash implementation can easily be separated and meets the Submission Guidelines.</li>
|
||||
<li>The CPU code should be in plain C99, optionally with use of intrinsics, inline or standalone assembly, pthreads or/and OpenMP.</li>
|
||||
<li>The GPU code, if any, should be in OpenCL and/or CUDA (but we’ll favor OpenCL).</li>
|
||||
<li>The Equihash solver portion must build and run on Linux/x86_64, and in particular on recent Ubuntu and on CentOS 7 (systems where we test zcashd)</li>
|
||||
<li>At the minimum, the Equihash solver must support Zcash’s current Equihash parameters, which are n=200, k=9 (and preferably other parameters as well).</li>
|
||||
<li>The Submission must be a correct Equihash solver.</li>
|
||||
</ul><p>To learn more about the judging criteria and the timeline, please visit the <a class="reference external" href="http://zcashminers.org/">Challenge website</a>.</p>
|
||||
<p>You can also join in the mining conversations on the <a class="reference external" href="https://forum.z.cash/">Zcash Forum</a> or email <a class="reference external" href="mailto:challenge@zcashminers.org">challenge@zcashminers.org</a> with any specific questions.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we deployed the second beta release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <cite>1.0.0-beta2</cite>, to the testnet. This is the second release of the Zcash Beta Series. The new release includes the following changes <a class="footnote-reference" href="#id2" id="id1">[1]</a>:</p>
|
||||
<ol class="arabic simple"><li>We have changed the address prefixes. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1477">#1477</a>)</li>
|
||||
<li>Encrypting your wallet with a passphrase now also encrypts the spending key for zaddrs. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1372">#1372</a>)</li>
|
||||
<li>Founders’ Reward addresses will now rotate monthly. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1398">#1398</a>)</li>
|
||||
<li>We have re-enabled disabled compiler warnings and updated all dependencies, including Boost and OpenSSL. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1429">#1429</a>)</li>
|
||||
<li>We have merged in upstream patches to mitigate the risk of DoS attacks. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1411">#1411</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1407">#1407</a>)</li>
|
||||
<li>We have deployed a dnsseed to improve launching and connecting to the network. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1443">#1443</a>)</li>
|
||||
<li>The RPC call getbalance now returns a correct balance for UTXOs. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1427">#1427</a>)</li>
|
||||
<li>High-priority alerts now put the RPC into safe mode. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1374">#1374</a>)</li>
|
||||
<li>We have updated the public parameters. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1476">#1476</a>)</li>
|
||||
</ol><p>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 <cite>-reindex</cite> flag (Example: <cite>./src/zcashd -reindex</cite>).</p>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Beta-Guide">Beta Guide</a>.</p>
|
||||
<p>Additionally, you can now reach our main test network node through a Tor hidden service at <cite>zctestseie6wxgio.onion</cite>.</p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/milestone/37">1.0.0-beta2</a> release github milestone.</td></tr></tbody></table>
|
||||
|
|
@ -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 <a class="reference external" href="/announcing-beta-series/">Zcash cryptocurrency launch is approaching</a> and we're making progress on <a class="reference external" href="/helloworld/">our mission</a> to create the first open financial system with zero-knowledge privacy.
|
||||
|
||||
When we say <cite>open</cite>, we mean anyone in the world can use it.
|
||||
|
||||
So… <em>should</em> they?
|
||||
|
||||
In order to decide if they <em>should</em> 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.
|
||||
<div id="how-do-cryptocurrency-communities-evolve" class="section">
|
||||
<h2>How do cryptocurrency communities evolve?</h2>
|
||||
Like all cryptocurrencies so far, Zcash is a <em>consensual</em> 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 <em>community</em> 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 <em>developer-supported</em> 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 <a class="reference external" href="/funding/">¹</a>, <a class="reference external" href="/continued-funding-and-transparency/">²</a> is important in the long run. It provides both the incentives and the resources for developer support.
|
||||
|
||||
</div>
|
||||
<div id="what-happens-when-communities-grow" class="section">
|
||||
<h2>What happens when communities grow?</h2>
|
||||
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.)
|
||||
|
||||
</div>
|
||||
<div id="summary" class="section">
|
||||
<h2>Summary</h2>
|
||||
Zcash is launching soon as an open financial system with zero-knowledge privacy. It is a <em>consensual</em>, <em>community-based</em>, and <em>developer-supported</em> 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.
|
||||
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<div class="section" id="slow-start-and-zec-scarcity">
|
||||
<h2>Slow-start and ZEC scarcity</h2>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center" style="width: 85%">
|
||||
<img alt="ZEC distribution rate for first 30,000 blocks" src="http://blog.z.cash/wp-content/uploads/2016/11/slow-start-rate-30k.png"/><p class="caption">ZEC distribution rate for first 30,000 blocks</p>
|
||||
</div>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center" style="width: 75%">
|
||||
<img alt="Total ZEC distributed for first 30,000 blocks" src="http://blog.z.cash/wp-content/uploads/2016/10/slow-start-total-30k.png"/><p class="caption">Total ZEC distributed for first 30,000 blocks</p>
|
||||
</div>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center" style="width: 75%">
|
||||
<img alt="Total ZEC distributed for first 190,000 blocks" src="http://blog.z.cash/wp-content/uploads/2016/10/slow-start-total-190k.png"/><p class="caption">Total ZEC distributed for first 190,000 blocks</p>
|
||||
</div>
|
||||
<p>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!</p>
|
||||
</div>
|
||||
<div class="section" id="small-miners-and-early-adoption">
|
||||
<h2>“Small” miners and early adoption</h2>
|
||||
<p>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 <a class="reference external" href="/why-equihash/">Equihash</a> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>As Mike Perry of Tor Project <a class="reference external" href="https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise">wrote back in 2013</a>, 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 <em>“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.”</em></p>
|
||||
<p>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.</p>
|
||||
<p>We're keen on presenting verifiably secure and trustworthy software to the world, as demonstrated by the <a class="reference external" href="/auditing-zcash/">several audits</a> we've commissioned. So for our version 1.0.0 release candidates, we have started following a deterministic build process, courtesy of Gitian.</p>
|
||||
<p><a class="reference external" href="https://gitian.org/">Gitian</a> is a method of secure software distribution which allows multiple developers to create identical binaries. It was originally developed by <a class="reference external" href="https://bitcoin.org/en/">Bitcoin Core</a>, and was subsequently adapted for use by the <a class="reference external" href="https://www.torproject.org/">Tor Project</a>. 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.</p>
|
||||
|
||||
<h2>How it works</h2>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/gitian.sigs">published on GitHub</a> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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:</p>
|
||||
<dl class="docutils"><dt>::</dt>
|
||||
<dd>- 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</dd>
|
||||
</dl><p>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:</p>
|
||||
<dl class="docutils"><dt>::</dt>
|
||||
<dd>$ 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
|
||||
│ │ ╵
|
||||
│ ╵</dd>
|
||||
</dl><p>We quickly traced it to <a class="reference external" href="https://github.com/scipr-lab/libsnark/blob/master/src/common/profiling.cpp#L346-L351">this function</a>, which prints the date and time of compilation, and developed a <a class="reference external" href="https://github.com/zcash/libsnark/pull/7">fix</a>.</p>
|
||||
<p>We think that having deterministic builds is an exciting milestone for Zcash, and encourage other open-source projects to follow suit.</p>
|
||||
|
||||
<h2>Technical details</h2>
|
||||
<p>The <a class="reference external" href="https://github.com/zcash/zcash-gitian">Zcash deterministic build environment</a>, which runs Debian 8, is a virtual machine created with <a class="reference external" href="https://www.vagrantup.com/">Vagrant</a>, using <a class="reference external" href="https://www.virtualbox.org/">VirtualBox</a> for virtualization. It runs <a class="reference external" href="https://github.com/devrandom/gitian-builder">gitian-builder</a> and Linux containers (LXC) as guests.</p>
|
||||
<p><a class="reference external" href="https://docs.ansible.com/ansible/index.html">Ansible</a>, 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.</p>
|
||||
<p>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 <a class="reference external" href="https://inviteme.z.cash/">community Slack</a> #zcash-dev channel.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we deployed the third beta release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <cite>1.0.0-rc1</cite>, to the testnet. This is the third release of the Zcash Beta Series. The new release includes the following changes <a class="footnote-reference" href="#id2" id="id1">[1]</a>:</p>
|
||||
<ol class="arabic simple"><li>We added a script to create a Zcash Debian package. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1448">#1448</a>)</li>
|
||||
<li>We have published the first release of our <a class="reference external" href="/deterministic-builds/">Gitian-based deterministic build environment</a> and updated libsnark to support it. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1521">#1521</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1543">#1543</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1541">#1541</a>)</li>
|
||||
<li>We have renamed the client identifier from “Satoshi” to “Magic Bean”. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1481">#1481</a>)</li>
|
||||
<li>We have made the 100kb transaction size limit a consensus rule, rather than a standard rule. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1501">#1501</a>)</li>
|
||||
<li>Fixed UTXO selection and improved error reporting surrounding the consensus rule that coinbase UTXOs must be sent to a zaddr. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1431">#1431</a>)</li>
|
||||
<li>Added JoinSplits to the JSON output of the RPC call gettransaction. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1493">#1493</a>)</li>
|
||||
<li>The ‘account’ parameter in RPC calls is now deprecated. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1490">#1490</a>)</li>
|
||||
<li>Debug log messages for z_* RPC calls can be viewed with option -debug=”zrpc”. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1523">#1523</a>)</li>
|
||||
<li>Fixed a bug in encrypted wallets by caching nullifiers. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1520">#1520</a>)</li>
|
||||
<li>Added fixes to address a bug with note witnesses in the wallet. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1526">#1526</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1547">#1547</a>)</li>
|
||||
<li>Fixed an issue where some tests where outputting data to local directory. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1506">#1506</a>)</li>
|
||||
<li>We have updated documentation related to Tor, the release process, security risks and wallet reindexing. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1483">#1483</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1511">#1511</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1499">#1499</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1492">#1492</a>)</li>
|
||||
</ol><p>Note that this release does not reset the beta testnet and continues to uses the beta 2 proving and verify keys. <strong>NOTE:</strong> <cite>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.</cite> <tt class="docutils literal">./src/zcashd <span class="pre">-reindex</span></tt> <cite>) to resolve this issue.</cite></p>
|
||||
<p>To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.</p>
|
||||
<table class="docutils footnote" frame="void" id="id2" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>For more specific detail, view our <a class="reference external" href="https://github.com/zcash/zcash/milestone/39">1.0.0-rc1</a> release github milestone.</td></tr></tbody></table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>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).</p>
|
||||
<p>These submissions, along with links to the code hosted on GitHub, are on the <a class="reference external" href="https://zcashminers.org/submissions">Challenge website</a>. 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.</p>
|
||||
<p>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).</p>
|
||||
<p>If you are interested in participating in the Challenge, please look at <a class="reference external" href="https://zcashminers.org/timeline">the timeline</a>, read <a class="reference external" href="https://zcashminers.org/rules">the rules</a> and <a class="reference external" href="https://zcashminers.org/judging">the judging criteria</a>, before <a class="reference external" href="https://zcashminers.org/apply">applying</a>. 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.</p>
|
||||
<p>You can also participate in the discussions on <a class="reference external" href="https://forum.z.cash/">the Zcash forum</a>.</p>
|
||||
|
|
@ -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 <a class="reference external" href="/announcing-beta-series/">on track to launch</a> the Zcash currency on October 28th. Recently, we shared our vision of Zcash as a <a class="reference external" href="/consensual-currency/">consensual currency</a>: 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.
|
||||
<div id="upgrade-strategy" class="section">
|
||||
<h2>Upgrade Strategy</h2>
|
||||
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 <cite>hard forking upgrade</cite> although we prefer to avoid the term <cite>fork</cite> because it's both highly-conflated and often repeated in highly contentious debates. The term <cite>fork</cite> itself can mean at least any of the following:
|
||||
<ol class="arabic simple">
|
||||
<li>diverging software revisions,</li>
|
||||
<li>persistently diverging blockchain histories,</li>
|
||||
<li>diverging communities.</li>
|
||||
</ol>
|
||||
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. <a class="reference external" href="https://ethcore.io/parity.html">parity</a> after the divergence of <cite>ETH</cite> and <cite>ETC</cite>).
|
||||
|
||||
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 <em>still</em> provide benefits that outweight the drawbacks (e.g. confusion caused by diverging blockchains). <em>If</em> 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 <em>even if the blockchain diverges</em>, so if we forsee a blockchain divergence, one of our focuses will be in collaborating between the subcommunities participating in each side.
|
||||
|
||||
</div>
|
||||
<div id="potentially-surprising-upgrades" class="section">
|
||||
<h2>Potentially Surprising Upgrades</h2>
|
||||
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.
|
||||
<div id="mining" class="section">
|
||||
<h3>Mining</h3>
|
||||
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.
|
||||
|
||||
</div>
|
||||
<div id="founders-reward" class="section">
|
||||
<h3>Founders' Reward</h3>
|
||||
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.
|
||||
|
||||
</div>
|
||||
<div id="counterfeit-detection" class="section">
|
||||
<h3>Counterfeit Detection</h3>
|
||||
Any currency with strong privacy carries a risk of undetected counterfeiting <a id="id1" class="footnote-reference" href="/zcash-evolution#id3">[1]</a>. 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).
|
||||
|
||||
</div>
|
||||
<div id="removing-technical-debt" class="section">
|
||||
<h3>Removing Technical Debt</h3>
|
||||
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 <a id="id2" class="footnote-reference" href="/zcash-evolution#id4">[2]</a>.
|
||||
|
||||
</div>
|
||||
<div id="and-more" class="section">
|
||||
<h3>…and More</h3>
|
||||
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 <em>coolest</em> potential upgrades. ;-)
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<div id="future-evolution" class="section">
|
||||
<h2>Future Evolution</h2>
|
||||
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 <a class="reference external" href="/consensual-currency/">consensual currency</a> post how we intend to propose changes that anyone is free to adopt, but we haven't yet clarified <em>how</em> 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
|
||||
|
||||
<strong>Footnotes:</strong>
|
||||
<table id="id3" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="/zcash-evolution#id1">[1]</a></td>
|
||||
<td>Different privacy systems have different <cite>attack surfaces</cite> 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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="id4" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="/zcash-evolution#id2">[2]</a></td>
|
||||
<td>The Bitcoin community maintains <a class="reference external" href="https://en.bitcoin.it/wiki/Hardfork_Wishlist">a wishlist</a> 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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>This is the second post in a two-part series about what users can expect from the launch of Zcash Sprout. The <a class="reference external" href="/slow-start-and-mining-ecosystem/">first post</a> 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.</p>
|
||||
<div class="section" id="using-linux-natively-or-through-a-virtual-environment">
|
||||
<h2>Using Linux natively or through a virtual environment</h2>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zcash/wiki/Beta-Guide">Beta release</a>). 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 <a class="reference external" href="https://www.virtualbox.org/">VirtualBox</a> - and together with community support from the <a class="reference external" href="https://forum.z.cash/">Zcash community</a> and <a class="reference external" href="https://forums.virtualbox.org/">VirtualBox forums</a>, there’s plenty of opportunity to receive guidance along the way.</p>
|
||||
</div>
|
||||
<div class="section" id="blockchain-and-zero-knowledge-proof-generation-hardware-requirements">
|
||||
<h2>Blockchain and zero-knowledge proof generation hardware requirements</h2>
|
||||
<p>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.</p>
|
||||
<p>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).</p>
|
||||
<p>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).</p>
|
||||
<p>The current state of zero-knowledge proof generation represents an initial implementation. Optimization is an <a class="reference external" href="https://github.com/zcash/zcash/issues/750">open task</a> 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.</p>
|
||||
<p>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 <a class="reference external" href="https://forum.z.cash/">Zcash community forum</a> to discuss your findings, ideas, and work with others on support needs. Your active participation only makes this network stronger.</p>
|
||||
</div>
|
||||
|
|
@ -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 <a class="reference external" href="https://www.wired.com/2016/10/internet-outage-ddos-dns-dyn/">widespread DNS disruptions</a> on Friday, today we deployed the fourth beta release of the <a class="reference external" href="https://github.com/zcash">Zcash</a> reference implementation, <a class="reference external" href="https://github.com/zcash/zcash/milestone/42?closed=1">1.0.0-rc2</a>, to the testnet.
|
||||
|
||||
The new release includes the following user-visible changes:
|
||||
<ol class="arabic simple">
|
||||
<li>Wallet encryption has been disabled. The reasons for disabling this feature for the time being are explained in our <a class="reference external" href="https://github.com/zcash/zcash/blob/v1.0.0-rc2/doc/security-warnings.md#wallet-encryption">security warnings document</a>. We recommend using <a class="reference external" href="https://theintercept.com/2015/04/27/encrypting-laptop-like-mean/">full disk encryption</a> for now instead. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1552">#1552</a>)</li>
|
||||
<li>We have included mitigations for security issues found by the NCC Group and Coinspect audits. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1459">#1459</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1464">#1464</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1504">#1504</a>)</li>
|
||||
<li>We have merged some changes from Bitcoin to help address potential denial-of-service vulnerabilities. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1588">#1588</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1589">#1589</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1591">#1591</a>)</li>
|
||||
<li>A bug that could cause assertion failures when restarting after a crash has been fixed. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1378">#1378</a>)</li>
|
||||
<li>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 <tt class="docutils literal">equihashsolver=tromp</tt> to <tt class="docutils literal">zcash.conf</tt>. Thanks go to John Tromp, and to @sarath-hotspot for providing the impetus for this improvement. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1570">#1570</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1578">#1578</a>)</li>
|
||||
<li>Running the node now displays a screen showing node metrics (and some pretty ASCII art ☺). (<a class="reference external" href="https://github.com/zcash/zcash/pull/1375">#1375</a>)</li>
|
||||
<li>The consensus rules have been tightened to reject block and transaction versions that were previously used by Bitcoin but are not valid for Zcash. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1556">#1556</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1600">#1600</a>)</li>
|
||||
<li>The testnet now enforces the same rules on standard transactions as will be enforced on mainnet. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1582">#1582</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1557">#1557</a>)</li>
|
||||
<li>We have made changes to the <tt class="docutils literal">getblocktemplate</tt> RPC call to support mining pools. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1424">#1424</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1602">#1602</a>)</li>
|
||||
<li>Improved support for <a class="reference external" href="/deterministic-builds/">deterministic builds</a>. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1549">#1549</a>)</li>
|
||||
<li>Build fixes for the musl C library used by Alpine Linux. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1558">#1558</a>)</li>
|
||||
<li>Documentation improvements. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1500">#1500</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1575">#1575</a>)</li>
|
||||
</ol>
|
||||
For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/42?closed=1">1.0.0-rc2</a> 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 <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="https://zcashminers.org/submissions">Challenge website</a>. Anyone with a miner not participating in the Challenge, but still interested in having it listed should send information to <a class="reference external" href="mailto:challenge@zcashminers.org">challenge@zcashminers.org</a>.</p>
|
||||
<p>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.</p>
|
||||
<p>If you are interested in participating in the Challenge, please look at <a class="reference external" href="https://zcashminers.org/timeline">the timeline</a>, read <a class="reference external" href="https://zcashminers.org/rules">the rules</a> and <a class="reference external" href="https://zcashminers.org/judging">the judging criteria</a>, before <a class="reference external" href="https://zcashminers.org/apply">applying</a>. 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.</p>
|
||||
<p>You can also participate in the discussions on the <a class="reference external" href="https://inviteme.z.cash/">Zcash Community Slack</a> or <a class="reference external" href="https://forum.z.cash/">the Zcash forum</a>.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Update: <a class="reference external" href="https://z.cash/technology/paramgen.html">Read our full summary</a> of what took place in the Zcash Parameter Generation Ceremony.</p>
|
||||
<div class="section" id="the-toxic-waste-and-other-ways-to-counterfeit-zcash">
|
||||
<h2>The Toxic Waste, and Other Ways To Counterfeit Zcash</h2>
|
||||
<p>As we've mentioned in a <a class="reference external" href="/snark-parameters/">previous blog post</a>, the private transactions in Zcash “Sprout” 1.0 rely on <em>SNARK public parameters</em> 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.</p>
|
||||
<p>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 <em>only</em> harm they could do with it — they could not violate anyone else's privacy nor steal other people's Zcash.</p>
|
||||
<p>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 <em>all</em> 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.</p>
|
||||
<p>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 <a class="reference external" href="https://en.bitcoin.it/wiki/Value_overflow_incident">counterfeit 184 billion BTC</a>. Zcash could turn out to have a similar flaw, totally unrelated to the toxic waste private key.</p>
|
||||
<p>Bitcoin was able to detect this problem because it publicly exposes all transactions. Zcash won't have that ability. In fact, <em>any</em> system which shields the amounts of transactions risks losing the ability to detect such counterfeiting.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="the-design-of-a-secure-ceremony">
|
||||
<h2>The Design of a Secure Ceremony</h2>
|
||||
<p>In order to reduce the risk of an attacker acquiring the toxic waste, we developed a <a class="reference external" href="/generating-zcash-parameters/">Multi-Party Computation</a> (MPC) protocol in which a set of multiple participants in separate geographic locations cooperatively construct the public key. Each participant separately generates one <em>shard</em> 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.</p>
|
||||
<p>With the MPC protocol, as long as <em>at least one</em> 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 <em>every</em> participant in the protocol were dishonest or compromised.</p>
|
||||
<p>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”.</p>
|
||||
<p>The identities of three of the Witnesses were revealed to all of the participants and observers at the beginning of the Ceremony: Andrew Miller (<a class="reference external" href="http://soc1024.ece.illinois.edu/">computer scientist</a> and <a class="reference external" href="https://z.cash/team.html#advisors">Zcash technical advisor</a>), <a class="reference external" href="http://www.petervv.com/">Peter Van Valkenburgh</a>, and yours truly.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>On October 27, “Fabrice Renault” <a class="reference external" href="https://twitter.com/petertoddbtc/status/791495928108625921">revealed himself</a> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>The Ceremony design we chose has three core defenses which work together: <em>Multi-Party Computation</em>, <em>air gaps</em>, and <em>evidence trails</em>.</p>
|
||||
<div class="section" id="id1">
|
||||
<h3>Multi-Party Computation</h3>
|
||||
<p>The <em>Multi-Party Computation</em> effect is that it only takes <em>one</em> 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.</p>
|
||||
</div>
|
||||
<div class="section" id="air-gaps">
|
||||
<h3>Air Gaps</h3>
|
||||
<p>Each participant's private key shard was used solely on an air-gapped machine. <em>Air-gapping</em> means that the computer is physically disconnected from all networks.</p>
|
||||
<p>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.</p>
|
||||
<p>These air-gapped machines were called the “Compute Nodes”.</p>
|
||||
<p>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.</p>
|
||||
<img alt="an air-gapped Compute Node being set up" class="zecc-blog-inline-image" src="http://blog.z.cash/wp-content/uploads/2016/10/compute-node.jpg"/></div>
|
||||
<div class="section" id="evidence-trails">
|
||||
<h3>Evidence Trails</h3>
|
||||
<p>We needed to communicate messages back and forth between the Compute Nodes in order to perform the Multi-Party Computation protocol.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>A major advantage of using append-only optical discs is that they provide an indelible <em>evidence trail</em> 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, <em>did</em> 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.</p>
|
||||
<p>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.</p>
|
||||
<img alt="ceremony design" class="zecc-blog-inline-image" src="http://blog.z.cash/wp-content/uploads/2016/10/paramgen_v3.png"/></div>
|
||||
</div>
|
||||
<div class="section" id="additional-defenses">
|
||||
<h2>Additional Defenses</h2>
|
||||
<p>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 <a class="reference external" href="https://twitter.com/zooko/status/789894254021660673">to Twitter</a> and <a class="reference external" href="https://web.archive.org/web/20161022182123/https:/twitter.com/zooko/status/789894254021660673">the Internet Archive</a>, 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.</p>
|
||||
</div>
|
||||
<div class="section" id="future-work">
|
||||
<h2>Future Work</h2>
|
||||
<p>Our task is not yet done. Here are two important steps to take next:</p>
|
||||
<div class="section" id="evidence-archiving-and-independent-inspection">
|
||||
<h3>Evidence Archiving and Independent Inspection</h3>
|
||||
<p>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.</p>
|
||||
<p>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!</p>
|
||||
<p>We have already begun this process by publishing <a class="reference external" href="https://github.com/zcash/mpc/tree/c2012297b01a72c63505053b2c79ad33159141f5">the source code</a> 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.</p>
|
||||
</div>
|
||||
<div class="section" id="a-proposed-counterfeiting-detection-feature-for-zcash">
|
||||
<h3>A Proposed Counterfeiting-Detection Feature for Zcash</h3>
|
||||
<p>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 <em>not</em> 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.</p>
|
||||
<p>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 <em>actually</em> 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.</p>
|
||||
<p>Therefore, I intend to advocate for a Zcash protocol upgrade in the future — after the launch of Zcash 1.0 “Sprout” — which adds a <em>counterfeiting-detection</em> 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.</p>
|
||||
<p>I will write more on this in a future blog post.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="the-bottom-line">
|
||||
<h2>The Bottom Line</h2>
|
||||
<p>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 <em>others</em> 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 <em>detection</em> in addition to the current layer of <em>prevention</em>.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<h3 class="author">Maureen Walsh and Nathan Wilcox</h3>
|
||||
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.
|
||||
<div id="security-recap" class="section">
|
||||
<h2>Security Recap</h2>
|
||||
To give context, in April <a class="reference external" href="/fixing-zcash-vulns/">we highlighted a few vulnerabilities</a> in our code that our team found and fixed. In August, <a class="reference external" href="/auditing-zcash/">we announced our work with two top security auditing teams</a>, and we're presenting those security audit results in this post <a id="id1" class="footnote-reference" href="/audit-results#id2">[1]</a>.
|
||||
|
||||
We maintain a <a class="reference external" href="https://z.cash/support/security.html">security page</a> on this site with up-to-date security information about Zcash. We also maintain a <a class="reference external" href="https://github.com/zcash/zcash/blob/master/doc/security-warnings.md">security warnings</a> document for each release.
|
||||
|
||||
</div>
|
||||
<div id="security-audits" class="section">
|
||||
<h2>Security Audits</h2>
|
||||
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 <cite>Bitcoin Core</cite> developers to ensure any findings relating to our codebase (which is derived from <a class="reference external" href="https://github.com/bitcoin/bitcoin/releases/tag/v0.11.2">Bitcoin Core v0.11.2</a>) does not present any substantial risk to Bitcoin users. We also sent private notifications to developers of <a class="reference external" href="https://www.bitcoinunlimited.info/">Bitcoin Unlimited</a>, <a class="reference external" href="https://bitcoinxt.software/">Bitcoin XT</a>, and <a class="reference external" href="https://bitcoinclassic.com/">Bitcoin Classic</a>. We did not contact developers of any other projects derived from the <cite>Bitcoin Core</cite> 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:
|
||||
<div id="ncc-group" class="section">
|
||||
<h3>NCC Group</h3>
|
||||
<div class="zecc-paragraph-small-margin docutils container">
|
||||
|
||||
<strong>Report URL:</strong> <a class="reference external" href="https://www.nccgroup.trust/us/our-research/zcash-cryptography-and-code-review/?research=Public+Reports">https://www.nccgroup.trust/us/our-research/zcash-cryptography-and-code-review/?research=Public+Reports</a>
|
||||
|
||||
<strong>Zcash Issue Tracking:</strong> <a class="reference external" href="https://github.com/zcash/zcash/issues?utf8=%E2%9C%93&q=label%3A%22NCC%20finding%22">NCC findings</a>
|
||||
|
||||
<strong>Their Summary:</strong>
|
||||
<blockquote>“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).”</blockquote>
|
||||
</div>
|
||||
</div>
|
||||
<div id="coinspect" class="section">
|
||||
<h3>Coinspect</h3>
|
||||
<div class="zecc-paragraph-small-margin docutils container">
|
||||
|
||||
<strong>Report URL:</strong> <a class="reference external" href="https://coinspect.com/doc/CoinspectReportZcash2016.pdf">https://coinspect.com/doc/CoinspectReportZcash2016.pdf</a>
|
||||
|
||||
<strong>Their Announcement:</strong> <a class="reference external" href="https://coinspect.com/zcash-security-audit-results">https://coinspect.com/zcash-security-audit-results</a>
|
||||
|
||||
<strong>Zcash Issue Tracking:</strong> <a class="reference external" href="https://github.com/zcash/zcash/issues?utf8=%E2%9C%93&q=label%3A%22Coinspect%20Finding%22">Coinspect findings</a>
|
||||
|
||||
<strong>Their Summary:</strong>
|
||||
<blockquote>“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.”</blockquote>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div id="conclusion" class="section">
|
||||
<h2>Conclusion</h2>
|
||||
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 <a class="reference external" href="https://inviteme.z.cash/">our Slack</a> and <a class="reference external" href="https://forum.z.cash/">Forum</a> conversations.
|
||||
<table id="id2" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="/audit-results#id1">[1]</a></td>
|
||||
<td>Our blog post also <a class="reference external" href="/auditing-zcash#auditors-and-consultants">described our work with Solar Designer</a> 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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
|
|
@ -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 <a class="reference external" href="/the-design-of-the-ceremony/">Parameter Generation Ceremony</a>. The <a class="reference external" href="https://github.com/zcash/mpc">transcripts and software used for the ceremony</a> have been published, and we'll be making another post with more information on that very soon.
|
||||
|
||||
We encourage everyone to test this latest <tt class="docutils literal"><span class="pre">1.0.0-rc4</span></tt> release by following the <a class="reference external" href="https://github.com/zcash/zcash/wiki/Public-Beta-Guide">Beta Guide</a>. 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.
|
||||
<div id="two-releases" class="section">
|
||||
<h2>Two Releases</h2>
|
||||
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 <tt class="docutils literal"><span class="pre">1.0.0-rc2</span></tt> directly to <a class="reference external" href="https://github.com/zcash/zcash/milestone/44?closed=1">1.0.0-rc4</a>.
|
||||
<div id="rc3-bug-fixes-and-dependency-upgrades" class="section">
|
||||
<h3>1.0.0-rc3 - bug fixes and dependency upgrades</h3>
|
||||
The intermediate <a class="reference external" href="https://github.com/zcash/zcash/milestone/43?closed=1">1.0.0-rc3</a> release included only bug fixes, and updates of libraries that Zcash depends on:
|
||||
<ol class="arabic simple">
|
||||
<li>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. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1612">#1612</a>)</li>
|
||||
<li>The version of Berkeley DB has been updated to 6.2.23. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1637">#1637</a>)</li>
|
||||
<li>The tinyformat library was updated in order to mitigate a potential buffer overflow vulnerability. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1640">#1640</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1349">#1349</a>)</li>
|
||||
<li>A fix for a minor potential race condition was backported from Bitcoin. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1634">#1634</a>)</li>
|
||||
<li>A couple of portability problems with the <cite>fetch-params.sh</cite> script and the Debian packages have been fixed. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1053">#1053</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1537">#1537</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1613">#1613</a>)</li>
|
||||
<li>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. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1616">#1616</a>)</li>
|
||||
<li>Updates to documentation and examples. (<a class="reference external" href="https://github.com/zcash/zcash/pull/826">#826</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/965">#965</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1152">#1152</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1154">#1154</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1643">#1643</a>)</li>
|
||||
<li>Network bootstrapping for mainnet. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1369">#1369</a>)</li>
|
||||
</ol>
|
||||
</div>
|
||||
<div id="rc4-zksnark-params-and-founders-reward-addresses" class="section">
|
||||
<h3>1.0.0-rc4 - zkSNARK Params and Founders' Reward Addresses</h3>
|
||||
The <a class="reference external" href="https://github.com/zcash/zcash/milestone/44?closed=1">1.0.0-rc4</a> release, which is the one now deployed on the testnet, made some final updates in preparation for the Zcash launch:
|
||||
<ol class="arabic simple">
|
||||
<li>The zk-SNARK parameters have been updated to the ones created by the ceremony performed last weekend.</li>
|
||||
<li>The <a class="reference external" href="/continued-funding-and-transparency/">Founders' Reward</a> addresses for mainnet have also been updated.</li>
|
||||
</ol>
|
||||
For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/43?closed=1">1.0.0-rc3</a> and <a class="reference external" href="https://github.com/zcash/zcash/milestone/44?closed=1">1.0.0-rc4</a> release github milestones.
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<div id="imminent-launch" class="section">
|
||||
<h2>Imminent Launch</h2>
|
||||
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 <a class="reference external" href="https://twitter.com/ZcashCo">Twitter feed</a>!
|
||||
|
||||
To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>. To get an email announcement when <a class="reference external" href="/sprout-roadmap/">Zcash Sprout</a> is ready, put your email address <a class="reference external" href="https://z.cash/#launch-notification">in here</a>.
|
||||
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p><a class="reference external" href="https://z.cash">Our homepage</a> 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.</p>
|
||||
<p>Our blog hosts a number of articles that Zcash users should read, including <a class="reference external" href="/slow-start-and-mining-ecosystem/">User Expectation of our Slow Start Mining</a>, the <a class="reference external" href="/continued-funding-and-transparency/">Distribution of Zcash</a>, and how we think the <a class="reference external" href="/zcash-evolution/">Zcash Evolution</a> might happen. This technology is still an experiment and it is not yet shown to be safe and stable.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<div class="section" id="why-we-ve-come-together">
|
||||
<h2>Why We've Come Together</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>This technology can do for cooperation what the Internet did for communication two decades ago.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p><strong>Update: 2017-09-25</strong> - 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 <a class="reference external" href="https://www.zcashcommunity.com/markets/">markets</a> and <a class="reference external" href="https://www.zcashcommunity.com/wallets/">wallets</a> for up-to-date community-curated lists.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>What follows is a list of some of the wallets and exchange that we currently know about.</p>
|
||||
<p>A word of caution: there have already been multiple scams and fraudulent projects, so we suggest researching any third-party application well before using.</p>
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="https://forum.z.cash/users/vaklinov/activity">@vaklinov</a> has begun hosting a list of wallets here: <a class="reference external" href="https://zcashblog.wordpress.com/zcash-gui-wallets/">https://zcashblog.wordpress.com/zcash-gui-wallets/</a>.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<div class="section" id="id1">
|
||||
<h2>WALLETS</h2>
|
||||
<div class="line-block">
|
||||
<div class="line"><strong>Cockpit UI Wallet</strong> - <a class="reference external" href="https://github.com/hellcatz/zcash-cli-cockpit">https://github.com/hellcatz/zcash-cli-cockpit</a></div>
|
||||
<div class="line">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 <a class="reference external" href="https://github.com/hellcatz/zcash-cli-cockpit">GitHub</a>.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Desktop GUI Wallet</strong> - <a class="reference external" href="https://github.com/vaklinov/zcash-swing-wallet-ui">https://github.com/vaklinov/zcash-swing-wallet-ui</a></div>
|
||||
<div class="line">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 <a class="reference external" href="https://github.com/vaklinov/zcash-swing-wallet-ui">on GitHub</a>. Users who are less experienced with working on a command line, may instead use this quite user-friendly <a class="reference external" href="https://www.cryptocompare.com/wallets/guides/how-to-install-the-zcash-gui-wallet">installation guide</a> and <a class="reference external" href="https://www.cryptocompare.com/wallets/guides/how-to-use-the-zcash-gui-wallet">usage guide</a>.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Jaxx</strong> - <a class="reference external" href="https://jaxx.io/">https://jaxx.io/</a></div>
|
||||
<div class="line">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.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>TREZOR</strong> - <a class="reference external" href="http://bitcointrezor.com/">http://bitcointrezor.com/</a></div>
|
||||
<div class="line">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.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Waterhole GUI mobile wallet</strong> - <a class="reference external" href="https://waterhole.io/">https://waterhole.io/</a></div>
|
||||
<div class="line">From the waterhole.io site, “This is a trading platform and a wallet provider for multiple crypto-currencies. It already supports ZCash.”</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="section" id="exchanges">
|
||||
<h2>EXCHANGES</h2>
|
||||
<div class="line-block">
|
||||
<div class="line"><strong>Bitfinex</strong> - <a class="reference external" href="https://www.bitfinex.com/">https://www.bitfinex.com/</a></div>
|
||||
<div class="line">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.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Bittrex</strong> - <a class="reference external" href="https://bittrex.com/">https://bittrex.com/</a></div>
|
||||
<div class="line">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.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Bitnow</strong> - <a class="reference external" href="https://bitnow.co.nz/">https://bitnow.co.nz/</a></div>
|
||||
<div class="line">New Zealand</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Bitsquare</strong> - <a class="reference external" href="https://bitsquare.io/bitsquare.pdf">https://bitsquare.io/bitsquare.pdf</a></div>
|
||||
<div class="line">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.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Changelly</strong> - <a class="reference external" href="https://changelly.com/">https://changelly.com/</a></div>
|
||||
<div class="line">From a Changelly representative, “Changelly is an instant cryptocurrency exchange.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>HitBTC</strong> - <a class="reference external" href="https://hitbtc.com/">https://hitbtc.com/</a></div>
|
||||
<div class="line">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.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Kraken</strong> - <a class="reference external" href="https://www.kraken.com/">https://www.kraken.com/</a></div>
|
||||
<div class="line">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.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>Poloniex</strong> - <a class="reference external" href="https://poloniex.com/">https://poloniex.com/</a></div>
|
||||
<div class="line">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.”</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>ShapeShift</strong> - <a class="reference external" href="https://shapeshift.io">https://shapeshift.io</a></div>
|
||||
<div class="line">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.</div>
|
||||
<div class="line"><br/></div>
|
||||
<div class="line"><strong>YUNBI</strong> - <a class="reference external" href="https://yunbi.com">https://yunbi.com</a></div>
|
||||
<div class="line">From the YUNBI website, “Formerly Peatio Exchange, YUNBI is an open source cryptocurrency exchange cofunded by BitFundPE.”</div>
|
||||
</div>
|
||||
<p>There are many more discussions open on the <a class="reference external" href="https://forum.z.cash">Forum</a>. Join the community to contribute and participate!</p>
|
||||
<p>If you are interested in providing external support by creating a wallet or supporting Zcash on your exchange, please view the <a class="reference external" href="https://z.cash/support/zig.html">Zcash Integration Guide</a>, and contact <a class="reference external" href="mailto:info@z.cash">info@z.cash</a> 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!</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<hr class="docutils"/><p>I found <a class="reference external" href="https://explorer.zcha.in/">this explorer</a> 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 <a class="reference external" href="/third-party-support/">permissionless innovation</a> that permeates cryptocurrencies.)</p>
|
||||
<hr class="docutils"/><p>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 <cite>blockminsize=300000</cite> to your <cite>zcash.conf</cite> and restart your miner. You can track the progress on this at <a class="reference external" href="https://github.com/zcash/zcash/issues/1705">issue #1705</a>.</p>
|
||||
<hr class="docutils"/><p>There was a brief DDoS attack yesterday. Our web site (<a class="reference external" href="https://z.cash">https://z.cash</a>) was down for a bit while we engaged DDoS defenses. You should be aware of <a class="reference external" href="https://z.cash/support/security.html">our security page</a> on which we'll log such events.</p>
|
||||
<hr class="docutils"/><p>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:</p>
|
||||
<div class="figure align-center" style="width: 75%">
|
||||
<img alt="ZEC distribution rate for first 30,000 blocks" src="http://blog.z.cash/wp-content/uploads/2016/11/slow-start-rate-30k.png"/><p class="caption">ZEC distribution rate for first 30,000 blocks</p>
|
||||
</div>
|
||||
<p>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.</p>
|
||||
<p>And here is a graph of the total supply over the first couple of months:</p>
|
||||
<div class="figure align-center" style="width: 75%">
|
||||
<img alt="Total ZEC distributed for first 30,000 blocks" src="http://blog.z.cash/wp-content/uploads/2016/10/slow-start-total-30k.png"/><p class="caption">Total ZEC distributed for first 30,000 blocks</p>
|
||||
</div>
|
||||
<p>So in a few weeks the total supply will be around 125,000 ZEC, compared to the current supply of 1900 ZEC.</p>
|
||||
<p>Here is a graph of the total supply over the first half year:</p>
|
||||
<div class="figure align-center" style="width: 75%">
|
||||
<img alt="Total ZEC distributed for first 190,000 blocks" src="http://blog.z.cash/wp-content/uploads/2016/10/slow-start-total-190k.png"/><p class="caption">Total ZEC distributed for first 190,000 blocks</p>
|
||||
</div>
|
||||
<p>So in about half a year, the total supply will be around 1,250,000 ZEC.</p>
|
||||
<p>(Historical note: these graphs are from <a class="reference external" href="/slow-start-and-mining-ecosystem/">our blog post of October 14</a>.)</p>
|
||||
<hr class="docutils"/><p>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.</p>
|
||||
<p>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.</p>
|
||||
<hr class="docutils"/><p>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 <a class="reference external" href="https://github.com/zcash/zcash/blob/1feaefac51f64bc51d6954d70dc64b3815f95a05/src/chainparams.cpp#L263">the addresses that the Founders' Reward will be sent to</a>. You can also use the aforementioned block explorer to see the <a class="reference external" href="https://explorer.zcha.in/accounts/t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd">history of the first such address</a>, which (as of the time of this writing) shows that no Zcash has yet been moved out of the Founders' Reward address.</p>
|
||||
<hr class="docutils"/><p>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 <a class="reference external" href="/continued-funding-and-transparency/">Continued Funding and Transparency</a>.)</p>
|
||||
<hr class="docutils"/><p>Okay, that's the round-up! Stay tuned for more exciting announcements. ☺</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today we're announcing the release of Zcash 1.0.1, which fixes a few bugs and improves diagnostics:</p>
|
||||
<ol class="arabic simple"><li>Fixed a bug where transactions that contain shielded payments were not being mined in some circumstances. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1718">#1718</a>)</li>
|
||||
<li>Invalid arguments passed when building JoinSplits now produce more descriptive errors. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1752">#1752</a>)</li>
|
||||
<li>Added new RPC call, z_validateaddress (<a class="reference external" href="https://github.com/zcash/zcash/pull/1748">#1748</a>)</li>
|
||||
<li>The friendly metrics screen has improved accuracy and additional information. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1735">#1735</a>)</li>
|
||||
<li>A consensus rule improperly applied to the genesis block was adjusted. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1754">#1754</a>)</li>
|
||||
<li><cite>fetch-params.sh</cite> has been improved and is included in the gitian build. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1758">#1758</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1759">#1759</a>)</li>
|
||||
<li>A checkpoint was added for block 2500. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1750">#1750</a>)</li>
|
||||
</ol><p>We're encouraging all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.</p>
|
||||
<p>For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/45?closed=1">1.0.1</a> github milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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 <tt class="docutils literal">zcashd</tt> wallet which does not impact the consensus protocol.</p>
|
||||
<p>The list of changes included in this release:</p>
|
||||
<ol class="arabic simple"><li>We fixed a bug to ensure that JoinSplit transactions to multiple z-addresses will succeed. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1790">#1790</a>)</li>
|
||||
<li>We changed z_sendmany to check if the size of a transaction for a given number of outputs will be valid. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1808">#1808</a>)</li>
|
||||
<li>We fixed a bug that could crash the miner when it was interrupted. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1778">#1778</a>)</li>
|
||||
<li>Community contributors helped improve our documentation. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1765">#1765</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1763">#1763</a>)</li>
|
||||
</ol><p>We're encouraging all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.</p>
|
||||
<p>For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/45?closed=1">1.0.2</a> github milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.</p>
|
||||
<div class="section" id="background">
|
||||
<h2>Background</h2>
|
||||
<p>JoinSplits encapsulate zero-knowledge value transfer and have two private inputs and two private outputs. Multiple JoinSplits may be <cite>chained</cite> 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 <a class="reference external" href="https://github.com/zcash/zcash/issues/778">#778</a>). A patch to fix this information leak (<a class="reference external" href="https://github.com/zcash/zcash/pull/1561">#1561</a>) in our <a class="reference external" href="/new-release-candidate-less-than-one-week/">1.0.0-rc2</a> 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 (<a class="reference external" href="https://github.com/zcash/zcash/pull/1790">#1790</a>).</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>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 <cite>mining slow start</cite> 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.</p>
|
||||
<div class="section" id="background">
|
||||
<h2>Background</h2>
|
||||
<p>The rest of this post presents a technical background on the <cite>Founders'
|
||||
Reward</cite> and the <cite>Miners' Reward</cite>, and how the <cite>mining slow start</cite>
|
||||
interacts with them. Finally, some of the links provided allow you to
|
||||
observe up-to-date details for these kinds of funds.</p>
|
||||
<p>For further background, please see our prior blog posts:</p>
|
||||
<ul class="simple"><li><a class="reference external" href="/funding/">Funding</a></li>
|
||||
<li><a class="reference external" href="/continued-funding-and-transparency/">Continued Funding and Transparency</a></li>
|
||||
<li><a class="reference external" href="/slow-start-and-mining-ecosystem/">User Expectations at Sprout Pt. 1: Slow-Start Mining & Mining Ecosystem</a></li>
|
||||
</ul><div class="section" id="monetary-base-and-founders-reward">
|
||||
<h3>Monetary Base and Founders' Reward</h3>
|
||||
<p>The Founders' Reward is the cornerstone of our funding and developer incentives model, and allocates 10% of <em>all</em> tokens created to a Founders' Reward fund, with the remaining 90% allocated to miners eventually.</p>
|
||||
<div class="figure align-center" style="width: 75%">
|
||||
<img alt="Zcash Distribution" class="zecc-blog-inline-image" src="http://blog.z.cash/wp-content/uploads/2016/09/founders-reward-1-v3.png"/><p class="caption">Source: <a class="reference external" href="/continued-funding-and-transparency/">Continued Funding and Transparency</a></p>
|
||||
</div>
|
||||
<p>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:</p>
|
||||
<div class="figure align-center" style="width: 75%">
|
||||
<img alt="Founders Reward Graph" class="zecc-blog-inline-image" src="http://blog.z.cash/wp-content/uploads/2016/11/foundersreward.png"/><p class="caption">Source: <a class="reference external" href="/funding/">Funding</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="block-subsidies">
|
||||
<h3>Block Subsidies</h3>
|
||||
<p>When a new valid block is discovered, the special <cite>coinbase</cite> transaction is permitted to create new ⓩ tokens according to the monetary base growth schedule. The <em>total</em> number of ⓩ created per block in this beginning stage of the network follow the <cite>slow start</cite> 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:</p>
|
||||
<div class="figure align-center" style="width: 85%">
|
||||
<img alt="ZEC distribution rate for first 30,000 blocks" src="http://blog.z.cash/wp-content/uploads/2016/11/slow-start-rate-30k.png"/><p class="caption">ZEC distribution rate for first 30,000 blocks. Source: <a class="reference external" href="/slow-start-and-mining-ecosystem/">User Expectations at Sprout Pt. 1: Slow-Start Mining & Mining Ecosystem</a></p>
|
||||
</div>
|
||||
<p>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 <cite>coinbase transaction</cite>, such as <a class="reference external" href="https://explorer.zcha.in/transactions/ad1f2885b082e1990c3b843876ecdc3d8f4a3be9bd31ea7f980f9dda081ef645">this example from block 8086</a>:</p>
|
||||
<ul class="simple"><li>Address <tt class="docutils literal">t1XepX38RxS3o5hLioLbaNb6Fa2Y2Be55xw</tt>, the miner's address, receives 4.0431 ⓩ, and</li>
|
||||
<li>Address <tt class="docutils literal">t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd</tt>, which collects the Founders' Reward, receives 1.01075 ⓩ.</li>
|
||||
</ul></div>
|
||||
<div class="section" id="founders-reward-addresses">
|
||||
<h3>Founders' Reward Addresses</h3>
|
||||
<p>The miner's address is chosen by the miner at the time they created the block, whereas the founders' Reward address, <a class="reference external" href="https://explorer.zcha.in/accounts/t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd">t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd</a> seen above, is specified in the consensus rules (specifically in <a class="reference external" href="https://github.com/zcash/zcash/blob/v1.0.0/src/chainparams.cpp#L135-L192">this source code</a>). Throughout the approximately four years of Founders' Reward distribution, the specific addresses used will change, a measure to improve our operational security.</p>
|
||||
<p>You can see that as of this writing (around block 8775), no funds have moved from the Founders' Reward address <a class="reference external" href="https://explorer.zcha.in/accounts/t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd">t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd</a> (link to <a class="reference external" href="https://explorer.zcha.in/">zcha.in explorer</a>). Once we begin transfering funds out of that address, the URL should reflect those transfers out.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="conclusion">
|
||||
<h2>Conclusion</h2>
|
||||
<p>Once Founders' Reward transfers begin, on or around November 28th, and the <cite>slow start</cite> 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!</p>
|
||||
<div class="section" id="resources">
|
||||
<h3>Resources</h3>
|
||||
<p>To learn about the current public state of Founders' Reward funds or Miners' reward funds, you can use the following resources:</p>
|
||||
<ul class="simple"><li>The list of all Founders' Reward addresses is found in <a class="reference external" href="https://github.com/zcash/zcash/blob/v1.0.0/src/chainparams.cpp#L135-L192">this source code</a> table.</li>
|
||||
<li>The untransfered balance of the Founders' Reward can be viewed with any 'balance view' of those addresses, such as this view of the current <a class="reference external" href="https://explorer.zcha.in/accounts/t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd">t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd</a> address.</li>
|
||||
<li>The rewards for the Miner and Founders are found in any <cite>coinbase</cite> transaction, such as <a class="reference external" href="https://explorer.zcha.in/transactions/ad1f2885b082e1990c3b843876ecdc3d8f4a3be9bd31ea7f980f9dda081ef645">this example from block 8086</a>.</li>
|
||||
</ul><p>Note: The last two links are to the <a class="reference external" href="https://explorer.zcha.in/">zcha.in explorer</a> which is not operated by the Zcash Company. Any blockchain explorer will provide the same information.</p>.
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today we're announcing the release of Zcash 1.0.3 which fixes several crashes and security bugs, improves performance, and adjusts relay policies.</p>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zcash/pull/1874">#1874</a>.)</p>
|
||||
<p>Other changes in this release include:</p>
|
||||
<ol class="arabic simple"><li>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. (<a class="reference external" href="https://github.com/zcash/zcash/issues/1858">#1858</a>)</li>
|
||||
<li>We re-enabled note randomization that was temporarily disabled in 1.0.2. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1814">#1814</a>)</li>
|
||||
<li>We adjusted fee policies to reflect changes made in Bitcoin Core and encourage relaying of transactions containing JoinSplits. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1855">#1855</a>)</li>
|
||||
<li>We improved diagnostics and strengthened testing for the merkle tree's interaction with the constraint system. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1797">#1797</a>)</li>
|
||||
<li>We disabled RPC keepalive features temporarily to avoid deadlocks. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1847">#1847</a>)</li>
|
||||
<li>We adjusted our use of the libsnark verification API to improve zk-SNARK verification performance by 10%. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1760">#1760</a>, <a class="reference external" href="https://speed.z.cash/changes/?rev=057ab6b4d1&exe=undefined&env=1">stats</a>)</li>
|
||||
<li>We changed the error message format for <cite>z_sendmany</cite> so that amounts are displayed in units of ZEC. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1838">#1838</a>)</li>
|
||||
</ol><p>We're encouraging all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.</p>
|
||||
<p>For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/47?closed=1">1.0.3</a> github milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.</p>
|
||||
|
|
@ -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 <a class="reference external" href="/auditing-zcash/">announced</a> back in August, we commissioned two security audits of the Zcash codebase and an analysis of our proof-of-work algorithm. We <a class="reference external" href="/audit-results/">published</a> the two security audits shortly before Zcash’s launch. Today, we are pleased to share the analysis from <a class="reference external" href="https://en.wikipedia.org/wiki/Solar_Designer">Solar Designer</a> of the Zcash Equihash proof-of-work scheme.
|
||||
|
||||
<h2>Solar Designer’s Report</h2>
|
||||
<strong>Report URL:</strong> <a class="reference external" href="http://www.openwall.com/articles/Zcash-Equihash-Analysis">http://www.openwall.com/articles/Zcash-Equihash-Analysis</a>
|
||||
<dl class="docutils">
|
||||
<dt><strong>Solar’s summary:</strong></dt>
|
||||
<dd>
|
||||
<p class="first">“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.</p>
|
||||
<p class="last">“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.”</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2>Related Work</h2>
|
||||
In addition to the analysis presented here, Solar Designer is one of three judges evaluating the first <a class="reference external" href="https://zcashminers.org/">Zcash Mining Competition</a>, which we announced <a class="reference external" href="/announcing-miner-contest/">previously on this blog</a>.
|
||||
|
||||
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 <a class="reference external" href="https://chat.zcashcommunity.com/channel/zcash-miner-dev"><tt class="docutils literal"><span class="pre">#zcash-miner-dev</span></tt></a> community chat channel.
|
||||
|
||||
To keep up in general with the Zcash Company, read this blog, follow our <a class="reference external" href="https://twitter.com/zcashco">@zcashco</a> Twitter handle, and join our forum.
|
||||
|
|
@ -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
|
||||
---
|
||||
<strong>Synopsis:</strong> 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 <a class="reference external" href="https://z.cash/download.html">zcashd release 1.0.3</a>.
|
||||
|
||||
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.
|
||||
|
||||
<strong>Who is at Risk:</strong> Users are at risk only when two conditions are met simultaneously:
|
||||
<ol class="arabic simple">
|
||||
<li>They rely on <a class="reference external" href="https://github.com/zcash/zcash/releases">zcashd releases</a> older than 1.0.3, including 1.0.0, 1.0.1, and 1.0.2, <em>AND</em></li>
|
||||
<li>A network-wide attack is executed to trigger a chain fork. This requires a majority of miners to run vulnerable software.</li>
|
||||
</ol>
|
||||
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.
|
||||
|
||||
<strong>Who is not at Risk:</strong> Users who meet <em>either</em> of the following two conditions are not at risk:
|
||||
<ol class="arabic simple">
|
||||
<li>they have upgraded to <cite>zcashd 1.0.3</cite>, or rely on a service which has done so, <em>OR</em></li>
|
||||
<li>no network-wide attack has succeeded (for example, because a sufficient portion of miners have mitigated the vulnerability).</li>
|
||||
</ol>
|
||||
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.
|
||||
|
||||
<strong>How can at-risk users protect themselves?</strong>
|
||||
<ol class="arabic simple">
|
||||
<li>Upgrading to <a class="reference external" href="https://z.cash/download.html">zcashd release 1.0.3</a> is the most certain protection.</li>
|
||||
<li>For users of third party services (such as exchanges, wallets, or mining pools), check if the service has announced upgrading to <cite>zcashd 1.0.3</cite>. If it hasn't, consider pausing use of that service until they announce an upgrade.</li>
|
||||
</ol>
|
||||
<strong>How can I tell if an attack is occurring?</strong> 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:
|
||||
<ul>
|
||||
<li>
|
||||
<p class="first">The Zcash developers will issue an in-band alert, causing all <cite>zcashd</cite> nodes to announce the potential attack.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p class="first">ZcashCo will always announce known ongoing attacks in these places:</p>
|
||||
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>a banner on every page of this website,</li>
|
||||
<li>the <a class="reference external" href="https://z.cash/support/security.html">security notifications</a> page of this website,</li>
|
||||
<li>the <a class="reference external" href="https://twitter.com/zcashco">@ZcashCo</a> twitter stream,</li>
|
||||
<li>the <a class="reference external" href="https://chat.zcashcommunity.com/channel/zcash">#zcash community chat room</a>, <em>and</em></li>
|
||||
<li>the <a class="reference external" href="https://forum.z.cash/">Zcash forum</a>.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
</li>
|
||||
<li>
|
||||
<p class="first">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.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<em>Note:</em> The major exchanges, wallet vendors, and miners we are in communication with are already protected against such an attack.
|
||||
|
||||
<strong>Impact:</strong> <em>If</em> a network attack is successfully executed (which requires a majority of mining capacity to be vulnerable) then <em>only</em> 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.
|
||||
|
||||
<strong>Technical Background:</strong> Due to a cache invalidation bug, some nodes on the Zcash network will accept particular invalid transactions as valid <a id="id1" class="footnote-reference" href="/security-announcement-2016-11-22#id2">[1]</a>. If a majority of the network hashrate accepts an invalid transaction as valid, there could be a chain fork.
|
||||
|
||||
<strong>Followup Announcements:</strong>
|
||||
<ul class="simple">
|
||||
<li>See the <a class="reference external" href="https://z.cash/support/security.html">security notifications</a> page for further updates on this issue, and any future security issue.</li>
|
||||
<li>Continue to check this blog.</li>
|
||||
</ul>
|
||||
<table id="id2" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="https://z.cash/blog/security-announcement-2016-11-22.html#id1">[1]</a></td>
|
||||
<td>Note that transaction validity is well specified by our protocol specification, <a class="reference external" href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">Zcash protocol specification, v2016.0-beta-1.10</a>; It is unambiguous that this security flaw is an implementation bug.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Since the successful launch of the Zcash network on <a class="reference external" href="/zcash-begins/">October 28th</a>, 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.</p>
|
||||
<div class="section" id="the-building-blocks-of-a-transaction">
|
||||
<h2>The Building Blocks of A Transaction</h2>
|
||||
<p>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 <a class="reference external" href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">protocol specification</a> 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.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="A high-level skeleton diagram of a Zcash transaction" class="center-image" src="http://blog.z.cash/wp-content/uploads/2016/11/high-level-txn_v3.png"/><p class="caption">A high-level view of a Zcash transaction</p>
|
||||
</div>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="A screenshot from Zchain block explorer showing sending ZEC between shielded addresses" src="http://blog.z.cash/wp-content/uploads/2016/11/shield-shield-txn.png"/><p class="caption">A screenshot from the Zchain block explorer of a <a class="reference external" href="https://explorer.zcha.in/transactions/35f6674a1691f21aff6a3819467dbba82aaebf061d50c6ac55f39fbeae73b9a6">transaction between shielded addresses</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="change-addresses">
|
||||
<h2>Change Addresses</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="sending-between-shielded-and-transparent-addresses">
|
||||
<h2>Sending Between Shielded and Transparent Addresses</h2>
|
||||
<div class="figure align-center">
|
||||
<img alt="A diagram showing differences between sending ZEC to and from shielded and transparent addresses" class="center-image" src="http://blog.z.cash/wp-content/uploads/2016/11/basic-txn-types_v2.png"/><p class="caption">Properties of sending ZEC between shielded and transparent addresses</p>
|
||||
</div>
|
||||
<p>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 <a class="reference external" href="/software-usability-and-hardware-requirements/">user expectations for hardware and software limitations</a>.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="A screenshot from Zchain block explorer showing sending ZEC from a transparent address to a shielded address" src="http://blog.z.cash/wp-content/uploads/2016/11/transparent-shield-txn.png"/><p class="caption">A screenshot from the Zchain block explorer of a transaction <a class="reference external" href="https://explorer.zcha.in/transactions/de1d78ee310ba2c9fbeb13881f431fdc8b55aa5f79e61dd3c294177401878f11">shielding ZEC</a></p>
|
||||
</div>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="further-notes-on-more-complex-transactions-and-privacy-implications">
|
||||
<h2>Further Notes on More Complex Transactions and Privacy Implications</h2>
|
||||
<p>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 <a class="reference external" href="https://explorer.zcha.in/statistics/value">stats</a> 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.</p>
|
||||
</div>
|
||||
|
|
@ -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 <a class="reference external" href="/blog/anatomy-of-zcash/">'Anatomy of A Zcash Transaction'</a> we gave a general overview of Zcash Transactions. The purpose of this post is to provide a simplified explanation of how <em>privacy-preserving</em> 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 <em>even after it has been spent</em>. Thus, it is no longer a database of unspent notes, but rather a database of <em>all notes that ever existed</em>.
|
||||
|
||||
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 <em>nullifier set</em> 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.
|
||||
<table class="fixed-table docutils" border="1"><colgroup> <col width="53%" /> <col width="47%" /> </colgroup>
|
||||
<thead valign="bottom">
|
||||
<tr>
|
||||
<th class="head">Hashed notes</th>
|
||||
<th class="head">Nullifier set</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td>:math:`\mathsf{H}_1=` :math:`\mathbf{HASH}(\mathsf{Note}_1)`</td>
|
||||
<td>:math:`\mathsf{nf}_1=` :math:`\mathbf{HASH}(\mathsf{r}_2)`</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>:math:`\mathsf{H}_2=` :math:`\mathbf{HASH}(\mathsf{Note}_2)`</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>:math:`\mathsf{H}_3=` :math:`\mathbf{HASH}(\mathsf{Note}_3)`</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2>How a transaction is made</h2>
|
||||
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.
|
||||
<ol>
|
||||
<li>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).`</li>
|
||||
<li>She sends :math:`\mathsf{Note}_4` to Bob privately.</li>
|
||||
<li>She sends the nullifier of :math:`\mathsf{Note}_1,` :math:`\mathsf{nf}_2=` :math:`\mathbf{HASH}(\mathsf{r}_1)` to all nodes.</li>
|
||||
<li>She sends the hash of the new note :math:`\mathsf{H}_4=,` :math:`\mathbf{HASH}(\mathsf{Note}_4)` to all nodes.</li>
|
||||
</ol>
|
||||
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.
|
||||
<table class="fixed-table docutils" border="1"><colgroup> <col width="53%" /> <col width="47%" /> </colgroup>
|
||||
<thead valign="bottom">
|
||||
<tr>
|
||||
<th class="head">Hashed notes</th>
|
||||
<th class="head">Nullifier set</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td>:math:`\mathsf{H}_1=` :math:`\mathbf{HASH}(\mathsf{Note}_1)`</td>
|
||||
<td>:math:`\mathsf{nf}_1=` :math:`\mathbf{HASH}(\mathsf{r}_2)`</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>:math:`\mathsf{H}_2=` :math:`\mathbf{HASH}(\mathsf{Note}_2)`</td>
|
||||
<td>:math:`\mathsf{nf}_2=` :math:`\mathbf{HASH}(\mathsf{r}_1)`</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>:math:`\mathsf{H}_3=` :math:`\mathbf{HASH}(\mathsf{Note}_3)`</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>:math:`\mathsf{H}_4=` :math:`\mathbf{HASH}(\mathsf{Note}_4)`</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
..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 <em>Zero-Knowledge proofs</em> come to the rescue:
|
||||
|
||||
In addition to the steps above, Alice will publish a proof-string :math:`\pi` convincing the nodes that <em>whomever published this transaction knows values</em> :math:`\mathsf{PK}_1,` :math:`\mathsf{sk}_1,` <em>and</em> :math:`r_1` <em>such that</em>
|
||||
<ol>
|
||||
<li style="list-style-type: none;">
|
||||
<ol>
|
||||
<li>The hash of the note :math:`\mathsf{Note}_1=` (:math:`\mathsf{PK}_1,` :math:`r_1)` exists in the set of hashed notes.</li>
|
||||
<li>: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`).</li>
|
||||
<li>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).</li>
|
||||
</ol>
|
||||
</li>
|
||||
</ol>
|
||||
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`.
|
||||
<h3>The main places above where we cheated or omitted details</h3>
|
||||
We emphasize that this has been an oversimplified description, and recommend the <a class="reference external" href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf">protocol spec</a> for full details.
|
||||
|
||||
Here are some of the main things that were overlooked:
|
||||
<ol>
|
||||
<li style="list-style-type: none;">
|
||||
<ol class="arabic simple">
|
||||
<li>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 <em>computationally hiding and binding commitment</em> of the note, rather than just its hash.</li>
|
||||
<li>The nullifier needs to be defined in a slightly more complex way to ensure future privacy of the receiver in relation to the sender.</li>
|
||||
<li>We did not go into details on how to eliminate the need for a private channel between sender and recipient.</li>
|
||||
</ol>
|
||||
</li>
|
||||
</ol>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>A few months ago, we launched the <a class="reference external" href="https://zcashminers.org/">Zcash Open Source Miner Challenge</a> and today we are announcing the winners:</p>
|
||||
<ul class="simple"><li>CPU Winner, $10,000 prize: xenoncat with <a class="reference external" href="https://github.com/xenoncat/equihash-xenon">https://github.com/xenoncat/equihash-xenon</a></li>
|
||||
<li>GPU Winner, $10,000 prize: mbevand with <a class="reference external" href="https://github.com/mbevand/silentarmy">https://github.com/mbevand/silentarmy</a></li>
|
||||
<li>Runner Up, $5,000 prize: tromp with <a class="reference external" href="https://github.com/tromp/equihash">https://github.com/tromp/equihash</a></li>
|
||||
<li>Runner Up, $3,000 prize: morpav with <a class="reference external" href="https://github.com/morpav/zceq_solver">https://github.com/morpav/zceq_solver</a></li>
|
||||
<li>Runner Up, $2,000 prize: davidjaenson with <a class="reference external" href="https://github.com/davidjaenson/equihash">https://github.com/davidjaenson/equihash</a></li>
|
||||
</ul><p>The judges: <a class="reference external" href="https://str4d.xyz/">Jack Grigg</a>, <a class="reference external" href="http://www.openwall.com/">Solar Designer</a>, and <a class="reference external" href="https://www.cryptolux.org/index.php/Dmitry_Khovratovich">Dmitry Khovratovich</a>, selected these submissions as the Winners and Runners Up based on <a class="reference external" href="https://zcashminers.org/judging">the criteria</a>, which included many factors of quality, community contributions, and performance.</p>
|
||||
<p>The <a class="reference external" href="https://z.cash">Zcash Company</a> sponsored this challenge to help strengthen and decentralize the Zcash community, as well as contribute to the advancement of computer science. <a class="reference external" href="https://leastauthority.com/">Least Authority</a>, as a supporter of the Zcash Company, operated this challenge.</p>
|
||||
<p>The <a class="reference external" href="https://zcashminers.org/">Zcash Open Source Miner Challenge</a> has made mining for ZEC accessible to more people and facilitated collaboration within the Zcash community. While the <a class="reference external" href="https://zcashminers.org/submissions">code available</a> 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!</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>As of <a class="reference external" href="/zcash-begins/">October 28, 2016</a>, Zcash is a reality! Anybody with Internet access can <a class="reference external" href="https://z.cash/download.html">download the software</a>, connect to the <a class="reference external" href="https://mainnet.z.cash/">global decentralized network</a>, and send and receive payments, <em>without</em> exposing their confidential transaction metadata to the world.</p>
|
||||
<p>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 <a class="reference external" href="https://zcashblog.wordpress.com/zcash-gui-wallets/">graphical user interfaces</a>.</p>
|
||||
<p>This blog post is about a little-known but potentially valuable feature of this new protocol.</p>
|
||||
<div class="section" id="the-encrypted-memo-field">
|
||||
<h2>The Encrypted Memo Field</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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).</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="what-will-people-do-with-this">
|
||||
<h2>What Will People Do With This</h2>
|
||||
<div class="figure align-center">
|
||||
<img alt="a memo field. Remember those?" class="center-image" src="http://blog.z.cash/wp-content/uploads/2016/12/a-memo-field.png"/></div>
|
||||
<p>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 <em>else</em> will people use this for?</p>
|
||||
<p>Zcash is the first system which combines the <em>append-only</em> property of blockchains with the <em>selective disclosure</em> 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 <em>immutable</em> and <em>append-only</em> ledger, but it will not be <em>visible</em> to anyone else — yet. If you later disclose the transaction view key to someone, then the data will become visible to <em>them</em> 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.</p>
|
||||
<p>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?</p>
|
||||
<p>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!</p>
|
||||
</div>
|
||||
<div class="section" id="return-addresses">
|
||||
<h2>Return Addresses</h2>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="the-travel-rule">
|
||||
<h2>The Travel Rule</h2>
|
||||
<p>Another specific use that we had in mind was satisfying <a class="reference external" href="https://www.sec.gov/about/offices/ocie/aml2007/fincen-advissu7.pdf">The Travel Rule</a>. The Travel Rule is a regulation of <a class="reference external" href="https://en.wikipedia.org/wiki/Financial_Crimes_Enforcement_Network">FinCEN</a> 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 <em>travel with</em> 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!</p>
|
||||
<p>With Zcash, a financial institution <em>can</em> 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.</p>
|
||||
</div>
|
||||
<div class="section" id="love-notes-in-the-blockchain">
|
||||
<h2>Love Notes In The Blockchain</h2>
|
||||
<p>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 <a class="reference external" href="https://ipfs.io/">IPFS</a> 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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="zmsg">
|
||||
<h2>zmsg</h2>
|
||||
<p>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): <a class="reference external" href="https://github.com/whyrusleeping/zmsg">zmsg</a></p>
|
||||
</div>
|
||||
<div class="section" id="endless-possibilities">
|
||||
<h2>Endless possibilities</h2>
|
||||
<p>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 <a class="reference external" href="https://forum.z.cash">online community</a>.</p>
|
||||
</div>
|
||||
|
|
@ -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:
|
||||
<ol class="arabic simple">
|
||||
<li>We fixed a cache invalidation bug that caused some orphaned blocks to trigger node crashes. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1928">#1928</a>)</li>
|
||||
<li>We fixed a race condition that inhibited creation of multi-JoinSplit transactions. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1911">#1911</a>)</li>
|
||||
<li>We adjusted mining policies to encourage inclusion of transactions containing JoinSplits. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1895">#1895</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1902">#1902</a>)</li>
|
||||
<li>We improved rescan and reindex performance. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1892">#1892</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1904">#1904</a>)</li>
|
||||
<li>We improved zk-SNARK verification performance by 7%. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1919">#1919</a>, <a class="reference external" href="https://speed.z.cash/comparison/?exe=1%2B208%2C1%2B226&ben=3&env=1&hor=false&bas=1%2B208&chart=normal+bars">stats</a>)</li>
|
||||
<li>We added additional well-formedness checks for JoinSplit proofs. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1938">#1938</a>)</li>
|
||||
<li>We added a fee parameter to <cite>z_sendmany</cite>. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1907">#1907</a>)</li>
|
||||
<li>We added a <cite>getlocalsolps</cite> RPC method for obtaining the mining rate without the metrics screen. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1642">#1642</a>)</li>
|
||||
<li>The Bash completion files were updated to work with <cite>zcashd</cite>. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1909">#1909</a>)</li>
|
||||
<li>The build scripts were extended to make porting Zcash to other platforms easier. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1905">#1905</a>)</li>
|
||||
<li>A checkpoint was added at block height 15,000. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1865">#1865</a>)</li>
|
||||
</ol>
|
||||
We're encouraging all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.
|
||||
|
||||
For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/48?closed=1">1.0.4</a> GitHub milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.
|
||||
|
|
@ -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
|
||||
---
|
||||
<p><em>See also a related post:</em> <a class="reference external" href="/consensual-currency/">Consensual Currency</a>.</p>
|
||||
<p>“Forks” (or “hard-forks”) are a highly contentious topic in cryptocurrencies. You can analyze a fork with two questions:</p>
|
||||
<ul class="simple"><li>Does it result in two (persistent) separate branches of the original blockchain?</li>
|
||||
<li>Does it result in community schism?</li>
|
||||
</ul><p>In principle, any of the four combinations of these two consequences could happen.</p>
|
||||
<p>Interestingly, three out of four of these combinations have already occurred in practice!</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="A diagram depicting whether a fork resulted in a persistent branch of the blockchain and a schism in the community" class="center-image future-friendly-fork" src="http://blog.z.cash/wp-content/uploads/2017/01/friendly-fork.png"/></div>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<em>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</em> <a class="reference external" href="https://blog.ethereum.org/2017/01/19/update-integrating-zcash-ethereum/">Ethereum blog</a>, <em>and is coauthored by Ariel Gabizon (Zcash) and Christian Reitwiessner (Ethereum).</em>
|
||||
|
||||
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 <a class="reference external" href="/project-alchemy/">Project Alchemy</a>, 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 <a class="reference external" href="/zksnarks-in-ethereum/">Baby ZoE</a> 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.
|
||||
<div id="what-can-be-done-with-such-a-system" class="section">
|
||||
<h2>What can be done with such a system</h2>
|
||||
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 <a class="reference external" href="https://gitter.im/ethereum/privacy-tech">https://gitter.im/ethereum/privacy-tech</a>
|
||||
<pre class="code literal-block">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
|
||||
</pre>
|
||||
We also discussed various aspects of integrating zk-SNARKs into the Ethereum blockchain, on which we now expand.
|
||||
|
||||
<h2>Deciding what precompiled contracts to define</h2>
|
||||
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 <a class="reference external" href="https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/">here</a>, 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 <a class="reference external" href="https://drive.google.com/file/d/0BwDmGb8qpc8RMEhBMlR5VHE3bEU/view?usp=sharing">sketch</a> 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 <a class="reference external" href="https://github.com/scipr-lab/libsnark">libsnark</a> 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.
|
||||
|
||||
<h2>Reusing the Zcash setup for new anonymous tokens and other applications</h2>
|
||||
As you might have heard, using SNARKs requires a <a class="reference external" href="/the-design-of-the-ceremony/">complex setup phase</a> 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.
|
||||
|
||||
<h2>Other applications</h2>
|
||||
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.
|
||||
|
||||
<h2>The work ahead</h2>
|
||||
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 <a class="reference external" href="https://github.com/ConsenSys/Project-Alchemy">written</a>; however, its efficiency needs to be improved in order to be used in practical applications.
|
||||
|
||||
<em>Acknowledgement</em>: We thank Sean Bowe for technical assistance. We also thank Sean and Vitalik Buterin for helpful comments, and Ming Chan for editing.
|
||||
|
|
@ -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:
|
||||
<ol class="arabic simple">
|
||||
<li>The chain is now fully rescanned when keys are imported that are older than the wallet. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1978">#1978</a>)</li>
|
||||
<li>The number of commitments in the note commitment tree is now displayed by <cite>getblockchaininfo</cite>. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1946">#1946</a>)</li>
|
||||
<li><cite>zcash.conf</cite> now must exist in order to start zcashd. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2013">#2013</a>)</li>
|
||||
<li>Fixed a bug where <cite>z_sendmany</cite> logged incorrect txid fragments when sending from transparent addresses. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1980">#1980</a>)</li>
|
||||
<li>We integrated upstream's cookie-based RPC authentication. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1999">#1999</a>)</li>
|
||||
<li>We added a restriction to wallet export paths to protect user security. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2006">#2006</a>)</li>
|
||||
<li><cite>z_getoperationstatus</cite> is now sorted chronologically. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2015">#2015</a>)</li>
|
||||
<li>Messages containing newlines are now rendered properly by the metrics UI. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1972">#1972</a>)</li>
|
||||
<li>We added more tools for benchmarking JoinSplit creation. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1953">#1953</a>)</li>
|
||||
<li>We now show serialized transaction size in <cite>listtransactions</cite>, more operation details in <cite>z_getoperationstatus</cite>, and the age of the note being spent in <cite>z_sendmany</cite> logging. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2001">#2001</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1976">#1976</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/1977">#1977</a>)</li>
|
||||
<li>We now instruct users to run <cite>fetch-params</cite> if the parameters could not be found locally. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1979">#1979</a>)</li>
|
||||
<li>We handle exceptions better in some situations for more user-friendly error messages. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1976">#1976</a>)</li>
|
||||
</ol>
|
||||
We're encouraging all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.
|
||||
|
||||
For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/49">1.0.5</a> GitHub milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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).</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<div class="section" id="where-does-zcash-introduce-linkability">
|
||||
<h2>Where does Zcash introduce linkability?</h2>
|
||||
<div class="section" id="transparent-addresses">
|
||||
<h3>Transparent Addresses</h3>
|
||||
<p>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.</p>
|
||||
<p>But what happens when shielded addresses are sprinkled into the mix? Thankfully, shielded addresses in Zcash indeed break linkability when used properly.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="Comparing transaction series: three transparent addresses vs a shielded address sandwiched between two transparent addresses" class="center-image high-res-image" src="http://blog.z.cash/wp-content/uploads/2017/01/t-vs-z-links.png"/><p class="caption">Shielded addresses can de-link transparent addresses <a class="footnote-reference" href="#id4" id="id1">[1]</a></p>
|
||||
</div>
|
||||
<p>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: <a class="reference external" href="https://explorer.zcha.in/transactions/548a0ee2d59821624a13abe841c6a86eec85fec101eabe152254aa565a3abe9f">Alice sends 15 ZEC (minus fee) to transparent Bob</a> and <a class="reference external" href="https://explorer.zcha.in/transactions/ca69d489c5f1df34f4143d898284ade9f7a8df1f50955d6c77628c82b1702085">transparent Bob sends 10 ZEC to Carol</a> compared with <a class="reference external" href="https://explorer.zcha.in/transactions/7bf9d70ba43624c7fc88319b1caf9281b400ad5b3607024fb14e234fedb85854">Alice sends 15 ZEC (minus fee) to shielded Bob</a> and <a class="reference external" href="https://explorer.zcha.in/transactions/87570f1d30841ea41ea4cbf5a85f1eb6a6879b5fbc0c1d9c6e360702e0af0e45">shielded Bob sends 10 ZEC to Carol</a>.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="linking-values">
|
||||
<h3>Linking Values</h3>
|
||||
<p>The above method where Bob de-links Alice and Carol simply by using a shielded address isn’t 100% reliable for every situation, however.</p>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="A diagram showing the possibile value linkability in a transaction series even when a shielded address is used in between transparent addresses" class="center-image high-res-image" src="http://blog.z.cash/wp-content/uploads/2017/01/z-linkability.png"/><p class="caption">A shielded address might not protect against value linkability in some cases</p>
|
||||
</div>
|
||||
<p>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: <a class="reference external" href="https://explorer.zcha.in/transactions/20d2742d56ab03012ea92d1521db22b8224ff5fe52218686e1cee3fda609bcde">Alice sends 15 ZEC (minus .0001 ZEC fee) to shielded Bob</a> and <a class="reference external" href="https://explorer.zcha.in/transactions/12255ca035f59e2373ba16b820763de788536a73812b2b025df11e46757e96f3">shielded Bob sends 14.9999 ZEC (minus .0001 ZEC fee) to Carol</a>.</p>
|
||||
<p>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.</p>
|
||||
<p>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. <a class="footnote-reference" href="#id5" id="id2">[2]</a></p>
|
||||
</div>
|
||||
<div class="section" id="unique-transaction-fees">
|
||||
<h3>Unique Transaction Fees</h3>
|
||||
<p>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 <a class="reference external" href="/anatomy-of-zcash/">Zcash transaction anatomy</a>, 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.</p>
|
||||
<p>The solution here is to simply use standard transaction fees!</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="reducing-linkability-by-reducing-complexity">
|
||||
<h2>Reducing Linkability By Reducing Complexity</h2>
|
||||
<p>While the advantages of supplying both transparent and shielded addresses to users allows for more options <a class="footnote-reference" href="#id6" id="id3">[3]</a>, 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.</p>
|
||||
<table class="docutils footnote" frame="void" id="id4" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>In transaction series <em>b</em>, 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.</td></tr></tbody></table><table class="docutils footnote" frame="void" id="id5" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id2">[2]</a></td><td>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.</td></tr></tbody></table><table class="docutils footnote" frame="void" id="id6" rules="none"><colgroup><col class="label"/><col/></colgroup><tbody valign="top"><tr><td class="label"><a class="fn-backref" href="#id3">[3]</a></td><td>While <a class="reference external" href="/zcash-private-transactions/">shielded addresses</a> offer the privacy features which distinguish Zcash from purely public blockchain networks, the transparent addresses provide (at least for now) a relief in <a class="reference external" href="/software-usability-and-hardware-requirements/">resource requirements</a> along with familiar functionality to previously launched cryptocurrencies.</td></tr></tbody></table></div>
|
||||
|
|
@ -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:
|
||||
<ol class="arabic simple">
|
||||
<li>Users can now mine to a single address by using new zcashd options <cite>-mineraddress</cite> and <cite>-minetolocalwallet</cite> (<a class="reference external" href="https://github.com/zcash/zcash/pull/1965">#1965</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2081">#2081</a>)</li>
|
||||
<li>Updated RPC calls <cite>getrawtransaction</cite> and <cite>decoderawtransaction</cite> to display all fields of a JoinSplit. Now includes the zk-proof, ephemeral key, random seed and encrypted ciphertexts (<a class="reference external" href="https://github.com/zcash/zcash/pull/2054">#2054</a>)</li>
|
||||
<li>Updated logging in RPC call <cite>z_sendmany</cite> for the debug categories <cite>zrpc</cite> and <cite>zrpcunsafe</cite> (<a class="reference external" href="https://github.com/zcash/zcash/pull/2058">#2058</a>)</li>
|
||||
<li>Fixed a bug which prevented passing a fee parameter of zero to RPC call <cite>z_sendmany</cite> (<a class="reference external" href="https://github.com/zcash/zcash/pull/2068">#2068</a>)</li>
|
||||
<li>Added build option <cite>--disable-mining</cite> to zcutil/build.sh to allow removal of mining code when compiling (<a class="reference external" href="https://github.com/zcash/zcash/pull/1836">#1836</a>)</li>
|
||||
<li>ZeroMQ notification support has been backported (<a class="reference external" href="https://github.com/zcash/zcash/pull/2050">#2050</a>)</li>
|
||||
<li>Upgraded OpenSSL to 1.1.0d (<a class="reference external" href="https://github.com/zcash/zcash/pull/2051">#2051</a>). We now also use libsodium’s CSPRNG instead of OpenSSL’s (<a class="reference external" href="https://github.com/zcash/zcash/pull/1706">#1706</a>)</li>
|
||||
<li>Backported and updated Univalue library to replace usage of json spirit library (<a class="reference external" href="https://github.com/zcash/zcash/pull/1990">#1990</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2082">#2082</a>)</li>
|
||||
<li>Removed unnecessary exceptions from libsnark (<a class="reference external" href="https://github.com/zcash/zcash/pull/2080">#2080</a>)</li>
|
||||
<li>Added zcashd option flag <cite>-experimentalfeatures</cite> (<a class="reference external" href="https://github.com/zcash/zcash/pull/2056">#2056</a>), fixed a bug in a test (<a class="reference external" href="https://github.com/zcash/zcash/pull/2078">#2078</a>) and updated documentation (<a class="reference external" href="https://github.com/zcash/zcash/pull/2069">#2069</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2077">#2077</a>)</li>
|
||||
</ol>
|
||||
We're encouraging all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.
|
||||
|
||||
For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/50">1.0.6</a> GitHub milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.
|
||||
|
|
@ -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
|
||||
---
|
||||
<p><a class="reference external" href="/helloworld/">Our Mission</a> 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.</p>
|
||||
<div class="section" id="the-story-so-far">
|
||||
<h2>the story so far</h2>
|
||||
<p><a class="reference external" href="/zcash-begins/">Zcash first launched</a> on October 28, 2016. During the first few months of its life, we focused on stabilization and incremental improvement.</p>
|
||||
<p>We delivered a series of improvements (the <a class="reference external" href="/tag/releases/">“Zcash Sprout” series</a> of releases) which fix bugs and improve usability based on iterative feedback from our lovely users. Our users are the best! ❤</p>
|
||||
<p>At the same time, we've been monitoring and supporting the continuous reliable operation of <a class="reference external" href="https://network.zcha.in/">the global Zcash network</a>. So far, the network has experienced zero downtime, and no security breaches.</p>
|
||||
<p>Now we are announcing our development priorities for the next stage of Zcash's growth.</p>
|
||||
<!-- We intend for Zcash to evolve faster than Bitcoin does but slower than Ethereum. We believe this will yield a good compromise of stability and innovation. -->
|
||||
</div>
|
||||
<div class="section" id="stability">
|
||||
<h2>stability</h2>
|
||||
<p>Our first and second priorities will always be:</p>
|
||||
<ol class="arabic simple"><li><strong>Security and reliability</strong>, and</li>
|
||||
<li><strong>Iterative improvement</strong> in response to demand from our users.</li>
|
||||
</ol><p>We will continue to vigilantly guard the security of the system, support our users, and deliver regular stable releases as we have been doing.</p>
|
||||
</div>
|
||||
<div class="section" id="innovation">
|
||||
<h2>innovation</h2>
|
||||
<ol class="arabic"><li><p class="first"><strong>Payment Disclosure</strong> will allow you to reveal the information about a specific payment (including the <a class="reference external" href="/encrypted-memo-field/">encrypted memo field</a>) in the blockchain to a specific party of your choice.</p>
|
||||
<p>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. (<a class="reference external" href="https://github.com/zcash/zcash/issues/2036">Payment Disclosure on GitHub</a>)</p>
|
||||
</li>
|
||||
<li><p class="first"><strong>Payment Off-loading</strong> will allow users of light wallets to send Zcash to shielded addresses without placing any funds at risk. (<a class="reference external" href="https://github.com/zcash/zips/issues/104">Payment Off-loading on GitHub</a>)</p>
|
||||
</li>
|
||||
<li><p class="first"><strong>Cross-Chain Atomic Transactions (“XCAT”)</strong>, part of our <a class="reference external" href="https://forum.z.cash/t/there-are-three-different-flavors-of-project-alchemy/13963">Project Alchemy initiative</a>, will allow transactions that span multiple blockchains. This will enable you to trade Zcash, Ethereum, and Bitcoin tokens without relying on an intermediary. (<a class="reference external" href="https://github.com/zcash/zcash/issues/2098">XCAT on GitHub</a>)</p>
|
||||
</li>
|
||||
<li><p class="first"><strong>The “Sapling” Cryptography Upgrade</strong> 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:</p>
|
||||
</li>
|
||||
<li><p class="first">… <strong>User-Issued Tokens</strong>, which allow you to issue, transfer, and atomically trade unique tokens for your own purposes, with Zcash's strong privacy protections. (<a class="reference external" href="https://github.com/zcash/zcash/issues/830">User-Issued Tokens on GitHub</a>)</p>
|
||||
</li>
|
||||
</ol><p>The Sapling upgrade with User-Issued Tokens will require a <a class="reference external" href="/zcash-evolution/">network-wide upgrade</a>, 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.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="Zcash Sprout to Sapling logo transition" class="center-image" src="http://blog.z.cash/wp-content/uploads/2017/02/zcash-sprout-to-sapling.png"/></div>
|
||||
</div>
|
||||
<div class="section" id="this-is-only-the-beginning">
|
||||
<h2>this is only the beginning</h2>
|
||||
<p>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 <a class="reference external" href="/bolt-private-payment-channels/">BOLT</a>. Other teams and companies may also come out with applications that extend Zcash or leverage its unique features, so stay tuned.</p>
|
||||
<p>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. <a class="reference external" href="https://z.cash/support">Join the growing Zcash community</a> and let us know what <em>you</em> envision for the future!</p>
|
||||
<p>As we wrote at the beginning, the ultimate destiny of Zcash lies not in our hands but in yours.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>The SHA-1 hash function, which has long been considered insecure, is now <a class="reference external" href="https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html">officially broken</a> 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.</p>
|
||||
<p>You can can read the full article at <a class="reference external" href="https://z.cash/technology/history-of-hash-function-attacks.html">https://z.cash/technology/history-of-hash-function-attacks.html</a>.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center">
|
||||
<a class="reference external image-reference" href="https://z.cash/technology/history-of-hash-function-attacks.html"><img alt="chronological view of collision attacks" class="center-image" src="http://blog.z.cash/wp-content/uploads/2017/02/hash-functions-chronology.png"/></a>
|
||||
</div>
|
||||
<p>Thanks to Andreas Hülsing, Samuel Neves, and Zcash engineer Daira Hopwood for their input on this investigation.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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 <a class="reference external" href="/transaction-linkability/">Transaction Linkability</a> 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.</p>
|
||||
<div class="section" id="strength-in-numbers-and-diversity">
|
||||
<h2>Strength In Numbers and Diversity</h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="shielding-the-zcash-ecosystem">
|
||||
<h2>Shielding The Zcash Ecosystem</h2>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="A depiction of a transaction graph with a smaller number of shielded addresses" class="center-image high-res-image" src="http://blog.z.cash/wp-content/uploads/2017/02/ecosystems-more-t.png"/></div>
|
||||
<p>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.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="A depiction of a transaction graph with a larger number of shielded addresses" class="center-image high-res-image" src="http://blog.z.cash/wp-content/uploads/2017/02/ecosystems-more-z.png"/></div>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="a-community-effort-for-a-shielded-ecosystem">
|
||||
<h2>A Community Effort For A Shielded Ecosystem</h2>
|
||||
<p>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 <a class="reference external" href="https://explorer.zcha.in/statistics/network">29%</a>, 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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
|
|
@ -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 <strong>one ingredient</strong> whose role is most prominent, it would be what I will call here <em>Homomorphic Hiding</em> (HH) <a id="id1" class="footnote-reference" href="#id4">[1]</a>. 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:
|
||||
<ul>
|
||||
<li>For most :math:`x`'s, given :math:`E(x)` it is hard to find :math:`x.`</li>
|
||||
<li>Different inputs lead to different outputs - so if :math:`x\neq y,` then :math:`E(x)\neq E(y).`</li>
|
||||
<li>If someone knows :math:`E(x)` and :math:`E(y),` they can generate the HH of <em>arithmetic expressions in</em> :math:`x` <em>and</em> :math:`y.` For example, they can compute :math:`E(x+y)` from :math:`E(x)` and :math:`E(y).`</li>
|
||||
</ul>
|
||||
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).
|
||||
<ol>
|
||||
<li>Alice sends :math:`E(x)` and :math:`E(y)` to Bob.</li>
|
||||
<li>Bob computes :math:`E(x+y)` from these values (which he is able to do since :math:`E` is an HH).</li>
|
||||
<li>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.</li>
|
||||
</ol>
|
||||
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 <a id="id2" class="footnote-reference" href="#id5">[2]</a>.
|
||||
|
||||
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 <em>finite groups</em>:
|
||||
|
||||
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 <em>multiplication</em> 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.` <a id="id3" class="footnote-reference" href="#id6">[3]</a> 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:
|
||||
<ol>
|
||||
<li>It is a <em>cyclic</em> group; which means that there is some element :math:`g` in :math:`\mathbb{Z}_p^*` called a <em>generator</em> 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.`</li>
|
||||
<li>The <em>discrete logarithm problem</em> 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).`</li>
|
||||
<li>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)}.`</li>
|
||||
</ol>
|
||||
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).`
|
||||
<table id="id4" class="docutils footnote" frame="void" rules="none">
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id1">[1]</a></td>
|
||||
<td>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''.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="id5" class="docutils footnote" frame="void" rules="none"><colgroup> <col class="label" /> <col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id2">[2]</a></td>
|
||||
<td>Bob does learn <em>some</em> 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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="id6" class="docutils footnote" frame="void" rules="none"><colgroup> <col class="label" /> <col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id3">[3]</a></td>
|
||||
<td>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).</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p><a class="reference external" href="/snark-explain2">Part II >></a></p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<div class="section" id="upcoming-testnet-upgrade">
|
||||
<h2>Upcoming Testnet Upgrade</h2>
|
||||
<p>The Zcash testnet will soon be upgraded in order to resolve an issue with the Testnet Founders Reward addresses. This <em>will not</em> 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.</p>
|
||||
<p>Summary of the changes in this release:</p>
|
||||
<ol class="arabic simple"><li>Pull in upstream changes related to testing, the RPC interface, as well as others. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2099">#2099</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2100">#2100</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2101">#2101</a>)</li>
|
||||
<li>Keep a record of alerts sent to mainnet. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2093">#2093</a>)</li>
|
||||
<li>Pause mining during joinsplit creation. (<a class="reference external" href="https://github.com/zcash/zcash/pull/1932">#1932</a>)</li>
|
||||
<li>Fix bug in testnet and update Founder’s Reward addresses. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2114">#2114</a>)</li>
|
||||
<li>Large shielded transactions using the default fee are no longer treated as "free" transactions. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2141">#2141</a>)</li>
|
||||
<li>Improve auto-generated manpages. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2124">#2124</a>)</li>
|
||||
<li>Add checkpoint on testnet and mainnet. (<a class="reference external" href="https://github.com/zcash/zcash/pull/2128">#2128</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2126">#2126</a>)</li>
|
||||
</ol><p>We're encouraging all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.</p>
|
||||
<p>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.</p>
|
||||
<p>For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/51">1.0.7</a> GitHub milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Last year, <a class="reference external" href="http://www.r3cev.com/">R3</a> commissioned us to co-author (along with Danny Yang, founder of blockchain analytics company <a class="reference external" href="https://www.blockseer.com/">Blockseer</a>) 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, <a class="reference external" href="https://www.r3cev.com/blog/2017/3/8/survey-of-confidentiality-and-privacy-preserving-technologies-for-blockchains">R3 have published it on their website</a>.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="https://www.corda.net/#intro">R3's Corda</a> and <a class="reference external" href="https://www.jpmorgan.com/Quorum">JP Morgan's Quorum</a>, and <a class="reference external" href="http://www.coindesk.com/chain-previews-new-blockchain-privacy-tech-confidential-assets/">Chain has previewed their "Confidential Assets" technology</a>. We expect to see further developments and progress in this space throughout 2017.</p>
|
||||
<p>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.</p>
|
||||
<p><a class="reference external" href="https://z.cash/static/R3_Confidentiality_and_Privacy_Report.pdf">Download the report in PDF format</a>.</p>
|
||||
|
|
@ -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 <a class="reference external" href="/zcash-private-transactions/">shielded transactions</a>. As we mentioned in our <a class="reference external" href="/the-near-future-of-zcash/">near future priorities</a> 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.
|
||||
<div class="figure align-center"><img class="center-image" src="https://z.cash/images/curve-graph-sm.png" alt="The BLS12-381 curve." /></div>
|
||||
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.
|
||||
<h2>Barreto-Naehrig curves</h2>
|
||||
Barreto-Naehrig (BN) curves are a class of <a href="/pairing-cryptography-in-rust/">pairing-friendly</a> 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, <a href="https://ellipticnews.wordpress.com/2016/05/02/kim-barbulescu-variant-of-the-number-field-sieve-to-compute-discrete-logarithms-in-finite-fields/">Kim and Barbulescu presented</a> a variant of the Number Field Sieve algorithm which reduced a conservative <a href="#id2">[1]</a> estimate of the security level to around 110 bits based on a <a href="http://eprint.iacr.org/2016/1102.pdf">recent paper</a>.
|
||||
|
||||
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.
|
||||
<h2>Barreto-Lynn-Scott curves</h2>
|
||||
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.
|
||||
<h2>BLS12-381</h2>
|
||||
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 <a href="https://eprint.iacr.org/2012/232.pdf">common</a>, 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 <strong>BLS12-381</strong> as :math:`q \approx 2^{381}`.
|
||||
|
||||
<div class="new-curve-blog line-block">
|
||||
<div class="line">u = -0xd201000000010000</div>
|
||||
<div class="line">k = 12</div>
|
||||
<div class="line">q = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab</div>
|
||||
<div class="line">r = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001</div>
|
||||
<div class="line">E(Fq) := y^2 = x^3 + 4</div>
|
||||
<div class="line">Fq2 := Fq[i]/(x^2 + 1)</div>
|
||||
<div class="line">E'(Fq2) := y^2 = x^3 + 4(i + 1)</div>
|
||||
</div>
|
||||
|
||||
<h2>Rust language implementation</h2>
|
||||
I have begun working on an implementation of the construction in Rust as part of my <a class="reference external" href="https://github.com/ebfull/pairing">pairing</a> 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.
|
||||
|
||||
<table id="id2" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="https://z.cash/blog/new-snark-curve.html#id1">[1]</a></td>
|
||||
<td>Menezes, Sarkar and Singh (<a class="reference external" href="http://eprint.iacr.org/2016/1102.pdf">http://eprint.iacr.org/2016/1102.pdf</a>) 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.)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<a class="reference external" href="/snark-explain/"><< Part I</a>
|
||||
|
||||
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 <a class="reference external" href="/snark-explain/">Part I</a> 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.
|
||||
<h2>Polynomials and linear combinations</h2>
|
||||
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 <em>evaluate</em> :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 <em>linear combination</em> 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.`
|
||||
<h2>Blind evaluation of a polynomial</h2>
|
||||
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:
|
||||
<ul>
|
||||
<li>Alice sends :math:`P` to Bob, and he computes :math:`E(P(s))` by himself.</li>
|
||||
<li>Bob sends :math:`s` to Alice; she computes :math:`E(P(s))` and sends it to Bob.</li>
|
||||
</ul>
|
||||
However, in the <em>blind evaluation problem</em> 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 <a class="footnote-reference" href="#id4" id="id2">[1]</a>.
|
||||
|
||||
Using HH, we can perform blind evaluation as follows.
|
||||
<ol>
|
||||
<li>Bob sends to Alice the hidings :math:`E(1),E(s),\ldots,E(s^d).`</li>
|
||||
<li>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.)`</li>
|
||||
</ol>
|
||||
Note that, as only hidings were sent, neither Alice learned :math:`s` <a class="footnote-reference" href="#id5" id="id3">[2]</a>, nor Bob learned :math:`P`.
|
||||
<h2>Why is this useful?</h2>
|
||||
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".
|
||||
<table id="id4" class="docutils footnote" frame="void" rules="none">
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id2">[1]</a></td>
|
||||
<td>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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="id5" class="docutils footnote" frame="void" rules="none"><colgroup> <col class="label" /> <col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id3">[2]</a></td>
|
||||
<td>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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<a class="reference external" href="/snark-explain3/">Part III >></a>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p><a class="reference external" href="/helloworld/">Our Mission</a> is to give every person in the world economic freedom — to do for cooperation what the Internet did for communication.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>Today we are announcing the formation of <a class="reference external" href="http://z.cash.foundation/">The Zcash Foundation</a>, which I hope will fill this role.</p>
|
||||
<p>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.</p>
|
||||
<p>The Zcash Foundation is funded by the blockchain itself. A portion of the Zcash Founders' Reward <a class="reference external" href="/funding/">¹</a>, <a class="reference external" href="/continued-funding-and-transparency/">²</a> 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!</p>
|
||||
<p>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!</p>
|
||||
<p>The initial <a class="reference external" href="http://z.cash.foundation/about/">Board of Directors</a> 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.</p>
|
||||
<p>Please read the <a class="reference external" href="http://z.cash.foundation/blog/hello-world/">Foundation's Hello World</a> blog post to see their initial plans and how you can get involved and help make Zcash live up to its potential!</p>
|
||||
|
|
@ -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 <a class="reference external" href="http://leastauthority.com/blog/least_authority_performs_incentive_analysis_for_ethereum/">security audit of Ethereum</a> and several other successful security audits (<a class="reference external" href="http://leastauthority.com/blog/least_authority_performs_security_audit_for_cryptocat/">CryptoCat</a>, <a class="reference external" href="http://leastauthority.com/blog/least_authority_performs_security_audit_for_globaleaks/">GlobalLeaks</a>, <a class="reference external" href="http://leastauthority.com/blog/least_authority_performs_security_audit_for_spideroak/">SpiderOak</a>, and Ooni). Least Authority also developed the advanced cryptographically-protected, decentralized file store, <a class="reference external" href="https://tahoe-lafs.org">Tahoe-LAFS</a>.
|
||||
|
||||
When we formed a <a class="reference external" href="/helloworld/">new company to launch Zcash</a> (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 class="reference external" href="https://LeastAuthority.com">a new web site</a>. 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 <a class="reference external" href="https://s4.leastauthority.com/s4-subscription-form">sign up</a> 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 <a class="reference external" href="https://bitcointalk.org/index.php?topic=890.0">Satoshi Nakamoto replied</a>.)
|
||||
|
|
@ -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.
|
||||
<div id="zcashs-layered-architecture" class="section">
|
||||
<h2>Zcash’s Layered Architecture</h2>
|
||||
On the Bitcoin blockchain, creating a valid transaction involves proving three things:
|
||||
<ol class="arabic simple">
|
||||
<li>that the coins have not been spent previously,</li>
|
||||
<li>that the Sender is authorised to transfer “ownership” of the coins in question, and</li>
|
||||
<li>that the transaction’s inputs equal its outputs.</li>
|
||||
</ol>
|
||||
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.
|
||||
<div class="figure align-center"><img class="zsl" src="http://blog.z.cash/wp-content/uploads/2017/03/bitcoin-transaction.png" alt="A high-level skeleton diagram of a Bitcoin transaction" /></div>
|
||||
Zcash uses zero-knowledge proofs (specifically, <a class="reference external" href="/snark-explain/">zk-SNARKs</a>) 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.
|
||||
<div class="figure align-center"><img class="zsl" src="http://blog.z.cash/wp-content/uploads/2017/03/zkp-transaction.png" alt="A high-level skeleton diagram of a zero-knowledge proof transaction" /></div>
|
||||
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.
|
||||
<div class="figure align-center"><img class="zsl" src="http://blog.z.cash/wp-content/uploads/2017/03/zcash-transaction.png" alt="A high-level skeleton diagram of a Zcash transaction" /></div>
|
||||
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 <a class="reference external" href="https://en.wikipedia.org/wiki/Grow_the_Pie_(phrase)">grow the pie</a> through collaboration instead of competing for as big a slice as possible.
|
||||
|
||||
</div>
|
||||
<div id="improving-zcashs-and-zsls-functionality" class="section">
|
||||
<h2>Improving Zcash’s (and ZSL’s) functionality</h2>
|
||||
Zcash has already set the gold standard for privacy but we’re not resting on our laurels. We recently announced our <a class="reference external" href="/the-near-future-of-zcash/">development priorities for 2017</a>, 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 <a class="reference external" href="https://github.com/zcash/zcash/issues/2036">Payment Disclosure</a> 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 <a class="reference external" href="https://github.com/zcash/zcash/issues/830">User-Issued Tokens</a> 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 <a class="reference external" href="https://github.com/zcash/zcash/issues/2098">cross-chain atomic transactions (XCAT)</a>, 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 <a class="reference external" href="https://speed.z.cash/comparison/?exe=1%2B178%2C1%2B188%2C1%2B194%2C1%2B208%2C1%2B226%2C1%2B243%2C1%2B257&ben=2&env=1&hor=false&bas=none&chart=normal+bars">incremental performance improvements</a> over time, we’re also conducting research into how to improve the <a class="reference external" href="/new-snark-curve/">core cryptographic circuit</a>, which could enable significant efficiency improvements, unlocking the use of ZSL for use cases that require low latency and high-throughput.
|
||||
|
||||
In the meantime, <a class="reference external" href="https://github.com/zcash/zips/issues/104">Payment Offloading</a> 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.
|
||||
|
||||
</div>
|
||||
<div id="looking-to-the-future" class="section">
|
||||
<h2>Looking to the Future</h2>
|
||||
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 <a class="reference external" href="http://z.cash.foundation/">Zcash Foundation</a> 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.
|
||||
|
||||
<em>Edit: February 5th, 2018
|
||||
In October 2017, Zerocoin Electric Coin Company announced integration of <a href="/jpm-quorum-integration/">Zero-knowledge Security Technology on J.P. Morgan’s Quorum</a></em>
|
||||
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>Summary of the changes in this release:</p>
|
||||
<ol class="arabic simple"><li>The <cite>z_importkey</cite> RPC call now lets the user specify the number of blocks to rescan when importing keys (<a class="reference external" href="https://github.com/zcash/zcash/pull/2052">#2052</a>).</li>
|
||||
<li>The <cite>getblock</cite> RPC call now returns an <cite>anchor</cite> field (the anchor is the Merkle tree root of the note commitment tree) (<a class="reference external" href="https://github.com/zcash/zcash/pull/2168">#2168</a>) and also lets the user specify a block by height, as well as block hash (<a class="reference external" href="https://github.com/zcash/zcash/pull/2187">#2187</a>).</li>
|
||||
<li>Backported a libevent-based HTTP server to improve JSON-RPC handling (<a class="reference external" href="https://github.com/zcash/zcash/pull/2176">#2176</a>).</li>
|
||||
<li>Backported Tor ephemeral hidden service support, making it easier for users to run Zcash over Tor (<a class="reference external" href="https://github.com/zcash/zcash/pull/2177">#2177</a>).</li>
|
||||
<li>Backported improvements to the <cite>getmempoolinfo</cite> RPC call (<a class="reference external" href="https://github.com/zcash/zcash/pull/2175">#2175</a>).</li>
|
||||
<li>Cleaned up the source tree by removing 181,000 lines of redundant QT code (<a class="reference external" href="https://github.com/zcash/zcash/pull/1636">#1636</a>).</li>
|
||||
<li>Introduced the Rust language to the Zcash build system (<a class="reference external" href="https://github.com/zcash/zcash/pull/2183">#2183</a>), in preparation for writing parts of future Zcash versions in Rust.</li>
|
||||
<li>Updated the metrics screen (<a class="reference external" href="https://github.com/zcash/zcash/pull/2198">#2198</a>) and minor UI tweak (<a class="reference external" href="https://github.com/zcash/zcash/pull/2203">#2203</a>).</li>
|
||||
<li>Updated documentation (<a class="reference external" href="https://github.com/zcash/zcash/pull/2157">#2157</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2161">#2161</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2184">#2184</a>).</li>
|
||||
</ol><p>We're encouraging all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.</p>
|
||||
<p>For a more complete list of changes, see our <a class="reference external" href="https://github.com/zcash/zcash/milestone/52">1.0.8</a> GitHub milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p><a class="reference external" href="/snark-explain2/"><< Part II</a></p>
|
||||
|
||||
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 <em>able</em> 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 <em>Knowledge of Coefficient (KC) Test</em>.
|
||||
|
||||
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`.
|
||||
|
||||
<h2>The KC Test</h2>
|
||||
|
||||
For :math:`\alpha\in\mathbb{F}_p^*` <a class="footnote-reference" href="#id4" id="id1">[1]</a>, 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.
|
||||
<ol>
|
||||
<li>Bob chooses random :math:`\alpha\in\mathbb{F}_p^*` and :math:`a\in G.` He computes :math:`b=\alpha\cdot a.`</li>
|
||||
<li>He sends to Alice the "challenge" pair :math:`(a,b).` Note that :math:`(a,b)` is an :math:`\alpha`-pair.</li>
|
||||
<li>Alice must now respond with a <em>different</em> pair :math:`(a',b')` that is also an :math:`\alpha`-pair.</li>
|
||||
<li>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'.)`</li>
|
||||
</ol>
|
||||
|
||||
Now, let's think how Alice could successfully respond to the challenge. Let's assume for a second that she <em>knew</em> :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 <em>knows the ratio</em> 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 <a class="footnote-reference" href="#id5" id="id2">[2]</a> (KCA) states that <em>this is always the case</em>, namely:
|
||||
|
||||
<em>KCA: If Alice returns a valid response</em> :math:`(a',b')` <em>to Bob's challenge</em> :math:`(a,b)` <em>with non-negligible probability over Bob's choices of</em> :math:`a,\alpha`, <em>then she knows</em> :math:`\gamma` <em>such that</em> :math:`a'=\gamma\cdot a.`
|
||||
|
||||
The KC Test and Assumption will be important tools in Part IV.
|
||||
|
||||
|
||||
<h2>What does "Alice knows" mean exactly</h2>
|
||||
|
||||
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 <em>Alice's Extractor</em>. 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.` <a class="footnote-reference" href="#id6" id="id3">[3]</a>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id4" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id1">[1]</a></td>
|
||||
<td>: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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id5" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id2">[2]</a></td><td>This is typically called the Knowledge of Exponent Assumption in the literature, as traditionally it was used for groups written multiplicatively.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id6" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id3">[3]</a></td>
|
||||
<td>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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p><a class="reference external" href="https://z.cash/blog/snark-explain4.html">Part IV >></a></p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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.</p>
|
||||
<p>HTLCs are a fundamental tool in the Lightning network, in zero-knowledge contingent payments (ZKCP) like the one we performed <a class="reference external" href="/science-roundup">last year</a> at FC'16, and in our XCAT project <a class="reference external" href="/the-near-future-of-zcash">that we announced last month</a>. One of the first steps forward is the inclusion of general HTLC functionality in the Bitcoin Core wallet.</p>
|
||||
<p>This week, our submitted BIP199 draft was merged. We also have a work-in-progress <a class="reference external" href="https://github.com/bitcoin/bitcoin/pull/7601">reference implementation</a> 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.</p>
|
||||
<p>Check out the current BIP text here: <a class="reference external" href="https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki</a></p>
|
||||
<div class="section" id="overview-of-htlc">
|
||||
<h2>Overview of HTLC</h2>
|
||||
<p>HTLC scripts look like this:</p>
|
||||
<table class="codehilitetable"><tr><td class="linenos"><div class="linenodiv"><pre>1
|
||||
2
|
||||
3
|
||||
4
|
||||
5
|
||||
6
|
||||
7</pre></div></td><td class="code"><div class="codehilite"><pre><span/>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
|
||||
</pre></div>
|
||||
</td></tr></table><p>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.</p>
|
||||
<p>It's easy to see how cross-chain atomic swaps can be built with this mechanism:</p>
|
||||
<ol class="arabic simple"><li>Alice randomly samples K, the key. She hashes it, producing X.</li>
|
||||
<li>Alice creates a transaction paying Bob 1 BTC, with a timeout of 1 day, to produce the preimage of X.</li>
|
||||
<li>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.</li>
|
||||
<li>Once Bob's transaction appears in the Zcash blockchain, Alice can obtain her ZEC. The script forces her to reveal K.</li>
|
||||
<li>Once Bob sees Alice's reveal of K, he can obtain his BTC.</li>
|
||||
</ol><p>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.</p>
|
||||
<p>Having contracts like HTLCs standardized and included in Bitcoin and Zcash will help both of our communities build exciting technologies like decentralized exchanges.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>The Zcash blockchain has completed the distribution of <a class="reference external" href="https://explorer.zcha.in/statistics/timeseries?hashrate=false&trnstx=false&shldtx=false">the first 1,000,000 Zcash coins</a>. Only 20,000,000 more to go! Now's a good time for your irregularly scheduled “State of the Network” update.</p>
|
||||
<hr class="docutils"/><p>It has been five months since <a class="reference external" href="/zcash-begins">the beginning of the blockchain</a>. <a class="reference external" href="https://explorer.zcha.in/network">The network</a> 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 <a class="reference external" href="https://z.cash/support/security/privacy-security-recommendations.html">known issues</a>). If you are aware of any security or privacy problems, please <a class="reference external" href="https://z.cash/contact.html">contact us</a>. Also keep an eye on the <a class="reference external" href="https://z.cash/support/security/index.html">Zcash Security Information</a> page.</p>
|
||||
<hr class="docutils"/><p>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 <a class="reference external" href="/audit-results">independent security audits</a> 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.</p>
|
||||
<hr class="docutils"/><p>We have delivered — as planned — a steady sequence of <a class="reference external" href="/tag/releases/">stable software updates</a> 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.</p>
|
||||
<hr class="docutils"/><p>We've announced our priorities for new improvements, <a class="reference external" href="/the-near-future-of-zcash">“The Sapling Roadmap”</a>. I'm excited about the improvements that we're working on. If you have uses for any of these upcoming new features, please <a class="reference external" href="https://z.cash/contact.html">contact us</a> so that we can make sure the design and the interface fit your needs.</p>
|
||||
<hr class="docutils"/><p>The <a class="reference external" href="/announcing-the-zcash-foundation">Zcash Foundation was announced</a>, 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.</p>
|
||||
<p>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.</p>
|
||||
<hr class="docutils"/><p>There are about 90,000 transactions — 23,000 of which involve shielded addresses — <a class="reference external" href="https://explorer.zcha.in/statistics/usage">sent over the Zcash network</a> 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 <a class="reference external" href="https://www.zcashcommunity.com/wallets/">Zcash wallet</a> and buying some Zcash from <a class="reference external" href="https://www.zcashcommunity.com/markets/">a market</a>. Then get a friend to install a Zcash wallet and send them some of your Zcash. ☺</p>
|
||||
<hr class="docutils"/><p>Stay tuned! There is going to be a lot of good news coming. Watch this blog, the <a class="reference external" href="https://forum.z.cash">community forum</a>, the <a class="reference external" href="https://twitter.com/ZcashCo">company twitter</a>, and (for programmers) <a class="reference external" href="https://github.com/zcash/zcash/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc">the github repo</a>.</p>
|
||||
<p>Remember, we developers started the Zcash project, but its destiny is in your hands.</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<a class="reference external" href="https://github.com/ebfull/bellman">Bellman</a> is a Rust-language library for building zk-SNARKs — small, cheap-to-verify <a class="reference external" href="https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/">zero-knowledge proofs</a> 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, <a class="reference external" href="/the-near-future-of-zcash/">Sapling</a>.
|
||||
|
||||
Bellman contains an implementation of the <strong>BLS12-381</strong> elliptic curve construction that we <a class="reference external" href="/new-snark-curve/">described</a> 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 <a class="reference external" href="https://eprint.iacr.org/2016/260">new zk-SNARK proving system</a> 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.
|
||||
|
||||
<h2>Overview of zk-SNARKs</h2>
|
||||
If you're interested in how zk-SNARKs work internally, Ariel Gabizon has been writing a <a class="reference external" href="/snark-explain/">series of blog posts</a> 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 <em>preprocessing</em>. 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 <a class="reference external" href="https://z.cash/technology/paramgen.html">here</a>. 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.
|
||||
|
||||
<h2>Overview of Bellman</h2>
|
||||
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 <a class="reference external" href="https://crates.io/crates/bellman">bellman crate from crates.io</a>.
|
||||
|
||||
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:
|
||||
<table class="codehilitetable">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="linenos">
|
||||
<div class="linenodiv">
|
||||
<pre> 1
|
||||
2
|
||||
3
|
||||
4
|
||||
5
|
||||
6
|
||||
7
|
||||
8
|
||||
9
|
||||
10
|
||||
11
|
||||
12
|
||||
13</pre>
|
||||
</div></td>
|
||||
<td class="code">
|
||||
<div class="codehilite">
|
||||
<pre><span class="k">pub</span> <span class="k">trait</span> <span class="n">ConstraintSystem</span><span class="o"><</span><span class="n">E</span>: <span class="nc">Engine</span><span class="o">></span> <span class="p">{</span>
|
||||
<span class="sd">/// Allocate a private variable in the constraint system, setting it to</span>
|
||||
<span class="sd">/// the provided value.</span>
|
||||
<span class="k">fn</span> <span class="nf">alloc</span><span class="p">(</span><span class="o">&</span><span class="k">mut</span> <span class="bp">self</span><span class="p">,</span> <span class="n">value</span>: <span class="nc">E</span>::<span class="n">Fr</span><span class="p">)</span> -> <span class="nc">Variable</span><span class="p">;</span>
|
||||
|
||||
<span class="sd">/// Enforce that `A` * `B` = `C`.</span>
|
||||
<span class="k">fn</span> <span class="nf">enforce</span><span class="p">(</span>
|
||||
<span class="o">&</span><span class="k">mut</span> <span class="bp">self</span><span class="p">,</span>
|
||||
<span class="n">a</span>: <span class="nc">LinearCombination</span><span class="o"><</span><span class="n">E</span><span class="o">></span><span class="p">,</span>
|
||||
<span class="n">b</span>: <span class="nc">LinearCombination</span><span class="o"><</span><span class="n">E</span><span class="o">></span><span class="p">,</span>
|
||||
<span class="n">c</span>: <span class="nc">LinearCombination</span><span class="o"><</span><span class="n">E</span><span class="o">></span>
|
||||
<span class="p">);</span>
|
||||
<span class="p">}</span>
|
||||
</pre>
|
||||
</div></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
There are two important design decisions here:
|
||||
<ol class="arabic simple">
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
</ol>
|
||||
As an example of a kind of gadget implementation, here's how a boolean constrained variable could be implemented, along with XOR:
|
||||
<table class="codehilitetable">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="linenos">
|
||||
<div class="linenodiv">
|
||||
<pre> 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</pre>
|
||||
</div></td>
|
||||
<td class="code">
|
||||
<div class="codehilite">
|
||||
<pre><span class="cp">#[derive(Clone)]</span>
|
||||
<span class="k">pub</span> <span class="k">struct</span> <span class="nc">Bit</span> <span class="p">{</span>
|
||||
<span class="n">var</span>: <span class="nc">Variable</span><span class="p">,</span>
|
||||
<span class="n">value</span>: <span class="kt">bool</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="k">impl</span> <span class="n">Bit</span> <span class="p">{</span>
|
||||
<span class="k">pub</span> <span class="k">fn</span> <span class="nf">alloc</span><span class="o"><</span><span class="n">E</span><span class="p">,</span> <span class="n">CS</span><span class="o">></span><span class="p">(</span><span class="n">e</span>: <span class="kp">&</span><span class="nc">E</span><span class="p">,</span>
|
||||
<span class="n">cs</span>: <span class="kp">&</span><span class="nc">mut</span> <span class="n">CS</span><span class="p">,</span>
|
||||
<span class="n">value</span>: <span class="kt">bool</span><span class="p">)</span> -> <span class="nc">Bit</span>
|
||||
<span class="k">where</span> <span class="n">E</span>: <span class="nc">Engine</span><span class="p">,</span> <span class="n">CS</span>: <span class="nc">ConstraintSystem</span><span class="o"><</span><span class="n">E</span><span class="o">></span> <span class="o">+</span> <span class="o">?</span><span class="nb">Sized</span>
|
||||
<span class="p">{</span>
|
||||
<span class="c1">// Allocate the variable</span>
|
||||
<span class="kd">let</span> <span class="n">var</span> <span class="o">=</span> <span class="n">cs</span><span class="p">.</span><span class="n">alloc</span><span class="p">(</span>
|
||||
<span class="k">if</span> <span class="n">value</span> <span class="p">{</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">one</span><span class="p">(</span><span class="n">e</span><span class="p">)</span> <span class="p">}</span> <span class="k">else</span> <span class="p">{</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">zero</span><span class="p">()</span> <span class="p">}</span>
|
||||
<span class="p">);</span>
|
||||
|
||||
<span class="c1">// Enforce (1 - var) * var = 0, which requires</span>
|
||||
<span class="c1">// var to be either 0 or 1</span>
|
||||
<span class="n">cs</span><span class="p">.</span><span class="n">enforce</span><span class="p">(</span>
|
||||
<span class="n">LinearCombination</span>::<span class="n">one</span><span class="p">(</span><span class="n">e</span><span class="p">)</span> <span class="o">-</span> <span class="n">var</span><span class="p">,</span>
|
||||
<span class="n">LinearCombination</span>::<span class="n">zero</span><span class="p">(</span><span class="n">e</span><span class="p">)</span> <span class="o">+</span> <span class="n">var</span><span class="p">,</span>
|
||||
<span class="n">LinearCombination</span>::<span class="n">zero</span><span class="p">(</span><span class="n">e</span><span class="p">)</span>
|
||||
<span class="p">);</span>
|
||||
|
||||
<span class="n">Bit</span> <span class="p">{</span>
|
||||
<span class="n">var</span>: <span class="nc">var</span><span class="p">,</span>
|
||||
<span class="n">value</span>: <span class="nc">value</span>
|
||||
<span class="p">}</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="k">pub</span> <span class="k">fn</span> <span class="nf">xor</span><span class="o"><</span><span class="n">E</span><span class="p">,</span> <span class="n">CS</span><span class="o">></span><span class="p">(</span><span class="o">&</span><span class="bp">self</span><span class="p">,</span>
|
||||
<span class="n">e</span>: <span class="kp">&</span><span class="nc">E</span><span class="p">,</span>
|
||||
<span class="n">cs</span>: <span class="kp">&</span><span class="nc">mut</span> <span class="n">CS</span><span class="p">,</span>
|
||||
<span class="n">other</span>: <span class="kp">&</span><span class="nc">Bit</span><span class="p">)</span> -> <span class="nc">Bit</span>
|
||||
<span class="k">where</span> <span class="n">E</span>: <span class="nc">Engine</span><span class="p">,</span> <span class="n">CS</span>: <span class="nc">ConstraintSystem</span><span class="o"><</span><span class="n">E</span><span class="o">></span>
|
||||
<span class="p">{</span>
|
||||
<span class="kd">let</span> <span class="n">new_value</span> <span class="o">=</span> <span class="bp">self</span><span class="p">.</span><span class="n">value</span> <span class="o">^</span> <span class="n">other</span><span class="p">.</span><span class="n">value</span><span class="p">;</span>
|
||||
<span class="kd">let</span> <span class="n">new_var</span> <span class="o">=</span> <span class="n">cs</span><span class="p">.</span><span class="n">alloc</span><span class="p">(</span>
|
||||
<span class="k">if</span> <span class="n">new_value</span> <span class="p">{</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">one</span><span class="p">(</span><span class="n">e</span><span class="p">)</span> <span class="p">}</span> <span class="k">else</span> <span class="p">{</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">zero</span><span class="p">()</span> <span class="p">}</span>
|
||||
<span class="p">);</span>
|
||||
|
||||
<span class="c1">// 2a * b = a + b - c</span>
|
||||
<span class="n">cs</span><span class="p">.</span><span class="n">enforce</span><span class="p">(</span>
|
||||
<span class="n">LinearCombination</span>::<span class="n">zero</span><span class="p">(</span><span class="n">e</span><span class="p">)</span> <span class="o">+</span> <span class="bp">self</span><span class="p">.</span><span class="n">var</span> <span class="o">+</span> <span class="bp">self</span><span class="p">.</span><span class="n">var</span><span class="p">,</span>
|
||||
<span class="n">LinearCombination</span>::<span class="n">zero</span><span class="p">(</span><span class="n">e</span><span class="p">)</span> <span class="o">+</span> <span class="n">other</span><span class="p">.</span><span class="n">var</span><span class="p">,</span>
|
||||
<span class="n">LinearCombination</span>::<span class="n">zero</span><span class="p">(</span><span class="n">e</span><span class="p">)</span> <span class="o">+</span> <span class="bp">self</span><span class="p">.</span><span class="n">var</span> <span class="o">+</span> <span class="n">other</span><span class="p">.</span><span class="n">var</span> <span class="o">-</span> <span class="n">new_var</span>
|
||||
<span class="p">);</span>
|
||||
|
||||
<span class="n">Bit</span> <span class="p">{</span>
|
||||
<span class="n">var</span>: <span class="nc">new_var</span><span class="p">,</span>
|
||||
<span class="n">value</span>: <span class="nc">new_value</span>
|
||||
<span class="p">}</span>
|
||||
<span class="p">}</span>
|
||||
<span class="p">}</span>
|
||||
</pre>
|
||||
</div></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
Building a circuit is a matter of implementing the <cite>Circuit</cite> and <cite>Input</cite> traits:
|
||||
<table class="codehilitetable">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="linenos">
|
||||
<div class="linenodiv">
|
||||
<pre> 1
|
||||
2
|
||||
3
|
||||
4
|
||||
5
|
||||
6
|
||||
7
|
||||
8
|
||||
9
|
||||
10
|
||||
11</pre>
|
||||
</div></td>
|
||||
<td class="code">
|
||||
<div class="codehilite">
|
||||
<pre><span class="k">pub</span> <span class="k">trait</span> <span class="n">Circuit</span><span class="o"><</span><span class="n">E</span>: <span class="nc">Engine</span><span class="o">></span> <span class="p">{</span>
|
||||
<span class="k">type</span> <span class="nc">InputMap</span>: <span class="nc">Input</span><span class="o"><</span><span class="n">E</span><span class="o">></span><span class="p">;</span>
|
||||
<span class="k">fn</span> <span class="nf">synthesize</span><span class="o"><</span><span class="n">CS</span>: <span class="nc">ConstraintSystem</span><span class="o"><</span><span class="n">E</span><span class="o">>></span><span class="p">(</span><span class="bp">self</span><span class="p">,</span>
|
||||
<span class="n">engine</span>: <span class="kp">&</span><span class="nc">E</span><span class="p">,</span>
|
||||
<span class="n">cs</span>: <span class="kp">&</span><span class="nc">mut</span> <span class="n">CS</span><span class="p">)</span>
|
||||
-> <span class="nc">Self</span>::<span class="n">InputMap</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="k">pub</span> <span class="k">trait</span> <span class="n">Input</span><span class="o"><</span><span class="n">E</span>: <span class="nc">Engine</span><span class="o">></span> <span class="p">{</span>
|
||||
<span class="k">fn</span> <span class="nf">synthesize</span><span class="o"><</span><span class="n">CS</span>: <span class="nc">PublicConstraintSystem</span><span class="o"><</span><span class="n">E</span><span class="o">>></span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">engine</span>: <span class="kp">&</span><span class="nc">E</span><span class="p">,</span> <span class="n">cs</span>: <span class="kp">&</span><span class="nc">mut</span> <span class="n">CS</span><span class="p">);</span>
|
||||
<span class="p">}</span>
|
||||
</pre>
|
||||
</div></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
This design splits up circuits into a <cite>Circuit</cite> implementation, which provers instantiate to construct proofs, and a <cite>Input</cite> 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 <cite>Circuit</cite> and <cite>Input</cite>, we can use the functions provided in the <cite>groth16</cite> module: create a keypair (with some randomly selected trapdoors), construct a proof, and perform verifications:
|
||||
<table class="codehilitetable">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="linenos">
|
||||
<div class="linenodiv">
|
||||
<pre> 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</pre>
|
||||
</div></td>
|
||||
<td class="code">
|
||||
<div class="codehilite">
|
||||
<pre><span class="c1">// Create a proving key and verifying key</span>
|
||||
<span class="kd">let</span> <span class="p">(</span><span class="n">pk</span><span class="p">,</span> <span class="n">vk</span><span class="p">)</span> <span class="o">=</span> <span class="p">{</span>
|
||||
<span class="kd">let</span> <span class="n">tau</span> <span class="o">=</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">random</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">rng</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="n">alpha</span> <span class="o">=</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">random</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">rng</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="n">beta</span> <span class="o">=</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">random</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">rng</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="n">gamma</span> <span class="o">=</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">random</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">rng</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="n">delta</span> <span class="o">=</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">random</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">rng</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="n">c</span> <span class="o">=</span> <span class="n">DummyCircuit</span><span class="p">;</span>
|
||||
|
||||
<span class="n">groth16</span>::<span class="n">keypair</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">c</span><span class="p">,</span> <span class="o">&</span><span class="n">tau</span><span class="p">,</span> <span class="o">&</span><span class="n">alpha</span><span class="p">,</span> <span class="o">&</span><span class="n">beta</span><span class="p">,</span> <span class="o">&</span><span class="n">gamma</span><span class="p">,</span> <span class="o">&</span><span class="n">delta</span><span class="p">)</span>
|
||||
<span class="p">};</span>
|
||||
|
||||
<span class="c1">// Construct a proof</span>
|
||||
<span class="kd">let</span> <span class="n">proof</span> <span class="o">=</span> <span class="p">{</span>
|
||||
<span class="kd">let</span> <span class="n">r</span> <span class="o">=</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">random</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">rng</span><span class="p">);</span>
|
||||
<span class="kd">let</span> <span class="n">s</span> <span class="o">=</span> <span class="n">E</span>::<span class="n">Fr</span>::<span class="n">random</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">rng</span><span class="p">);</span>
|
||||
|
||||
<span class="kd">let</span> <span class="n">c</span> <span class="o">=</span> <span class="n">DummyCircuit</span><span class="p">;</span>
|
||||
|
||||
<span class="n">groth16</span>::<span class="n">prove</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="n">c</span><span class="p">,</span> <span class="o">&</span><span class="n">r</span><span class="p">,</span> <span class="o">&</span><span class="n">s</span><span class="p">,</span> <span class="o">&</span><span class="n">pk</span><span class="p">).</span><span class="n">unwrap</span><span class="p">()</span>
|
||||
<span class="p">};</span>
|
||||
|
||||
<span class="c1">// Prepare the verifying key</span>
|
||||
<span class="kd">let</span> <span class="n">pvk</span> <span class="o">=</span> <span class="n">groth16</span>::<span class="n">prepare_verifying_key</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="o">&</span><span class="n">vk</span><span class="p">);</span>
|
||||
|
||||
<span class="c1">// Verify proof</span>
|
||||
<span class="n">assert</span><span class="o">!</span><span class="p">(</span><span class="n">groth16</span>::<span class="n">verify</span><span class="p">(</span><span class="n">e</span><span class="p">,</span> <span class="o">|</span><span class="n">cs</span><span class="o">|</span> <span class="p">{</span>
|
||||
<span class="n">DummyInput</span>
|
||||
<span class="p">},</span> <span class="o">&</span><span class="n">proof</span><span class="p">,</span> <span class="o">&</span><span class="n">pvk</span><span class="p">));</span>
|
||||
</pre>
|
||||
</div></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Future work</h2>
|
||||
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 <a class="reference external" href="https://github.com/zcash/zcash">our project</a>, join our <a class="reference external" href="https://chat.zcashcommunity.com/">community chat</a> or look at some of the various things we’ve written in Rust before, like our <a class="reference external" href="https://github.com/zcash/mpc">multi-party computation ceremony code</a>.
|
||||
|
|
@ -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
|
||||
---
|
||||
<a class="reference external" href="/snark-explain3/"><< Part III</a>
|
||||
|
||||
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 <a href="/snark-explain2/">Part II</a>, 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:
|
||||
|
||||
<ol>
|
||||
<li><strong>Blindness</strong>: Alice will <em>not</em> learn :math:`s` (and Bob will not learn :math:`P`).</li>
|
||||
<li><strong>Verifiability</strong>: 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.</li>
|
||||
</ol>
|
||||
|
||||
This is what we call <em>verifiable</em> 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 <em>without seeing</em> :math:`s`. <a class="footnote-reference" href="#id3" id="id1">[1]</a> 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.
|
||||
|
||||
<h2>An Extended KCA</h2>
|
||||
|
||||
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 <em>she does not know</em> :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 <em>multiple</em> :math:`\alpha`-pairs? Perhaps using several of the received :math:`\alpha`-pairs <em>simultaneously</em> to get a new one?
|
||||
|
||||
The answer is yes: For example, Alice can choose <em>two</em> 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 <em>linear combination</em> 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 <em>d-power Knowledge of Coefficient Assumption</em> (d-KCA) <a class="footnote-reference" href="#id4" id="id2">[2]</a> in :math:`G` is as follows:
|
||||
|
||||
<strong>d-KCA</strong>: <em>Suppose Bob chooses random</em> :math:`\alpha\in\mathbb{F}_p^*` <em>and</em> :math:`s\in\mathbb{F}_p`, <em>and sends to Alice the</em> :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)`. <em>Suppose that Alice then outputs another</em> :math:`\alpha`-pair :math:`(a',b')`. <em>Then, except with negligible probability, Alice knows</em> :math:`c_0,\ldots,c_d\in\mathbb{F}_p` <em>such that</em> :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.
|
||||
|
||||
<h2>The Verifiable Blind Evaluation Protocol</h2>
|
||||
|
||||
Assume that our <a href="/snark-explain1/">HH</a> 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`:
|
||||
|
||||
<ol>
|
||||
<li>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`).</li>
|
||||
<li>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.</li>
|
||||
<li>Bob checks that :math:`b=\alpha \cdot a`, and accepts if and only if this equality holds.</li>
|
||||
</ol>
|
||||
|
||||
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.
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id3" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td>
|
||||
<td>In the fully formal proof, things are somewhat more subtle, as Alice <em>does</em> see some information about :math:`s` before deciding on her :math:`P` - for example, the hidings of :math:`s,\ldots,s^d`.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id4" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id2">[2]</a></td>
|
||||
<td>The d-KCA was introduced in a <a class="reference external" href="http://www0.cs.ucl.ac.uk/staff/J.Groth/ShortNIZK.pdf">paper</a> of Jens Groth.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p><a class="reference external" href="/snark-explain5/">Part V >></a></p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<strong>Full announcement</strong>
|
||||
|
||||
Please see <a class="reference external" href="https://z.cash/security-announcement-2017-04-13.html">the disclosure announcement</a>.
|
||||
|
||||
<hr class="docutils" />
|
||||
|
||||
<strong>Update announcement</strong>
|
||||
|
||||
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.
|
||||
|
||||
<hr class="docutils" />
|
||||
|
||||
<strong>Initial announcement</strong>
|
||||
|
||||
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.
|
||||
|
|
@ -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 <a class="reference external" href="/security-announcement-2017-04-13">security announcement</a>.
|
||||
|
||||
Summary of the changes in this release:
|
||||
<ol class="arabic simple">
|
||||
<li>Fix a Denial of Service vulnerability that could cause nodes receiving a specially crafted transaction into their mempool to crash.</li>
|
||||
<li>Simplify the calculation of priority for shielded transactions.</li>
|
||||
</ol>
|
||||
We <strong>highly</strong> encourage all users and miners to update to this new version as soon as possible. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.
|
||||
|
|
@ -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
|
||||
---
|
||||
<strong>Synopsis:</strong> 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 <a class="reference external" href="https://z.cash/download.html">zcashd release 1.0.8-1</a>.
|
||||
|
||||
There is a <a class="reference external" href="/new-release-1-0-8-1">separate release post</a> 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.
|
||||
|
||||
<strong>Who is at Risk:</strong> Users are at risk who rely on <a class="reference external" href="https://github.com/zcash/zcash/releases">zcashd releases</a> 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.
|
||||
|
||||
<strong>Who is not at Risk:</strong> Users who have upgraded to <cite>zcashd 1.0.8-1</cite>, or rely on a service which has done so are not at risk.
|
||||
|
||||
<strong>How can at-risk users protect themselves?</strong>
|
||||
<ol class="arabic simple">
|
||||
<li>Upgrading to <a class="reference external" href="https://z.cash/download.html">zcashd release 1.0.8-1</a> is the most certain protection.</li>
|
||||
<li>For users of third party services (such as exchanges, wallets, or mining pools), check if the service has announced upgrading to <cite>zcashd 1.0.8-1</cite>.</li>
|
||||
</ol>
|
||||
<strong>How can I tell if an attack is occurring?</strong> 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:
|
||||
<ul>
|
||||
<li>
|
||||
<p class="first">The Zcash developers will issue an in-band alert, causing all <cite>zcashd</cite> nodes to announce the potential attack.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p class="first">ZcashCo will always announce known ongoing attacks in these places:</p>
|
||||
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>a banner on every page of this website,</li>
|
||||
<li>the <a class="reference external" href="https://z.cash/support/security.html">security notifications</a> page of this website,</li>
|
||||
<li>the <a class="reference external" href="https://twitter.com/zcashco">@ZcashCo</a> twitter stream,</li>
|
||||
<li>the <a class="reference external" href="https://chat.zcashcommunity.com/channel/zcash">#zcash community chat room</a>, <em>and</em></li>
|
||||
<li>the <a class="reference external" href="https://forum.z.cash/">Zcash forum</a>.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
</li>
|
||||
<li>
|
||||
<p class="first">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.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<em>Note:</em> The major exchanges, wallet vendors, and miners we are in communication with are already protected against such an attack.
|
||||
|
||||
<strong>Impact:</strong> <em>If</em> an attack transaction is successfully executed then <em>only</em> 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.
|
||||
|
||||
<strong>Technical Background:</strong> 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.
|
||||
|
||||
<strong>Followup Announcements:</strong>
|
||||
<ul class="simple">
|
||||
<li>See the <a class="reference external" href="https://z.cash/support/security.html">security notifications</a> page for further updates on this issue, and any future security issue.</li>
|
||||
<li>Continue to check this blog.</li>
|
||||
</ul>
|
||||
<strong>Acknowledgements</strong>
|
||||
|
||||
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.
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>An exciting update for the Zcash ecosystem comes from the <a class="reference external" href="https://jaxx.io/">Jaxx</a> team. Jaxx were one of the very first wallets to support Zcash, implementing it into their Android and desktop wallets only days after the <a class="reference external" href="/zcash-begins">Zcash launch</a> on October 28th.</p>
|
||||
<p>In their initial statement announcing integration with Zcash, they indicated upcoming support in their iOS wallet and today, Zcash on <a class="reference external" href="https://itunes.apple.com/us/app/jaxx-blockchain-wallet/id1084514516">Jaxx for iOS</a> is live!</p>
|
||||
<p>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."</p>
|
||||
<p>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.</p>
|
||||
<p>Jaxx has additionally confirmed their interest in supporting <a class="reference external" href="/anatomy-of-zcash">shielded addresses</a> 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 <a class="reference external" href="/shielded-ecosystem">ecosystem as a whole will become more private</a>.</p>
|
||||
<p>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.</p>
|
||||
<p>Jaxx for iOS joins a <a class="reference external" href="https://zcashblog.wordpress.com/zcash-gui-wallets/">growing list</a> of third-party GUI applications supporting Zcash. Wallets considering adding Zcash support should reach out to us in <a class="reference external" href="mailto:info@z.cash">email</a> or by joining our <a class="reference external" href="https://chat.zcashcommunity.com">community chat</a>, we'd be happy to help!</p>
|
||||
<p>For more details, see the <a class="reference external" href="http://decentral.ca/zcash-announces-apple-app-store-approval-jaxxs-ios-platform/">full press release from Jaxx</a>.</p>
|
||||
|
|
@ -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 <a class="reference external" href="/the-near-future-of-zcash/">Sapling protocol upgrade</a>. Due to the <a class="reference external" href="/new-release-1-0-8-1/">v1.0.8-1 hotfix release</a> 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!
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Today, we are telling the story of a company in Brazil who started a venture mining Bitcoin. With this revenue the company, <a class="reference external" href="https://coinbr.net/">coinBR</a>, grew their business to build a money application for Brazilians.</p>
|
||||
<p>This application, <a class="reference external" href="https://coinbr.io/">SmartWallet</a>, allows their users to pay utility bills, buy pre-paid credit for phones and even pay taxes.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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."</p>
|
||||
<p>In order to have the ZEC on hand to exchange for their customers, coinBR also added Zcash to their mining portfolio.</p>
|
||||
<p>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!</p>
|
||||
<p>SmartWallet joins a <a class="reference external" href="https://zcashblog.wordpress.com/zcash-gui-wallets/">growing list</a> of third-party GUI applications supporting Zcash for users to choose from. Wallets considering adding Zcash support should reach out to us in <a class="reference external" href="mailto:info@z.cash">email</a> or by joining our <a class="reference external" href="https://chat.zcashcommunity.com">community chat</a>, we'd be happy to help!</p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>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 <a class="reference external" href="/transaction-linkability">becoming linked in the blockchain</a>. 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).</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="Data revealed for a single shielded address" class="center-image" src="http://blog.z.cash/wp-content/uploads/2017/04/CircuitDraw.png"/></div>
|
||||
<div class="section" id="distinct-payment-contexts">
|
||||
<h2>Distinct Payment Contexts</h2>
|
||||
<p>While shielded addresses are encrypted, the scope of the payment address is something to consider.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="reusing-shielded-addresses">
|
||||
<h2>Reusing Shielded Addresses</h2>
|
||||
<p>Note that it <em>is</em> 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 <em>and</em> 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.</p>
|
||||
<p>A great example of this distinction can be seen on the <a class="reference external" href="https://riseup.net/donate">donations page</a> 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!</p>
|
||||
</div>
|
||||
<div class="section" id="one-shielded-address-per-purpose">
|
||||
<h2>One Shielded Address Per Purpose</h2>
|
||||
<p>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.</p>
|
||||
<p>For more user privacy considerations, see the <a class="reference external" href="https://z.cash/support/security/privacy-security-recommendations.html">Privacy & Security Recommendations</a>.</p>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<a class="reference external" href="/snark-explain4"><< Part IV</a>
|
||||
|
||||
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 <a class="reference external" href="https://pdfs.semanticscholar.org/4c3a/78661fd920b4116afd0ad88247bbd00160ce.pdf">groundbreaking work</a> of Lund, Fortnow, Karloff and Nisan.
|
||||
|
||||
In 2013, <a class="reference external" href="https://eprint.iacr.org/2012/215.pdf">another breakthrough work</a> of Gennaro, Gentry, Parno and Raykova defined an extremely useful translation of computations into polynomials called a <em>Quadratic Arithmetic Program</em> (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 <em>arithmetic circuit</em>.
|
||||
|
||||
<h3>Arithmetic circuits</h3>
|
||||
|
||||
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:
|
||||
|
||||
<div class="figure align-center"><img alt="An example of an arithmetic circuit" class="center-image" src="/wp-content/uploads/2017/04/CircuitDrawing.png" style="height: 350px;"/></div>
|
||||
|
||||
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:
|
||||
|
||||
<ul>
|
||||
<li>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.</li>
|
||||
<li>We assume multiplication gates have exactly two input wires, which we call the left wire and right wire.</li>
|
||||
<li>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}`.</li>
|
||||
|
||||
A <em>legal assignment</em> 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.
|
||||
|
||||
|
||||
|
||||
<h3>Reduction to a QAP</h3>
|
||||
|
||||
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 <em>target points</em>. 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 <em>both</em> 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)` <em>is a legal assignment to the circuit if and only if</em> :math:`P` <em>vanishes on all the target points</em>.
|
||||
|
||||
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` <em>divides</em> :math:`P`, i.e. :math:`P=(X-a)\cdot H` for some polynomial :math:`H`.
|
||||
|
||||
Defining the <em>target polynomial</em> :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:
|
||||
|
||||
<em>A Quadratic Arithmetic Program</em> :math:`Q` <em>of degree</em> :math:`d` <em>and size</em> :math:`m` <em>consists of polynomials</em> :math:`L_1,\ldots,L_m`, :math:`R_1,\ldots,R_m`, :math:`O_1,\ldots,O_m` <em>and a target polynomial</em> :math:`T` <em>of degree</em> :math:`d`.
|
||||
|
||||
<em>An assignment</em> :math:`(c_1,\ldots,c_m)` <strong>satisfies</strong> :math:`Q` <em>if, defining</em> :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` <em>and</em> :math:`P:=L\cdot R -O`, <em>we have that</em> :math:`T` <em>divides</em> :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.
|
||||
|
||||
<a class="reference external" href="/snark-explain6">>> Part VI</a>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id1" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label">[1]</td>
|
||||
<td>In this post we tried to give the most concise example of a reduction to QAP; we also recommend Vitalik Buterin's <a href="https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649">excellent post</a> for more details on the transformation from a program to a QAP.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Six months ago today <a class="reference external" href="/zcash-begins/">we launched</a> an ambitious attempt to create <em>Internet Money</em>. 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.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="Sprout thriving" class="center-image" src="http://blog.z.cash/wp-content/uploads/2017/04/sprout-glow.png"/></div>
|
||||
<p>Today, exactly six months after launch, is the first day that the Zcash market cap reached $100M.</p>
|
||||
<div class="figure align-center">
|
||||
<img alt="Chart of Zcash market cap history and growth to 100 million USD" class="center-image high-res-image" src="http://blog.z.cash/wp-content/uploads/2017/04/100m-chart.png"/><p class="caption">The history of the Zcash market cap, from <a class="reference external" href="https://coinmarketcap.com/currencies/zcash/#charts">Coinmarketcap.com</a>.</p>
|
||||
</div>
|
||||
<p>We’re all extremely excited and proud of our baby blockchain for coming so far so fast.</p>
|
||||
<p>There are <a class="reference external" href="https://explorer.zcha.in/">currently 1.2 million Zcash coins (ZEC) in existence</a>. 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.</p>
|
||||
<p>During the first six months of Zcash, our development team has focused on ensuring the security and stability of the network, <a class="reference external" href="/tag/releases/">making improved stable releases of the software</a> and supporting third-parties who are building products and services on top of Zcash, such as <a class="reference external" href="https://www.zcashcommunity.com/wallets/">wallets</a> and <a class="reference external" href="https://www.zcashcommunity.com/markets/">exchanges</a>.</p>
|
||||
<p>Among the many third parties who are building on top of Zcash, a few have recently announced their progress, including <a class="reference external" href="/zcash-on-ios/">Jaxx deploying Zcash on Apple iPhones</a> and <a class="reference external" href="/zcash-in-brazil-and-south-africa/">CoinBR deploying Zcash to Brazil and South Africa</a>. 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).</p>
|
||||
<p>We have big projects in the works, and so do many of our partners in the large and growing Zcash ecosystem. Stay tuned!</p>
|
||||
<p>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.</p>
|
||||
|
|
@ -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:
|
||||
<ul class="simple">
|
||||
<li>We'll release monthly on the third Tuesday, starting with 1.0.9 on May 16th.</li>
|
||||
<li>Each release starting with 1.0.9 will become deprecated 4 months after its release date. <a id="id1" class="footnote-reference" href="#id3">[1]</a></li>
|
||||
<li>We may deprecate releases earlier than this schedule to mitigate security vulnerabilities.</li>
|
||||
</ul>
|
||||
This is an aggressive upgrade schedule and if it doesn't work for your case, <a class="reference external" href="https://z.cash/contact.html">we'd love to hear from you</a> 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.
|
||||
<div id="better-safety-and-quality" class="section">
|
||||
<h2>Better Safety and Quality</h2>
|
||||
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 <a class="reference external" href="/zcash-1-0-9-postponed/">postponed 1.0.9 release</a> and an <a class="reference external" href="/new-release-1-0-8-1/">1.0.8-1 hotfix release</a>.
|
||||
|
||||
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 <a class="reference external" href="/the-near-future-of-zcash/">roadmap priorities</a>.
|
||||
|
||||
</div>
|
||||
<div id="clearer-coordination" class="section">
|
||||
<h2>Clearer Coordination</h2>
|
||||
An essential change with this new policy is an explicit <cite>release lifecycle</cite>, the most important parts of which are the release date and the <cite>deprecation date</cite>, about four months later on the 4th third-Tuesday after the release.
|
||||
|
||||
For <cite>active releases</cite> 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 <cite>deprecated releases</cite> 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 <cite>auto-senescence</cite> 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.
|
||||
<div id="user-autonomy-deprecation-vs-auto-upgrade" class="section">
|
||||
<h3>User autonomy: deprecation vs auto-upgrade</h3>
|
||||
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 <cite>deprecation</cite> approach, rather than an <cite>auto-upgrade</cite> 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 <em>themselves</em> choose either to upgrade to <em>our</em> new releases or <em>other people's</em> 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.
|
||||
|
||||
</div>
|
||||
<div id="how-is-deprecation-better-for-zcash" class="section">
|
||||
<h3>How is deprecation better for Zcash?</h3>
|
||||
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 <a class="reference external" href="/the-near-future-of-zcash/">Sapling feature set</a>.
|
||||
|
||||
We'll also be able to roll out usability improvements, such as <cite>payment disclosure</cite> and in several months' time we'll know that support for those improvements <em>should be</em> 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.
|
||||
<div id="id2" class="section">
|
||||
<h4>We'd Love to Hear From You</h4>
|
||||
Please reach out to us with any feedback on this new release policy. You can find us on the <a class="reference external" href="https://chat.zcashcommunity.com">community chat</a> or if preferred, reach out directly via <a class="reference external" href="mailto:info@z.cash">email</a>.
|
||||
<table id="id3" class="docutils footnote" frame="void" rules="none"><colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr>
|
||||
<td class="label"><a class="fn-backref" href="#id1">[1]</a></td>
|
||||
<td>We're still determining when and how to deprecate releases before 1.0.9.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -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
|
||||
---
|
||||
<a class="reference external" href="/snark-explain5/"><< Part V</a>
|
||||
|
||||
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 <a class="reference external" href="https://eprint.iacr.org/2013/279.pdf">Pinocchio Protocol</a> of Parno, Howell, Gentry and Raykova. But first let us recall the definition of a QAP we gave last time:
|
||||
|
||||
<em>A Quadratic Arithmetic Program</em> :math:`Q` <em>of degree</em> :math:`d` <em>and size</em> :math:`m` <em>consists of polynomials</em> :math:`L_1,\ldots,L_m`, :math:`R_1,\ldots,R_m`, :math:`O_1,\ldots,O_m` <em>and a target polynomial</em> :math:`T` <em>of degree</em> :math:`d`.
|
||||
|
||||
<em>An assignment</em> :math:`(c_1,\ldots,c_m)` <strong>satisfies</strong> :math:`Q` <em>if, defining</em>
|
||||
: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` <em>and</em> :math:`P:=L\cdot R -O`, <em>we have that</em> :math:`T` <em>divides</em> :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 <em>some</em> 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 <em>doesn't</em> 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 <a href="https://en.wikipedia.org/wiki/Schwartz%E2%80%93Zippel_lemma">Schwartz-Zippel Lemma</a> 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.
|
||||
|
||||
<ol>
|
||||
<li>Alice chooses polynomials :math:`L,R,O,H` of degree at most :math:`d`.</li>
|
||||
<li>Bob chooses a random point :math:`s\in\mathbb{F}_p`, and computes :math:`E(T(s))`.</li>
|
||||
<li>Alice sends Bob the <a href="/snark-explain1/">hidings</a> of all these polynomials evaluated at :math:`s`, i.e. :math:`E(L(s)),E(R(s)),E(O(s)),E(H(s))`.</li>
|
||||
<li>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))`.</li>
|
||||
</ol>
|
||||
|
||||
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, <em>without</em> knowing :math:`s`. But this is exactly the problem we solved in the <a href="/snark-explain4/">verifiable blind evaluation protocol</a>, 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.
|
||||
|
||||
<h2>Making sure Alice chooses her polynomials according to an assignment</h2>
|
||||
|
||||
Here is an important point: If Alice doesn't have a satisfying assignment, it doesn't mean she can't find <em>any</em> 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 <em>the same</em> :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 <a href="/snark-explain3/">Knowledge of Coefficient Assumption</a> implies she knows how to write :math:`F` as a linear combination of the :math:`F_i`'s.
|
||||
|
||||
<h2>Adding the zero-knowledge part - concealing the assignment</h2>
|
||||
|
||||
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 <em>some</em> 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.
|
||||
|
||||
<h2>What's left for next time?</h2>
|
||||
|
||||
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:
|
||||
|
||||
<ul>
|
||||
<li>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.</li>
|
||||
<li>Throughout this series, we have discussed <em>interactive</em> protocols between Alice and Bob. Our final goal, though, is to enable Alice to send single-message <em>non-interactive proofs</em>, that are <em>publicly verifiable</em> - meaning that anybody seeing this single message proof will be convinced of its validity, not just Bob (who had prior communication with Alice).</li>
|
||||
</ul>
|
||||
|
||||
Both these issues can be resolved by the use of pairings of elliptic curves, which we will discuss in the next and final part.
|
||||
|
||||
<p><a class="reference external" href="https://z.cash/blog/snark-explain7.html">>> Part VII</a></p>
|
||||
|
|
@ -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
|
||||
---
|
||||
<p>Over the short history of Zcash, we've seen a substantial growth in the ecosystem from <a class="reference external" href="https://www.zcashcommunity.com/wallets/">wallets</a> and <a class="reference external" href="https://www.zcashcommunity.com/markets/">exchanges</a> to more experimental applications like <a class="reference external" href="https://github.com/whyrusleeping/zmsg">zmsg</a>. As the Zcash core development team continues to improve the underlying Zcash protocol, we encourage more developers to join the community!</p>
|
||||
<p>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.</p>
|
||||
<div class="section" id="level-1-support-transparent-addresses">
|
||||
<h2>Level 1 Support (Transparent addresses)</h2>
|
||||
<p>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.</p>
|
||||
<p>While transparent addresses don't allow users to send privately, in many cases the mere existence and use of shielded addresses by others provides <a class="reference external" href="/transaction-linkability/">protection from linkability</a>.</p>
|
||||
</div>
|
||||
<div class="section" id="level-2-support-shielded-addresses">
|
||||
<h2>Level 2 Support (Shielded addresses)</h2>
|
||||
<p>Supporting shielded addresses requires more work but we encourage those interested to take advantage of their added capabilities. <a class="reference external" href="https://shapeshift.io">ShapeShift</a> and <a class="reference external" href="https://keybase.io/blog/keybase-and-zcash">Keybase</a> are two examples of services which work with shielded addresses.</p>
|
||||
<p>We're doing a lot of work to make shielded addresses easier to support and more useful. For example, some <a class="reference external" href="/near-future-priorities/">near future priorities</a> for Zcash development include <a class="reference external" href="https://github.com/zcash/zcash/pull/2159">payment disclosure</a> and <a class="reference external" href="https://github.com/zcash/zcash/pull/2120">payment offloading</a> 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)!</p>
|
||||
</div>
|
||||
<div class="section" id="getting-started-with-zcash-integration">
|
||||
<h2>Getting Started with Zcash Integration</h2>
|
||||
<p>The quest to establish an Internet money ecosystem requires a variety of third-party services and we are here to help!</p>
|
||||
<p>Please view the <a class="reference external" href="https://z.cash/support/zig.html">Zcash Integration Guide</a> to get started with either <cite>Level 1</cite> or <cite>Level 2</cite> Zcash integration. You can get help by posting on our <a class="reference external" href="https://forum.z.cash">forum</a>, joining us in the <a class="reference external" href="https://chat.zcashcommunity.com">community chat</a> or, if you prefer, sending us an <a class="reference external" href="mailto:info@z.cash">email</a>.</p>
|
||||
<p>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 <a class="reference external" href="https://z.cash/support/zig.html">Zcash Integration Guide</a> and tell them why you want them to support Zcash!</p>
|
||||
|
|
@ -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: <a class="reference external" href="mailto:press@z.cash">press@z.cash</a>
|
||||
|
||||
<strong>About Zerocoin Electric Coin Company:</strong>
|
||||
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 <a class="reference external" href="https://z.cash">https://z.cash</a>.
|
||||
|
||||
|
||||
<strong>About J.P. Morgan’s Corporate & Investment Bank:</strong>
|
||||
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 <a class="reference external" href="https://www.jpmorgan.com">www.jpmorgan.com</a>.
|
||||
|
|
@ -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 <a class="reference external" href="/release-cycle-and-lifetimes/">Release Cycles and Lifetimes</a> post. It also introduces opt-in support for the <a class="reference external" href="https://www.amqp.org/">AMQP protocol</a>.
|
||||
|
||||
We encourage all users and miners to update to this new version. See our <a class="reference external" href="https://z.cash/download.html">download</a> page and the <a class="reference external" href="https://github.com/zcash/zcash/wiki/1.0-User-Guide">1.0 User Guide</a> for more information.
|
||||
<ol class="arabic simple">
|
||||
<li>Implemented automatic deprecation shutdown. <a class="reference external" href="https://github.com/zcash/zcash/pull/2297">#2297</a></li>
|
||||
<li>Added opt-in AMQP support. <a class="reference external" href="https://github.com/zcash/zcash/pull/2189">#2189</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2362">#2362</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2280">#2280</a></li>
|
||||
<li>Performance benchmarking and testing improvements: fix hang in benchmarking CI automation, add <cite>connectblockslow</cite> benchmark, re-enabled miner tests, improved error reporting in <cite>rpc-tests</cite> framework, changed default regtest port. <a class="reference external" href="https://github.com/zcash/zcash/pull/2397">#2397</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2372">#2372</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2389">#2389</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2376">#2376</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2265">#2265</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2270">#2270</a></li>
|
||||
<li>Automated the release process, added build diagnostics for better user support, and fixed versioning problems in debian packaging and manpages. <a class="reference external" href="https://github.com/zcash/zcash/pull/2393">#2393</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2369">#2369</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2281">#2281</a></li>
|
||||
<li>Added test for pairing bug when G1 is infinity. <a class="reference external" href="https://github.com/zcash/zcash/pull/2399">#2399</a></li>
|
||||
<li>Documentation: Clarify release policy, added wallet backup instructions, and fixed some incorrect references to "bitcoin". <a class="reference external" href="https://github.com/zcash/zcash/pull/2401">#2401</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2340">#2340</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2364">#2364</a>, <a class="reference external" href="https://github.com/zcash/zcash/pull/2338">#2338</a></li>
|
||||
<li>Added alert sources for <a class="reference external" href="/security-announcement-2017-04-13/">2017-04-13 security incident</a>. <a class="reference external" href="https://github.com/zcash/zcash/pull/2293">#2293</a></li>
|
||||
</ol>
|
||||
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 <a class="reference external" href="https://github.com/zcash/zcash/milestone/53?closed=1">1.0.9</a> GitHub milestone. To follow our progress, watch <a class="reference external" href="https://github.com/zcash/zcash/milestones">the GitHub project</a> and <a class="reference external" href="https://forum.z.cash/">join the forum</a>.
|
||||
|
|
@ -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
|
||||
---
|
||||
<a class="reference external" href="/snark-explain6/"><< Part VI</a>
|
||||
|
||||
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.
|
||||
|
||||
<h2>Elliptic curves and their pairings</h2>
|
||||
|
||||
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)` <a class="footnote-reference" href="#id6" id="id1">[1]</a> 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 <em>divisor class group</em> 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.
|
||||
|
||||
<div class="figure align-center">
|
||||
<img alt="Test |P+Q=O --> P=-Q|" src="http://blog.z.cash/wp-content/uploads/2017/06/ECVertical.png" style="height: 320px;"/>
|
||||
</div>
|
||||
|
||||
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`.
|
||||
|
||||
<div class="figure align-center">
|
||||
<img alt="Test |P+Q+R=0|" src="http://blog.z.cash/wp-content/uploads/2017/06/ECCregular.png" style="height: 320px;"/>
|
||||
</div>
|
||||
|
||||
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. <a class="footnote-reference" href="#id7" id="id2">[2]</a>
|
||||
|
||||
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 <em>embedding degree</em> 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 <a class="footnote-reference" href="#id8" id="id3">[3]</a> 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 <em>Tate reduced pairing</em>, taking a pair of elements from :math:`G_1` and :math:`G_2` into an element of :math:`G_T`,
|
||||
|
||||
such that
|
||||
|
||||
<ol>
|
||||
<li>:math:`\mathrm{Tate}(g,h)=\mathbf{g}` for a generator :math:`\mathbf{g}` of :math:`G_T`, and</li>
|
||||
<li>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}`.</li>
|
||||
</ol>
|
||||
|
||||
Defining :math:`\mathrm{Tate}` is a bit beyond the scope of this series, and relies on concepts from algebraic geometry, most prominently that of <em>divisors</em>. Here's a sketch of :math:`\mathrm{Tate}`'s definition: <a class="footnote-reference" href="#id9" id="id4">[4]</a>
|
||||
|
||||
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'.
|
||||
|
||||
<h2>Non-interactive proofs in the common reference string model</h2>
|
||||
|
||||
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. <a class="footnote-reference" href="#id10" id="id5">[5]</a>
|
||||
|
||||
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 <a href="/snark-explain4/">Part IV </a> 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.
|
||||
|
||||
<h2>A non-interactive evaluation protocol</h2>
|
||||
|
||||
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`.
|
||||
|
||||
<strong>Setup</strong>: 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.
|
||||
|
||||
<strong>Proof</strong>: 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` <a href="/snark-explain2/">support linear combinations</a>.
|
||||
|
||||
<strong>Verification</strong>: 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.
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id6" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td>
|
||||
<td>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.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id7" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id2">[2]</a></td>
|
||||
<td>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.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id8" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id3">[3]</a></td><td><a class="reference external" href="https://eprint.iacr.org/2005/133.pdf">https://eprint.iacr.org/2005/133.pdf</a></td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id9" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id4">[4]</a></td>
|
||||
<td>The pairing Zcash actually uses is the <a href="https://www.esat.kuleuven.be/cosic/publications/talk-96.pdf">optimal Ate pairing</a>, which is based on the Tate reduced pairing, and can be computed more efficiently than :math:`\mathrm{Tate}`.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id10" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id5">[5]</a></td>
|
||||
<td>In computational complexity theory terms, one can show that only languages in <a href="https://en.wikipedia.org/wiki/BPP_(complexity)">BPP</a> 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 <a href="https://en.wikipedia.org/wiki/NP_(complexity)">NP</a> which is believed to be much larger than BPP. </td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table class="docutils footnote" frame="void" id="id11" rules="none">
|
||||
<colgroup><col class="label"><col></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label">[6]</td><td>The images used were taken from the following <a class="reference external" href="https://en.wikipedia.org/wiki/Elliptic_curve">article</a> and are used under the <a class="reference external" href="https://creativecommons.org/licenses/by-sa/3.0/">creative commons license</a>.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue