diff --git a/draft-hopwood-coinbase-balance.rst b/draft-hopwood-coinbase-balance.rst new file mode 100644 index 00000000..1c63f12c --- /dev/null +++ b/draft-hopwood-coinbase-balance.rst @@ -0,0 +1,174 @@ +:: + + ZIP: XXX + Title: Blocks should balance exactly + Owners: Daira-Emma Hopwood + Credits: Jack Grigg + Kris Nuttycombe + Status: Draft + Category: Consensus + Created: 2024-07-02 + License: MIT + Discussions-To: + + +Terminology +=========== + +The key word "MUST" in this document is to be interpreted as described in BCP 14 +[#BCP14]_ when, and only when, it appears in all capitals. + +The term "network upgrade" in this document is to be interpreted as described in +ZIP 200. [#zip-0200]_ + +The terms "Testnet" and "Mainnet" are to be interpreted as described in section +3.12 of the Zcash Protocol Specification. [#protocol-networks]_ + +The character § is used when referring to sections of the Zcash Protocol Specification +[#protocol]_. + + +Abstract +======== + +In the current Zcash protocol, the miner of a coinbase transaction is permitted to +claim up to and including the total amount of miner subsidy plus fees from other +transactions in the block, but is not required to claim the full amount. + +This proposal would require the full amount of miner subsidy and fees to be +collected in coinbase transactions. + + +Motivation +========== + +The current semantics of coinbase transactions creates a potential for miners to +miscalculate the total amount of miner subsidy plus fees in a block. If they claim +a higher amount than the actual miner subsidy plus total fees, the block will be +invalid, but if they claim a lower amount, the excess is effectively burnt. As a +consequence, the effective ZEC issuance can fall short of the amount calculated +from the intended issuance curve. + +This unnecessarily complicates the question of how much ZEC has been issued: if it +is defined as not including the amounts that were left unclaimed by miners, then it +is difficult to calculate, and cannot be predicted exactly in advance for any given +block height. Alternatively if it is defined to include those amounts, then that +introduces potentially confusing discrepancies between different definitions of +issuance or total supply. + + +Requirements +============ + +The consensus rule change specified in this ZIP must: + +* allow issuance to be predicted exactly in advance, starting from the point at + which it activates; +* preclude errors by miners in computing the total miner subsidy plus fees for + transactions in the mined block; +* be deployable in the NU6 network upgrade, which is not expected to define a new + transaction version. + + +Non-requirements +================ + +Since this ZIP is intended to activate in a network upgrade that is not expected +to support a new transaction version, it cannot resolve the issue that the amounts +of fees are implicit in non-coinbase transactions. That issue results in various +potential security difficulties and the potential for users' wallets to inadvertently +overpay the fee, but solving that would require an explicit "fee" field. + +(It would technically be possible to encode the fee as a transparent output, but +that would be a more disruptive change than is desirable, since other consensus +rules would have to change in order to prevent this output from being spent, and +since existing consumers of the transaction format could misinterpret such outputs.) + +This consensus change is not intended to prevent other methods of provably removing +ZEC from the circulating supply, such as sending it to an address for which it +would be demonstrably infeasible to find the spending key. + + +Specification +============= + +From the activation block of this ZIP onward, coinbase transactions MUST claim all +of the available miner subsidy plus fees in their block. More specifically, the +following paragraph and consensus rule in § 3.4 "Transactions and Treestates" of +the Zcash Protocol Specification [#protocol-transactions]_: + + Transparent inputs to a transaction insert value into a transparent transaction + value pool associated with the transaction, and transparent outputs remove value + from this pool. As in Bitcoin, the remaining value in the transparent transaction + value pool of a non-coinbase transaction is available to miners as a fee. The + remaining value in the transparent transaction value pool of a coinbase transaction + is destroyed. + + **Consensus rule:** The remaining value in the transparent transaction value pool + MUST be nonnegative. + +is modified to become: + + Transparent inputs to a transaction insert value into a transparent transaction + value pool associated with the transaction, and transparent outputs remove value + from this pool. The effect of Sapling Spends and Outputs, and of Orchard Actions + on the transaction value pool are specified in § 4.13 and § 4.14 respectively. + + As in Bitcoin, the remaining value in the transparent transaction value pool of + a non-coinbase transaction is available to miners as a fee. That is, the sum of + those values for non-coinbase transactions in each block is treated as an implicit + input to the transaction value balance of the block's coinbase transaction (in + addition to the implicit input created by issuance). + + The remaining value in the transparent transaction value pool of coinbase transactions + in blocks prior to NU-X is destroyed. From activation of NU-X, this remaining value + is required to be zero; that is, all of the available balance MUST be consumed by + outputs of the coinbase transaction. + + **Consensus rules:** + + * The remaining value in the transparent transaction value pool of a non-coinbase + transaction MUST be nonnegative. + * [Pre-NU-X] The remaining value in the transparent transaction value pool of a + coinbase transaction MUST be nonnegative. + * [NU-X onward] The remaining value in the transparent transaction value pool of + a coinbase transaction MUST be zero. + +where "NU-X" is to be replaced by the designation of the network upgrade in which +this ZIP will be activated. + +Note that the differences in the first two paragraphs of the above replacement text +are clarifications of the protocol, rather than consensus changes. Those could be +made independently of this ZIP. + +This change applies identically to Mainnet and Testnet. + + +Deployment +========== + +Subject to community agreement, this ZIP is proposed to be deployed with NU6. [#zip-0253]_ + + +Reference implementation +======================== + +TODO + + +Acknowledgements +================ + +The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading +to the submission of this ZIP. + + +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" `_ +.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later `_ +.. [#protocol-transactions] `Zcash Protocol Specification, Version 2023.4.0. Section 3.4: Transactions and Treestates `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0253] `ZIP 253: Deployment of the NU6 Network Upgrade `_