Zcash - Internet Money

Overview

Zcash 4.4.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.
  • 💬 Join our 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. See the Debian / Ubuntu build for detailed instructions.

License

For license information see the file COPYING.

Issues
  • Write spec for Harmony Mining

    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 by nathan-at-least 173
  • Asymmetric payment construction

    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 by ebfull 150
  • select difficulty adjustment algorithm

    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 by nathan-at-least 105
  • Experimental feature: remote proving service

    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 PR_cleanup 
    opened by str4d 89
  • [macOS] Darwin build patches

    [macOS] Darwin build patches

    Part of #2246.

    I-SECURITY A-build O-macos portability 
    opened by str4d 80
  • Optimize Equihash implementation

    Optimize Equihash implementation

    There are several ways our initial release of Equihash are suboptimal for memory usage and time. Let's do a subsequent release to improve those so that we can set the parameters (#856) appropriately.

    We don't have to do every possible optimization, but enough that it's feasible to run a miner with the right parameters.

    A-pow 
    opened by nathan-at-least 80
  • Windows cross-compile support

    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 by str4d 80
  • Add Note tracking

    Add Note tracking

    This PR extends the existing transaction tracking in the wallet to track spendable Notes.

    Closes #1199

    A-wallet S-waiting-on-review 
    opened by str4d 77
  • Bitcoin Core refactoring and cleanups 1

    Bitcoin Core refactoring and cleanups 1

    Cherry-picked from the following upstream PRs:

    • bitcoin/bitcoin#6538
    • bitcoin/bitcoin#6163
    • bitcoin/bitcoin#6982
    • bitcoin/bitcoin#6986
    • bitcoin/bitcoin#7053
    • bitcoin/bitcoin#7444
    • bitcoin/bitcoin#7793
      • Excluding some comments in txmempool.h on code we haven't yet pulled in.
    • bitcoin/bitcoin#7916
    • bitcoin/bitcoin#7815

    Additionally, the Equihash parameters are moved into the consensus parameters, and various other functions in main.cpp have const CChainParams& arguments added.

    Part of #2074.

    A-documentation C-upstream-port C-cleanup A-consensus 
    opened by str4d 73
  • [Sapling] specify Pedersen hashes for a collision-resistant hash function inside the SNARK

    [Sapling] specify Pedersen hashes for a collision-resistant hash function inside the SNARK

    from https://github.com/zcash/zcash/issues/2230

    Ian Miers noticed that a pedersen hash is an exceptionally good application for this fast ECC. Pedersen hashes have been mentioned in papers spanning decades, but have been largely ignored due to inefficiency. However, in our case they are perfect. Inside the circuit they are very competitive with MiMC (a hash function submitted to Asiacrypt last year) except that a pedersen hash has collision resistance that reduces to discrete log -- far more believable than their construction.

    In particular, we select a vector g of n group elements of unknown exponent, and given a vector x of n scalar bits, we compute:

    g1x1 g2x2 ... gnxn

    It is trivial to see that finding a collision requires defeating discrete log in the group. Further, in our construction we can return the y coordinate of the result, which is a single field scalar. (Recall that in Edwards curves, the x coordinate encodes the sign.) Because the group order is an odd prime, collision resistance still reduces to discrete log.

    I-SECURITY C-research A-crypto I-performance A-circuit special to Zooko M-requires-nu NU1-sapling elliptic curves 
    opened by zookozcash 71
  • Revert 1 imgbot

    Revert 1 imgbot

    Please ensure this checklist is followed for any pull requests for this repo. This checklist must be checked by both the PR creator and by anyone who reviews the PR.

    • [x] Relevant documentation for this PR has to be completed and reviewed by @mdr0id before the PR can be merged
    • [x] A test plan for the PR must be documented in the PR notes and included in the test plan for the next regular release

    As a note, all buildbot tests need to be passing and all appropriate code reviews need to be done before this PR can be merged

    opened by Psyruss77 0
  • Prerequisites for adding unified addresses to the wallet.

    Prerequisites for adding unified addresses to the wallet.

    This is a small collection of minor refactoring and non-functional changes in preparation for adding unified spending/viewing key support to the zcashd wallet.

    safe-to-build 
    opened by nuttycom 0
  • Add unified addresses to the zcashd wallet.

    Add unified addresses to the zcashd wallet.

    Fixes #5179

    opened by nuttycom 0
  • Add Orchard key support to `ZcashdUnified*` types

    Add Orchard key support to `ZcashdUnified*` types

    Up until this point, support for handling wallet-generated Orchard keys and protocol addresses has been developed separately from handling wallet-generated USKs and UAs. For this issue, we will add an Orchard type to the wallet's USK etc. types.

    This is the equivalent issue to #5256 but deals with wallet-generated keys and addresses (where we know the full set of types to support), rather than user-supplied external addresses (where we need to handle arbitrary receiver types).

    A-wallet S-committed A-orchard 
    opened by str4d 0
  • (low priority) zcashd excessive logging if network is unreachable

    (low priority) zcashd excessive logging if network is unreachable

    This is a low-priority problem, seen with v4.5.1 but probably on all releases. If the network is unavailable, zcashd logs one or two messages per second (looks like for each peer) to debug.log, for example:

    Nov 19 08:21:40.663  INFO main: connect() to 199.182.185.44:8233 failed after select(): Network is unreachable (101)
    Nov 19 08:21:41.265  INFO main: connect() to [2408:8207:7839:35a0:f5c4:d6c5:c995:2440]:8233 failed: Network is unreachable (101)
    Nov 19 08:21:41.771  INFO main: connect() to 13.59.196.177:8233 failed after select(): Network is unreachable (101)
    Nov 19 08:21:42.274  INFO main: connect() to 88.11.237.105:8233 failed after select(): Network is unreachable (101)
    Nov 19 08:21:42.775  INFO main: connect() to 172.98.67.36:8233 failed after select(): Network is unreachable (101)
    Nov 19 08:21:43.276  INFO main: connect() to 159.89.20.210:8233 failed after select(): Network is unreachable (101)
    Nov 19 08:21:43.778  INFO main: connect() to 151.38.14.78:8233 failed after select(): Network is unreachable (101)
    Nov 19 08:21:44.280  INFO main: connect() to [2001:470:d:1355::201]:8233 failed: Network is unreachable (101)
    

    This happened on my system overnight, and the debug.log file is 500 MB and growing unbounded. This could potentially run the file system out of space, depending of course on the amount of space available and how long this situation persists.

    Logging that the network is unreachable is beneficial, but perhaps it should occur less often. It may be worth considering using an exponential backoff algorithm, where it logs every second (or so) for a few seconds, then doubling to no more often than every 2 seconds, then every 4 seconds, and so on, to some upper limit such as every 10 minutes or one hour. That's still unbounded growth, the constant factor is much smaller, so shouldn't be a problem in practice.

    When zcashd starts up, I thought that it trims the debug.log file to the most recent 10 MB of logging entries, but I just noticed that it does not. This functionality was disabled in #4144 (first commit) and makes this problem a bit more severe. There's a comment in that PR asking why this functionality (the boolean -shrinkdebugfile command-line argument to zcashd) was removed, but this comment was never responded to. I think we should restore this functionality, even if we retain the default to not shrink the debug log file (although I can't think of a reason why shrinking shouldn't occur by default). Tag @str4d.

    C-bug A-networking A-logging 
    opened by LarryRuane 0
  • Sapling-version error.

    Sapling-version error.

    Hi! I'm trying to send money in testnet network.

    My testnet node settings:

    curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' http://mytestnode {"result":{"version":4050150,"build":"v4.5.1","subversion":"/MagicBean:4.5.1/","protocolversion":170015,"walletversion":60000,"balance":6.00000000,"blocks":1654490,"timeoffset":0,"connections":3,"proxy":"","difficulty":12.05895070957058,"testnet":true,"keypoololdest":1636016994,"keypoolsize":101,"paytxfee":0.00000000,"relayfee":0.00000100,"errors":"","errorstimestamp":1637330833},"error":null,"id":"curltest"}

    Next scheme:

    1. Get listunspent. curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listunspent", "params": [0, 999999, []] }' -H 'content-type: text/plain;' http://mytestnode

    2. Build inputs and outputs. curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params":[[{"txid":"32a77d45ccbfa2c4c5bf486b6f2f1bfa2b449d0bed8cff7bcb635b179c063385","vout":1}],{"tmLLt81KbAzEmy1WjDsyTnNjUE4KvTvZ6NJ":0.01}] }' -H 'content-type: text/plain;' http://mytestnode

    3. I sign raw transaction. curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "signrawtransaction", "params": ["050000800a27a7262196513700000000123f1900018533069c175b63cb7bff8ced0b9d442bfa1b2f6f6b48bfc5c4a2bfcc457da7320100000000ffffffff0140420f00000000001976a9148c69e0394f0683820d43b12b96306a1da6a2579788ac000000"] }' -H 'content-type: text/plain;' http://mytestnode

    4. Send raw transaction. curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendrawtransaction", "params": ["050000800a27a7262196513700000000123f1900018533069c175b63cb7bff8ced0b9d442bfa1b2f6f6b48bfc5c4a2bfcc457da732010000006b483045022100cc89602a500adc179d9744e2affbc2ef731e5451c8494948efd0fbbb63c8108702202e7e9360de2f767102435903fcb058a449f4782ab333779f56c91b5877845501012102cd5d93ffa6d75a5512b86a606a9f1320559fcbfc3b833fc4fada5662ef7d2cb6ffffffff0140420f00000000001976a9148c69e0394f0683820d43b12b96306a1da6a2579788ac000000"] }' -H 'content-type: text/plain;' http://mytestnode

    I get response: {"result":null,"error":{"code":-26,"message":"64: sapling-version"},"id":"curltest"}

    What am I doing wrong ?

    opened by asovetnikov 0
  • Add Orchard support to the zcashd wallet.

    Add Orchard support to the zcashd wallet.

    This is the long-lived feature branch providing Orchard support and mnemonic-seed based recovery to the zcashd wallet.

    This PR must not be rebased; instead, master will be merged into it as necessary to fix merge conflicts.

    A-wallet NU5 A-orchard 
    opened by nuttycom 1
  • Release v5.0.0

    Release v5.0.0

    null

    release 
    opened by str4d 0
  • Release v5.0.0-rc1

    Release v5.0.0-rc1

    null

    release 
    opened by str4d 0
  • Update orchard crate and NU5 branch ID, and set activation heights

    Update orchard crate and NU5 branch ID, and set activation heights

    We will be rolling back testnet alongside the mainnet activation definition, because we are making final cleanup changes to the Orchard Action circuit.

    A-consensus A-circuit NU5 A-orchard 
    opened by str4d 1
