zcash/zcash

Zcash - Internet Money

Zcash 5.9.0

What is Zcash?

Zcash is HTTPS for money.

Initially based on Bitcoin's design, Zcash has been developed from the Zerocash protocol to offer a far higher standard of privacy and anonymity. It uses a sophisticated zero-knowledge proving scheme to preserve confidentiality and hide the connections between shielded transactions. More technical details are available in our Protocol Specification.

The zcashd Full Node

This repository hosts the zcashd software, a Zcash consensus node implementation. It downloads and stores the entire history of Zcash transactions. Depending on the speed of your computer and network connection, the synchronization process could take several days.

The zcashd code is derived from a source fork of Bitcoin Core. The code was forked initially from Bitcoin Core v0.11.2, and the two codebases have diverged substantially.

🔒 Security Warnings

See important security warnings on the Security Information page.

Zcash is experimental and a work in progress. Use it at your own risk.

📒 Deprecation Policy

This release is considered deprecated 16 weeks after the release day. There is an automatic deprecation shutdown feature which will halt the node some time after this 16-week period. The automatic feature is based on block height.

Other Zcash Implementations

The Zebra project offers a different Zcash consensus node implementation, written largely from the ground up.

Getting Started

Please see our user guide for instructions on joining the main Zcash network.

Need Help?

• 📘 See the documentation at the ReadTheDocs for help and more information.
• 📨 Ask for help on the Zcash forum.
• 💬 Join our community on Discord
• 🧑‍🎓: Learn at ZecHub

Participation in the Zcash project is subject to a Code of Conduct.

Building

Build Zcash along with most dependencies from source by running the following command:

./zcutil/build.sh -j$(nproc)

Currently, Zcash is only officially supported on Debian and Ubuntu. See the Debian / Ubuntu build for detailed instructions.

License

For license information see the file COPYING.

zcash's Issues

roadmap

This will be refined as we go. Let's put a draft in place prior to our public announcement.

This will depend on a feature-set document. Ticket forthcoming.

[CLOSED] Add build instructions for Debian to the README.md.

Issue by nathan-at-least
Sunday Dec 07, 2014 at 00:00 GMT
Originally opened as Electric-Coin-Company/libzerocash#11

---

Add build instructions (for Debian) which suffice for #10.

---

nathan-at-least included the following code: https://github.com/Electric-Coin-Company/libzerocash/pull/11/commits

Set up Travis CI for libzerocash.

Issue by nathan-at-least
Sunday Dec 07, 2014 at 00:02 GMT
Originally opened as Electric-Coin-Company/libzerocash#13

---

Let's set up travis, buildbot, or some other continuous integration system.

Develop a competitive strategy against forks.

Is the potential for others to fork the codebase and launch independent networks a high risk?

If so, what are some competitive advantages we can maintain over forks?

Let's develop a strategy prior to a public announcement, so that the public is generally convinced that our network will be the shelling point.

Note: There are two parts to the first question: First, Is it feasible that independent parties can launch a network that garners a number of users and/or market cap on the same order as ours? Second, if that occurs, will it be detrimental to the value of our network?

Reduce depth of merkle tree over commitments.

How do we protect against altcoin infanticide?

Refactor zerocashd code to minimize cost of tracking upstream

See also #23

Design wallet coin management algorithms / automated txn creation.

Plan security audits.

Let's organize a security audit focused on the delta from upstream bitcoin-core. Ideally this would be performed by an independent third party auditor.

I recommend focusing on the delta rather than bitcoin-core on the assumption that bitcoin-core has many eyes on it. (However, this might be a catastrophically dangerous assumption, and if we have extra time/resources we should also scrutinize bitcoin-core.)

Choose the proof-of-work algorithm

[CLOSED] Nathan automated test instructions

Issue by nathan-at-least
Sunday Dec 07, 2014 at 00:02 GMT
Originally opened as Electric-Coin-Company/libzerocash#12

---

Add instructions for building and running the automated tests; should suffice for #9.

Note: This pull request extends (and is a superset) of #11. Landing this on master would implicitly land #11. #11 should be landed first.

---

nathan-at-least included the following code: https://github.com/Electric-Coin-Company/libzerocash/pull/12/commits

[Sapling] If Mint/Shield operations are disunified from JoinSplits, ensure they include a "note encrypted to self" field

@tromer wrote in #18:

I suggest the following criterion: if you have printed out your address private key, then this data (which is immutable and transaction independent), together with the public data in the blockchain, should suffice to recognize and pour all coins you own. Any additional information you keep is merely for improved performance.

This is already the case [in Zerocash] for coins that are an output of a Pour operation provided that the C1 and C2 fields are used. To make it also true for minted coins, we need to change Mint operations to include a "coin encrypted to self" field.

