Bot releases are hidden (Show)
Published by str4d almost 3 years ago
From this release, newly-created wallets will save the chain name ("Zcash") and network identifier (e.g. "main") to the wallet.dat
file. This will enable the zcashd
node to check on subsequent starts that the wallet.dat
file matches the node's configuration. Existing wallets will start saving this information in a later release.
libzcash_script
Two new APIs have been added to this library (zcash_script_legacy_sigop_count
and zcash_script_legacy_sigop_count_precomputed
), for counting the number of signature operations in the transparent inputs and outputs of a transaction. The presence of these APIs is indicated by a library API version of 2.
The getblocktemplate
RPC method output now includes a defaultroots
field, which provides various tree roots and block commitments matching the contents of the block template. If any part of the block template marked as mutable
in the RPC method output is mutated, these roots may need to be recomputed. For more information on the derivation process, see the block header changes in ZIP 244.
Fixed an issue where ERROR: spent index not enabled
would be logged unnecessarily on nodes that have either -insightexplorer
or -lightwalletd
configuration options enabled.
The getmininginfo
RPC now omits currentblocksize
and currentblocktx
when a block was never assembled via RPC on this node during its current process instantiation. (#5404)
Published by str4d about 3 years ago
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.
listaddresses
RPC methodThe 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.
Published by mdr0id about 3 years ago
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.
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 ivk
s).
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
:
0x37519621
.170015
.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.
getbalance
RPC methodzcashd 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.
Published by therealyingtong about 3 years ago
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:
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.
CInv
message typesPreviously, 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).
zcashd
.Published by str4d over 3 years ago
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.
Published by therealyingtong over 3 years ago
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
.
Published by ebfull over 3 years ago
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).
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:
consensusBranchId
and amount
fields.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
).
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.
statx
-related breakage in some container environments.Published by daira almost 4 years ago
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.
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.
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.
This unifies and simplifies the RPC testing framework, as has been done in the upstream Bitcoin codebase.
Published by daira almost 4 years ago
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.
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.
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.
Published by therealyingtong almost 4 years ago
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.
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.
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.
getaddressutxos
RPC. (Previously, this was only available to the Insightz_gettreestate
RPC returns the Sprout and Sapling treestate at aThis 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.
Published by ebfull about 4 years ago
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.
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.
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 timeevents
in tracing
.)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.
macOS versions earlier than 10.12 (Sierra) are no longer supported.
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.
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.
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.
-debuglogfile=<file>
can be used to specify an alternative debug logging file.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.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.Published by ebfull over 4 years ago
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.
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.
Published by daira over 4 years ago
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.
Published by ebfull over 4 years ago
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.
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.
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.
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.
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:
outgoing
flag on each new note, which will be true
if the output is notmemoStr
field for each new note, containing its text memo (if its memoInformation 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
).
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.
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.
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. 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
z_mergetoaddress
promoted out of experimental statusThe 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).
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.
listtransactions
, listunspent
, or contribute toimportaddress
orimportmulti
with hex script argument). signrawtransaction*
also stillPublished by ebfull over 4 years ago
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).
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).
Published by str4d almost 5 years ago
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.
Published by daira almost 5 years ago
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.
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.
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.
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.
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.
Published by str4d about 5 years ago
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.
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.