Releases(v4.5.1-1)
  • v4.5.1-1(Oct 10, 2021)

    Notable changes

    Added v5 transactions to standard rules

    In v4.5.0 we added the v5 transaction format to the NU5 consensus rules for testnet. However, it was omitted from the standard rules, which meant that zcashd testnet nodes would not accept v5 transactions into their mempools, causing them to not be propagated or mined. This release updates the zcashd standard rules to accept v5 transactions alongside v4 transactions.

    New listaddresses RPC method

    The listaddresses endpoint has been added to the RPC API. This method allows the caller to obtain addresses managed by the wallet, grouped by the source of the address, including both those addresses generated by the wallet and those associated with imported viewing or spending keys. This provides functionality that replaces and subsumes the previously removed getaddressesbyaccount method.

    Source code(tar.gz)
    Source code(zip)
  • v4.5.1(Sep 29, 2021)

    TL;DR: This is a required update for all testnet nodes, and is highly recommended for mainnet nodes if you are using the getbalance RPC method.

    If you are running zcashd in Docker, you may need to upgrade Docker to a recent version. Version 19.03.12 is reported to work.

    Notable changes

    Fixed bugs in the testnet Orchard circuit

    In the zcashd v4.5.0 release notes we indicated that a testnet rollback might occur to update the consensus rules, if we needed to make backwards-incompatible changes. Shortly after zcashd v4.5.0 was released, during another internal review of the Orchard circuit, we identified two bugs that would affect the upcoming testnet activation of NU5:

    • The diversifier base g_d_old, for the note being spent, is required to be a non-identity point. A note created from a payment address with g_d set to the identity (via collaboration between sender and recipient) could be spent multiple times with different nullifiers (corresponding to different ivks). The code outside the circuit correctly enforced the non-identity requirement, but the circuit did not correctly constrain this, and allowed the prover to witness the identity.

    • SinsemillaCommit can be modeled as a Pedersen commitment to an output of SinsemillaHash: SinsemillaCommit(r, M) = SinsemillaHashToPoint(M) + [r] R. The specification used incomplete addition here, matching its use inside SinsemillaHash. However, unlike in SinsemillaHash, an exceptional case can be produced here when r = 0. The derivations of rivk (for computing ivk) and rcm (for computing the note commitment) normally ensure that r = 0 can only occur with negligible probability, but these derivations are not checked by the circuit for efficiency; thus SinsemillaCommit needs to use complete addition.

    These bugs do not affect mainnet, as zcashd v4.5.0 only set the activation height for NU5 on testnet for testing purposes. Nevertheless, in the interest of keeping the testnet environment as close to mainnet as possible, we are fixing these bugs immediately. This means a change to the NU5 consensus rules, and a new testnet activation height for NU5.

    To this end, the following changes are made in zcashd v4.5.1:

    • The consensus branch ID for NU5 is changed to 0x37519621.
    • The protocol version indicating NU5-aware testnet nodes is set to 170015.
    • The testnet activation height for NU5 is set to 1,599,200.

    Testnet nodes that upgrade to zcashd v4.5.1 prior to block height 1,590,000 will follow the new testnet network upgrade. Testnet nodes that are running zcashd v4.5.0 at that height will need to upgrade to v4.5.1 and then run with -reindex.

    As always, it is possible that further backwards incompatible changes might be made to the NU5 consensus rules in this testing phase, prior to setting the mainnet activation height, as we continue to conduct additional internal review. In the event that this happens, testnet will be rolled back in (or prior to) v5.0.0, and a new testnet activation will occur.

    Fixed regression in getbalance RPC method

    zcashd v4.5.0 removed the account API from the wallet, following its deprecation and removal in upstream Bitcoin Core. As part of the upstream changes, the getbalance RPC method was altered from using two custom balance computation methods, to instead relying on CWallet::GetBalance. This method internally relies on CWalletTx::IsFromMe as part of identifying "trusted" zero-confirmation transactions to include in the balance calculation.

    There is an equivalent and closely-named CWallet::IsFromMe method, which is used throughout the wallet, and had been updated before Zcash launched to be aware of spent shielded notes. The change to getbalance exposed a bug: CWalletTx::IsFromMe had not been similarly updated, which caused getbalance to ignore wallet-internal (sent between two addresses in the node's wallet) unshielding transactions with zero confirmations. This release fixes the bug.

    Source code(tar.gz)
    Source code(zip)
  • v4.5.0(Sep 23, 2021)

    Notable changes

    Network Upgrade 5

    The code preparations for the Network Upgrade 5 consensus rules are finished and included in this release. The following ZIPs are being deployed:

    NU5 will activate on testnet at height 1,590,000, and can also be activated at a specific height in regtest mode by setting the config option -nuparams=f919a198:HEIGHT.

    The testnet activation of NU5, and zcashd v4.5.0 itself, is aimed at enabling existing Zcash users to test their software and make the necessary changes to be compatible with the new consensus rules. In particular:

    • Wallets should start adding support for v5 transactions.
    • Miners and mining pools should ensure that their software is compatible with the semantic change to the block header specified in ZIP 244

    A subsequent v4.5.1 release in the coming weeks will add support for generating and using Unified Addresses (ZIP 316), which will enable zcashd wallets to interact with the Orchard shielded pool.

    As with previous network upgrades, it is possible that backwards-incompatible changes might be made to the consensus rules in this testing phase, prior to setting the mainnet activation height. In the event that this happens, testnet will be rolled back in v5.0.0 and a second testnet activation will occur.

    See ZIP 252 for additional information about the deployment process for NU5.

    Rejecting unknown CInv message types

    Previously, if zcashd received an inv or getdata message containing unknown CInv message types, it would ignore them and process the remainder of the message. Starting with v4.5.0, zcashd will instead drop the entire inv or getdata message and reply with a reject message. This will enable node operators to discover whether their nodes are sending unexpected CInv types; in particular, node operators should ensure their software does not produce the MSG_WTX CInv message type intended for the Bitcoin network, which is incompatible with the MSG_WTX CInv message type defined in ZIP 239 (which will be used from NU5 activation for advertising v5 transactions).

    Deprecated or removed RPCs

    • The 'account' API inherited from Bitcoin Core has been disabled since the launch of Zcash. Following its deprecation in Bitcoin Core v0.17 and removal in Bitcoin Core v0.18, we have now removed the API from zcashd.
    Source code(tar.gz)
    Source code(zip)
  • v4.4.1(Jun 10, 2021)

    Notable changes

    Fixed chain sync stall bug

    The 4.3.0 release included a change to prevent redundant getheaders P2P requests, to reduce node bandwith usage. This behaviour could be disabled by setting the config option -nooptimize-getheaders.

    It turns out that these redundant requests were masking an unrelated bug in the chain-rewinding logic that is used when the node detects a change to the consensus rules (for example, if a user forgets to upgrade their zcashd node before a network upgrade activates, and temporarily follows an un-upgraded chain before restarting with the latest version).

    In certain uncommon scenarios, a node could end up in a situation where it would believe that the best header it knew about was more than 160 blocks behind its actual best-known block. The redundant getheaders requests meant that this did not cause an issue, because the node would continue requesting headers until it found new blocks. After the getheaders optimizations, if a peer returned a headers message that was entirely known to the node, it would stop requesting more headers from that peer; this eventually caused node synchronization to stall. Restarting with the -nooptimize-getheaders config option would enable the node to continue syncing.

    This release fixes the bug at its source, but the -nooptimize-getheaders config option remains available if necessary.

    Build system changes

    • Cross-compilation support for Windows XP, Windows Vista, and 32-bit Windows binaries, has been removed. Cross-compiled Windows binaries are now 64-bit only, and target a minimum of Windows 7.
    Source code(tar.gz)
    Source code(zip)
  • v4.4.0(Apr 15, 2021)

    Notable changes

    Prometheus metrics

    zcashd can now be configured to optionally expose an HTTP server that acts as a Prometheus scrape endpoint. The server will respond to GET requests on any request path.

    To enable the endpoint, add -prometheusport=<port> to your zcashd configuration (either in zcash.conf or on the command line). After restarting zcashd you can then test the endpoint by querying it with e.g. curl http://127.0.0.1:<port>.

    The feature includes IP-level access control rules, the default being to allow connections only from localhost. Users of this feature should be aware of the threat from DNS rebinding attacks and not rely on these access control rules for security. The allowed IPs can be expanded with -metricsallowip=<ip>, which can specify IPs or subnets.

    Note that HTTPS is not supported, and therefore connections to the endpoint are not encrypted or authenticated. Access to the endpoint, including through DNS rebinding attacks, should be assumed to compromise the privacy of node operations, by the provided metrics and/or by timing side channels and so for now: You should NOT use this feature while private keys are loaded in zcashd.

    The specific metrics names may change in subsequent releases, in particular to improve interoperability with zebrad.

    Source code(tar.gz)
    Source code(zip)
  • v4.3.0(Feb 24, 2021)

    Notable changes

    Reduce download traffic

    We have made several changes to reduce the amount of data downloaded by zcashd during initial block download (IBD):

    • Significant time and bandwidth is spent in issuing getheaders P2P requests. This results in noticeable bandwidth usage due to the large size of Zcash block headers.

      We now eliminate redundant requests in cases where we already know the last header in the message. This optimization is enabled by default, but can be disabled by setting the config option -nooptimize-getheaders.

    • Transactions in the mempool are no longer downloaded during IBD (zcashd will only request block data).

    Reduce upload traffic

    A major part of the outbound traffic is caused by serving historic blocks to other nodes in initial block download state.

    It is now possible to reduce the total upload traffic via the -maxuploadtarget parameter. This is not a hard limit but a threshold to minimize the outbound traffic. When the limit is about to be reached, the uploaded data is cut by not serving historic blocks (blocks older than one week). Moreover, any SPV peer is disconnected when they request a filtered block.

    This option can be specified in MiB per day and is turned off by default (-maxuploadtarget=0). The recommended minimum is 1152 * MAX_BLOCK_SIZE (currently 2304MB) per day.

    Whitelisted peers will never be disconnected, although their traffic counts for calculating the target.

    A more detailed documentation about keeping traffic low can be found in /doc/reduce-traffic.md.

    libzcashconsensus replaced by libzcash_script

    The libzcashconsensus library inherited from upstream has been unusable since the Overwinter network upgrade in 2018. We made changes to signature digests similar to those made in Bitcoin's SegWit, which required additional per-input data that could not be added to the existing APIs without breaking backwards compatibility.

    Additionally, it has become increasingly inaccurately named; it only covers (Zcash's subset of) the Bitcoin scripting system, and not the myriad of other consensus changes: in particular, Zcash's shielded pools.

    We have now renamed the library to libzcash_script, and reworked it to instead focus on transparent script verification:

    • The script verification APIs are altered to take consensusBranchId and amount fields.
    • New precomputing APIs have been added that enable multiple transparent inputs on a single transaction to be verified more efficiently.
    • Equihash has been removed from the compiled library. The canonical Equihash validator is the equihash Rust crate since v3.1.0.

    The C++ library can be built by compiling zcashd with the environment variable CONFIGURE_FLAGS=--with-libs. It is also wrapped as the zcash_script Rust crate (maintained by the Zcash Foundation for use in zebrad).

    Other P2P Changes

    The list of banned peers is now stored on disk rather than in memory. Restarting zcashd will no longer clear out the list of banned peers; instead the clearbanned RPC method can be used to manually clear the list. The setban RPC method can also be used to manually ban or unban a peer.

    Build system updates

    • We now build with Clang 11 and Rust 1.49.
    • We have downgraded Boost to 1.74 to mitigate statx-related breakage in some container environments.
    Source code(tar.gz)
    Source code(zip)
  • v4.2.0(Dec 21, 2020)

    Notable changes

    Switch to ed25519-zebra for consensus signature checks

    This removes the zcashd dependency upon libsodium for ed25519 signature checks and instead uses the Rust implementation in ed25519-zebra, which has been active for signature verification since the Canopy upgrade. For more information on the conditions that led to this change see https://hdevalence.ca/blog/2020-10-04-its-25519am.

    Update default fees according to ZIP-313

    Reduce default fees to 0.00001 ZEC as specified in ZIP-313 and ensure that transactions paying at least the new minimum fee meet the transaction relay threshold irrespective of transaction size.

    Improve getblocktemplate rpc performance when using shielded coinbase

    This change precomputes future block templates to permit miners to begin working atop newly arrived blocks as quickly as possible, rather than waiting for a new template to be generated after a block has arrived. It also reduces the initial wait time for incorporating new mempool transactions into a block from 1 minute to 10 seconds; the previous value was inherited from the upstream bitcoin codebase but is inappropriate for our block timing.

    Migrate from rpc-tests.sh to rpc-tests.py

    This unifies and simplifies the RPC testing framework, as has been done in the upstream Bitcoin codebase.

    Source code(tar.gz)
    Source code(zip)
  • v4.1.1(Nov 17, 2020)

    Notable changes

    This release is a hotfix release that addresses a performance regression in v4.1.0. It is recommended that either v4.0.0 or this release, v4.1.1 be used for Canopy activation.

    Optimize release build

    The release build now sets CFLAGS/CXXFLAGS to use the -O3 optimization option, which turns on more optimization flags than the previously used -O1. This produces a faster build, addressing a performance regression in v4.1.0.

    Correctly report Founders' Reward amount in getblocktemplate

    This release correctly returns the foundersreward field from getblocktemplate output pre-Canopy and removes the field post-Canopy. (The Founders' Reward will expire exactly as Canopy activates, as specified in ZIP 207.) To obtain information about funding stream amounts, use getblocksubsidy HEIGHT, passing in the height returned by the getblocktemplate API.

    Source code(tar.gz)
    Source code(zip)
  • v4.1.0(Nov 10, 2020)

    Notable changes

    Migration to Clang and static libc++

    zcashd now builds its C++ (and C) dependencies entirely with a pinned version of Clang, and statically links libc++ instead of dynamically linking libstdc++. This migration enables us to reliably use newer C++ features while supporting older LTS platforms, be more confident in the compiler's optimisations, and leverage security features such as sanitisers and efficient fuzzing. In future, this will also allow optimizing across the boundary between Rust and C++.

    The system compiler is still used to compile a few native dependencies (used by the build machine to then compile zcashd for the target machine). These will likely also be migrated to use the pinned Clang in a future release.

    Fast sync for initial block download

    The -ibdskiptxverification flag allows faster synchronization during initial block sync, by skipping transaction verification and instead verifying only PoW. Note that this mode requires checkpoints to be enabled, to make sure that each block under inspection is an ancestor of the latest checkpoint.

    Convenient testing for invalid note plaintexts

    After the mainnet activation of Canopy (block 1046400), correct wallet software will no longer produce v1 note plaintexts (with a lead byte of 0x01). However, v1 note plaintexts will continue to be accepted for a grace period of 32256 blocks (about 4 weeks), as specified in ZIP 212. The new receiveunsafe log category complains if an invalid note plaintext is received.

    Additional lightwalletd and light client RPCs

    • lightwalletd is now able to retrieve all UTXOs related to a t-address through the getaddressutxos RPC. (Previously, this was only available to the Insight Explorer.)
    • The new z_gettreestate RPC returns the Sprout and Sapling treestate at a given block height or block hash. This makes it easier for light clients to generate checkpoints.

    Update/removal of several cryptographic dependencies

    This release updates secp256k1 to enable the GLV endomorphism optimisation by default, after the recent expiry of the GLV patents. It also removes OpenSSL, and replaces libsodium BLAKE2b usage with the blake2b_simd Rust crate.

    Source code(tar.gz)
    Source code(zip)
  • v4.0.0(Sep 1, 2020)

    Notable changes

    The mainnet activation of the Canopy network upgrade is supported by the 4.0.0 release, with an activation height of 1046400, which should occur roughly in the middle of November — following the targeted EOS halt of our 3.1.0 release. Please upgrade to this release, or any subsequent release, in order to follow the Canopy network upgrade.

    The following ZIPs are being deployed as part of this upgrade:

    In order to help the ecosystem prepare for the mainnet activiation, Canopy has already been activated on the Zcash testnet. Any node version 3.1.0 or higher, including this release, supports the Canopy activation on testnet.

    Disabling new value in the Sprout value pool

    After the mainnet activation of Canopy, it will not be possible to send funds to Sprout z-addresses from any other kind of address, as described in ZIP 211. It will still be possible to send funds from a Sprout z-address and to send funds between Sprout addresses. Users of Sprout z-addresses are encouraged to use Sapling z-addresses instead, and to migrate their remaining Sprout funds into a Sapling z-address using the migration utility in zcashd: set migrate=1 in your zcash.conf file, or use the z_setmigration RPC.

    New logging system

    The zcashd logging system is now powered by the Rust tracing crate. This has two main benefits:

    • tracing supports the concept of "spans", which represent periods of time with a beginning and end. These enable logging additional information about temporality and causality of events. (Regular log lines, which represent moments in time, are called events in tracing.)
    • Spans and events are structured, and can record typed data in addition to text messages. This structure can then be filtered dynamically.

    The existing -debug=target config flags are mapped to tracing log filters, and will continue to correctly enable additional logging when starting zcashd. A new setlogfilter RPC method has been introduced that enables reconfiguring the log filter at runtime. See zcash-cli help setlogfilter for its syntax.

    As a minor note, zcashd no longer reopens the debug.log file on SIGHUP. This behaviour was originally introduced in upstream Bitcoin Core to support log rotation using external tools. tracing supports log rotation internally (which is currently disabled), as well as a variety of interesting backends (such as journald and OpenTelemetry integration); we are investigating how these might be exposed in future releases.

    Compatibility

    macOS versions earlier than 10.12 (Sierra) are no longer supported.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.0(Jul 28, 2020)

    Notable changes

    Network Upgrade 4: Canopy

    The code preparations for the Canopy network upgrade are finished and included in this release. The following ZIPs are being deployed:

    Canopy will activate on testnet at height 1028500, and can also be activated at a specific height in regtest mode by setting the config option -nuparams=0xe9ff75a6:HEIGHT. Note that v3.1.0 enables Canopy support on the testnet.

    Canopy will activate on mainnet at height 1046400.

    See ZIP 251 for additional information about the deployment process for Canopy.

    Debian 8 "Jessie" will no longer be supported after v3.1.0, due to its end-of-life on June 30th, 2020. This will allow us to direct more resources to supporting Debian 10 Buster, other Linux distributions, and other platforms such as Windows and macOS.

    Flush witness data to disk only when it's consistent

    This fix prevents the wallet database from getting into an inconsistent state. By flushing witness data to disk from the wallet thread instead of the main thread, we ensure that the on-disk block height is always the same as the witness data height. Previously, the database occasionally got into a state where the latest block height was one ahead of the witness data. This then triggered an assertion failure in CWallet::IncrementNoteWitnesses() upon restarting after a zcashd shutdown.

    Note that this code change will not automatically repair a data directory that has been affected by this problem; that requires starting zcashd with the -rescan or -reindex options.

    New DNS seeders

    DNS seeders hosted at "zfnd.org" and "yolo.money" have been added to the list in chainparams.cpp. They're running CoreDNS with a Zcash crawler plugin, the result of a Zcash Foundation in-house development effort to replace zcash-seeder with something memory-safe and easier to maintain.

    These are validly operated seeders per the existing policy. For general questions related to either seeder, contact [email protected] or mention @gtank in the Zcash Foundation's Discord. For bug reports, open an issue on the dnsseeder repo.

    Changed command-line options

    • -debuglogfile=<file> can be used to specify an alternative debug logging file.

    RPC methods

    • joinSplitPubKey and joinSplitSig have been added to verbose transaction outputs. This enables the transaction's binary form to be fully reconstructed from the RPC output.
    • The output of getblockchaininfo now includes an estimatedheight parameter. This can be shown in UIs as an indication of the current chain height while zcashd is syncing, but should not be relied upon when creating transactions.

    Metrics screen

    • A progress bar is now visible when in Initial Block Download mode, showing both the prefetched headers and validated blocks. It is only printed for TTY output. Additionally, the "not mining" message is no longer shown on mainnet, as the built-in CPU miner is not effective at the current network difficulty.
    • The number of block headers prefetched during Initial Block Download is now displayed alongside the number of validated blocks. With current compile-time defaults, a Zcash node prefetches up to 160 block headers per request without a limit on how far it can prefetch, but only up to 16 full blocks at a time.
    Source code(tar.gz)
    Source code(zip)
  • v3.0.0(May 27, 2020)

    The mainnet activation of the Heartwood network upgrade is supported by this release, with an activation height of 903000, which should occur in the middle of July — following the targeted EOS halt of our 2.1.2-3 release. Please upgrade to this release, or any subsequent release, in order to follow the Heartwood network upgrade.

    The following two ZIPs are being deployed as part of this upgrade:

    In order to help the ecosystem prepare for the mainnet activiation, Heartwood has already been activated on the Zcash testnet. Any node version 2.1.2 or higher, including this release, supports the Heartwood activation on testnet.

    Mining to Sapling addresses

    After the mainnet activation of Heartwood, miners can mine directly into a Sapling shielded address. Miners should wait until after Heartwood activation before they make changes to their configuration to leverage this new feature. After activation of Heartwood, miners can add mineraddress=SAPLING_ADDRESS to their zcash.conf file, where SAPLING_ADDRESS represents a Sapling address that can be generated locally with the z_getnewaddress RPC command. Restart your node, and block templates produced by the getblocktemplate RPC command will now have coinbase transactions that mine directly into this shielded address.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.2-3(May 10, 2020)

    This release fixes a crash on testnet that v2.1.2 nodes are likely to experience on startup. This release also allows nodes that did not follow the testnet activation of Heartwood to properly roll back and follow the Heartwood activation on testnet.

    In addition, we have ensured that this release’s end-of-service halt is in the middle of July, just prior to our anticipated activation of Heartwood on mainnet.

    We recommend that anyone testing their integration with Heartwood should upgrade to this release.

    As a reminder, 2.1.2 included the following major changes:

    • Support for Sapling viewing keys (specifically, Sapling extended full viewing keys, as described in ZIP 32), has been added to the wallet. Nodes will track both sent and received transactions for any Sapling addresses associated with the imported Sapling viewing keys.

    • Removal of time adjustment and the -maxtimeadjustment= option. Prior to v2.1.1-1, zcashd would adjust the local time that it used by up to 70 minutes, according to a median of the times sent by the first 200 peers to connect to it. This mechanism was inherently insecure, since an adversary making multiple connections to the node could effectively control its time within that +/- 70 minute window (this is called a "timejacking attack"). As a simplification the time adjustment code has now been completely removed, together with -maxtimeadjustment=. Node operators should instead ensure that their local time is set reasonably accurately.

    • View shielded information in wallet transactions. In previous zcashd versions, there were no RPC methods that directly returned details about spends, or anything equivalent to the gettransaction method (which returns transparent information about in-wallet transactions). This release introduces a new RPC method z_viewtransaction to fill that gap.

    • Better error messages for rejected transactions after network upgrades. Starting from this release, zcashd nodes will re-verify invalid transparent and Sprout signatures against the consensus branch ID from before the most recent network upgrade. If the signature then becomes valid, the transaction will be rejected with the error message old-consensus-branch-id. This error can be handled specifically by wallet providers to inform the user that they need to upgrade their wallet software.

    • A new config option -txexpirynotify has been added that will cause zcashd to execute a command when a transaction in the mempool expires.

    • The z_importkey and z_importviewingkey RPC methods now return the type of the imported spending or viewing key (sprout or sapling), and the corresponding payment address.

    • Negative heights are now permitted in getblock and getblockhash, to select blocks backwards from the chain tip. A height of -1 corresponds to the last known valid block on the main chain.

    • A new RPC method getexperimentalfeatures returns the list of enabled experimental features.

    • The --enable-lcov, --disable-tests, and --disable-mining flags for zcutil/build.sh have been removed. You can pass these flags instead by using the CONFIGURE_FLAGS environment variable. Also, the build system no longer defaults to verbose output.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.2(Apr 22, 2020)

    Notable changes

    Network Upgrade 3: Heartwood

    The code preparations for the Heartwood network upgrade are finished and included in this release. The following ZIPs are being deployed:

    Heartwood will activate on testnet at height 903800, and can also be activated at a specific height in regtest mode by setting the config option -nuparams=f5b9230b:HEIGHT.

    As a reminder, because the Heartwood activation height is not yet specified for mainnet, version 2.1.2 will behave similarly as other pre-Heartwood releases even after a future activation of Heartwood on the network. Upgrading from 2.1.2 will be required in order to follow the Heartwood network upgrade on mainnet.

    See ZIP 250 for additional information about the deployment process for Heartwood.

    Mining to Sapling addresses

    Miners and mining pools that wish to test the new "shielded coinbase" support on the Heartwood testnet can generate a new Sapling address with z_getnewaddress, add the config option mineraddress=SAPLING_ADDRESS to their zcash.conf file, and then restart their zcashd node. getblocktemplate will then return coinbase transactions containing a shielded miner output.

    Note that mineraddress should only be set to a Sapling address after the Heartwood network upgrade has activated; setting a Sapling address prior to Heartwood activation will cause getblocktemplate to return block templates that cannot be mined.

    Sapling viewing keys support

    Support for Sapling viewing keys (specifically, Sapling extended full viewing keys, as described in ZIP 32), has been added to the wallet. Nodes will track both sent and received transactions for any Sapling addresses associated with the imported Sapling viewing keys.

    • Use the z_exportviewingkey RPC method to obtain the viewing key for a shielded address in a node's wallet. For Sapling addresses, these always begin with "zxviews" (or "zxviewtestsapling" for testnet addresses).

    • Use z_importviewingkey to import a viewing key into another node. Imported Sapling viewing keys will be stored in the wallet, and remembered across restarts.

    • z_getbalance will show the balance of a Sapling address associated with an imported Sapling viewing key. Balances for Sapling viewing keys will be included in the output of z_gettotalbalance when the includeWatchonly parameter is set to true.

    • RPC methods for viewing shielded transaction information (such as z_listreceivedbyaddress) will return information for Sapling addresses associated with imported Sapling viewing keys.

    Details about what information can be viewed with these Sapling viewing keys, and what guarantees you have about that information, can be found in ZIP 310.

    Removal of time adjustment and the -maxtimeadjustment= option

    Prior to v2.1.1-1, zcashd would adjust the local time that it used by up to 70 minutes, according to a median of the times sent by the first 200 peers to connect to it. This mechanism was inherently insecure, since an adversary making multiple connections to the node could effectively control its time within that +/- 70 minute window (this is called a "timejacking attack").

    In the v2.1.1-1 security release, in addition to other mitigations for timejacking attacks, the maximum time adjustment was set to zero by default. This effectively disabled time adjustment; however, a -maxtimeadjustment= option was provided to override this default.

    As a simplification the time adjustment code has now been completely removed, together with -maxtimeadjustment=. Node operators should instead ensure that their local time is set reasonably accurately.

    If it appears that the node has a significantly different time than its peers, a warning will still be logged and indicated on the metrics screen if enabled.

    View shielded information in wallet transactions

    In previous zcashd versions, to obtain information about shielded transactions you would use either the z_listreceivedbyaddress RPC method (which returns all notes received by an address) or z_listunspent (which returns unspent notes, optionally filtered by addresses). There were no RPC methods that directly returned details about spends, or anything equivalent to the gettransaction method (which returns transparent information about in-wallet transactions).

    This release introduces a new RPC method z_viewtransaction to fill that gap. Given the ID of a transaction in the wallet, it decrypts the transaction and returns detailed shielded information for all decryptable new and spent notes, including:

    • The address that each note belongs to.
    • Values in both decimal ZEC/TAZ and zatoshis.
    • The ID of the transaction that each spent note was received in.
    • An outgoing flag on each new note, which will be true if the output is not for an address in the wallet.
    • A memoStr field for each new note, containing its text memo (if its memo field contains a valid UTF-8 string).

    Information will be shown for any address that appears in z_listaddresses; this includes watch-only addresses linked to viewing keys imported with z_importviewingkey, as well as addresses with spending keys (both generated with z_getnewaddress and imported with z_importkey).

    Better error messages for rejected transactions after network upgrades

    The Zcash network upgrade process includes several features designed to protect users. One of these is the "consensus branch ID", which prevents transactions created after a network upgrade has activated from being replayed on another chain (that might have occurred due to, for example, a friendly fork). This is known as "two-way replay protection", and is a core requirement by various members of the cryptocurrency ecosystem for supporting "hard fork"-style changes like our network upgrades.

    One downside of the way replay protection is implemented in Zcash, is that there is no visible difference between a transaction being rejected by a zcashd node due to targeting a different branch, and being rejected due to an invalid signature. This has caused issues in the past when a user had not upgraded their wallet software, or when a wallet lacked support for the new network upgrade's consensus branch ID; the resulting error messages when users tried to create transactions were non-intuitive, and particularly cryptic for transparent transactions.

    Starting from this release, zcashd nodes will re-verify invalid transparent and Sprout signatures against the consensus branch ID from before the most recent network upgrade. If the signature then becomes valid, the transaction will be rejected with the error message old-consensus-branch-id. This error can be handled specifically by wallet providers to inform the user that they need to upgrade their wallet software.

    Wallet software can also automatically obtain the latest consensus branch ID from their (up-to-date) zcashd node, by calling getblockchaininfo and looking at {'consensus': {'nextblock': BRANCH_ID, ...}, ...} in the JSON output.

    Expired transactions notifications

    A new config option -txexpirynotify has been added that will cause zcashd to execute a command when a transaction in the mempool expires. This can be used to notify external systems about transaction expiry, similar to the existing -blocknotify config option that notifies when the chain tip changes.

    RPC methods

    • The z_importkey and z_importviewingkey RPC methods now return the type of the imported spending or viewing key (sprout or sapling), and the corresponding payment address.

    • Negative heights are now permitted in getblock and getblockhash, to select blocks backwards from the chain tip. A height of -1 corresponds to the last known valid block on the main chain.

    • A new RPC method getexperimentalfeatures returns the list of enabled experimental features.

    Build system

    • The --enable-lcov, --disable-tests, and --disable-mining flags for zcutil/build.sh have been removed. You can pass these flags instead by using the CONFIGURE_FLAGS environment variable. For example, to enable coverage instrumentation (thus enabling "make cov" to work), call:

      CONFIGURE_FLAGS="--enable-lcov --disable-hardening" ./zcutil/build.sh
      
    • The build system no longer defaults to verbose output. You can re-enable verbose output with ./zcutil/build.sh V=1

    Source code(tar.gz)
    Source code(zip)
  • v2.1.1(Feb 13, 2020)

    Notable changes

    z_mergetoaddress promoted out of experimental status

    The z_mergetoaddress API merges funds from t-addresses, z-addresses, or both, and sends them to a single t-address or z-address. It was added in v1.0.15 as an experimental feature, to simplify the process of combining many small UTXOs and notes into a few larger ones.

    In this release we are promoting z_mergetoaddress out of experimental status. It is now a stable RPC, and any future changes to it will only be additive. See zcash-cli help z_mergetoaddress for API details and usage.

    Unlike most other RPC methods, z_mergetoaddress operates over a particular quantity of UTXOs and notes, instead of a particular amount of ZEC. By default, it will merge 50 UTXOs and 10 notes at a time; these limits can be adjusted with the parameters transparent_limit and shielded_limit.

    z_mergetoaddress also returns the number of UTXOs and notes remaining in the given addresses, which can be used to automate the merging process (for example, merging until the number of UTXOs falls below some value).

    Option parsing behavior

    Command line options are now parsed strictly in the order in which they are specified. It used to be the case that -X -noX ends up, unintuitively, with X set, as -X had precedence over -noX. This is no longer the case. Like for other software, the last specified value for an option will hold.

    Low-level RPC changes

    • Bare multisig outputs to our keys are no longer automatically treated as incoming payments. As this feature was only available for multisig outputs for which you had all private keys in your wallet, there was generally no use for them compared to single-key schemes. Furthermore, no address format for such outputs is defined, and wallet software can't easily send to it. These outputs will no longer show up in listtransactions, listunspent, or contribute to your balance, unless they are explicitly watched (using importaddress or importmulti with hex script argument). signrawtransaction* also still works for them.
    Source code(tar.gz)
    Source code(zip)
  • v2.1.1-1(Feb 7, 2020)

    This release fixes a security issue described at https://z.cash/support/security/announcements/security-announcement-2020-02-06/ .

    This release also adds a -maxtimeadjustment option to set the maximum time, in seconds, by which the node's clock can be adjusted based on the clocks of its peer nodes. This option defaults to 0, meaning that no such adjustment is performed. This is a change from the previous behaviour, which was to adjust the clock by up to 70 minutes forward or backward. The maximum setting for this option is now 25 minutes (1500 seconds).

    Fix for incorrect banning of nodes during syncing

    After activation of the Blossom network upgrade, a node that is syncing the block chain from before Blossom would incorrectly ban peers that send it a Blossom transaction. This resulted in slower and less reliable syncing (#4283).

    Source code(tar.gz)
    Source code(zip)
  • v2.1.0-1(Nov 12, 2019)

    Electric Coin Co. became aware of the following security announcement on the bitcoin-dev mailing list on 8th November: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017453.html

    Upon investigation, the team found that versions of zcashd prior to 2.1.0-1 suffered from the above bug, CVE-2017-18350. Nodes in the affected configuration (with a SOCKS proxy enabled) could be compromised by an attacker executing arbitrary code in the context of the zcashd daemon, allowing them to violate user privacy, steal user funds, or perform other unauthorized actions on the machine. The affected configuration is not the default.

    zcashd version 2.1.0-1 contains a fix for this issue, and we recommend updating all affected nodes as soon as possible.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.0(Nov 4, 2019)

    Blossom network upgrade

    The mainnet activation of the Blossom network upgrade is supported by this release, with an activation height of 653600, which should occur in early December — roughly one day following the targeted EOS halt of our 2.0.7-3 release. Please upgrade to this release, or any subsequent release, in order to follow the Blossom network upgrade.

    The Blossom network upgrade implements ZIP 208 which shortens block times from 150s to 75s.

    DoS Mitigation: Mempool Size Limit and Random Drop

    This release adds a mechanism for preventing nodes from running out of memory in the situation where an attacker is trying to overwhelm the network with transactions. This is achieved by keeping track of and limiting the total cost and evictionWeight of all transactions in the mempool. The cost of a transaction is determined by its size in bytes, and its evictionWeight is a function of the transaction's cost and its fee. The maximum total cost is configurable via the parameter mempooltxcostlimit which defaults to 80,000,000 (up to 20,000 txs). If a node's total mempool cost exceeds this limit the node will evict a random transaction, preferentially picking larger transactions and ones with below the standard fee. To prevent a node from re-accepting evicted transactions, it keeps track of ones that it has evicted recently. By default, a transaction will be considered recently evicted for 60 minutes, but this can be configured with the parameter mempoolevictionmemoryminutes.

    For full details see ZIP 401.

    Asynchronous Operations Incorrectly Reporting Success

    We fixed an issue where asynchronous operations were sometimes reporting success when they had actually failed. One way this could occur was when trying to use z_sendmany to create a transaction spending coinbase funds in a way where change would be generated (not a valid use of z_sendmany). In this case the operation would erroneously report success, and the only way to see that the transaction had actually failed was to look in the debug.log file. Such operations will now correctly report that they have failed.

    Fake chain detection during initial block download

    One of the mechanisms that zcashd uses to detect whether it is in "initial block download" (IBD) mode is to compare the active chain's cumulative work against a hard-coded "minimum chain work" value. This mechanism (inherited from Bitcoin Core) means that once a node exits IBD mode, it is either on the main chain, or a fake alternate chain with similar amounts of work. In the latter case, the node has most likely become the victim of a 50% + 1 adversary.

    Starting from this release, zcashd additionally hard-codes the block hashes for the activation blocks of each past network upgrade (NU). During initial chain synchronization, and after the active chain has reached "minimum chain work", the node checks the blocks at each NU activation height against the hard-coded hashes. If any of them do not match, the node will immediately alert the user and shut down for safety.

    Disabling old Sprout proofs

    As part of our ongoing work to clean up the codebase and minimise the security surface of zcashd, we are removing libsnark from the codebase, and dropping support for creating and verifying old Sprout proofs. Funds stored in Sprout addresses are not affected, as they are spent using the hybrid Sprout circuit (built using bellman) that was deployed during the Sapling network upgrade.

    This change has several implications:

    • zcashd no longer verifies old Sprout proofs, and will instead assume they are valid. This has a minor implication for nodes: during initial block download, an adversary could feed the node fake blocks containing invalid old Sprout proofs, and the node would accept the fake chain as valid. However, as soon as the active chain contains at least as much work as the hard-coded "minimum chain work" value, the node will detect this situation and shut down.

    • Shielded transactions can no longer be created before Sapling has activated. This does not affect Zcash itself, but will affect downstream codebases that have not yet activated Sapling (or that start a new chain after this point and do not activate Sapling from launch). Note that the old Sprout circuit is vulnerable to counterfeiting and should not be used in current deployments.

    • Starting from this release, the circuit parameters from the original Sprout MPC are no longer required to start zcashd, and will not be downloaded by fetch-params.sh. They are not being automatically deleted at this time.

    We would like to take a moment to thank the libsnark authors and contributors. It was vital to the success of Zcash, and the development of zero-knowledge proofs in general, to have this code available and usable.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.7-3(Sep 25, 2019)

    This release fixes a security issue described at https://z.cash/support/security/announcements/security-announcement-2019-09-24/ .

    Users should upgrade their nodes to this version immediately and discontinue use of older versions.

    Please note that the issue does not put funds at risk of theft or counterfeiting.

    The service period of this release is shorter than normal due to the upcoming v2.1.0 Blossom release. The End-of-Service of v2.0.7-3 will occur at block height 653012, expected to be on 2019-12-10.

    Shrinking of debug.log files is temporarily disabled

    In previous versions, zcashd would shrink the debug.log file to 200 KB on startup if it was larger than 10 MB. This behaviour, and the -shrinkdebugfile option that controlled it, has been disabled.

    Source code(tar.gz)
    Source code(zip)
    zcash-2.0.7-3-amd64-jessie.deb(4.06 MB)
    zcash-2.0.7-3-amd64-stretch.deb(4.36 MB)
    zcash-2.0.7-3-linux64-debian-jessie.tar.gz(7.70 MB)
    zcash-2.0.7-3-linux64-debian-stretch.tar.gz(8.28 MB)
  • v2.0.7-2(Sep 2, 2019)

    Pre-Blossom EOS Halt

    v2.0.7-2 contains a shortened EOS halt so that it is in alignment with v2.0.7.

    Testnet Blossom Rewind

    Testnet users needed to upgrade to 2.0.7 before Blossom activated. The amount of notice given to these users was brief, so many were not able to upgrade in time. These users may now be on the wrong branch. v2.0.7-2 adds an "intended rewind" to prevent having to manually reindex when reconnecting to the correct chain.

    Insight Explorer Logging Fix

    Fixed an issue where ERROR: spent index not enabled would be logged unnecessarily.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.7(Aug 20, 2019)

    Shorter Block Times

    Shorter block times are coming to Zcash! In the v2.0.7 release we have implemented ZIP208 which will take effect when Blossom activates. Upon activation, the block times for Zcash will decrease from 150 seconds to 75 seconds, and the block reward will decrease accordingly. This affects at what block height halving events will occur, but should not affect the overall rate at which Zcash is mined. The total founders' reward stays the same, and the total supply of Zcash is decreased only microscopically due to rounding.

    Blossom Activation on Testnet

    The v2.0.7 release includes Blossom activation on testnet, bringing shorter block times. The testnet Blossom activation height is 584000.

    Insight Explorer

    Changes needed for the Insight explorer have been incorporated into Zcash. This is an experimental feature and therefore is subject to change. To enable, add the experimentalfeatures=1, txindex=1, and insightexplorer=1 flags to zcash.conf. This feature adds several RPCs to zcashd which allow the user to run an Insight explorer.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.6(Jul 1, 2019)

    Zcashd v2.0.6 is a maintenance release, focussing on code clean-ups and minor bug fixes. It precedes v2.0.7 which is planned to include the implementation of the Blossom upgrade for testnet.

    This release will be supported until block 617512, expected to arrive around October 9th 2019, at which point the software will end-of-support halt and shut down.

    Summary of the changes included in this release:

    • Debian Stretch is now a supported platform.
    • Fixed a bug in z_mergetoaddress, that prevented users sending from ANY_SPROUT or ANY_SAPLING when a wallet contained both Sprout and Sapling notes (#3909).
    • Insight Explorer: we have been incorporating changes to support the Insight Explorer directly from zcashd. v2.0.6 includes the first change to an RPC method.

    For a more complete list of changes for 2.0.6, see our 2.0.6 milestone.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.5-2(May 21, 2019)

    This is a hotfix release that all users are encouraged to upgrade to, especially users who updated to 2.0.5 or 2.0.5-1.

    Zcashd v2.0.5-2 will be supported until block 598012, expected to arrive around September 5th 2019, at which point the software will end-of-support halt and shut down.

    Summary of the changes included in this release:

    1. We prevented zcashd from trying to send migration transactions when it is syncing. (#3987)
    2. We increased the expiry height for migration transactions to 450. (#3995)
    3. We added additional logging to the Sprout to Sapling migration tool. (#4002)

    For a more complete list of changes for this hotfix and 2.0.5, see our 2.0.5 milestone.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.5-1(May 21, 2019)

    This is a hotfix release that all users are encouraged to upgrade to, especially users who updated to 2.0.5.

    Zcashd v2.0.5-1 will be supported until block 593762, expected to arrive around 28th August 2019, at which point the software will end-of-support halt and shut down.

    Summary of the changes included in this release:

    1. We fixed an issue that would cause the Zcashd to crash when calling z_getmigrationstatus while a wallet's migration transactions were in the mempool. (#3987)
    2. We fixed an where the wallet would incorrectly calculate the amount to migrate and would not send as many migration transactions as it could each round of migration. (#3990)
    3. We fixed an issues that could cause Zcashd to crash while generating migration transactions if a wallet had a large number of sprout notes. (#3990)

    For a more complete list of changes for this hotfix and 2.0.5, see our 2.0.5 milestone.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.5(May 21, 2019)

    UPDATE: We are aware of an issue that causes nodes running Sprout->Sapling migrations in v2.0.5 to occasionally crash. Users are advised to upgrade to v2.0.5-1, which fixes the issue.

    This release of Zcashd v2.0.5 adds the Sprout to Sapling migration tool, introduces a new consensus rule on mainnet to reject blocks that violate turnstiles, and adds 64-bit ARMv8 support. Zcashd v2.0.5 will be supported until block 592512, expected to arrive around 26th August 2019, at which point the software will end-of-support halt and shut down.

    Notable Changes in this Release

    Sprout to Sapling Migration Tool

    This release includes the addition of a tool that will enable users to migrate shielded funds from the Sprout pool to the Sapling pool while minimizing information leakage.

    The migration can be enabled using the RPC z_setmigration or by including -migration in the zcash.conf file. Unless otherwise specified funds will be migrated to the wallet's default Sapling address; it is also possible to set the receiving Sapling address using the -migrationdestaddress option in zcash.conf.

    See ZIP308 for full details.

    New consensus rule: Reject blocks that violate turnstile

    In the 2.0.4 release the consensus rules were changed on testnet to enforce a consensus rule which marks blocks as invalid if they would lead to a turnstile violation in the Sprout or Shielded value pools. This release enforces the consensus rule change on mainnet

    The motivations and deployment details can be found in the accompanying ZIP draft and PR 3968.

    Developers can use a new experimental feature -developersetpoolsizezero to test Sprout and Sapling turnstile violations. See PR 3964 for more details.

    64-bit ARMv8 support

    Added ARMv8 (AArch64) support. This enables users to build zcash on even more devices.

    For information on how to build see the User Guide

    Users on the Zcash forum have reported successes with both the Pine64 Rock64Pro and Odroid C2 which contain 4GB and 2GB of RAM respectively.

    Just released, the Odroid N2 looks like a great solution with 4GB of RAM. The newly released Jetson Nano Developer Kit from Nvidia (also 4GB of RAM) is also worth a look. The NanoPC-T3 Plus is another option but for the simplest/best experience choose a board with 4GB of RAM. Just make sure before purchase thatthe CPU supports the 64-bit ARMv8 architecture.

    Summary of the Changes Included in this Release

    1. Sprout to Sapling migration (#3848, #3888, #3967, #3973, #3977)
    2. Activate turnstile on mainnet (#3968)
    3. Update boost to v1.70.0 to eliminate build warning (#3951)
    4. Fix new HD seed generation for previously-encrypted wallets (#3940)
    5. Fix enable-debug build DB_COINS undefined (#3907)
    6. Update "Zcash Company" to "Electric Coin Company" (#3901)
    7. Support additional cross-compilation targets in Rust (#3505)

    For a more complete list of changes, please see the 2.0.5 milestone.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.4(Mar 27, 2019)

    This release of Zcashd v2.0.4 fixes a Sprout wallet security bug, fixes miner address selection behaviour and introduces a new consensus rule on testnet to reject blocks that violate turnstiles. Zcashd v2.0.4 will be supported until block 569112, expected to arrive around 15th July 2019, at which point the software will end-of-support halt and shut down.

    Notable Changes in this Release

    Sprout note validation bug fixed in wallet

    We include a fix for a bug in the Zcashd wallet which could result in Sprout z-addresses displaying an incorrect balance. Sapling z-addresses are not impacted by this issue.

    This bug would occur if someone sending funds to a Sprout z-address intentionally sent a different amount in the note commitment of a Sprout output than the value provided in the ciphertext (the encrypted message from the sender). A symptom of this bug is the error message "logic error: witness of wrong element for joinsplit input" when attempting to send Sprout funds.

    Users should install this update and then rescan the blockchain by invoking “zcashd -rescan”. Sprout address balances shown by the zcashd wallet should then be correct.

    Thank you to Alexis Enston for bringing this to our attention.

    Security Announcement 2019-03-19

    Miner address selection behaviour fixed

    Zcash inherited a bug from upstream Bitcoin Core where both the internal miner and RPC call getblocktemplate would use a fixed transparent address, until RPC getnewaddress was called, instead of using a new transparent address for each mined block. This was fixed in Bitcoin 0.12 and we have now merged the change.

    Miners who wish to use the same address for every mined block, should use the -mineraddress option.

    Mining Guide

    New consensus rule: Reject blocks that violate turnstile (Testnet only)

    Testnet nodes will now enforce a consensus rule which marks blocks as invalid if they would lead to a turnstile violation in the Sprout or Sapling value pools. The motivations and deployment details can be found in the accompanying ZIP draft.

    The consensus rule will be enforced on mainnet in a future release.

    Summary of the Changes Included in this Release

    1. Fix Sprout note validation bug in wallet (#3897)
    2. Fix default miner address behaviour (#3762)
    3. Add consensus rule on testnet to reject blocks that violate turnstile (#3885)
    4. Sapling benchmarks updated (#3657, #3843)
    5. Boost, OpenSSL, Rust and Proton dependencies updated (#3809). AMQP users should review the Proton security fixes.
    6. Backported 'size_on_disk' field to RPC call 'getblockchaininfo' (#3639)
    7. Docs folder updated (#3819, #3846)
    8. Security related documentation updated (#3890, #3892)

    For a more complete list of changes, please see the 2.0.4 milestone.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.3(Feb 11, 2019)

    This release is intended to address security issues in libraries used by Zcash and other outstanding tickets that were in our Spring cleaning sprints.

    Notable Changes in this Release

    [CVE-2019-6250] Update libzmq version

    A pointer overflow, with code execution, was discovered in ZeroMQ libzmq (aka 0MQ) 4.2.x and 4.3.x before 4.3.1. A v2_decoder.cpp zmq::v2_decoder_t::size_ready integer overflow allows an authenticated attacker to overwrite an arbitrary amount of bytes beyond the bounds of a buffer, which can be leveraged to run arbitrary code on the target system. This update addresses the vulnerability when ZeroMQ is enabled, which is not enabled by default.

    Bitcoin 0.12 Performance Improvements

    This change makes sigcache faster, more efficient, and larger. It also reduces the number of database lookups when processing new transactions.

    Summary of the Changes Included in this Release

    1. Update ZMQ to 4.3.1 (#3789)
    2. Fix Tx expiring soon test (#3784)
    3. ZMQ: add flag to publish all checked blocks (#3737)
    4. wallet: Skip transactions with no shielded data in CWallet::SetBestChain() (#3711)
    5. Update z_mergetoaddress documentation (#3699)
    6. Allow user to ask server to save the Sprout R1CS to a file during startup (#3691)
    7. On shutdown, wait for miner threads to exit (join them) (#3647)
    8. Update for Mac OS local rpc-tests
    9. Bitcoin 0.12 performance improvements (#3263)

    For a more complete list of changes, please see the 2.0.3 milestone.

    For information on specific Sapling RPC parameter changes, please see the Network Upgrade Developer guide.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.2(Nov 30, 2018)

    This release adds further support for Sapling in the zcashd wallet RPC and mitigates an issue identified by an external auditor. Information on the Sapling network upgrade (which activated on Oct 28th 2018) can be found below:

    Notable Changes in this Release

    RPC z_getnewaddress now returns a Sapling address by default

    Previously when calling z_getnewaddress a Sprout shielded address would be returned by default. With this release, a Sapling shielded address will be returned by default.

    Transactions expiring soon will not be propagated

    To address auditor issue ZEC-013 which identified a potential denial-of-service vector related to expiry height, nodes will no longer propagate transactions which are expiring soon, defined as within the next 3 blocks. For example, if the current block height is 99, and the next block to be mined is 100, a transaction with an expiry height of 100, 101, 102 will be considered "expiring soon" and will be rejected by the mempool. A transaction with an expiry height of 103 will be accepted. This does not impact transactions which have disabled expiry height (by setting to 0).

    Summary of the Changes Included in this Release

    1. Add Sapling support to RPC z_mergetoaddress (#3619)
    2. Mitigate ZEC-013 transaction expiry height related DoS vector (#3689)
    3. Return Sapling addresses by default when calling RPC z_getnewaddress (#3680)
    4. Add Sapling spend and output description benchmarks to RPC zcbenchmark (#3611)
    5. Fix bug with Sapling chain value tracking (#3684)
    6. Fix language encoding bug with parameter paths on Windows (#3633)
    7. Backport from upstream the relaying of blocks when pruning (#2815)
    8. Don't ban peers when loading pre-Sapling blocks during syncing (#3670)
    9. Fix bug with contents of default memo in Sapling (#3605)
    10. Update tests for Sapling (#3585, #3588)

    For a more complete list of changes, please see the 2.0.2 milestone.

    For information on specific Sapling RPC parameter changes, please see the Network Upgrade Developer guide.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.1(Oct 15, 2018)

    This release is the first Sapling RPC supported version of the Zcash node software!

    Sapling Activation

    Mainnet

    This release is consensus-compatible with the Sapling network upgrade and adds significant support in the zcashd wallet RPC. We’re encouraging all users and miners to upgrade as soon as possible. The first block of Sapling will be block 419200, which is expected to be mined on the 28th of October 2018, the second anniversary of Zcash’s official launch. More information on the upcoming Sapling network upgrade can be found below:

    Testnet

    Sapling has activated on the testnet at block 280000. If you are running a v2.0.1 node, you no longer need to specify -experimentalfeatures and -developersapling to use Sapling functionality on testnet. If you are running an older v2.0.0 node, please upgrade to version v2.0.1 which introduced a consensus rule change to allow min difficulty blocks to be mined from block 299188, thereby splitting the chain.

    Other Notable Changes

    Sapling RPC Support

    This release contains support for Sapling RPC functionality on mainnet, enabling the sending of Sapling shielded funds.

    Hierarchical Deterministic Key Generation

    All Sapling addresses will use hierarchical deterministic key generation according to ZIP 32 (keypath m/32'/133'/k' on mainnet). Transparent and Sprout addresses will still use traditional key generation.

    Backups of HD wallets, regardless of when they have been created, can therefore be used to re-generate all possible Sapling private keys, even the ones which haven't already been generated during the time of the backup. Regular backups are still necessary, however, in order to ensure that transparent and Sprout addresses are not lost.

    A future release will support the importing and restoration of HD wallets.

    Fix Signing Raw Transactions with Unsynced Offline Nodes

    In signrawtransaction we determine the consensus branch ID (which we then later use to construct the transaction) using the chain height. We now also consider the APPROX_RELEASE_HEIGHT , as this is a better estimation than 0 for the height of the chain if we are unsynced. We have also added an additional parameter to signrawtransaction to allow manually overriding the consensus branch ID that zcashd determines we are on.

    Summary of the Changes Included in this Release

    1. Allow minimum-difficulty blocks on testnet (#3559)
    2. Enable Sapling features on mainnet (#3537)
    3. Use ZIP 32 for all Sapling spending keys (#3492)
    4. Fix signing raw transaction with unsynced offline node (#3520)
    5. Sapling support for persisting wallet to disk (#3517)
    6. Add Sapling RPC support to z_shieldcoinbase (#3518)
    7. Add Sapling RPC support to z_listunspent (#3510)
    8. Add Sapling RPC support to z_listreceivedbyaddress (#3499)
    9. Add Sapling RPC support to z_importwallet and z_exportwallet (#3491)
    10. Add Sapling RPC support to z_sendmany (#3489)
    11. Add Sapling RPC support to z_getbalance and z_gettotalbalance (#3436)
    12. Track Sapling notes and nullifiers in the wallet (in-memory only, no persistence to disk) (#3422)
    13. Make NU peer management logic upgrade-agnostic (#3512)
    14. Generate an ovk to encrypt outCiphertext for Sapling t-addr senders (#3516)
    15. Windows cross-compile support (#3172)

    For a more complete list of changes, please see the 2.0.1 milestone.

    For information on specific Sapling RPC parameter changes, please see the Network Upgrade Developer guide on using zcashd unmodified .

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Aug 17, 2018)

    This release is the first Sapling-compatible version of the Zcash node software!

    Sapling Activation

    Mainnet

    This release is consensus-compatible with the Sapling network upgrade, and so we’re encouraging all users and miners to upgrade as soon as possible. The first block of Sapling will be block 419200, which is expected to be mined on the 28th of October 2018, the second anniversary of Zcash’s official launch. You can read more about the Sapling network upgrade here or on the Sapling Network Upgrade page.

    Testnet

    Sapling will activate on the testnet at block 280000, which is expected about a week after this release. Sapling had previously activated on testnet, but because changes were made to the consensus rules your node will automatically roll back and proceed on the Overwinter testnet branch until Sapling activates again at the new height.

    Other Notable Changes

    Experimental Sapling RPC Support

    This release contains only experimental support for Sapling RPC functionality. Full support for Sapling RPC functionality will appear in the 2.0.1 release.

    Developers must specify -experimentalfeatures and -developersapling to use the existing functionality on testnet after activation. Alternatively, developers can use these features in regtest mode.

    Fix Peer Banning Bug Introduced In Overwinter

    After Overwinter activation, nodes syncing from a block height prior to the activation height (347500) experienced slow syncing due to a peer banning mechanism that was introduced to mitigate against a class of DoS attacks from Sprout nodes. This fix replaces the use of peer banning with behavior to ignore invalid transactions.

    Summary of the Changes Included in this Release

    1. Set the Sapling activation height for mainnet and testnet. (#3469)
    2. Adopted the official Sapling system parameters. (#3448)
    3. Added support for rollbacks of testnet. (#3443)
    4. Added experimental wallet support for Sapling z-addresses. (#3273, #3353, #3392, #3429, #3396, #3458)
    5. Added experimental support for building Sapling transactions. (#3417)
    6. Added experimental support for Sapling note encryption and decryption. (#3324, #3391)
    7. Accept the transaction expiry height as a parameter to RPC call createrawtransaction. (#3336)
    8. Prepared the codebase for ZIP 32 integration, including bumping the Rust compiler version to 1.28. (#3447)
    9. Begin checking the zk-SNARK parameter hash when loaded into memory. (#3441)
    10. Always record the best Sapling anchor on disk even if it is for the empty tree, because rollbacks may occur. (#3463)
    11. Fixed a bug where nodes may ban peers during synchronization before network upgrade activation. (#3410)
    12. Backport upstream improvements to InitialBlockDownload. (#3263)
    13. Update the mainnet checkpoints to improve the speed of initial synchronization. (#3246)

    For a more complete list of changes, see the 2.0.0 milestone.

    Source code(tar.gz)
    Source code(zip)
Owner
Zcash
Internet Money
Zcash
Zcash - Internet Money

Zcash 4.4.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

Zcash 4.5k Nov 22, 2021
Dank - The Internet Computer Decentralized Bank - A collection of Open Internet Services - Including the Cycles Token (XTC)

Dank - The Internet Computer Decentralized Bank Dank is a collection of Open Internet Services for users and developers on the Internet Computer. In t

Psychedelic 36 Nov 21, 2021
Open Internet Service to store transaction history for NFTs/Tokens on the Internet Computer

CAP - Certified Asset Provenance Transaction history & asset provenance for NFT’s & Tokens on the Internet Computer CAP is an open internet service pr

Psychedelic 16 Nov 18, 2021
Cover is an open internet service for canister code verification on the Internet Computer

Cover Cover (short for Code Verification) is an open internet service that helps verify the code of canisters on the Internet Computer. Visit our webs

Psychedelic 5 Nov 22, 2021
Rust implementation of Zcash protocol

The Parity Zcash client. Gitter Blog: Parity teams up with Zcash Foundation for Parity Zcash client Installing from source Installing the snap Running

Parity Technologies 165 Nov 26, 2021
Rust implementation of Zcash protocol

The Parity Zcash client. Gitter Blog: Parity teams up with Zcash Foundation for Parity Zcash client Installing from source Installing the snap Running

Parity Technologies 164 Nov 19, 2021
Limit screen time to children's various mobile devices by blocking internet access on the family Wifi router.

Device Blocker Limit screen time to children's various mobile devices by blocking internet access on the family Wifi router. This is the server which

null 32 May 20, 2021
Source project for the Internet Computer software

The Internet Computer is the world’s first blockchain that runs at web speed and can increase its capacity without bound. Like the Internet (which is composed of many machines adhering to TCP/IP protocol) and blockchain protocols (such as Bitcoin and Ethereum).

DFINITY 798 Nov 22, 2021
Agent library for Internet Computer, in Dart

An agent library built for Internet Computer, a plugin package for dart and flutter apps. Developers can build ones to interact with Dfinity's blockchain directly.

null 41 Nov 18, 2021
A rust library containing typings and utility functions dealing with the Public specification of the Internet Computer.

IC Types Contributing Please follow the guidelines in the CONTRIBUTING.md document. Goal This library contains typings and utility functions dealing w

DFINITY 3 Oct 21, 2021
Combine internet connections, increase your download speed

dispatch A SOCKS proxy that balances traffic between network interfaces. Should work on macOS, Windows, and Linux. Only tested on macOS for now. This

Alexandre Kirszenberg 10 Aug 6, 2021
Task scheduler for the Internet Computer

IC Cron Makes your IC canister proactive Abstract Canisters are reactive by their nature - they only do something when they're asked by a client or an

Alexander Vtyurin 14 Sep 28, 2021
⌚ A command-line tool (and library) for the rusty Swatch Internet Time.

⌚ A command-line tool (and library) for the rusty Swatch Internet Time. Comes with XBar/Swiftbar support.

Gil Desmarais 2 Nov 15, 2021
A learning project/fun experiment in internet protocol

Piper a learning project/fun experiment in internet protocol Version 0.4.0 (SEMVER) Goals Piper is Simple. A page is a page. There are no secondary re

null 5 Nov 24, 2021
All the data an IC app needs to make seamless experiences, accessible directly on the IC. DAB is an open internet service for NFT, Token, Canister, and Dapp registries.

DAB ?? Overview An Internet Computer open internet service for data. All the data an IC app needs to make a seamless experience, accessible directly o

Psychedelic 33 Nov 24, 2021