New Release 4.5.1 – Electric Coin Company

TL;DR: This is a required replace for all testnet nodes, and is extremely advisable for mainnet nodes if you’re utilizing the getbalance RPC methodology.

Testnet Orchard Circuit Changes

In the zcashd 4.5.0 weblog submit, we indicated {that a} testnet rollback may happen to replace the consensus guidelines, if we would have liked to make backwards-incompatible modifications. Shortly after zcashd v4.5.0 was launched, throughout one other inner evaluation of the Orchard circuit, we recognized two bugs that might have an effect on the upcoming testnet activation of NU5:

  • The diversifier base g_d_old, for the word being spent, is required to be a non-identity level. A word created from a cost tackle with g_d set to the id (through collaboration between sender and recipient) could possibly be spent a number of occasions with totally different nullifiers (comparable to totally different ivks). The code exterior the circuit appropriately enforced the non-identity requirement, however the circuit didn’t appropriately constrain this, and allowed the prover to witness the id.
  • SinsemillaCommit could be modeled as a Pedersen dedication to an output of SinsemillaHash: SinsemillaCommit(r, M) = SinsemillaHashToLevel(M) + [r] R. The specification used incomplete addition right here, matching its use inside SinsemillaHash. However, in contrast to in SinsemillaHash, an distinctive case could be produced right here when r = 0. The derivations of rivk (for computing ivk) and rcm (for computing the word dedication) usually make sure that r = 0 can solely happen with negligible likelihood, however these derivations will not be checked by the circuit for effectivity; thus SinsemillaCommit wants to make use of full addition.

These bugs don’t have an effect on mainnet, as zcashd v4.5.0 solely set the activation top for NU5 on testnet for testing functions. Nevertheless, within the curiosity of retaining the testnet setting as near mainnet as potential, we’re fixing these bugs instantly. This means a change to the NU5 consensus guidelines, and a brand new testnet activation top for NU5.

To this finish, the next modifications are made in zcashd v4.5.1:

  • The consensus department ID for NU5 is modified to 0x37519621.
  • The protocol model indicating NU5-aware testnet nodes is about to 170015.
  • The testnet activation top for NU5 is about to 1,599,200.

Testnet nodes that improve to zcashd v4.5.1 prior to dam top 1,590,000 will comply with the brand new testnet community improve. Testnet nodes which are working zcashd v4.5.0 at that top might want to improve to v4.5.1 after which run with -reindex.

Fixed regression in getbalance RPC methodology

This launch additionally fixes a regression within the getbalance RPC methodology. zcashd v4.5.0 eliminated the account API from the pockets, following its deprecation and elimination in upstream Bitcoin Core. As a part of the upstream modifications, the getbalance RPC methodology was altered from utilizing two customized steadiness computation strategies, to as a substitute counting on CWallet::GetBalance. This methodology internally depends on CWalletTx::IsFromMe as a part of figuring out “trusted” zero-confirmation transactions to incorporate within the steadiness calculation.

There is an equal and closely-named CWallet::IsFromMe methodology, which is used all through the pockets, and had been up to date earlier than Zcash launched to pay attention to spent shielded notes. The change to getbalance uncovered a bug: CWalletTx::IsFromMe had not been equally up to date, which triggered getbalance to disregard wallet-internal (despatched between two addresses within the node’s pockets) unshielding transactions with zero confirmations. This launch fixes the bug.


As at all times, it’s potential that additional backwards-incompatible modifications is perhaps made to the NU5 consensus guidelines on this testing section, previous to setting the mainnet activation top, as we proceed to conduct further inner evaluation. In the occasion that this occurs, testnet might be rolled again in (or previous to) v5.0.0, and a brand new testnet activation will happen.

You might also like