I believe this should be part of 1.0. It's an important marketing feature that it's possible to print out something small, that is sufficient to ensure you don't lose your coins.

Create automated test which asserts Verify fails when serial numbers collide for distinct coins.

Issue by nathan-at-least
Sunday Dec 07, 2014 at 00:06 GMT
Originally opened as Electric-Coin-Company/libzerocash#14

---

This test should pass only when Verify is augmented to protect against this attack vector. (Note: we also should attempt to ensure any change to Verify matches any changes to the formal security analysis, although we may not want to block on that.)

Decide on policy for ``libzerocash`` label versus using that repositories issue tracker.

What is the purpose of libzerocash label? When should a ticket live in this tracker with that label rather than over in the libzerocash issue tracker?

For example, this ticket and libzerocash issue #15 are almost identical. This is intentional to highlight the need to clarify our policy.

A similar issue exists for libsnark label.

Document potential protocol versioning techniques.

[CLOSED] Add build instructions for Debian to the README.md.

Issue by nathan-at-least
Sunday Dec 07, 2014 at 00:00 GMT
Originally opened as Electric-Coin-Company/libzerocash#11

---

Add build instructions (for Debian) which suffice for #10.

---

nathan-at-least included the following code: https://github.com/Electric-Coin-Company/libzerocash/pull/11/commits

Verify all code licensing works for us.

C++ standardization issues.

I'm currently attempting to build zerocashd by hacking the generated ./src/Makefile to append CXXFLAGS like this:

CPPFLAGS =  -DBOOST_SPIRIT_THREADSAFE -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS -I../../libzerocash -I../../libzerocash/depinst/include -I../../libzerocash/depinst/include/libsnark -std=c++11 -DCURVE_BN128

Obviously this is an attempt at a temporary hack and we should update the autoconf/automake source to properly set these options.

Without -std=c++11, libsnark header files generate compilation errors. With -std=c++11 zerocashd hits compilation errors. I believe I could fix the first several -std=c++11 errors by modifying the source of zerocashd, but I don't have enough language/domain expertise to know the right path.

Some C++ questions:

• Should we simply consider my version of g++ unsupported and support a version that works by default?
• Is it possible/sane to compile with some headers files relying on -std=c++11 and others using the g++ default?
• If we choose to modify the source of zerocashd to follow the C++ 0x11 standard, how much will that interfere with the goal of maintaining zerocashd as a moving rebase on top of bitcoin-core? (Which language standard does bitcoin-core use?)

Note: @nathan-at-least hasn't touched C++ since well before C++ 0x11 standard, so hopefully a C++ expert can resolve these issues quickly.

Investigate using "application specific salting" for ``CRH`` and ``PRF`` instantiations.

Issue by nathan-at-least
Monday Dec 08, 2014 at 04:20 GMT
Originally opened as Electric-Coin-Company/libzerocash#16

---

Is it worth adding high-entropy "application-specific salts" to any of the CRH or PRFs in zerocash?

(My hunch is: no, because every PRF or CRH input is already highly entropic. This ticket is just to remind me to re-read over each of the inputs and ask if this assumption is justified.)

In tahoe-lafs, some hash functions use "application specific salting", which I believe is similar to the "personal" field of the blake2 hash API.

Imagine a world where some adversaries have very very large rainbow tables, and they grow continually. As these grow over time, more and more preimages will be aggregated. If an adversary with access to such a rainbow table sees an image (output) which happens to correspond to an entry in their table, they have learned the preimage (input).

If the inputs are already guaranteed to be high-entropy, this isn't a very large concern.

If the inputs may be low entropy, by using a public global application-specific salt, this adds some cost to the giant-rainbow-table-in-the-sky because it must have a special case for the target application.

Design protocol and wallet features to support a recoverable brain wallet.

Ticket #20 and #18.

improved encryption in `libzerocash`

Measure how large the nullifier table in leveldb can get.

Document how to run automated tests.

Issue by nathan-at-least
Saturday Dec 06, 2014 at 23:00 GMT
Originally opened as Electric-Coin-Company/libzerocash#9

---

My plan right now is to determine how to run automated tests (at least unit-style tests, and perhaps also benchmarks and the like), and as I do so add instructions to the README.

Secure Multiparty Computation for setup parameters.

Research GHOST, the Ethereum-variant there-of, and DAG-chains

In my opinion, this area of mining/consensus design space is probably outside our desired features list. However, it'd be prudent to understand them and the arguments that they may help with lower confirmation times, and pool-centralization resistance.

Sompolinsky and Zohar authored GHOST, and the Ethereum Design Rationale describes their modified incentives as well as alluding to newer work by Sompolinsky and Zohar wrt block DAGs.

[CLOSED] Do Pour txns need at least two public outputs?

