NU5 what holders should do?

Yes, but purely on-chain leakage is also possible.

One simple example: it’s likely your ZEC wallet balance is a round number minus a small multiple of the standard tx fees.
I send 0.00269412 ZEC to your (public) Sapling address.
When you migrate, I find the two migration txs which sum to a round number minus a small multiple of the standard tx fees plus 0.00269412 ZEC.
Now I know your account balance.

Another example: I saw the shielding transaction you used to fund your Sapling zaddr (after, say, you bought ZEC on Coinbase and withdrew it to your taddr). Later, I see two migration txs that sum to exactly that, minus 0.3527 ZEC. Which happens to be the membership dues of the Caribou Hugging Club. You’re outed.

Far-fetched? Perhaps. But remember, this is on-chain, so there is all the time in the world for people to come up with new algorithms and heuristics, as well as dig up new data to correlate against.

4 Likes

All your ZEC stored within a T-address & Sapling Z-addresses can be transacted on the Zcash chain. The various wallet providers will have their own plans for adding support for Orchard U-address. And there will be a way to recover your ZEC as long as you secure your seed words(private keys) to your wallet.

The Zcash network is not deprecating support to any pool in this upgrade.

It would be good to know the recommendations around breaking down transaction amounts towards the migration flow for wallet developers to incorporate a similar, user-friendly experience.

Please post wallet related improvements & ideas here

1 Like

Zecwallet lite for Android is not NU5 ready and neither Zcash Foundation nor the developer have commented on its future. As of now its users will not be able to access the new features like Unified Addresses nor will their shielded transactions be in the Orchard pool.

Thread here: Zecwallet community reorg

1 Like

So nighthawk wallet should i choose??

Nighthawk is an alternative, yes. In my experience Nighthawk is painfully slow to sync with the network, on both highspeed wifi or mobile, thus making it virtually unusable.

ZecWallet Lite implemented some fast sync technology making it far more usable, but again, its future is unclear and it’s not NU5 ready. ZecWallet Lite is also tied to the lightwallet server of the developer and there is no way to change that, so it involves trusting the devs and the jurisdiction in which they operate.

The fastest wallet with the most features is Ywallet. Check it out. IMO its the best… Test all of them and you’ll see.

Zecwallet lite desktop version this day not work well. Icon menus cannot clicked. It stuck blank. Usually i can restore all my Z addresses in zecwallet lite desktop. And when i use that same seed phase on zecwallet lite android it just show 1 Z address. It must use private keys to get all my Z adresses. Now i try using nighthawk and do with the same seed phrase it shows just 1 Z address but i dont found where i can input/import private key menu? This is so frustating. It took so long to download n syncing.

What’s behind the politics of Ywallet not being listed on z.cash/wallets?

This lack of inclusion should give pause to the average user as it appears that Ywallet is not trusted or endorsed by the community: Y/ZWallet: mobile app (Q&A) - #43 by ChileBob

1 Like

I use it. Many Zcashers use it. There is politics behind it. The lack of inclusion has nothing to do with the dev work itself. @hanh has developed many things for Zcash. I suggest people to check it out…

Use at your own risk. Again, I find it concerning that a compatible shielded wallet, that claims to offer one of the fastest litewallet syncs, is not even mention on ECC or Halo wallet pages…

Either there are trust/endorsement issues or ECC needs to be clear as to why they’re not mentioning Ywallet/Zwallet despite being content to list closed source wallets, KYC exchange wallets, and other multicoin wallets.

1 Like

I do not find it concerning at all. It has nothing to do with the dev work or trust. Ywallet is the official wallet of Ycash. But if you dont want to use it, dont. The code is available on github.

I’m pretty sure it’s because it doesn’t use the SDK.

It’s crazy fast to sync, I use it all the time.

1 Like

I :heart: YWallet

Below is a very clear explanation by @joshs from ECC, which I’ve pasted from the Telegram Community. ZCG plans on funding audits for wallets later this year.

4 Likes

Thanks for the citation and feedback. I stear clear of wallets that haven’t been audited or do not have a track record of privacy/FOSS activism.

Unfortunately, IMO, there are no good mobile lite wallet options that are NU5 ready, fast to sync, and audited/supported by the ECC.

should ecc zec foundation provide clarity to new users how and should store their zec in what wallet or can only store users’ zec in a transparent exodus wallet to face the upcoming nu5 31 may

1 Like

I believe holding ZEC on any of the listed Zcash wallets should be fine. UA support will probably be added over time, after the NU5 activation. Wallets - Zcash

1 Like

For whatever wallet you pick just ensure you back it up

3 Likes

Also I recommend reading tbe 4.7.0 and 5.0.0 release notes, important information especially if your running a FN with those versions but even still good to know if you aren’t

