Bot releases are hidden (Show)
License documentation has been updated to account for the orchard
crate now being licensed under "MIT OR Apache-2.0".
Debian 11 (Bookworm) is now a Tier 1 platform.
Intel macOS will be formally downgraded to a Tier 3 platform in the next release. Previously it has informally been at both Tier 1 (because builds and tests were run in CI) and Tier 3 (because no packages were provided). However, we are currently unable to update the Clang and Rust compilers due to there being no Clang release built for Intel macOS from LLVM 16 onwards. Combined with the fact that the Intel Macbook was discontinued in 2021, this decision means that we will no longer be building zcashd
natively on Intel macOS in CI for testing purposes. We will not be removing build system support (so builds may still function, and community patches to fix issues are welcomed).
Published by nuttycom 10 months ago
This is a maintenance release that updates dependencies and sets a new end-of-service height to help ensure continuity of services.
Published by nuttycom about 1 year ago
fetch-params.sh
The fetch-params.sh
script (also zcash-fetch-params
) is now deprecated. The zcashd
binary now bundles zk-SNARK parameters directly and so parameters do not need to be downloaded or stored separately. The script will now do nothing but state that it is deprecated; it will be removed in a future release.
Previously, parameters were stored by default in these locations:
~/.zcash-params
(on Linux); or~/Library/Application Support/ZcashParams
(on Mac); orC:\Users\Username\AppData\Roaming\ZcashParams
(on Windows)Unless you need to generate transactions using the deprecated Sprout shielded pool, you can delete the parameter files stored in these directories to save space as they are no longer read or used by zcashd
. If you do wish to use the Sprout pool, you will need the sprout-groth16.params
file in the aforementioned directory. This file is currently available for download here.
zcashd
now reports the following new metrics when -prometheusport
is set:
zcash.mempool.actions.unpaid { "bk" = ["< 0.2", "< 0.4", "< 0.6", "< 0.8", "< 1"] }
zcash.mempool.actions.paid
zcash.mempool.size.weighted { "bk" = ["< 1", "1", "> 1", "> 2", "> 3"] }
The zcash.mempool.actions
metrics count the number of logical actions across the transactions in the mempool, while zcash.mempool.size.weighted
is a weight-bucketed version of the zcash.mempool.size.bytes
metric.
The ZIP 317 weight ratio of a transaction is used to bucket its logical actions and byte size. A weight ratio of at least 1 means that the transaction's fee is at least the ZIP 317 conventional fee, and all of its logical actions are considered "paid". A weight ratio lower than 1 corresponds to the fraction of the transaction's logical actions that are "paid". The remaining fraction (i.e. 1 - weight ratio) are subject to the unpaid action limit that miners configure for their blocks with -blockunpaidactionlimit
.
Published by nuttycom over 1 year ago
Fixes an issue introduced in v5.6.0 that could cause loss of data from the
wallet's Orchard note commitment tree. Users upgrading directly from v5.5.0
should upgrade directly to v5.6.1. Wallets that were previously upgraded to
v5.6.0 whose wallets contained unspent Orchard notes at the time of the upgrade
will be automatically re-scanned on startup to repair the corrupted note
commitment tree.
Also, the height
parameter to the getblocksubsidy
RPC call had accidentally
been made required instead of optional as part of the v5.5.0 upgrade. This
hotfix restores height
to being treated as an optional parameter.
Published by ebfull over 1 year ago
Transactions paying less than the ZIP 317 conventional fee to the extent that they have more than -txunpaidactionlimit
unpaid actions (default: 50) will not be accepted to the mempool or relayed. For the default values of -txunpaidactionlimit
and -blockunpaidactionlimit
, these transactions would never be mined by the ZIP 317 block construction algorithm. (If the transaction has been prioritised by prioritisetransaction
, the modified fee is used to calculate the number of unpaid actions.)
The estimatefee
RPC call, which estimated the fee needed for a transaction to be included within a target number of blocks, has been removed. The fee that should be paid under normal circumstances is the ZIP 317 conventional fee; it is not possible to compute that without knowing the number of logical actions in a transaction, which was not an input to estimatefee
. The fee_estimates.dat
file is no longer used.
A new RPC method, z_getsubtreesbyindex
, has been added to the RPC interface. This method is only enabled when running with the -experimentalfeatures=1
and -lightwalletd=1
node configuration options. This method makes available to the caller precomputed node values within the Sapling and Orchard note commitment trees. Wallets can make use of these precomputed values to make their existing notes spendable without needing to fully scan the sub-trees whose roots correspond to the returned node values.
In conjunction with this change, the getblock
RPC method now returns an additional trees
field as part of its result. The value for this field is an object that contains the final sizes of the Sapling and Orchard note commitment trees after the block's note commitments have been appended to their respective trees.
Error reporting has also been improved for a number of RPC methods.
The AllowRevealedSenders
privacy policy no longer allows sending from multiple taddrs in the same transaction. This now requires AllowLinkingAccountAddresses
. Care should be taken in using AllowLinkingAccountAddresses
too broadly, as it can also result in linking UAs when transparent funds are sent from them. The practical effect is that an explicit privacy policy is always required for z_mergetoaddress
, z_sendmany
, and z_shieldcoinbase
when sending from multiple taddrs, even when using wildcards like *
and ANY_TADDR
.
A number of libraries that zcashd relies upon have been updated as part of this release, including some changes that result in updates to wallet serialization formats for Orchard note commitment tree data. As always, it is recommended that users back up their wallets prior to upgrading to a new release to help guarantee the continued availability of their funds.
Published by str4d over 1 year ago
Fixes an issue that could cause a node to crash if the privacy policy does not include AllowRevealedRecipients
when attempting to create a transaction that results in transparent change. See #6662 for details.
Also corrects an underestimate of the ZIP 317 conventional fee when spending UTXOs, which can result in mining of the transaction being delayed or blocked. See #6660 for details.
Published by nuttycom over 1 year ago
getdeprecationinfo
has several changes:
end_of_service
object that contains both the block height for end-of-service and the estimated time that the end-of-service halt is expected to occur. Note that this time is just an approximation and will change over time as the end-of-service block height approaches, due to the variability in block times. The end_of_service
object is intended to replace the deprecationheight
field; see the Deprecations section for additional detail.z_sendmany
, z_shieldcoinbase
and z_mergetoaddress
failures have moved from synchronous to asynchronous, so while you should already be checking the async operation status, there are now more cases that may trigger failure at that stage.AllowRevealedRecipients
privacy policy is now required in order to choose a transparent change address for a transaction. This will only occur when the wallet is unable to construct the transaction without selecting funds from the transparent pool, so the impact of this change is that for such transactions, the user must specify AllowFullyTransparent
.z_shieldcoinbase
RPC method now supports an optional memo.z_shieldcoinbase
and z_mergetoaddress
RPC methods now support an optional privacy policy.z_mergetoaddress
RPC method can now merge to UAs and can also send between different shielded pools (when AllowRevealedAmounts
is specified).estimatepriority
RPC call has been removed.priority_delta
argument to the prioritisetransaction
RPC call now has no effect and must be set to a dummy value (0 or null).sendtoaddress
, sendmany
, and fundrawtransaction
) when the -paytxfee
option is set.-mintxfee
and -sendfreetransactions
options have been removed. These options previously instructed the legacy transaction creation APIs to increase fees to this limit and to use a zero fee for "small" transactions that spend "old" inputs, respectively. They will now cause a warning on node startup if used.We now use a new block template construction algorithm documented in ZIP 317.
-blockprioritysize
config option, which configured the portion of the block reserved for these transactions, has been removed and will now cause a warning if used.-blockminsize
option, which configured the size of a portion of the block to be filled regardless of transaction fees or priority, has also been removed and will cause a warning if used.-blockunpaidactionlimit
option has been added to control the limit on "unpaid actions" that will be accepted in a block for transactions paying less than the ZIP 317 fee. This defaults to 50.The allowance for "free transactions" in mempool acceptance and relay has been removed. All transactions must pay at least the minimum relay threshold, currently100 zatoshis per 1000 bytes up to a maximum of 1000 zatoshis, in order to be accepted and relayed. (Individual nodes can change this using -minrelaytxfee
but in practice the network default needs to be adhered to.) This policy is under review and might be made stricter; if that happens then the ZIP 317 conventional fee will still be sufficient for mempool acceptance and relay.
Estimation of "priority" needed for a transaction to be included within a target number of blocks, and the associated estimatepriority
RPC call, have been removed. The format for fee_estimates.dat
has also changed to no longer save these priority estimates. It will automatically be converted to the new format which is not readable by prior versions of the software. The -txconfirmtarget
config option is now obsolete and has also been removed. It will cause a warning if used.
The following features have been deprecated, but remain available by default. These features may be disabled by setting -allowdeprecated=none
. 18 weeks after this release, these features will be disabled by default and the following flags to -allowdeprecated
will be required to permit their continued use:
deprecationinfo_deprecationheight
: The deprecationheight
field of getdeprecationinfo
has been deprecated and replaced by the end_of_service
object.Published by str4d over 1 year ago
This hotfix remediates memory exhaustion vulnerabilities that zcashd
inherited as a fork of bitcoind
. These bugs could allow an attacker to use peer-to-peer messages to fill the memory of a node, resulting in a crash.
Published by str4d over 1 year ago
This hotfix remediates memory exhaustion vulnerabilities that zcashd inherited as a fork of bitcoind
. These bugs could allow an attacker to use peer-to-peer messages to fill the memory of a node, resulting in a crash.
Published by str4d over 1 year ago
allowdeprecated
in zcash.conf
In v5.0.0 a feature deprecation framework was released, to enable zcashd
features to be formally deprecated and removed:
-allowdeprecated
config option. It remains in this stage for at least 18 weeks.Config options can be specified either as a zcashd
argument (-option=value
) or in zcash.conf
(as a option=value
line). However, due to a bug in the implementation, allowdeprecated=feature
lines in zcash.conf
were ignored. The bug went unnoticed until v5.4.0, in which the first group of features moved from stage 1 to stage 2. This hotfix release fixes the bug.
The known issue reported in the v5.4.0 release notes has been fixed.
Published by str4d over 1 year ago
This release fixes an issue that could potentially cause a node to crash with the log message "The wallet's best block hash <hash>
was not detected in restored chain state. Giving up; please restart with -rescan
."
Additionally, a bug that could cause an assertion failure during reindexing has been fixed. See #6387 for details.
zcashd
is started with -reindex
, until the node's chain tip catches back up to the main chain, RPC calls might block for long periods of time (or time out), and the wallet's view of the chain may lag significantly behind the node's chain tip. See #6406 for details and the fix (which will be included in the next release).Since v2.0.0, zcashd
has tracked the change in value within the Sprout and Sapling shielded pools for each block; v5.0.0 added the Orchard pool. This release completes the set, by tracking the change in value within the "transparent" pool (more precisely, the value stored in Bitcoin-style UTXOs).
zcashd
also now tracks the change in "chain supply" for each block, defined as the sum of coinbase output values, minus unclaimed fees. This is precisely equal to the sum of the value in the transparent and shielded pools, and equivalent to the sum of all unspent coins/notes on the chain. It is bounded above by the theoretical maximum supply, but in practice is lower due to, for example, miners not claiming transaction fees.
Bitcoin-style consensus rules implement fees as an imbalance between spent coins/notes and newly-created coins/notes. The consensus rules require that a coinbase transaction's outputs have a total value no greater than the sum of that block's subsidy and the fees made available by the transactions in the block. However, the consensus rules do not require that all of the available funds are claimed, and a miner can create coinbase transactions with lower value in the outputs (though in the case of Zcash, the consensus rules do require the transaction to include ZIP 1014 Funding Stream outputs).
After upgrading to v5.4.0, zcashd
will start tracking changes in transparent pool value and chain supply from the height at which it is restarted. Block heights prior to this will not have any information recorded. To track changes from genesis, and thus monitor the total transparent pool size and chain supply, you would need to restart your node with the -reindex
option.
The 100MiB memory limit for the batch scanner has been replaced by a 1000-block limit. This eliminates an expensive call to determine the current memory usage of the batch scanner.
The following associated metric has been removed from the set of metrics reported when -prometheusport
is set:
zcashd.wallet.batchscanner.usage.bytes
z_sendmany
will no longer select transparent coinbase when "ANY_TADDR" is used as the fromaddress
. It was already documented to do this, but the previous behavior didn’t match. When coinbase notes were selected in this case, they would (properly) require that the transaction didn’t have any change, but this could be confusing, as the documentation stated that these two conditions (using "ANY_TADDR" and disallowing change) wouldn’t coincide."id": "transparent"
has been added to the valuePools
list in getblockchaininfo
and getblock
.chainSupply
key has been added to getblockchaininfo
and getblock
to report the total chain supply as of that block height (if tracked), and the change in chain supply caused by the block (for getblock
, if measured).getblocktemplate
have been backported from upstream Bitcoin Core, to significantly improve its performance by doing more work ahead of time in the mempool (and reusing the work across multiple getblocktemplate
calls).The following features have been deprecated, but remain available by default. These features may be disabled by setting -allowdeprecated=none
. 18 weeks after this release, these features will be disabled by default and the following flags to -allowdeprecated
will be required to permit their continued use:
gbt_oldhashes
: the finalsaplingroothash
, lightclientroothash
, and blockcommitmentshash
fields in the output of getblocktemplate
have been replaced by the defaultroots
field.The following previously-deprecated features have been disabled by default, and will be removed in 18 weeks:
legacy_privacy
getnewaddress
getrawchangeaddress
z_getnewaddress
z_listaddresses
addrtype
wallettxvjoinsplit
The following previously-deprecated features have been removed:
dumpwallet
zcrawreceive
zcrawjoinsplit
zcrawkeygen
Published by str4d almost 2 years ago
This is a hotfix release that fixes a regression in memory usage during Initial Block Download. The regression was indirectly caused by a change to prioritize downloading headers (PR #6231), introduced in release 5.3.1. It caused memory usage for new nodes to spike to roughly 11 GiB about an hour after starting Initial Block Download.
The issue fixed by this release does not affect nodes that start from a fully synced chain, or that had sufficient memory available to get past the memory usage spike.
Published by str4d almost 2 years ago
This release fixes an error "Assertion uResultHeight == rewindHeight
failed" (#5958) that could sometimes happen when restarting a node.
The memory usage of zcashd has been reduced by not keeping Equihash solutions for all block headers in memory.
The following RPC methods that query wallet state now support an optional asOfHeight
parameter, to execute the query as if it were run when the blockchain was at the height specified by this argument:
getbalance
getreceivedbyaddress
gettransaction
(*)getwalletinfo
listaddressgroupings
listreceivedbyaddress
(*)listsinceblock
(*)listtransactions
listunspent
(*)z_getbalanceforaccount
z_getbalanceforviewingkey
z_getmigrationstatus
z_getnotescount
z_listreceivedbyaddress
z_listunspent
(*) For these methods, additional parameters have been added to maintain compatibility of parameter lists with Bitcoin Core. Default values should be passed for these additional parameters in order to use asOfHeight
. See the RPC documentation for details.
Published by daira almost 2 years ago
zcashd 5.2.0
improved the performance of wallet scanning with multithreaded batched trial decryption of Sapling outputs. However, for some nodes this resulted in growing memory usage that would eventually cause an OOM abort. We have identified the cause of the growth, and made significant improvements to reduce the memory usage of the batch scanner. In addition, the batch scanner now has a memory limit of 100 MiB.
zcashd
now reports the following new metrics when -prometheusport
is set:
zcashd.wallet.batchscanner.outputs.scanned
zcashd.wallet.batchscanner.size.transactions
zcashd.wallet.batchscanner.usage.bytes
zcashd.wallet.synced.block.height
finalorchardroot
field in the getblock
result and the orchard.commitments.finalRoot
field in the z_gettreestate
result have been changed to match the byte ordering used for the orchard.anchor
field in the getrawtransaction
result. These previously produced different hash values from the orchard.anchor
field due to having been byte-flipped in their internal representation in zcashd.Published by str4d about 2 years ago
This release makes several changes to improve the performance of node operations. These include:
This release makes several changes to improve the performance of wallet operations. These include:
-rescan
one time, in order to ensure that witnesses for spent notes are in the wallet are properly pruned.version
field was added to the result for the gettransaction
RPC call to avoid the need to make an extra call to getrawtransaction
just to retrieve the version.Published by str4d over 2 years ago
Block validation in zcashd
is a mostly single-threaded process, due to how the chain update logic inherited from Bitcoin Core is written. However, certain more computationally intensive checks are performed more efficiently than checking everything individually:
As of this release, zcashd
applies these techniques to more Sapling and Orchard components:
This reduces worst-case block validation times for observed historic blocks by around 80% on a Ryzen 9 5950X CPU.
The number of threads used for checking Groth16 and Halo 2 proofs (as well as for creating them when spending funds) can be set via the RAYON_NUM_THREADS
environment variable.
-preferredtxversion
argument allows the node to preferentially create transactions of a specified version, if a transaction does not contain components that necessitate creation with a specific version. For example, setting -preferredtxversion=4
will cause the node to create V4 transactions whenever the transaction does not contain Orchard components. This can be helpful if recipients of transactions are likely to be using legacy wallets that have not yet been upgraded to support parsing V5 transactions.The getblocktemplate
RPC method now skips proof and signature checks on templates it creates, as these templates only include transactions that have previously been checked when being added to the mempool.
The getrawtransaction
and decoderawtransaction
RPC methods now include details about Orchard actions within transactions.
Rescan performance of post-NU5 blocks has been slightly improved (overall rescan time for a single-account wallet decreases by around 6% on a Ryzen 9 5950X). Further improvements will be implemented in future releases to help mitigate the effect of blocks full of shielded outputs.
The CWallet::UpdatedTransaction
signal is no longer called while holding the cs_main
lock. This fixes an issue where RPCs could block for long periods of time on zcashd
nodes with large wallets. Downstream code forks that have reconnected the NotifyTransactionChanged
wallet signal should take note of this change, and not rely there on access to globals protected by cs_main
.
Some zcashd 5.0.0
nodes would shut down some time after start with the error ThreadNotifyWallets: Failed to read block X while notifying wallets of block disconnects
. zcashd
now attempts to rectify the situation, and otherwise will inform the user before shutting down that a reindex is required.
As of this release, the following previously deprecated features are disabled by default, but may be be reenabled using -allowdeprecated=<feature>
.
dumpwallet
RPC method is disabled. It may be reenabled with allowdeprecated=dumpwallet
. dumpwallet
should not be used; it is unsafe for backup purposes as it does not return any key information for keys used to derive shielded addresses. Use z_exportwallet
instead.As of this release, the following features are deprecated, but remain available by default. These features may be disabled by setting -allowdeprecated=none
. After at least 3 minor-version releases, these features will be disabled by default and the following flags to -allowdeprecated
will be required to permit their continued use:
wallettxvjoinsplit
- controls availability of the deprecated vjoinsplit
attribute returned by the gettransaction
RPC method.Published by nuttycom over 2 years ago
The mainnet activation of the NU5 network upgrade is supported by the 5.0.0 release, with an activation height of 1687104, which should occur on approximately May 31, 2022. Please upgrade to this release, or any subsequent release, in order to follow the NU5 network upgrade.
The following ZIPs are being deployed, or have been updated, as part of this upgrade:
zcashd
now has a process for how features of the public API may be deprecated and removed. Feature deprecation follows a series of steps whereby, over a series of releases, features first remain enabled by default (but may be explicitly disabled), then switch to being disabled by default, and eventually are removed entirely.
A new string-valued option, -allowdeprecated
has been introduced to allow a user to explicitly manage the availability of deprecated zcashd
features. This flag makes it possible for users to reenable deprecated methods, features, and APIs that are currently disabled by default, or alternately to explicitly disable all deprecated features if they so choose. Multiple instances of this argument may be provided. A user may disable deprecated features entirely by providing the string none
as the argument to this parameter. In the case that none
is specified, multiple invocations of -allowdeprecated
are not permitted.
As of this release, the following features are deprecated, but remain available by default. These features may be disabled by setting -allowdeprecated=none
. After release 5.3.0, these features will be disabled by default and the following flags to -allowdeprecated
will be required to permit their continued use:
legacy_privacy
- the default "legacy" privacy policy for z_sendmany
is deprecated. When disabled, the default behavior of z_sendmany
will conform to the FullPrivacy
directive (introduced in 4.7.0) in all cases instead of just for transactions involving unified addresses.getnewaddress
- controls availability of the getnewaddress
RPC method.getrawchangeaddress
- controls availability of the getrawchangeaddress
RPC method.z_getbalance
- controls availability of the z_getbalance
RPC method.z_gettotalbalance
- controls availability of the z_gettotalbalance
RPC method.z_getnewaddress
- controls availability of the z_getnewaddress
RPC method.z_listaddresses
- controls availability of the z_listaddresses
RPC method.addrtype
- controls availability of the deprecated type
attribute returned by RPC methods that return address metadata.As of this release, the following previously deprecated features are disabled by default, but may be be reenabled using -allowdeprecated=<feature>
.
zcrawreceive
RPC method is disabled. It may be reenabled with allowdeprecated=zcrawreceive
zcrawjoinsplit
RPC method is disabled. It may be reenabled with allowdeprecated=zcrawjoinsplit
zcrawkeygen
RPC method is disabled. It may be reenabled with allowdeprecated=zcrawkeygen
-reindex
and -reindex-chainstate
options now imply -rescan
(provided that the wallet is enabled and pruning is disabled, and unless -rescan=0
is specified explicitly).-anchorconfirmations
argument has been added to allow the user to specify the number of blocks back from the chain tip that anchors will be selected from when spending notes. By default, anchors will now be selected to have 3 confirmations. Values greater than 100 are not supported.-orchardactionlimit
option has been added to allow the user to override the default maximum of 50 Orchard actions per transaction. Transactions that contain large numbers of Orchard actions can use large amounts of memory for proving, so the 50-action default limit is imposed to guard against memory exhaustion. Systems with more than 16G of memory can safely set this parameter to allow 200 actions or more.minconf
value for z_sendmany
is now 10 confirmations instead of 1. If minconf
specifies a value less than that provided for -anchorconfirmations
, it will also override that value as it is not possible to spend notes that are more recent than the anchor. Selecting minconf
values less than 3 is not recommended, as it allows the transaction to be distinguished from transactions using the default for -anchorconfirmations
.zcrawkeygen
, zcrawreceive
, and zcrawjoinsplit
RPC methods are now disabled by default. Use -allowdeprecated=<feature>
to select individual features if you wish to continue using these APIs.zcutil/build.sh
now automatically runs zcutil/clean.sh
to remove files created by previous builds. We previously recommended to do this manually.boost
and native_b2
dependencies have been updated to version 1.79.0zcashd
executable has been changed from BITCOIND
to ZCASHD
.Published by daira over 2 years ago
NOTE: All testnet nodes that have been running on testnet above height 1599200 will need to upgrade to v4.7.0
and then run with -reindex
and -rescan
.
scriptPubKeys
values, except in the case that the ANYONECANPAY
flag is set. This allows hardware wallet devices to verify the UTXO amounts without having to stream all the previous transactions containing the outputs being spent to the device. Also as part of these changes, the transparent signature hash digest now commits directly, rather than implicitly, to the sighash type, and the sighash type is restricted to a fixed set of valid values. The change to ZIP 244 can be seen here.v4.6.0
that caused a consensus failure on the Zcash testnet at height 1,779,200
. For details see https://github.com/zcash/zcash/commit/5990853de3e9f04f28b7a4d59ef9e549eb4b4cca.v4.6.0
. See https://github.com/zcash/orchard/issues?q=label%3AM-consensus-change-since-0.1.0-beta-1 for a complete list.v4.6.0
has been mitigated.To support the aforementioned testnet consensus changes, the following changes are made in zcashd v4.7.0
:
0xC2D6D0B4
.170050
.As mentioned above, all testnet nodes that have been running on testnet above height 1,599,200 will need to upgrade to v4.7.0
and then run with -reindex
and -rescan
.
The zcashd wallet has been modified to support BIP 39, which describes how to derive the wallet's HD seed from a mnemonic phrase, hereafter known as the wallet's "emergency recovery phrase". The emergency recovery phrase will be generated on load of the wallet, or the first time the wallet is unlocked, and is available via the z_exportwallet
RPC call. All new addresses produced by the wallet are now derived from this seed using the HD wallet functionality described in ZIP 32 and ZIP 316. For users upgrading an existing Zcashd wallet, it is recommended that the wallet be backed up prior to upgrading to the 4.7.0 Zcashd release. In the remainder of this document, the HD seed derived from the emergency recovery phrase will be termed the wallet's "mnemonic seed".
Following the upgrade to 4.7.0, Zcashd will require that the user confirm that they have backed up their new emergency recovery phrase, which may be obtained from the output of the z_exportwallet
RPC call. This confirmation can be performed manually using the zcashd-wallet-tool
utility that is supplied with this release (built or installed in the same directory as zcashd
). The wallet will not allow the generation of new addresses until this confirmation has been performed. It is recommended that after this upgrade, funds tied to preexisting addresses be migrated to newly generated addresses so that all wallet funds are recoverable using the emergency recovery phrase going forward. If you choose not to migrate funds in this fashion, you will continue to need to securely back up the entire wallet.dat
file to ensure that you do not lose access to existing funds; EXISTING FUNDS WILL NOT BE RECOVERABLE USING THE EMERGENCY RECOVERY PHRASE UNLESS THEY HAVE BEEN MOVED TO A NEWLY GENERATED ADDRESS FOLLOWING THE 4.7.0 UPGRADE.
In the case that your wallet previously contained a Sapling HD seed, the emergency recovery phrase is constructed using the bytes of that seed, such that it is possible to reconstruct keys generated using that legacy seed if you know the emergency recovery phrase. HOWEVER, THIS RECONSTRUCTION DOES NOT FOLLOW THE NORMAL PROCESS OF DERIVATION FROM THE EMERGENCY RECOVERY PHRASE. Instead, to recover a legacy Sapling key from the emergency recovery phrase, it is necessary to reconstruct the bytes of the legacy seed by conversion of the phrase back to its source randomness instead of by hashing as is specified in BIP 39. Only keys and addresses produced after the upgrade can be obtained by normal derivation of a ZIP 32 or BIP 32 master seed using BIP 39.
The zcashd wallet now supports the Orchard shielded protocol.
The zcashd wallet has been modified to alter the way that change is handled. In the case that funds are being spent from a unified account, change is sent to a wallet-internal change address for that account instead of sending change amounts back to the original address where a note being spent was received. The rationale for this change is that it improves the security that is provided to the user of the wallet when supplying incoming viewing keys to third parties; previously, an incoming viewing key could effectively be used to detect when a note was spent (hence violating the "incoming" restriction) by observing change outputs that were sent back to the address where the spent note was originally received.
walletconfirmbackup
This newly created API checks a provided emergency recovery phrase against the wallet's emergency recovery phrase; if the phrases match then it updates the wallet state to allow the generation of new addresses. This backup confirmation workflow can be disabled by starting zcashd with -walletrequirebackup=false
but this is not recommended unless you know what you're doing (and have otherwise backed up the wallet's emergency recovery phrase anyway). For security reasons, this RPC method is not intended for use via zcash-cli
but is provided to enable zcashd-wallet-tool
and other third-party wallet interfaces to satisfy the backup confirmation requirement. Use of the walletconfirmbackup
API via zcash-cli
would risk that the emergency recovery phrase being confirmed might be leaked via the user's shell history or the system process table; zcashd-wallet-tool
is provided specifically to avoid this problem.z_getnewaccount
This API allows for creation of new BIP 44 / ZIP 32 accounts using HD derivation from the wallet's mnemonic seed. Each account represents a separate spending authority and source of funds. A single account may contain funds in the Sapling and Orchard shielded pools, as well as funds held in transparent addresses.z_listaccounts
This API returns the list of BIP 44 / ZIP 32 accounts that are being tracked by the wallet.z_getaddressforaccount
This API allows for creation of diversified unified addresses under a single account. Each call to this API will, by default, create a new diversified unified address containing transparent p2pkh, Sapling, and Orchard receivers. Additional arguments to this API may be provided to request the address to be created with a user-specified set of receiver types and diversifier index.z_getbalanceforaccount
This API makes it possible to obtain balance information on a per-account basis.z_getbalanceforviewingkey
This API allows a user to obtain balance information for funds visible to a Sapling or Unified full viewing key; if a Sprout viewing key is provided, this method allows retrieval of the balance only in the case that the wallet controls the corresponding spending key. This API has been added to supplement (and largely supplant) z_getbalance
. Querying for balance by a single address returns only the amount received by that address, and omits value sent to other diversified addresses derived from the same full viewing key; by using z_getbalanceforviewingkey
it is possible to obtain a correct balance that includes all amounts controlled by a single spending key, including both those sent to external diversified addresses and to wallet-internal change addresses.z_listunifiedreceivers
This API allows the caller to extract the individual component receivers from a unified address. This is useful if one needs to provide a bare Sapling or transparent p2pkh address to a service that does not yet support unified addresses.listaddresses
endpoint has been modified:
keypool
source type has been removed; it was reserved but not used.sapling
address results, the zip32AccountId
attribute has been removed in favor of zip32KeyPath
. This is to allow distinct key paths to be reported for addresses derived from the legacy account under different child spending authorities, as are produced by z_getnewaddress
.listaddresses
output.dumpwallet
and z_exportwallet
RPC methods have been modified to now include the wallet's newly generated emergency recovery phrase as part of the exported data. Also, the seed fingerprint and HD keypath information are now included in the output of these methods for all HD-derived keys.getwalletinfo
RPC have been modified to return two new fields: mnemonic_seedfp
and legacy_seedfp
, the latter of which replaces the field that was previously named seedfp
.pool
attribute has been added to each element returned by z_listunspent
to indicate which value pool the unspent note controls funds in.z_listreceivedbyaddress
pool
attribute has been added to each result to indicate what pool the received funds are held in.change
attribute has been added to indicate whether the output is change.blockheight
, blockindex
, and blocktime
have been added to the result.z_viewtransaction
has been updated to include attributes that provide information about Orchard components of the transaction. Also, the type
attribute for spend and output values has been deprecated and replaced by the pool
attribute.z_getnotescount
now also returns information for Orchard notes.z_exportwallet
has been changed. The exported file now includes the mnemonic seed for the wallet, and HD keypaths are now exported for transparent addresses when available.z_importviewingkey
now includes an address_type
field that replaces the now-deprecated type
key.z_listunspent
has been updated to render unified addresses for Sapling and Orchard outputs when those outputs are controlled by unified spending keys. Outputs received by unified internal addresses do not include the address
field.getnewaddress
no longer uses a preallocated keypool, but instead performs HD derivation from the wallet's mnemonic seed according to BIP 39 and BIP 44 under account ID 0x7FFFFFFF
.z_gettreestate
has been updated to include information about the Orchard note commitment tree.z_sendmany
RPC call no longer permits Sprout recipients in the list of recipient addresses. Transactions spending Sprout funds will still result in change being sent back into the Sprout pool, but no other Sprout->Sprout
transactions will be constructed by the Zcashd wallet.Sprout->Sapling
transactions has been lifted; however, since such transactions reveal the amount crossing pool boundaries, they must be explicitly enabled via a parameter to the z_sendmany
call.privacyPolicy
, has been added to the list of arguments accepted by z_sendmany
. This parameter enables the caller to control what kind of information they permit zcashd
to reveal on-chain when creating the transaction. If the transaction can only be created by revealing more information than the given strategy permits, z_sendmany
will return an error. The parameter defaults to LegacyCompat
, which applies the most restrictive strategy FullPrivacy
when a Unified Address is present as the sender or a recipient, and otherwise preserves existing behaviour (which corresponds to the AllowFullyTransparent
policy). In cases where it is possible to do so without revealing additional information, and where it is permitted by the privacy policy, the wallet will now opportunistically shield funds to the most current pool.z_sendmany
no longer generates payment disclosures (which were only available for Sprout outputs) when the -paymentdisclosure
experimental feature flag is set.z_sendmany
might produce transparent change UTXOs, those UTXOs are sent to addresses derived from the wallet's mnemonic seed via the BIP 44 change
derivation path.z_getnewaddress
has been deprecated in favor of z_getnewaccount
and z_getaddressforaccount
.z_listaddresses
has been deprecated. Use listaddresses
instead.z_getbalance
has been deprecated. Use z_getbalanceforviewingkey
instead. See the discussion of how change is now handled under the Wallet
heading for additional background.z_gettotalbalance
has been deprecated. Use z_getbalanceforaccount
instead.dumpwallet
has been deprecated. Use z_exportwallet
instead.getblocktemplate
have been fixed via backports from Bitcoin Core.contrib/debian/copyright
has been updated to be more accurate.Published by daira over 2 years ago
This is a bugfix release that also bumps the End-of-Support height to May 16th. It backports bugfixes from v4.7.0-rc1, including a getblocktemplate
deadlock fix, and several portability fixes.
Debian 9 "Stretch" is no longer supported from v4.6.0-2, due to its end-of-life on June 30th, 2022. This will allow us to direct more resources to supporting Debian 11 Bullseye, other Linux distributions, and other platforms such as Windows and macOS.
Published by str4d almost 3 years ago
getblocktemplate
regression fixWe added support for the NU5 consensus rules in v4.5.0, which alters the block header to contain a hashBlockCommitments
value instead of the chain history root. However, the output of getblocktemplate
wasn't returning this value; once NU5 activated, the blockcommitmentshash
field was being set to "null" (all-zeroes).
In v4.6.0 we added full NU5 support to getblocktemplate
, by adding a defaultroots
field that gave default values for hashBlockCommitments
and the components required to derive it. However, in doing so we introduced a regression in the (now-deprecated) legacy fields, where prior to NU5 activation they contained nonsense.
This release fixes the output of getblocktemplate
to have the intended semantics for all fields:
blockcommitmentshash
and authdataroot
fields in defaultroots
are now omitted from block templates for heights before NU5 activation.