New Release 4.7.0 - Electric Coin Company

TL;DR:

Launch 4.7.0 marks a significant milestone on the trail to NU5. It permits full assist for the Orchard shielded protocol and Unified Addresses on testnet. Unified Addresses also can 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 most recent consensus adjustments. That reactivation is ready to happen on or about April twenty second. The Zcash Schedule web page has been up to date to mirror the 4.7.0 launch in addition to the testnet reactivation timing.

Pre-packed Linux binaries for 4.7.0 might be out there later immediately.

Notable adjustments

Adjustments to Testnet NU5 Consensus Guidelines

NOTE: All testnet nodes which were working on testnet above peak 1599200 might want to improve to v4.7.0 after which run with -reindex and -rescan.

With the intention to higher assist {hardware} wallets, clear signature hash development 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 the ANYONECANPAY flag is ready. 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 gadget. Additionally as a part of these adjustments, the clear signature hash digest now commits instantly, moderately than implicitly, to the sighash kind, and the sighash kind is restricted to a hard and fast set of legitimate values. The change to ZIP 244 will be seen right here.
This launch fixes a bug in v4.6.0 that triggered a consensus failure on the Zcash testnet at peak 1,779,200.
There have been adjustments to the Halo2 proving system to enhance consistency between the specification and the implementation, and these might break compatibility.
There have been quite a few adjustments to the Orchard circuit implementation since v4.6.0. An entire checklist will be discovered right here.
A possible Faerie Gold vulnerability affecting the earlier activation of NU5 on testnet and current since v4.6.0 has been mitigated.

NU5 Testnet Reactivation

To assist 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 ready to 170050.
The testnet reactivation peak for NU5 is ready to 1,842,420.

As talked about above, all testnet nodes which were 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 assist BIP 39, which describes how one can derive the pockets’s HD seed from a mnemonic phrase, hereafter often known as the pockets’s “emergency restoration phrase”. The emergency restoration phrase might be generated on load of the pockets, or the primary time the pockets is unlocked, and is accessible through the z_exportwallet RPC name. All new addresses produced by the pockets are actually derived from this seed utilizing the HD pockets performance described in ZIP 32 and ZIP 316. For customers upgrading an current Zcashd pockets, it’s endorsed 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 might be termed the pockets’s “mnemonic seed”.

Following the improve to 4.7.0, Zcashd would require that the consumer affirm 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 will be carried out manually utilizing the zcashd-wallet-tool utility that’s equipped with this launch (constructed or put in in the identical listing as zcashd). The pockets is not going to permit the era of recent addresses till this affirmation has been carried out. It is strongly recommended 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. In the event you select to not migrate funds on this trend, you’ll proceed to want to securely again up the complete pockets.dat file to make sure that you don’t lose entry to current 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 potential to reconstruct keys generated utilizing that legacy seed if you recognize the emergency restoration phrase. HOWEVER, THIS RECONSTRUCTION DOES NOT FOLLOW THE NORMAL PROCESS OF DERIVATION FROM THE EMERGENCY RECOVERY PHRASE. As a substitute, to get better 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 a substitute of by hashing as is laid out in BIP 39. Solely keys and addresses produced after the improve will 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 way in which 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 tackle for that account as a substitute of sending change quantities again to the unique tackle the place a word being spent was acquired. The rationale for this transformation is that it improves the safety that’s offered to the consumer of the pockets when supplying incoming viewing keys to 3rd events; beforehand, an incoming viewing key may successfully be used to detect when a word was spent (therefore violating the “incoming” restriction) by observing change outputs that have been despatched again to the tackle the place the spent word was initially acquired.

New RPC Strategies

walletconfirmbackup This newly created API checks a offered 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 recent addresses. This backup affirmation workflow will be disabled by beginning zcashd with -walletrequirebackup=false however this isn’t advisable until you recognize 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 meant to be used through zcash-cli however is offered to allow zcashd-wallet-tool and different third-party pockets interfaces to fulfill the backup affirmation requirement. Use of the walletconfirmbackup API through zcash-cli would danger that the emergency restoration phrase being confirmed is perhaps leaked through the consumer’s shell historical past or the system course of desk; zcashd-wallet-tool is offered particularly to keep away from this downside.
z_getnewaccount This API permits for creation of recent 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 might comprise funds within the Sapling and Orchard shielded swimming pools, in addition to funds held in clear addresses.
z_listaccounts This API returns the checklist 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 beneath a single account. Every name to this API will, by default, create a brand new diversified unified tackle containing clear p2pkh, Sapling, and Orchard receivers. Further arguments to this API could also be offered to request the tackle to be created with a user-specified set of receiver varieties and diversifier index.
z_getbalanceforaccount This API makes it potential to acquire stability data on a per-account foundation.
z_getbalanceforviewingkey This API permits a consumer to acquire stability data for funds seen to a Sapling or Unified full viewing key; if a Sprout viewing secret is offered, 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 tackle returns solely the quantity acquired by that tackle, and omits worth despatched to different diversified addresses derived from the identical full viewing key; through the use of z_getbalanceforviewingkey it’s potential 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 element receivers from a unified tackle. That is helpful if one wants to supply a naked Sapling or clear p2pkh tackle to a service that doesn’t but assist unified addresses.

