Home / Rust / Cryptocurrencies

zcash — Zcash is an implementation of the "Zerocash" protocol.

Zcash 3.0.0 What is Zcash? Zcash is an implementation of the "Zerocash" protocol. Based on Bitcoin's code, Zcash intends to offer a far higher standar
Information
Category: Rust / Cryptocurrencies
Watchers: 381
Star: 4.7k
Fork: 2k
Last update: Mar 22, 2023
Resource links
https://z.cash/
https://github.com/zcash/zcash

Zcash 3.0.0

What is Zcash?

Zcash is an implementation of the "Zerocash" protocol. Based on Bitcoin's code, Zcash intends to offer a far higher standard of privacy through a sophisticated zero-knowledge proving scheme that preserves confidentiality of transaction metadata. More technical details are available in our Protocol Specification.

This software is the Zcash client. 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 a day or more once the blockchain has reached a significant size.

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

Getting Started

Please see our user guide for 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.
  • 💬 Chat with our support community on Discord

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.

License

For license information see the file COPYING.

1099 Open More issues
Closed

Write spec for Harmony Mining

From Announcing Zcash Blossom and proposed feature goals:

Harmony Mining

  • What is it? A dual-proof-of-work scheme, where one algorithm is backwards compatible with current mining equipment, and another is designed to work well with GPUs on a temporary time scale.
  • Who does this affect? miners
  • Why is this a goal? By attracting distinct mining userbases (ASIC & GPU owners) we aim to make the Zcash ecosystem more resilient by spreading issuance and political influence among distinct kinds of stakeholders.

Close Criteria: Close this ticket when there are well-specified precise requirements for this feature goal.

I-SECURITY A-pow M-requires-nu C-feature-requirements D-decentralization Network Upgrade Wishlist 
opened Nov 14, 2018 by nathan-at-least 173
Closed

Asymmetric payment construction

This is a casual overview of the payment construction that Matthew, Ian and I have been playing with.

The first intuition is to treat nullifiers as randomized public keys, i.e., (gsk)r where r is the output of a PRF, and g is the generator of the fast ECC curve group from #2230. Outside of the zk-SNARK, the person in possession of sk can also sign using a Schnorr signature. As far as we're aware, this is compatible with standard threshold signature schemes.

There are two benefits to this: first, the zk-SNARK prover does not have spend authority, which allows us to achieve delegated proving for hardware wallets, mobile devices, businesses, etc. Second, there is no longer a need for hSig-style ephemeral public keys.

The first thing to notice is that the PRF for r cannot be keyed by sk without revealing it to the prover. We can solve this by making gsk the key, which means that addresses must be a commitment to gsk. However, the ultimate construction of the nullifier (gsk)PRFgskρ is difficult to write a proof for. We need the addresses to be a commitment to two keys: gsk and hprf_key instead.

At this point, there are many approaches for designing the addresses. Pedersen commitments are one option, but in order to achieve key plurality as in #570 we need to reduce the number of bases for the DH key exchange, so something like GH(i)H(gsk || hprf_key) is ideal.

Notes can be Pedersen commitments to the address/value/ρ and any additional metadata. During spending, the prover need only know how to decommit the note and the address. Note that it is not secure to allow the spender to decommit from any base, but instead only outputs of GH. If GH is expensive to compute inside of the zk-SNARK, its domain would need to be small enough that we can precompute all of the bases and bake them into the circuit.

The actual concrete constructions for H or PRFrho are not fully fleshed out. If truncating CRH(gsk || hprf_key) were acceptable, that would be great for H. But it's not clear to us that it is safe. Additionally, we can cheaply calculate (g1/(x+m) hx jm) inside the circuit and use this for the PRF (this is provably collision resistant, needed to prevent sniping), but for some reasons that @matthewdgreen could explain there are some technical difficulties with this approach. Thus only with some clever crypto engineering could we avoid using something like MiMC or a full-blown hash function for these purposes.

The general gist of this is: make sure the prover doesn't know the signing key, and use the nullifier to communicate spend authority to the outside consensus rules.

I-SECURITY A-crypto I-privacy A-consensus A-circuit protocol spec M-requires-nu NU1-sapling elliptic curves 
opened Apr 18, 2017 by ebfull 150
Closed