Here, read it

v5.0.0

Latest

Notable changes

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:

Feature Deprecation and removal

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.

Deprecated

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

  • The zcrawreceive RPC method is disabled. It may be reenabled with allowdeprecated=zcrawreceive
  • The zcrawjoinsplit RPC method is disabled. It may be reenabled with allowdeprecated=zcrawjoinsplit
  • The zcrawkeygen RPC method is disabled. It may be reenabled with allowdeprecated=zcrawkeygen

Option handling

  • The -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).
  • A new -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.
  • A new -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.

RPC Interface

  • The default 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 .

RPC Changes

  • The deprecated 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.

Build system

  • zcutil/build.sh now automatically runs zcutil/clean.sh to remove files created by previous builds. We previously recommended to do this manually.

Dependencies

  • The boost and native_b2 dependencies have been updated to version 1.79.0

Tests

  • The environment variable that allows users of the rpc (Python) tests to override the default path to the zcashd executable has been changed from BITCOIND to ZCASHD .

v4.7.0

Changes to Testnet NU5 Consensus Rules

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 .

  • In order to better support hardware wallets, transparent signature hash construction as defined in ZIP 244 has been modified to include a hash of the serialization of the amounts of all outputs being spent, along with a hash of all spent outputs 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.
  • This release fixes a bug in v4.6.0 that caused a consensus failure on the Zcash testnet at height 1,779,200 . For details see 5990853.
  • There have been changes to the Halo2 proving system to improve consistency between the specification and the implementation, and these may break compatibility. See for example zcash/halo2@247cd62.
  • There have been numerous changes to the Orchard circuit implementation since v4.6.0 . See Issues · zcash/orchard · GitHub for a complete list.
  • A potential Faerie Gold vulnerability affecting the previous activation of NU5 on testnet and existing since v4.6.0 has been mitigated.

NU5 Testnet Reactivation

To support the aforementioned testnet consensus changes, the following changes are made in zcashd v4.7.0 :

  • The consensus branch ID for NU5 is changed to 0xC2D6D0B4 .
  • The protocol version indicating NU5-aware testnet nodes is set to 170050 .
  • The testnet reactivation height for NU5 is set to 1,842,420 .

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 .

Emergency Recovery Phrases

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.

Wallet Updates

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.

New RPC Methods

  • 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.

RPC Changes

  • The result type for the listaddresses endpoint has been modified:
    • The keypool source type has been removed; it was reserved but not used.
    • In the 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 .
    • Addresses derived from the wallet’s mnemonic seed are now included in listaddresses output.
  • The results of the 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.
  • The results of the 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 .
  • A new 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
    • A pool attribute has been added to each result to indicate what pool the received funds are held in.
    • A boolean-valued change attribute has been added to indicate whether the output is change.
    • Block metadata attributes 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.
  • The output format of 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.
  • The result value for 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.
  • Legacy transparent address generation using 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’

  • The 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.
  • The restriction that prohibited 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.
  • A new string parameter, 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.
  • Since Sprout outputs are no longer created (with the exception of change) z_sendmany no longer generates payment disclosures (which were only available for Sprout outputs) when the -paymentdisclosure experimental feature flag is set.
  • Outgoing viewing keys used for shielded outputs are now produced as described in ZIP 316
  • When sending from or to one or more unified addresses, change outputs are now always sent to addresses controlled by the wallet’s internal spending keys, as described in ZIP 316. These addresses are not returned by any RPC API, as they are intended to never be shared with any third party, and are for wallet-internal use only. This change improves the privacy properties that may be maintained when sharing a unified internal viewing key for an account in the wallet.
  • In cases where 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.

RPC Deprecations

  • 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.

Build System

  • Clang has been updated to use LLVM 13.0.1.
  • libc++ has been updated to use LLVM 13.0.1, except on Windows where it uses 13.0.0-3.
  • The Rust toolchain dependency has been updated to version 1.59.0.

Platform Support

  • Debian 9 has been removed from the list of supported platforms.
  • Debian 11 (Bullseye) has been added to the list of supported platforms.
  • A build issue (a missing header file) has been fixed for macOS targets.
  • On Arch Linux only, a copy of Debian’s libtinfo5_6.0 is used to fix a build regression.

Mining

  • Mining to Orchard recipients is now supported on testnet.
  • It is now possible to mine to a Sapling receiver of a unified address.
  • Concurrency bugs related to getblocktemplate have been fixed via backports from Bitcoin Core.

Licenses

  • License information in contrib/debian/copyright has been updated to be more accurate.
2 Likes

Would anyone care to update the thread about NU5 FAQs with anything relevant from this thread? :nerd_face:

2 Likes