diff --git a/README.rst b/README.rst index 87cd85c50..f5f0e07c2 100644 --- a/README.rst +++ b/README.rst @@ -130,6 +130,7 @@ Released ZIPs 252 Deployment of the NU5 Network Upgrade Final 253 Deployment of the NU6 Network Upgrade Final 255 Deployment of the NU6.1 Network Upgrade Proposed + 256 Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2 Proposed 257 Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade Proposed 271 Dev Fund Extension and One-Time Disbursement Proposed 300 Cross-chain Atomic Transactions Proposed @@ -336,6 +337,7 @@ Index of ZIPs 253 Deployment of the NU6 Network Upgrade Final 254 Deployment of the NU7 Network Upgrade (Withdrawn) Withdrawn 255 Deployment of the NU6.1 Network Upgrade Proposed + 256 Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2 Proposed 257 Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade Proposed 258 Deployment of the NU6.3 Network Upgrade Draft 260 Extending Block Messages with Additional Authentication Data Reserved diff --git a/README.template b/README.template index 4f078629e..afb4ba91a 100644 --- a/README.template +++ b/README.template @@ -70,7 +70,6 @@ The following ZIPs are under consideration for deployment in NU7: - `ZIP 233: Network Sustainability Mechanism: Removing Funds From Circulation `__ - `ZIP 234: Network Sustainability Mechanism: Issuance Smoothing `__ - `ZIP 235: Network Sustainability Mechanism: Remove 60% of Transaction Fees From Circulation `__ -- `ZIP 246: Digests for the Version 6 Transaction Format `__ - `ZIP 2002: Explicit Fees `__ - `ZIP 2003: Disallow version 4 transactions `__ diff --git a/zips/zip-0209.rst b/zips/zip-0209.rst index 17aa3ab5d..7506ddc5f 100644 --- a/zips/zip-0209.rst +++ b/zips/zip-0209.rst @@ -56,9 +56,16 @@ and other disruption. Specification ============= -If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", or -"Orchard chain value pool balance" would become negative in the block chain created as a result of -accepting a block, then all nodes MUST reject the block as invalid. +If any of the Sprout chain value pool balance, Sapling chain value pool balance, +Orchard chain value pool balance, transparent chain value pool balance, or +deferred development fund chain value pool balance would become negative in the +block chain created as a result of accepting a block, then all nodes MUST reject +the block as invalid. + +If the sum of these chain value pool balances (i.e. the total supply, computed +without possibility of overflow) would become greater than $\mathsf{MAX\_MONEY}$ +zatoshis in the block chain created as a result of accepting a block, then all +nodes MUST reject the block as invalid. Nodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned restriction. diff --git a/zips/zip-0256.md b/zips/zip-0256.md new file mode 100644 index 000000000..c1224113b --- /dev/null +++ b/zips/zip-0256.md @@ -0,0 +1,397 @@ + + ZIP: 256 + Title: Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2 + Owners: Daira-Emma Hopwood + Status: Proposed + Category: Consensus / Network + Created: 2026-06-09 + License: MIT + Discussions-To: + + +# Terminology + +The key words "MUST" and "MUST NOT" in this document are to be interpreted as +described in BCP 14 [^BCP14] when, and only when, they appear in all capitals. + +The term "network upgrade" in this document is to be interpreted as described +in ZIP 200. [^zip-0200] + +The character § is used when referring to sections of the Zcash Protocol +Specification. [^protocol] + +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [^protocol-networks] + + +# Abstract + +This ZIP retrospectively documents the deployment and specification of +several consensus and denial-of-service bug fixes that were applied to the +Zcash node implementations, after the activation of NU6.1 [^zip-0255], up to +but not including the Orchard Temporary Vulnerability Mitigation and the +NU6.2 network upgrade. The latter are documented in ZIP 257. [^zip-0257]. + + +# Motivation + +Between the activation of NU6.1 and that of NU6.2, several consensus enforcement +bugs and denial-of-service vulnerabilities were reported and mitigated in the +zcashd and zebra full node implementations. This period corresponded to a sudden +spike in vulnerability reports, precipitated by the widespread use of capable AI +models for vulnerability discovery and mitigation. + +These vulnerabilities were fixed and deployed in zcashd releases v6.12.0 to +v6.12.4 inclusive, and in zebra releases v4.2.0 to v4.5.1 inclusive. + +This ZIP records the nature of those fixes, the releases in which they were +deployed, and corresponding specification changes and clarifications, so that +the behaviour of the network across this period is fully documented. + + +# Specification + +## Consensus rule changes + +The changes in this ZIP include the constricting consensus rule changes described +here. The corresponding [consensus changes in the Zcash Protocol Specification](#consensuschangesinthezcashprotocolspecification) +are described in that section. + +### Orchard identity rk + +An Orchard action with $\mathtt{rk}$ encoding the zero point on the Pallas curve +caused a panic during proof verification. Both zcashd and zebra now reject +$\mathtt{rk}$ encoding $\mathcal{O}_{\mathbb{P}}$. This is a constricting +consensus rule change, since the specification previously permitted $\mathtt{rk}$ +to encode the zero point. It is enforced by zcashd from v6.12.1, by zebra from v4.3.1, +and reflected in the `orchard` crate from version 0.13.0. [^ZODL-v6.12.1-fixes] + +### Changes to chain value balance accounting rules (ZIP 209) + +As a consequence of the integer-overflow and value-range hardening described +below for zcashd v6.12.1, the following change was made to ZIP 209. + +In ZIP 209's Specification section, replace + +> If any of the "Sprout chain value pool balance", "Sapling chain value pool +> balance", or "Orchard chain value pool balance" would become negative in the +> block chain created as a result of accepting a block, then all nodes MUST reject +> the block as invalid. + +with + +> If any of the Sprout chain value pool balance, Sapling chain value pool balance, +> Orchard chain value pool balance, transparent chain value pool balance, or +> deferred development fund chain value pool balance would become negative in the +> block chain created as a result of accepting a block, then all nodes MUST reject +> the block as invalid. +> +> If the sum of these chain value pool balances (i.e. the total supply, computed +> without possibility of overflow) would become greater than $\mathsf{MAX\_MONEY}$ +> zatoshis in the block chain created as a result of accepting a block, then all +> nodes MUST reject the block as invalid. + +The extension of the non-negativity rule to the deferred development pool balance +had already been implemented for NU6 [^zcashd-lockbox-PR] [^zebra-lockbox-PR]. + +The extension of the non-negativity rule to the transparent balance, and the rule +on the total supply, were implemented in zcashd v6.12.1 [^zcashd-v6.12.1-PR], in +response to weaknesses in zcashd's chain value pool balance accounting [^ZODL-v6.12.1-fixes]: + +- **Chain value pool balance-tracking reset.** A duplicate block header could + silently reset chain value pool balance-tracking fields, effectively disabling + ZIP 209 [^zip-0209] turnstile enforcement for versions of zcashd from v6.0.0 + (the first release in which the bug was triggerable on Mainnet) prior to + v6.12.1. A variation on the attack could persist corrupted per-block + chain value pool deltas. zcashd v6.12.1 onward defers pool-value initialization + until after the duplicate-data check, adds a chain-supply checkpoint at NU6.1 + activation covering all value pools, and recomputes shielded chain value pool + deltas (since the checkpoint) from block data on startup. + +- **Chain value pool balance hardening.** Complementary to the above fixes, + zcashd v6.12.1 onward tightened its implementation of turnstile and lockbox + accounting to more rigorously apply overflow/underflow checking, supporting + local reasoning about the correctness of the accounting arithmetic. + +An intended effect of the latter hardening was to enforce the stricter consensus +rules described above in zcashd. Zebra had already been using checked arithmetic +consistently, representing each chain value pool balance as an amount required to +be non-negative and at most $\mathsf{MAX\_MONEY}$, and constraining each intermediate +value to its correct range. + +## Consensus changes in the Zcash Protocol Specification + +This section includes only consensus changes; additional +[clarifications to the Zcash Protocol Specification](#clarificationstothezcashprotocolspecification) +are given in a later section. + +### rk-related changes + +Add a consensus rule in § 4.6 ‘Action descriptions’: + +> * $\mathsf{rk}$ MUST NOT be the identity point $\mathcal{O}_{\mathbb{P}}$. + +In the same section, change the non-normative note + +> * $\mathsf{cv}$ and $\mathsf{rk}$ can be the zero point $\mathcal{O}_{\mathbb{P}}$. +> $\mathsf{epk}$ cannot be $\mathcal{O}_{\mathbb{P}}$. + +to + +> * $\mathsf{cv}$ can be the zero point $\mathcal{O}_{\mathbb{P}}$. +> $\mathsf{rk}$ and $\mathsf{epk}$ cannot be $\mathcal{O}_{\mathbb{P}}$. + +Add a non-normative note: + +> * The restriction $\mathsf{rk} \neq \mathcal{O}_{\mathbb{P}}$ was enforced as +> a "soft fork", without a specific activation height, by zcashd from v6.12.1 and +> by zebra from v4.3.1 [ZIP-256]. It was introduced in response to a panic that +> $\mathtt{rk}$ encoding the zero point caused during proof verification, in both +> zcashd and zebra. The bug occurred in conversion of the $\mathsf{rk}$ Pallas +> curve point to the corresponding circuit public inputs. The underlying circuit +> implementation did and does support $\mathsf{rk} = \mathcal{O}_{\mathbb{P}}$, +> represented with coordinates $(0, 0)$, and that case would have been harmless +> had it been handled correctly, but excluding it was the simpler and safer response +> under the circumstances. + +Also add a note to § 4.18.4 ‘Action Statement (Orchard)’ explaining that the case +$\mathsf{rk} = \mathcal{O}_{\mathbb{P}}$ will not occur due to the above consensus +rule. + +### ZIP 209-related changes + +Make changes in § 4.17 ‘Chain Value Pool Balances’ [^protocol-chainvalue] +corresponding to the changes to ZIP 209. These mirror the changes described +above and are not spelled out here. + +## Additional consensus node implementation conformance fixes + +Each of the following makes an implementation enforce a rule the protocol +specification already defines, restoring agreement of zcashd and zebra to +the specification and to each other. + +No consensus rule change is introduced for these implementation flaws. +[Clarifications to the Zcash Protocol Specification](#clarificationstothezcashprotocolspecification) +relating to two of these flaws are given in that section below. + +- **Sprout transaction verification.** A flaw in zcashd's verification of + Sprout proofs on block connection could have allowed invalid Sprout + transactions to be accepted. Fixed in zcashd v6.12.0 [^zcashd-v6.12.0-PR]. + [^ZODL-v6.12.0-fixes] + +- **Orchard invalid $\mathtt{ephemeralKey}$.** + An Orchard action with $\mathtt{ephemeralKey}$ encoding the zero point —or any + other 32-byte string that does not encode a valid Pallas curve point— was accepted + by zcashd but rejected by zebra as required by § 4.6 [^protocol-actiondesc], a + potential consensus split. zcashd now requires $\mathtt{ephemeralKey}$ to decode + to a valid non-zero Pallas point. This was partially fixed in zcashd v6.12.1 + (rejecting the zero Pallas point encoding) [^ZODL-v6.12.1-fixes]. The fix was + extended to all invalid encodings in v6.12.2 [^zcashd-v6.12.2-PR]. + +- **Sapling v4 $\mathtt{valueBalanceSapling}$ normalization.** The v4 + transaction deserializer accepted a transaction with no Spend descriptions and + no Output descriptions, but $\mathtt{valueBalanceSapling}$ encoding a non-zero + value. The value was normalized to zero during deserialization, so the + consensus check that should have rejected it ran against the normalized zero + and never fired. zebra rejected the encoding at deserialization as required by + § 7.1.2 [^protocol-txnconsensus], so the malformed encoding would have caused + a consensus split. zcashd now rejects it at deserialization, matching zebra. + Fixed in zcashd v6.12.2 [^zcashd-v6.12.2-PR]. + +- **NU5-onward block-body poisoning.** In NU5 and later, the authorizing data of + v5 transactions is committed by the header's $\mathtt{hashBlockCommitments}$ + (via $\mathtt{hashAuthDataRoot}$), not by $\mathtt{hashMerkleRoot}$. A + body-derived rejection firing before the auth-commitment check could + permanently mark an honest header invalid. zcashd now pre-checks + $\mathtt{hashBlockCommitments}$ before any body-mutable check on the + active-tip path, and treats the sidechain case as body-replaceable. This + closes the class of vulnerabilities, including the `bad-blk-sigops`, + `bad-cb-length`, and `bad-blk-length` trigger paths. Initial fix in zcashd + v6.12.2 [^zcashd-v6.12.2-PR]; structurally closed in v6.12.4 [^zcashd-v6.12.4-PR]. + [^GHSA-ghc3-g8w4-whf9] + +- **P2SH input sigop count.** zebra's P2SH input signature-operation count did + not match zcashd; this was corrected to restore agreement. Fixed in zebra + v4.5.1 [^Zebra-v4.5.1-changelog]. + +- **Input ordering.** zebra did not preserve the order of inputs in + `spent_outputs` for transactions spending a mix of chain and mempool outputs, + and so an input could be matched against the wrong spent output during + validation. Fixed in zebra v4.2.0 [^Zebra-v4.2.0-changelog]. + +- **Other zebra validity fixes.** zebra accepted coinbase transactions + containing Sapling spends; did not validate transparent input/output alignment + before script verification; and could treat a v5 transaction as verified on + the basis of its mined transaction id alone. These were corrected in zebra + v4.4.0 [^Zebra-v4.4.0-changelog]. + +## Denial-of-service and node-crash hardening + +The following issues allowed remotely triggered crashes or unbounded resource use. +They affect node liveness but do not change which blocks or transactions are valid. + +### Zcashd + +- **Coinbase shielded value-balance crash.** A coinbase transaction with a + positive Sapling or Orchard value balance would desynchronize chain-supply + accounting from pool balances in `ConnectBlock`, triggering a node abort and a + crash loop on restart. Fixed in zcashd v6.12.4. [^GHSA-ghc3-g8w4-whf9] + +- **Out-of-range pool-value delta.** A block whose aggregate per-pool value + delta was out of monetary range left the sending peer unbanned, and re-wrote + the body to disk on each replay. Fixed in zcashd v6.12.4. [^GHSA-ghc3-g8w4-whf9] + +- **Use-after-free in `ConnectBlock`.** CVE-2024-52911, a use-after-free in the + script verification path inherited from Bitcoin Core [^CVE-2024-52911]. Fixed + in zcashd v6.12.3. + +- **Integer-overflow and value-range hardening.** Chain value pool balance + accumulation was hardened against undefined behaviour from signed integer + overflow. Value range exceptions are now caught as consensus rejections. + Fixed in zcashd v6.12.1. [^ZODL-v6.12.1-fixes] + +### Zebra + +- **Unbounded preallocation and duplicate-delivery DoS.** The fix for this + issue added caps on `Vec::with_capacity` reservations driven by peer-supplied + counts; added caps on `block::Hash` and `CountedHeader` allocation; and removed + rejected block hashes from `SentHashes` so that honest re-deliveries are not + short-circuited. Fixed in zebra v4.5.0. [^Zebra-v4.5.0-changelog] + +## Clarifications to the Zcash Protocol Specification + +These clarifications do not change consensus rules. + +### § 7.1.2 ‘Transaction Consensus Rules’ + +In reference to this rule: + +> If $\mathsf{effectiveVersion} = 4$ and there are no Spend descriptions or +> Output descriptions, then $\mathtt{valueBalanceSapling}$ MUST be $0$. + +add the note: + +> zcashd prior to v6.12.1 misimplemented the rule that requires +> $\mathtt{valueBalanceSapling} = 0$ for a v4 transaction with no Spend +> descriptions and no Output descriptions. It incorrectly normalized the +> value to $0$ when no Spend or Output descriptions were present, with the +> consequence that the failure case for this rule was never reached. For +> clarification, $\mathtt{valueBalanceSapling}$ refers to the value as +> encoded in the transaction, which is not normalized in this way; it does +> not refer to $\mathsf{v^{balanceSapling}}$. + +### Various sections + +The consensus rule "Elements of an Action description MUST be canonical encodings +of the types given above." in § 4.6 ‘Action descriptions’, properly belongs in +§ 7.5 ‘Action Description Encoding and Consensus’ [^protocol-actionencodingandconsensus]. + +Similarly, the corresponding rules in § 4.3 ‘JoinSplit Descriptions’, +§ 4.4 ‘Spend Descriptions’, and § 4.5 ‘Output Descriptions’, belong in +§ 7.2, § 7.3, and § 7.4 respectively. + +Add a non-normative note in section § 7.5 documenting the +[invalid $\mathsf{ephemeralKey}$ issue](#invalidephemeralkey) and the versions +of zcashd it affected. + +Wherever else Pallas curve points are decoded, add cross-references to +§ 5.4.9.6 ‘Pallas and Vesta’, and include implementation notes on validation +in that section. Similarly, wherever points on other elliptic curves are +decoded, add cross-references to the relevant sections. + +## Deployment + +These fixes were enforced immediately on upgrade in each release below; none +was gated on a block height or network-upgrade activation. + +| Release | Date | Fixes | +| -------------- | ---------- | ----- | +| zcashd v6.12.0 | 2026-03-27 | Sprout transaction verification | +| zcashd v6.12.1 | 2026-04-17 | Orchard zero $\mathtt{rk}$ / $\mathtt{ephemeralKey}$; chain value-pool accounting; integer-overflow / value-range hardening | +| zcashd v6.12.2 | 2026-05-06 | Sapling `valueBalanceSapling` normalization; strengthened $\mathtt{ephemeralKey}$ check; block-body poisoning (initial) | +| zcashd v6.12.3 | 2026-05-07 | CVE-2024-52911 use-after-free | +| zcashd v6.12.4 | 2026-06-01 | block-body poisoning (structural); coinbase value-balance crash; out-of-range pool-value delta | +| zebra v4.2.0 | 2026-03-12 | input-ordering validity fix | +| zebra v4.3.1 | 2026-04-17 | Orchard zero $\mathtt{rk}$ / $\mathtt{ephemeralKey}$ | +| zebra v4.4.0 | 2026-05-01 | coinbase Sapling spend; transparent input/output alignment; v5-verification | +| zebra v4.5.0 | 2026-05-28 | preallocation / duplicate-delivery DoS | +| zebra v4.5.1 | 2026-05-29 | P2SH input sigop count | + +## Backward compatibility + +Most of these fixes tighten validity checks or harden the node, rejecting inputs +that were already invalid under the specification but were previously accepted +(or mishandled) by one or both full node implementations. Honest blocks and +transactions remain valid, so upgraded nodes do not diverge from each other. +Where one implementation previously accepted a malformed encoding, the fix +restores agreement with the other (for example the Sapling +$\mathtt{valueBalanceSapling}$ and Orchard $\mathtt{ephemeralKey}$ cases, where +the specification already required the relevant encodings to be rejected). + +The exclusion of Orchard $\mathsf{rk}$ = $\mathcal{O}_{\mathbb{P}}$ is a soft +fork: it removes transactions from the valid set rather than adding any, so it +cannot cause an upgraded node to reject a block that conforming miners produce. +$\mathsf{rk}$ is the spend authorization validating key randomized by $\alpha$. +When, as specified, $\alpha$ is generated uniformly at random, +$\mathsf{rk}$ = $\mathcal{O}_{\mathbb{P}}$ only with negligible probability — +so in practice no honest transaction is affected. + +The changes to chain value balance accounting would only affect consensus in +the event of another violation of intended consensus security properties. + +The denial-of-service hardening changes do not affect block or transaction +validity. + +# References + +[^BCP14]: [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14) + +[^protocol]: [Zcash Protocol Specification, Version 2025.6.3 or later](protocol/protocol.pdf) + +[^protocol-networks]: [Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + +[^protocol-txnconsensus]: [Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 7.1.2: Transaction Consensus Rules](protocol/protocol.pdf#txnconsensus) + +[^protocol-actiondesc]: [Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 4.6: Action Descriptions](protocol/protocol.pdf#actiondesc) + +[^protocol-chainvalue]: [Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 4.17: Chain Value Pool Balances](protocol/protocol.pdf#chainvaluepoolbalances) + +[^protocol-actionencodingandconsensus]: [Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 7.5: Action Description Encoding and Consensus](protocol/protocol.pdf#actionencodingandconsensus) + +[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst) + +[^zip-0201]: [ZIP 201: Network Peer Management for Overwinter](zip-0201.rst) + +[^zip-0209]: [ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances](zip-0209.rst) + +[^zip-0255]: [ZIP 255: Deployment of the NU6.1 Network Upgrade](zip-0255.md) + +[^zip-0257]: [ZIP 257: Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade](zip-0257.md) + +[^GHSA-ghc3-g8w4-whf9]: [Urgent Zcash hotfixes v6.12.4 & v6.20.0 (zcashd, affected v5.0.0–v6.13.0)](https://github.com/zcash/zcash/security/advisories/GHSA-ghc3-g8w4-whf9) + +[^zcashd-v6.12.0-PR]: [zcashd v6.12.0 post-release merge (zcash/zcash#7133)](https://github.com/zcash/zcash/pull/7133) + +[^zcashd-v6.12.1-PR]: [zcashd v6.12.1 post-release merge (zcash/zcash#7141)](https://github.com/zcash/zcash/pull/7141) + +[^zcashd-v6.12.2-PR]: [Hotfix v6.12.2 (zcash/zcash#7157)](https://github.com/zcash/zcash/pull/7157) + +[^zcashd-v6.12.4-PR]: [Zcashd release v6.20.0, which published the v6.12.4 security fixes (zcash/zcash#7174)](https://github.com/zcash/zcash/pull/7174) + +[^zcashd-lockbox-PR]: [Add lockbox funding streams and chain lockbox value pool tracking for NU6 (zcash/zcash#6912)](https://github.com/zcash/zcash/pull/6912) + +[^Zebra-v4.2.0-changelog]: [Zebra CHANGELOG — Zebra 4.2.0 (2026-03-12)](https://github.com/ZcashFoundation/zebra/blob/main/CHANGELOG.md#zebra-420---2026-03-12) + +[^Zebra-v4.4.0-changelog]: [Zebra CHANGELOG — Zebra 4.4.0 (2026-05-01)](https://github.com/ZcashFoundation/zebra/blob/main/CHANGELOG.md#zebra-440---2026-05-01) + +[^Zebra-v4.5.0-changelog]: [Zebra CHANGELOG — Zebra 4.5.0 (2026-05-28)](https://github.com/ZcashFoundation/zebra/blob/main/CHANGELOG.md#zebra-450---2026-05-28) + +[^Zebra-v4.5.1-changelog]: [Zebra CHANGELOG — Zebra 4.5.1 (2026-05-29)](https://github.com/ZcashFoundation/zebra/blob/main/CHANGELOG.md#zebra-451---2026-05-29) + +[^zebra-lockbox-PR]: [Track the balance of the deferred chain value pool (ZcashFoundation/zebra#8729)](https://github.com/ZcashFoundation/zebra/pull/8729) + +[^ZODL-v6.12.1-fixes]: [Several Zcash Vulnerabilities Successfully Remediated (Zcash Open Development Lab, 2026-04-17; zcashd v6.12.1, zebra v4.3.1)](https://zodl.com/zcashd-zebra-april-2026-disclosure/) + +[^ZODL-v6.12.0-fixes]: [Zcash Vulnerability Successfully Remediated (Zcash Open Development Lab, 2026-03-31; zcashd v6.12.0)](https://zodl.com/zcashd-sprout-verification-vulnerability/) + +[^CVE-2024-52911]: [Bitcoin Core disclosure of CVE-2024-52911](https://bitcoincore.org/en/2026/05/05/disclose-cve-2024-52911/) diff --git a/zips/zip-0258.md b/zips/zip-0258.md index be2d2a38e..c084a7759 100644 --- a/zips/zip-0258.md +++ b/zips/zip-0258.md @@ -100,10 +100,9 @@ value is directed into the *Ironwood pool*. ## Changes to ZIP 209 ZIP 209 [^zip-0209] is extended to track an Ironwood chain value pool balance and to require -it, like the other shielded pool balances, not to become negative. - -[TODO take account of changes that should be (but are not currently) made in ZIP 256. -The check for each pool is now that the chain value pool balance stays within [0, MAX_MONEY].] +it, like the other shielded pool balances, not to become negative or result in a sum of all +chain value pool balances greater than $\mathsf{MAX\_MONEY}$ zatoshis. These changes are +expressed relative to those in ZIP 256 [^zip-0256]. In the Terminology section, after the paragraph @@ -119,22 +118,29 @@ add In the Specification section, replace -> If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", or -> "Orchard chain value pool balance" would become negative in the block chain created as a -> result of accepting a block, then all nodes MUST reject the block as invalid. +> If any of the Sprout chain value pool balance, Sapling chain value pool balance, +> Orchard chain value pool balance, transparent chain value pool balance, or +> deferred development fund chain value pool balance would become negative in the +> block chain created as a result of accepting a block, then all nodes MUST reject +> the block as invalid. with -> If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", -> "Orchard chain value pool balance", or "Ironwood chain value pool balance" would become -> negative in the block chain created as a result of accepting a block, then all nodes MUST -> reject the block as invalid. +> If any of the Sprout chain value pool balance, Sapling chain value pool balance, +> Orchard chain value pool balance, Ironwood chain value pool balance, transparent +> chain value pool balance, or deferred development fund chain value pool balance would +> become negative in the block chain created as a result of accepting a block, then all +> nodes MUST reject the block as invalid. + +Note that the reference to "these chain value pool balances" in the immediately following +paragraph that constrains the sum of their values, should be interpreted as including the +Ironwood chain value pool balance. ## Changes to the Protocol Specification Changes corresponding to the [ZIP 209 changes above](#changestozip209) are required in § 4.17 ‘Chain Value Pool Balances’ [^protocol-chainvalue] to define an Ironwood chain value -pool balance alongside those for the existing Sprout, Sapling, and *Orchard pools*. These +pool balance alongside those for the existing *Sprout*, *Sapling*, and *Orchard pools*. These mirror the changes above and are not spelled out here. ## ZIP 2005 activation @@ -179,6 +185,8 @@ lower protocol versions. [^zip-0209]: [ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances](zip-0209.rst) +[^zip-0256]: [ZIP 256: Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2](zip-0256.md) + [^zip-2005]: [ZIP 2005: Ironwood Quantum Recoverability](zip-2005.md) [^zip-0229]: [ZIP 229: Version 6 Transaction Format](zip-0229.md)