select difficulty adjustment algorithm

Are there improvements to availability if difficulty is adjusted each block? Is there any larger vulnerability (eg: DOSing a nodes peer connections to starve it of blocks lowering it's local belief about difficulty)?

Are there any known advantages or risks which clearly make this worthwhile to spend time on or avoid?

We suspect this may be important in the long term, because PoW mining may eventually lead to cascading exit of miners when their margins go <= 0 (Brad Templeton Death Spiral, #95), or during sudden-withdrawal infanticide, or during sudden withdrawal due to side-chain knock-on effects (see #146). This may help with availability during those kinds of events (although it won't mitigate those events directly).

Is the implementation complexity low? (It would seem like changing a single constant K to 1 in "calculate difficulty every K blocks".)

question I-SECURITY C-research I-performance D-economics A-consensus A-pow in 1.0 special to Daira special to Nathan A-consensus-genesis 
opened Mar 26, 2015 by nathan-at-least 105
Closed

Experimental feature: remote proving service

This implements proving service support in z_sendmany and adds two new binaries:

  • zcash-proving-service: listens on (one or both of) ZMQ and WebSocket ports for witness data, and returns the corresponding proof.
  • ExampleProvingServiceClient (in src/zcash): creates five new JSDescriptions using the proving service to calculate the proofs, and validates each proof.

To build: CONFIGURE_FLAGS="--with-proving-service-daemon" ./zcutil/build.sh

This is an experimental feature, and the network protocol is likely to change. Until the protocol has been specified in a ZIP, do not rely on it for interoperation.

Part of #1113. Closes #2066.

I-SECURITY SPV support S-waiting-on-review spring_cleaning 
opened Feb 21, 2017 by str4d 89
Closed

Windows cross-compile support

Usage on Debian / Ubuntu:

$ sudo apt install mingw-w64 $ sudo update-alternatives --config x86_64-w64-mingw32-gcc (configure to use POSIX variant) $ sudo update-alternatives --config x86_64-w64-mingw32-g++ (configure to use POSIX variant) $ HOST=x86_64-w64-mingw32 ./zcutil/build.sh

Closes #489.

A-build O-windows portability 
opened Apr 14, 2018 by str4d 80
Closed

[macOS] Darwin build patches

Part of #2246.

I-SECURITY A-build O-macos portability 
opened Dec 20, 2017 by str4d 80
Open

Improve code readability using `examine` macro

Improve code readability by replacing all instances of

std::visit(match {
    ...
}, specimen)

with a new examine macro:

examine(specimen, match {
    ...
})

With the previous ordering I often needed to read the code non-linearly to see what the specimen was, before being able to understand the code in the match body. (In all cases the specimen was a short expression, but the match body can be very large.)

fixes #6491

C-cleanup S-scratching-an-itch 
opened Mar 16, 2023 by daira 0
Open

Display pass ratio in RPC test summary

When everything passes, still show “True”, but when there are failures, show passed/total.

opened Mar 16, 2023 by sellout 0
Open

Add a wrapper around std::visit to allow the value being matched to be given first

In code that looks like

std::visit(match {
    /* ... lots of code ... */
}, specimen)

I often have to scroll down to the end to see what specimen is and then scroll back, which is annoying.

C-cleanup S-scratching-an-itch 
opened Mar 15, 2023 by daira 0
Open

Update CI components to contain build, worker, and bench Docker images with supporting scripts

Replaces #6134 but contains the same code needed to support current Zcash CI

opened Mar 14, 2023 by mdr0id 0
Open

[DO NOT MERGE] Testing CI checks

null

opened Mar 14, 2023 by str4d 1
Open

[DO NOT MERGE] docker release

null

opened Mar 14, 2023 by yasserisa 0

v5.4.2(Mar 13, 2023)

This hotfix remediates memory exhaustion vulnerabilities that zcashd inherited as a fork of bitcoind. These bugs could allow an attacker to use peer-to-peer messages to fill the memory of a node, resulting in a crash.

v5.3.3(Mar 13, 2023)

This hotfix remediates memory exhaustion vulnerabilities that zcashd inherited as a fork of bitcoind. These bugs could allow an attacker to use peer-to-peer messages to fill the memory of a node, resulting in a crash.

v5.4.1(Feb 14, 2023)

Notable changes

allowdeprecated in zcash.conf

In v5.0.0 a feature deprecation framework was released, to enable zcashd features to be formally deprecated and removed:

  • In stage 1, a feature is marked as deprecated, but otherwise left as-is. It remains in this stage for at least 18 weeks.
  • In stage 2, the feature is default-disabled, but can be re-enabled with the -allowdeprecated config option. It remains in this stage for at least 18 weeks.
  • Finally, the feature is removed - either entirely, or (e.g. in the case of RPC methods that were inherited from Bitcoin Core) with a "tombstone" left to inform users of the removal (and what to use instead if applicable).

Config options can be specified either as a zcashd argument (-option=value) or in zcash.conf (as a option=value line). However, due to a bug in the implementation, allowdeprecated=feature lines in zcash.conf were ignored. The bug went unnoticed until v5.4.0, in which the first group of features moved from stage 1 to stage 2. This hotfix release fixes the bug.

Fixed RPC blocking and wallet view lag on reindex

The known issue reported in the v5.4.0 release notes has been fixed.

v5.4.0(Feb 9, 2023)

Notable changes

Fixes

This release fixes an issue that could potentially cause a node to crash with the log message "The wallet's best block hash <hash> was not detected in restored chain state. Giving up; please restart with -rescan."

Additionally, a bug that could cause an assertion failure during reindexing has been fixed. See #6387 for details.

Known issues

  • When zcashd is started with -reindex, until the node's chain tip catches back up to the main chain, RPC calls might block for long periods of time (or time out), and the wallet's view of the chain may lag significantly behind the node's chain tip. See #6406 for details and the fix (which will be included in the next release).

Transparent pool and chain supply tracking

Since v2.0.0, zcashd has tracked the change in value within the Sprout and Sapling shielded pools for each block; v5.0.0 added the Orchard pool. This release completes the set, by tracking the change in value within the "transparent" pool (more precisely, the value stored in Bitcoin-style UTXOs).

zcashd also now tracks the change in "chain supply" for each block, defined as the sum of coinbase output values, minus unclaimed fees. This is precisely equal to the sum of the value in the transparent and shielded pools, and equivalent to the sum of all unspent coins/notes on the chain. It is bounded above by the theoretical maximum supply, but in practice is lower due to, for example, miners not claiming transaction fees.

Bitcoin-style consensus rules implement fees as an imbalance between spent coins/notes and newly-created coins/notes. The consensus rules require that a coinbase transaction's outputs have a total value no greater than the sum of that block's subsidy and the fees made available by the transactions in the block. However, the consensus rules do not require that all of the available funds are claimed, and a miner can create coinbase transactions with lower value in the outputs (though in the case of Zcash, the consensus rules do require the transaction to include ZIP 1014 Funding Stream outputs).

After upgrading to v5.4.0, zcashd will start tracking changes in transparent pool value and chain supply from the height at which it is restarted. Block heights prior to this will not have any information recorded. To track changes from genesis, and thus monitor the total transparent pool size and chain supply, you would need to restart your node with the -reindex option.

Wallet Performance Fixes

The 100MiB memory limit for the batch scanner has been replaced by a 1000-block limit. This eliminates an expensive call to determine the current memory usage of the batch scanner.

The following associated metric has been removed from the set of metrics reported when -prometheusport is set:

  • (gauge) zcashd.wallet.batchscanner.usage.bytes

RPC Changes

  • z_sendmany will no longer select transparent coinbase when "ANY_TADDR" is used as the fromaddress. It was already documented to do this, but the previous behavior didn’t match. When coinbase notes were selected in this case, they would (properly) require that the transaction didn’t have any change, but this could be confusing, as the documentation stated that these two conditions (using "ANY_TADDR" and disallowing change) wouldn’t coincide.
  • A new value pool object with "id": "transparent" has been added to the valuePools list in getblockchaininfo and getblock.
  • A new chainSupply key has been added to getblockchaininfo and getblock to report the total chain supply as of that block height (if tracked), and the change in chain supply caused by the block (for getblock, if measured).

Mining

  • Changes to getblocktemplate have been backported from upstream Bitcoin Core, to significantly improve its performance by doing more work ahead of time in the mempool (and reusing the work across multiple getblocktemplate calls).

Deprecations

The following features have been deprecated, but remain available by default. These features may be disabled by setting -allowdeprecated=none. 18 weeks after this release, these features will be disabled by default and the following flags to -allowdeprecated will be required to permit their continued use:

  • gbt_oldhashes: the finalsaplingroothash, lightclientroothash, and blockcommitmentshash fields in the output of getblocktemplate have been replaced by the defaultroots field.

The following previously-deprecated features have been disabled by default, and will be removed in 18 weeks:

  • legacy_privacy
  • getnewaddress
  • getrawchangeaddress
  • z_getnewaddress
  • z_listaddresses
  • addrtype
  • wallettxvjoinsplit

The following previously-deprecated features have been removed:

  • dumpwallet
  • zcrawreceive
  • zcrawjoinsplit
  • zcrawkeygen

Platform Support

  • CentOS 8 has been removed from the list of supported platforms. It reached EoL on December 31st 2021, and does not satisfy our Tier 2 policy requirements.

v5.3.2(Dec 13, 2022)

Notable changes

Fixed

This is a hotfix release that fixes a regression in memory usage during Initial Block Download. The regression was indirectly caused by a change to prioritize downloading headers (PR #6231), introduced in release 5.3.1. It caused memory usage for new nodes to spike to roughly 11 GiB about an hour after starting Initial Block Download.

The issue fixed by this release does not affect nodes that start from a fully synced chain, or that had sufficient memory available to get past the memory usage spike.

v5.3.1(Dec 13, 2022)

Notable changes

Fixed

This release fixes an error "Assertion uResultHeight == rewindHeight failed" (#5958) that could sometimes happen when restarting a node.

Memory Usage Improvement

The memory usage of zcashd has been reduced by not keeping Equihash solutions for all block headers in memory.

RPC changes

The following RPC methods that query wallet state now support an optional asOfHeight parameter, to execute the query as if it were run when the blockchain was at the height specified by this argument:

  • getbalance
  • getreceivedbyaddress
  • gettransaction (*)
  • getwalletinfo
  • listaddressgroupings
  • listreceivedbyaddress (*)
  • listsinceblock (*)
  • listtransactions
  • listunspent (*)
  • z_getbalanceforaccount
  • z_getbalanceforviewingkey
  • z_getmigrationstatus
  • z_getnotescount
  • z_listreceivedbyaddress
  • z_listunspent

(*) For these methods, additional parameters have been added to maintain compatibility of parameter lists with Bitcoin Core. Default values should be passed for these additional parameters in order to use asOfHeight. See the RPC documentation for details.

Contents

    zcash Zcash - Internet Money
    paritytech Parity-Zcash — Rust implementation of the Zcash protocol
    nginnever an OpenCL Zcash GPU miner
    matter-labs-archive sapling-crypto_ce - Cryptographic library for Zcash Sapling with more content
    TencentOpen KNV(Key-N-Value) is a very fast protocol engine for manipulating protocol data without knowing the detail of its contents. KNV serves for 3 main purposes: 1, As a fast protocol engine, supporting 1M+ processes per second; 2, As a schema-free protocol inspecter/modifier for general-purpose network server; 3, As a protocol and data storage engine for general data storage server.
    mbevand Zcash miner optimized for AMD & Nvidia GPUs
    mafintosh Base encodings for protocol-buffers
    alexeyxo Google ProtocolBuffers for Apple Swift
    nimiq Official JavaScript implementation of the Nimiq protocol
    google A Git protocol parser written in Go.
    bandprotocol Monolithic repository of everything Band Protocol
    protocolbuffers Protocol Buffers - Google's data interchange format
    dylanmckay protocol — Custom TCP/UDP protocol definitions
    Covertness coap-rs Constrained Application Protocol(CoAP) Covertness/coap-rs — A Constrained Application Protocol(CoAP) library for Rust.
    FreeRDP FreeRDP is a free remote desktop protocol library and clients
    GoogleChromeLabs A TypeScript implementation of the Android Debug Bridge(ADB) protocol over WebUSB
    mitchellh Finger protocol library
    ziglibs Microsoft's Language Server Protocol implemented in Zig for use in zls and beyond! <3
    openssl TLS/SSL and crypto library
    r-efi r-efi - UEFI Reference Specification Protocol Constants and Definitions
    mimblewimble Minimal implementation of the Mimblewimble protocol.
    Share this repo

    Related Repos


    Cryptocurrencies
    5
    A retroactively minted Bitcoin NFT
    casey Bitcoin Atoms Discover the current whereabouts of Bitcoin Atoms. Atoms are created, numbered, and transferred according to a few simple rules: Every n
     
    Cryptocurrencies
    4
    Utility for integration testing substrate runtimes
    polytope-labs substrate-simnode ⚙️ This library exists to allow substrate runtime developers test: complex pallets that require a full runtime runtime upgrades runt
     
    Cryptocurrencies
    787
    Emerging smart contract language for the Ethereum blockchain.
    ethereum Fe is an emerging smart contract language for the Ethereum blockchain. Overview Fe is a statically typed language for the Ethereum Virtual Machine (EV
     
    Cryptocurrencies
    5
    Use your bdk wallet to implement ldk lightning functionality
    johncantrell97 BDK-LDK The bdk-ldk library hopes to bridge the gaps needed to implement a ldk-based lightning client using a bdk::Wallet. Implements lightning::chain
     
    Cryptocurrencies
    3
    App for ethical dealers who trade bitcoin for government shitcoins and vice-versa.
    Kixunil Vekslosh (Veksloš) Warning: Just a proof of concept - result of hackathon! App for ethical dealers who trade bitcoin for government shitcoins and vice
     
    Cryptocurrencies
    4
    detect timestamp of all scene changes in video
    soruly detect-scene-change detect timestamp of all scene changes in video Usage cargo run <video> <threshold [0-1]> $ cargo run foo.mp4 0.03 Finished dev
     
    Cryptocurrencies
    12
    A hitchhiker's guide to the Ethereum dAppiverse
    vunderkind ethereum-dappiverse A hitchhiker's guide to the Ethereum dAppiverse Introduction/Justification The Ethereum blockchain is home to innovations and some
     
    Cryptocurrencies
    3
    I try to implement a linked list in rust. You can use it if you want to. You can modify th...
    kelvindoe22 Not Great Linked List in Rust You can use this if you want to and modify it however you want. Check my ReadME if you want to contact me. Will Add comm
     
    Cryptocurrencies
    299
    a graphical tool to visualize binary data
    sharkdp Examples • Screencast • How it works • Installation binocle is a graphical tool to visualize binary data. It colorizes bytes according to different ru
     
    Cryptocurrencies
    14
    Una lista di risorse in italiano per Bitcoin
    mirserena risorsebitcoin by Mir La mia lista di RISORSE su Bitcoin IN ITALIANO. Quindi, in sostanza, l'idea è che potete anche non conoscere l'inglese (oltre a
     
    Cryptocurrencies
    102
    Rust client to Opensea's APIs and Ethereum smart contracts
    gakonst opensea.rs Rust bindings & CLI to the Opensea API and Contracts CLI Usage Run cargo r -- --help to get the top level help menu: opensea-cli 0.1.0 Choo
     
    Cryptocurrencies
    201
    HyperCube is a free and open source blockchain project for everyone to use.
    hypercube-lab HyperCube is a free and open source blockchain project for everyone to use.
     
    Cryptocurrencies
    20
    The best links to articles debunking Bitcoin FUD.
    pox End The FUD Energy "Bitcoin wastes energy" How Much Energy Does Bitcoin Actually Consume? Three Myths about Bitcoin’s Energy Consumption On Bitcoin's
     
    Cryptocurrencies
    19
    Iterate over bitcoin blocks
    RCasatta Blocks iterator Iterates over Bitcoin blocks, decoding data inside Bitcoin Core's blocks directory. Features: Blocks are returned in height order, it
     
    Cryptocurrencies
    286
    Skyward Finance smart-contracts
    skyward-finance Build and Init ./build.sh near dev-deploy res/skyward.was export CONTRACT_ID=skyward.testnet near call $CONTRACT_ID new --account_id=$CONTRACT_ID Regi