RPC Adjustments

The end result kind for the listaddresses endpoint has been modified:
- The keypool supply kind has been eliminated; it was reserved however not used.
- Within the sapling tackle outcomes, the zip32AccountId attribute has been eliminated in favor of zip32KeyPath. That is to permit distinct key paths to be reported for addresses derived from the legacy account beneath totally different baby spending authorities, as are produced by z_getnewaddress.
- Addresses derived from the pockets’s mnemonic seed are actually included in listaddresses output.
The outcomes of the dumpwallet and z_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 are actually 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 and legacy_seedfp, the latter of which replaces the sphere that was beforehand named seedfp.
A brand new pool attribute has been added to every aspect returned by z_listunspent to point which worth pool the unspent word controls funds in.
z_listreceivedbyaddress
- A pool attribute has been added to every end result 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, and blocktime have been added to the end result.
z_viewtransaction has been up to date to incorporate attributes that present details about Orchard elements of the transaction. Additionally, the kind 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 contains the mnemonic seed for the pockets, and HD keypaths are actually exported for clear addresses when out there.
The end result worth for z_importviewingkey now contains an address_type area that replaces the now-deprecated kind 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 inside addresses don’t embody the tackle area.
Legacy clear tackle era utilizing getnewaddress now not makes use of a preallocated keypool, however as a substitute performs HD derivation from the pockets’s mnemonic seed in response to BIP 39 and BIP 44 beneath account ID 0x7FFFFFFF.
z_gettreestate has been up to date to incorporate details about the Orchard word dedication tree.

‘z_sendmany’

The z_sendmany RPC name now not permits Sprout recipients within the checklist of recipient addresses. Transactions spending Sprout funds will nonetheless lead to change being despatched again into the Sprout pool, however no different Sprout->Sprout transactions might be constructed by the Zcashd pockets.
The restriction that prohibited Sprout->Sapling transactions has been lifted; nonetheless, since such transactions reveal the quantity crossing pool boundaries, they have to be explicitly enabled through a parameter to the z_sendmany name.
A brand new string parameter, privacyPolicy, has been added to the checklist of arguments accepted by z_sendmany. This parameter permits the caller to manage what sort of data they allow zcashd 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 to LegacyCompat, which applies essentially the most restrictive technique FullPrivacy when a Unified Tackle is current because the sender or a recipient, and in any other case preserves current habits (which corresponds to the AllowFullyTransparent coverage). In instances the place it’s potential 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 now not created (except for change) z_sendmany now not generates fee disclosures (which have been solely out there for Sprout outputs) when the -paymentdisclosure experimental characteristic flag is ready.
Outgoing viewing keys used for shielded outputs are actually produced as described in ZIP 316
When sending from or to a number of unified addresses, change outputs are actually at all times despatched to addresses managed by the pockets’s inside spending keys, as described in ZIP 316. These addresses usually are not returned by any RPC API, as they’re meant to by no means be shared with any third celebration, and are for wallet-internal use solely. This transformation improves the privateness properties that could be maintained when sharing a unified inside viewing key for an account within the pockets.
In instances the place z_sendmany would possibly produce clear change UTXOs, these UTXOs are despatched to addresses derived from the pockets’s mnemonic seed through the BIP 44 change derivation path.

RPC Deprecations

z_getnewaddress has been deprecated in favor of z_getnewaccount and z_getaddressforaccount.
z_listaddresses has been deprecated. Use listaddresses as a substitute.
z_getbalance has been deprecated. Use z_getbalanceforviewingkey as a substitute. See the dialogue of how change is now dealt with beneath the Pockets heading for extra background.
z_gettotalbalance has been deprecated. Use z_getbalanceforaccount as a substitute.
dumpwallet has been deprecated. Use z_exportwallet as a substitute.

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 Assist

Debian 9 has been faraway from the checklist of supported platforms.
Debian 11 (Bullseye) has been added to the checklist of supported platforms.
A construct concern (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 potential to mine to a Sapling receiver of a unified tackle.
Concurrency bugs associated to getblocktemplate have been fastened through backports from Bitcoin Core.