New Launch 4.5.1 – Electrical Coin Firm

TL;DR: This can be a required replace for all testnet nodes, and is very advisable for mainnet nodes in case you are utilizing the getbalance RPC technique.

Testnet Orchard Circuit Adjustments

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

• The diversifier base g_d_old, for the be aware being spent, is required to be a non-identity level. A be aware created from a cost deal with with g_d set to the id (by way of collaboration between sender and recipient) may very well be spent a number of instances with completely different nullifiers (equivalent to completely different ivks). The code outdoors the circuit accurately enforced the non-identity requirement, however the circuit didn’t accurately constrain this, and allowed the prover to witness the id.
• SinsemillaCommit may be modeled as a Pedersen dedication to an output of SinsemillaHash: SinsemillaCommit(r, M) = SinsemillaHashToPoint(M) + [r] R. The specification used incomplete addition right here, matching its use inside SinsemillaHash. Nevertheless, in contrast to in SinsemillaHash, an distinctive case may be produced right here when r = 0. The derivations of rivk (for computing ivk) and rcm (for computing the be aware dedication) usually make sure that r = 0 can solely happen with negligible chance, however these derivations should not 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 peak for NU5 on testnet for testing functions. Nonetheless, within the curiosity of preserving the testnet setting as near mainnet as doable, we’re fixing these bugs instantly. This implies a change to the NU5 consensus guidelines, and a brand new testnet activation peak for NU5.

To this finish, the next adjustments 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 peak for NU5 is about to 1,599,200.

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

Fastened regression in getbalance RPC technique

This launch additionally fixes a regression within the getbalance RPC technique. 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 adjustments, the getbalance RPC technique was altered from utilizing two customized steadiness computation strategies, to as an alternative counting on CWallet::GetBalance. This technique internally depends on CWalletTx::IsFromMe as a part of figuring out “trusted” zero-confirmation transactions to incorporate within the steadiness calculation.

There may be an equal and closely-named CWallet::IsFromMe technique, 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 precipitated 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 doable that additional backwards-incompatible adjustments may be made to the NU5 consensus guidelines on this testing section, previous to setting the mainnet activation peak, as we proceed to conduct further inner evaluation. Within the occasion that this occurs, testnet will probably be rolled again in (or previous to) v5.0.0, and a brand new testnet activation will happen.