TL;DR:
Launch 4.7.0 marks a serious milestone on the trail to NU5. It allows full help for the Orchard shielded protocol and Unified Addresses on testnet. Unified Addresses may begin getting used on mainnet, however funds can’t be despatched to an Orchard receiver till NU5 prompts on mainnet. Launch 4.7.0 may even reactivate NU5 on testnet to choose up the newest consensus adjustments. That reactivation is about to happen on or about April twenty second. The Zcash Schedule web page has been up to date to replicate the 4.7.0 launch in addition to the testnet reactivation timing.
Pre-packed Linux binaries for 4.7.0 shall be accessible later at present.
Notable adjustments
Modifications to Testnet NU5 Consensus Guidelines
NOTE: All testnet nodes which have been working on testnet above peak 1599200 might want to improve to v4.7.0
after which run with -reindex
and -rescan
.
- So as to higher help {hardware} wallets, clear signature hash building as outlined in ZIP 244 has been modified to incorporate a hash of the serialization of the quantities of all outputs being spent, together with a hash of all spent outputs
scriptPubKeys
values, besides within the case that theANYONECANPAY
flag is about. This permits {hardware} pockets gadgets to confirm the UTXO quantities with out having to stream all of the earlier transactions containing the outputs being spent to the machine. Additionally as a part of these adjustments, the clear signature hash digest now commits instantly, somewhat than implicitly, to the sighash kind, and the sighash kind is restricted to a set set of legitimate values. The change to ZIP 244 may be seen right here. - This launch fixes a bug in
v4.6.0
that induced a consensus failure on the Zcash testnet at peak1,779,200
. - There have been adjustments to the Halo2 proving system to enhance consistency between the specification and the implementation, and these could break compatibility.
- There have been quite a few adjustments to the Orchard circuit implementation since
v4.6.0
. A whole record may be discovered right here. - A possible Faerie Gold vulnerability affecting the earlier activation of NU5 on testnet and present since
v4.6.0
has been mitigated.
NU5 Testnet Reactivation
To help the aforementioned testnet consensus adjustments, the next adjustments are made in zcashd v4.7.0
:
- The consensus department ID for NU5 is modified to
0xC2D6D0B4
. - The protocol model indicating NU5-aware testnet nodes is about to
170050
. - The testnet reactivation peak for NU5 is about to 1,842,420.
As talked about above, all testnet nodes which have been working on testnet above peak 1,599,200 might want to improve to v4.7.0
after which run with -reindex
and -rescan
.
Emergency Restoration Phrases
The zcashd pockets has been modified to help BIP 39, which describes the right way to derive the pockets’s HD seed from a mnemonic phrase, hereafter often known as the pockets’s “emergency restoration phrase”. The emergency restoration phrase shall be generated on load of the pockets, or the primary time the pockets is unlocked, and is obtainable by way of the z_exportwallet
RPC name. All new addresses produced by the pockets at the moment are derived from this seed utilizing the HD pockets performance described in ZIP 32 and ZIP 316. For customers upgrading an present Zcashd pockets, it is suggested that the pockets be backed up previous to upgrading to the 4.7.0 Zcashd launch. Within the the rest of this doc, the HD seed derived from the emergency restoration phrase shall be termed the pockets’s “mnemonic seed”.
Following the improve to 4.7.0, Zcashd would require that the person verify that they’ve backed up their new emergency restoration phrase, which can be obtained from the output of the z_exportwallet
RPC name. This affirmation may be carried out manually utilizing the zcashd-wallet-tool
utility that’s provided with this launch (constructed or put in in the identical listing as zcashd
). The pockets won’t permit the era of latest addresses till this affirmation has been carried out. It’s endorsed that after this improve, funds tied to preexisting addresses be migrated to newly generated addresses so that each one pockets funds are recoverable utilizing the emergency restoration phrase going ahead. For those who select to not migrate funds on this style, you’ll proceed to wish to securely again up your entire pockets.dat
file to make sure that you don’t lose entry to present 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.
Within the case that your pockets beforehand contained a Sapling HD seed, the emergency restoration phrase is constructed utilizing the bytes of that seed, such that it’s doable to reconstruct keys generated utilizing that legacy seed if you already know the emergency restoration phrase. HOWEVER, THIS RECONSTRUCTION DOES NOT FOLLOW THE NORMAL PROCESS OF DERIVATION FROM THE EMERGENCY RECOVERY PHRASE. As an alternative, to recuperate a legacy Sapling key from the emergency restoration phrase, it’s essential to reconstruct the bytes of the legacy seed by conversion of the phrase again to its supply randomness as an alternative of by hashing as is laid out in BIP 39. Solely keys and addresses produced after the improve may be obtained by regular derivation of a ZIP 32 or BIP 32 grasp seed utilizing BIP 39.
Pockets Updates
The zcashd pockets now helps the Orchard shielded protocol.
The zcashd pockets has been modified to change the best way that change is dealt with. Within the case that funds are being spent from a unified account, change is shipped to a wallet-internal change deal with for that account as an alternative of sending change quantities again to the unique deal with the place a observe being spent was acquired. The rationale for this variation is that it improves the safety that’s supplied to the person of the pockets when supplying incoming viewing keys to 3rd events; beforehand, an incoming viewing key may successfully be used to detect when a observe was spent (therefore violating the “incoming” restriction) by observing change outputs that have been despatched again to the deal with the place the spent observe was initially acquired.
New RPC Strategies
walletconfirmbackup
This newly created API checks a supplied emergency restoration phrase in opposition to the pockets’s emergency restoration phrase; if the phrases match then it updates the pockets state to permit the era of latest addresses. This backup affirmation workflow may be disabled by beginning zcashd with-walletrequirebackup=false
however this isn’t really useful except you already know what you’re doing (and have in any other case backed up the pockets’s emergency restoration phrase anyway). For safety causes, this RPC technique will not be supposed to be used by way ofzcash-cli
however is supplied to allowzcashd-wallet-tool
and different third-party pockets interfaces to fulfill the backup affirmation requirement. Use of thewalletconfirmbackup
API by way ofzcash-cli
would danger that the emergency restoration phrase being confirmed is likely to be leaked by way of the person’s shell historical past or the system course of desk;zcashd-wallet-tool
is supplied particularly to keep away from this drawback.z_getnewaccount
This API permits for creation of latest BIP 44 / ZIP 32 accounts utilizing HD derivation from the pockets’s mnemonic seed. Every account represents a separate spending authority and supply of funds. A single account could include funds within the Sapling and Orchard shielded swimming pools, in addition to funds held in clear addresses.z_listaccounts
This API returns the record of BIP 44 / ZIP 32 accounts which might be being tracked by the pockets.z_getaddressforaccount
This API permits for creation of diversified unified addresses below a single account. Every name to this API will, by default, create a brand new diversified unified deal with containing clear p2pkh, Sapling, and Orchard receivers. Further arguments to this API could also be supplied to request the deal with to be created with a user-specified set of receiver sorts and diversifier index.z_getbalanceforaccount
This API makes it doable to acquire stability data on a per-account foundation.z_getbalanceforviewingkey
This API permits a person to acquire stability data for funds seen to a Sapling or Unified full viewing key; if a Sprout viewing secret is supplied, this technique permits retrieval of the stability solely within the case that the pockets controls the corresponding spending key. This API has been added to complement (and largely supplant)z_getbalance
. Querying for stability by a single deal with returns solely the quantity acquired by that deal with, and omits worth despatched to different diversified addresses derived from the identical full viewing key; through the use ofz_getbalanceforviewingkey
it’s doable to acquire an accurate stability that features all quantities managed by a single spending key, together with each these despatched to exterior diversified addresses and to wallet-internal change addresses.z_listunifiedreceivers
This API permits the caller to extract the person part receivers from a unified deal with. That is helpful if one wants to supply a naked Sapling or clear p2pkh deal with to a service that doesn’t but help unified addresses.
RPC Modifications
- The outcome kind for the
listaddresses
endpoint has been modified:- The
keypool
supply kind has been eliminated; it was reserved however not used. - Within the
sapling
deal with outcomes, thezip32AccountId
attribute has been eliminated in favor ofzip32KeyPath
. That is to permit distinct key paths to be reported for addresses derived from the legacy account below completely different baby spending authorities, as are produced byz_getnewaddress
. - Addresses derived from the pockets’s mnemonic seed at the moment are included in
listaddresses
output.
- The
- The outcomes of the
dumpwallet
andz_exportwallet
RPC strategies have been modified to now embody the pockets’s newly generated emergency restoration phrase as a part of the exported information. Additionally, the seed fingerprint and HD keypath data at the moment are included within the output of those strategies for all HD-derived keys. - The outcomes of the
getwalletinfo
RPC have been modified to return two new fields:mnemonic_seedfp
andlegacy_seedfp
, the latter of which replaces the sphere that was beforehand namedseedfp
. - A brand new
pool
attribute has been added to every component returned byz_listunspent
to point which worth pool the unspent observe controls funds in. z_listreceivedbyaddress
- A
pool
attribute has been added to every outcome to point what pool the acquired funds are held in. - A boolean-valued
change
attribute has been added to point whether or not the output is change. - Block metadata attributes
blockheight
,blockindex
, andblocktime
have been added to the outcome.
- A
z_viewtransaction
has been up to date to incorporate attributes that present details about Orchard parts of the transaction. Additionally, thekind
attribute for spend and output values has been deprecated and changed by the pool attribute.z_getnotescount
now additionally returns data for Orchard notes.- The output format of
z_exportwallet
has been modified. The exported file now consists of the mnemonic seed for the pockets, and HD keypaths at the moment are exported for clear addresses when accessible. - The outcome worth for
z_importviewingkey
now consists of anaddress_type
area that replaces the now-deprecatedkind
key. z_listunspent
has been up to date to render unified addresses for Sapling and Orchard outputs when these outputs are managed by unified spending keys. Outputs acquired by unified inner addresses don’t embody thedeal with
area.- Legacy clear deal with era utilizing
getnewaddress
not makes use of a preallocated keypool, however as an alternative performs HD derivation from the pockets’s mnemonic seed in line with BIP 39 and BIP 44 below account ID0x7FFFFFFF
. z_gettreestate
has been up to date to incorporate details about the Orchard observe dedication tree.
‘z_sendmany’
- The
z_sendmany
RPC name not permits Sprout recipients within the record of recipient addresses. Transactions spending Sprout funds will nonetheless lead to change being despatched again into the Sprout pool, however no differentSprout->Sprout
transactions shall be constructed by the Zcashd pockets. - The restriction that prohibited
Sprout->Sapling
transactions has been lifted; nevertheless, since such transactions reveal the quantity crossing pool boundaries, they should be explicitly enabled by way of a parameter to thez_sendmany
name. - A brand new string parameter,
privacyPolicy
, has been added to the record of arguments accepted byz_sendmany
. This parameter allows the caller to manage what sort of data they enablezcashd
to disclose on-chain when creating the transaction. If the transaction can solely be created by revealing extra data than the given technique permits,z_sendmany
will return an error. The parameter defaults toLegacyCompat
, which applies essentially the most restrictive techniqueFullPrivacy
when a Unified Tackle is current because the sender or a recipient, and in any other case preserves present conduct (which corresponds to theAllowFullyTransparent
coverage). In circumstances the place it’s doable to take action with out revealing further data, and the place it’s permitted by the privateness coverage, the pockets will now opportunistically protect funds to essentially the most present pool. - Since Sprout outputs are not created (except for change)
z_sendmany
not generates cost disclosures (which have been solely accessible for Sprout outputs) when the-paymentdisclosure
experimental function flag is about. - Outgoing viewing keys used for shielded outputs at the moment are produced as described in ZIP 316
- When sending from or to a number of unified addresses, change outputs at the moment are all the time despatched to addresses managed by the pockets’s inner spending keys, as described in ZIP 316. These addresses are usually not returned by any RPC API, as they’re supposed to by no means be shared with any third social gathering, and are for wallet-internal use solely. This variation improves the privateness properties which may be maintained when sharing a unified inner viewing key for an account within the pockets.
- In circumstances the place
z_sendmany
may produce clear change UTXOs, these UTXOs are despatched to addresses derived from the pockets’s mnemonic seed by way of the BIP 44change
derivation path.
RPC Deprecations
z_getnewaddress
has been deprecated in favor ofz_getnewaccount
andz_getaddressforaccount
.z_listaddresses
has been deprecated. Uselistaddresses
as an alternative.z_getbalance
has been deprecated. Usez_getbalanceforviewingkey
as an alternative. See the dialogue of how change is now dealt with below the Pockets heading for extra background.z_gettotalbalance
has been deprecated. Usez_getbalanceforaccount
as an alternative.dumpwallet
has been deprecated. Usez_exportwallet
as an alternative.
Construct System
- Clang has been up to date to make use of LLVM 13.0.1.
- libc++ has been up to date to make use of LLVM 13.0.1, besides on Home windows the place it makes use of 13.0.0-3.
- The Rust toolchain dependency has been up to date to model 1.59.0.
Platform Help
- Debian 9 has been faraway from the record of supported platforms.
- Debian 11 (Bullseye) has been added to the record of supported platforms.
- A construct situation (a lacking header file) has been fastened for macOS targets.
- On Arch Linux solely, a duplicate of Debian’s libtinfo5_6.0 is used to repair a construct regression.
Mining
- Mining to Orchard recipients is now supported on testnet.
- It’s now doable to mine to a Sapling receiver of a unified deal with.
- Concurrency bugs associated to
getblocktemplate
have been fastened by way of backports from Bitcoin Core.
Licenses
License data in contrib/debian/copyright
has been up to date to be extra correct.