Issue by nathan-at-least
Wednesday Dec 03, 2014 at 21:41 GMT
Originally opened as Electric-Coin-Company/libzerocash#7

---

Suppose a user wishes to transfer private holdings into a public address for their use. They can use a Pour public output, but then how do they also pay transaction fees?

move libzerocash code into zerocashd repo

I proposed this in the context of discussions on Electric-Coin-Company/libzerocash#15 . I think there is little technical reason to keep the repos separate, and it would have the following advantages:

• avoiding version skew between libzerocash and zerocashd
• avoiding uncertainty about which issue tracker should be used
• changes that affect both libzerocash and zerocashd can be in the same commits or pull requests (this both simplifies development and clarifies the history of such changes)
• potentially simplifying the zerocashd build process a little.

Zooko and Nathan agreed this was probably a good idea, however I'd like to get feedback from the 7 scientists before making this change.

Note that libsnark would not be merged, since that is intended to be a separately reusable library.

support 2-factor auth

https://www.reddit.com/r/Bitcoin/comments/2njz9j/blockchaininfo_wallet_robbed/

How might libsnark side-channel leaks compromise users?

From the libsnark README:

* The ppzkSNARK's generator and prover exhibit data-dependent running times
  and memory usage. These form timing and cache-contention side channels,
  which may be an issue in some applications.

Can this lead to user compromise (anything any realistic user would care about)? In which use cases?

Brainstorm example: Suppose a use case is an automated system that Pours on demand using the same key material, addr_{sk}, and an adversary can elicit these Pour transactions and carefully time their emission. Can this kind of adversary learn anything about addr_{sk} or any other secret data-dependencies of the Pour proof? After how many such elicited Pours?

Running "./configure" should do dependency detection for libzerocash.

Decide on branch management / upstream integration policy with bitcoin.

Refactor this repository into a "single library source".

Issue by nathan-at-least
Tuesday Dec 02, 2014 at 17:40 GMT
Originally opened as Electric-Coin-Company/libzerocash#5

---

I'd like to make this (and any other C/C++ dependency) follow this customary open sourcey packaging flow:

• A user unpacks a tarball or does a git clone.
• There's a README.* and the source all lives under ./src.
• The README describes which dependencies must be installed, and then says: run ./configure [options]; make; make install

Optionally, the last step might be prefixed with some autoconf/automake step.

Does the wallet's creation of shielded transactions have impacts on security from traffic analysis / timing / sequencing?

[CLOSED] Nathan automated test instructions

Issue by nathan-at-least
Sunday Dec 07, 2014 at 00:02 GMT
Originally opened as Electric-Coin-Company/libzerocash#12

---

Add instructions for building and running the automated tests; should suffice for #9.

Note: This pull request extends (and is a superset) of #11. Landing this on master would implicitly land #11. #11 should be landed first.

---

nathan-at-least included the following code: https://github.com/Electric-Coin-Company/libzerocash/pull/12/commits

Make witness calculation more efficient while still deterministic and recoverable.

Check licensing for the codebase; add appropriate license.

Issue by nathan-at-least
Tuesday Nov 25, 2014 at 21:17 GMT
Originally opened as Electric-Coin-Company/libzerocash#1

---

Dust off codebase: build, run, poke at JSON api, try to exercise mint, pour, and receive manually.

implement two-stage pour proofs.

Issue by nathan-at-least
Tuesday Dec 02, 2014 at 18:17 GMT
Originally opened as Electric-Coin-Company/libzerocash#6

---

The prove time is large enough that users may perceive this as a drawback compared to competing cryptocurrencies. It may be possible to split the proof into two stages, where the early stage can be computed immediately upon receipt before the subsequent send details are known.

If this is possible and the early stage is a large enough fraction of the total proof time, then it would be a major usability improvement to compute the first stage immediately upon receipt. This early stage would overlap with block confirmation time, which users already understand and expect. Additionally, this would mean the delay to spend would be perceptually close to other bitcoin-likes.

Where should `libzerocash` tickets live?

Issue by nathan-at-least
Monday Dec 08, 2014 at 04:00 GMT
Originally opened as Electric-Coin-Company/libzerocash#15

---

I notice that in addition to this issue tracker, there is the libzerocash label within zerocashd. This may violate the single source-of-truth principle. So, should we:

• A: close this issue tracker and use that label over on the zerocashd issue tracker,
• B: remove the label within zerocashd and only use this issue tracker, or
• C: keep the label in zerocashd but only for issues which would not live here (such as issues specific to zerocashd that affect how it interacts with libzerocash) ?

isislovecruft/build/debian-jessie (builds successfully)

Issue by isislovecruft
Friday Nov 28, 2014 at 12:12 GMT
Originally opened as Electric-Coin-Company/libzerocash#2

---

@daira @zookoatleastauthoritycom @nejucomo I'm not sure if this should be merged into the snarks branch, or where it should go, however this branch does build successfully. (Or, at least, it does for me). :)

---

isislovecruft included the following code: https://github.com/Electric-Coin-Company/libzerocash/pull/2/commits

evaluate subset-sum-based hash function for commitment accumulator

Issue by daira
Sunday Nov 30, 2014 at 02:36 GMT
Originally opened as Electric-Coin-Company/libzerocash#3

---

As noted in http://eprint.iacr.org/2014/595 ("Scalable Zero Knowledge via Cycles of Elliptic Curves") sections 1.4.2 and 5.2, hashing based on modular subset-sum functions can have great advantages in reducing SNARK circuit size: ~300 gates for the function used in that paper (80-bit security level) compared to 27904 gates for the current hand-optimised SHA-256 compression function in the Zerocash implementation (128-bit security level). Note that this idea is independent of the other contributions of the paper and can be used in non-recursive SNARKs.

Subset-sum hashes can be collision-resistant, but they have more structure than "bit-twiddling" hashes, and because they are less efficient on conventional architectures, they have not been explored to the same extent for cryptographic applications. We should ask the hash function gurus we have contacts with --DJB and the BLAKE2 designers-- for their advice about this approach. If we decide to use it, we need to be particularly careful with parameter choices, and that we are using a hash with security properties that are actually sufficient for use in a Merkle tree. Nevertheless, the reduction in circuit size of a factor of possibly 100 for the tree hashing (on top of any reduction in tree depth due to decreasing the limit on number of coins) is extremely tempting.

Note that we do not necessarily have to use the same hash to instantiate the Merkle tree over coin commitments as for the COMM and PRF schemes; I argued at the hack fest that the latter should be more conservative because they can only be changed by recreating all coins. There is no circuit size penalty from using more than one hash per se, since circuits must be duplicated as often as they are used.

Make prepare-depends.sh caller-path-independent.

Issue by nathan-at-least
Tuesday Dec 02, 2014 at 17:34 GMT
Originally opened as Electric-Coin-Company/libzerocash#4

---

This small change makes the prepare-depends.sh script function identically regardless of the pwd of the caller. It does not change the build process. It works on my debian jessie system.

---

nathan-at-least included the following code: https://github.com/Electric-Coin-Company/libzerocash/pull/4/commits

Brainstorm on live mining algorithm upgrade path / social process.

isislovecruft/build/debian-jessie (builds successfully)

Issue by isislovecruft
Friday Nov 28, 2014 at 12:12 GMT
Originally opened as Electric-Coin-Company/libzerocash#2

---

@daira @zookoatleastauthoritycom @nejucomo I'm not sure if this should be merged into the snarks branch, or where it should go, however this branch does build successfully. (Or, at least, it does for me). :)

---

isislovecruft included the following code: https://github.com/Electric-Coin-Company/libzerocash/pull/2/commits

Add build instructions.

Issue by nathan-at-least
Saturday Dec 06, 2014 at 23:58 GMT
Originally opened as Electric-Coin-Company/libzerocash#10

---

Recoverable brain wallet.

Needs to track all information needed to generate a Pour transaction.

Edit 2015-08-24 We decided that #31 is a duplicate of this ticket.

Edit 2017-01-24 This ticket means different things to different people and thus needs to be split out into specific tickets:

• #2038 - feature to recover everything important from a static secret seed.
• #2039 - mnemonic entropy encoding (a la BIP39).
• #2040 - "Allow users to pick their own weak passwords for deterministic secret seeds. (strawman)"

Route privacy-sensitive operations over Tor automatically.

We need to analyze tor integration security issues in upstream also:

• Search for all bitcoin + tor issues publicized. (eg: http://arxiv.org/abs/1410.6079 )
• File tickets which are more specific to the issues uncovered.
• For each of those issues, see if upstream bitcoin-core is working on solutions that are acceptable to us.

Perform general security audit.

Issue by nathan-at-least
Friday Dec 05, 2014 at 03:23 GMT
Originally opened as Electric-Coin-Company/libzerocash#8

---

We should perform a general security audit of this codebase. Ideally we should get at least one third party to do an independent security review.

Make prepare-depends.sh caller-path-independent.

Issue by nathan-at-least
Tuesday Dec 02, 2014 at 17:34 GMT
Originally opened as Electric-Coin-Company/libzerocash#4

---

This small change makes the prepare-depends.sh script function identically regardless of the pwd of the caller. It does not change the build process. It works on my debian jessie system.

---

nathan-at-least included the following code: https://github.com/Electric-Coin-Company/libzerocash/pull/4/commits

Implement Equihash PoW