From 845ca0f8113bc73c42deb809cad3976d8cb7baa9 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Sat, 30 Mar 2019 04:47:27 -0300 Subject: [PATCH 01/14] Draft ZIP: Shielded Coinbase Part of https://github.com/zcash/zcash/issues/2488 --- drafts/zip-str4d-shielded-coinbase.rst | 162 +++++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 drafts/zip-str4d-shielded-coinbase.rst diff --git a/drafts/zip-str4d-shielded-coinbase.rst b/drafts/zip-str4d-shielded-coinbase.rst new file mode 100644 index 00000000..50378019 --- /dev/null +++ b/drafts/zip-str4d-shielded-coinbase.rst @@ -0,0 +1,162 @@ +:: + + ZIP: XXX + Title: Shielded Coinbase + Owners: Jack Grigg + Status: Draft + Category: Consensus + Created: 2019-03-30 + License: MIT + + +Terminology +=========== + +The key words "MUST" and "MAY" in this document are to be interpreted as described in +RFC 2119. [#RFC2119]_ + +The term "network upgrade" in this document is to be interpreted as described in ZIP 200 +[#zip-0200]_. + +The term "Sapling" in this document is to be interpreted as described in ZIP 205 +[#zip-0205]_. + +The terms "Founders' Reward", "funding stream", and "active funding stream" in this +document are to be interpreted as described in ZIP 207 [#zip-0207]_. + +Abstract +======== + +This proposal defines modifications to the Zcash consensus rules that enable coinbase +funds to be mined to Sapling addresses. It does not disable the use of transparent +addresses in coinbase transactions. + + +Motivation +========== + +Zcash inherited the concept of "coinbase transactions" from Bitcoin: special transactions +inside each block that are allowed to have no inputs. These transactions are created by +miners during block creation, and collect the block reward and transaction fees into new +transparent outputs that can then be spent. They are also leveraged in Zcash for the +Founders' Reward and funding streams [#zip-0207]_. + +On the path to deprecating and removing Bitcoin-inherited transparent addresses within the +Zcash network, a required step is to be able to create coinbase transactions that have no +transparent outputs. However, Zcash was launched with a consensus rule preventing coinbase +transactions from containing shielded outputs, instead enforcing that coinbase funds could +not be spent in transactions with transparent outputs. This was partly in order to reduce +the complexity of the original Zcash modifications to the Bitcoin Core codebase, but also +because at the time, shielded transactions required significant memory and CPU resources +to create. + +The Sapling network upgrade [#zip-0205]_ deployed architectural changes and performance +improvements that make shielding funds directly in the coinbase transaction feasible. In +order to reduce the complexity of the Sapling network upgrade, the existing consensus +rules preventing coinbase transactions from containing shielded outputs were extended to +cover Sapling outputs. Therefore, it is now necessary to modify the consensus rules in +order to enable miners to start using Sapling addresses. + + +Specification +============= + +Prior to activation of the TODO network upgrade, the existing consensus rule requiring +coinbase transactions to have zero Sapling outputs is enforced. + +Once the TODO network upgrade activates: + +- The above existing consensus rule is no longer active, and coinbase transactions MAY + contain Sapling outputs. + +- The consensus rules applied to ``valueBalance``, ``vShieldedOutput``, and ``bindingSig`` + in non-coinbase transactions MUST also be applied to coinbase transactions. + +- The existing consensus rule requiring transactions that spend coinbase outputs to have + an empty ``vout``, is amended to only apply to transactions that spend transparent + coinbase outputs. + +- The existing consensus rule requiring coinbase outputs to have 100 confirmations before + they may be spent (coinbase maturity), is amended to only apply to transparent coinbase + outputs. + +- All Sapling outputs in coinbase transactions MUST have valid note commitments when + recovered using a 32-byte array of zeroes as the outgoing viewing key. + +- Funding streams MAY target Sapling addresses in addition to transparent P2SH addresses. + +- The existing consensus rule from ZIP 207 [#zip-0207]_ requiring coinbase transactions + for block height ``height`` to pay active funding streams with a standard P2SH script, + is amended to only apply to active funding streams that target a transparent address at + ``height``. + +- In the coinbase transaction for block height ``height``, for every active funding stream + that targets a Sapling address at ``height``, the transaction MUST include at least one + Sapling output that pays exactly the funding stream's value to the target Sapling + address. + + +Rationale +========= + +The ZIP does not require that all coinbase must be shielded immediately from activation of +the network upgrade, so that miners and mining pools may gradually migrate from their +existing transparent addresses to Sapling addresses. This also simplifies the consensus +rules, because there are funding streams that target transparent addresses, and thus it +remains necessary for the time being to support them. A future ZIP will require all +coinbase to be shielded immediately. + +Enforcing coinbase maturity at the consensus level for Sapling outputs would incur +significant complexity in the consensus rules, because it would require special-casing +coinbase note commitments in the Sapling commitment tree. The standard recommendation when +spending a note is to select an anchor 10 blocks back from the current chain tip, which +acts as a de-facto 10-block maturity on all notes, coinbase included. This might be +proposed as a consensus rule in future. + +There is another reason for shielded coinbase maturity being unnecessary: when a rollback +occurs that would cause a shielded coinbase output to disappear, it will also invalidate +every shielded transaction that uses an anchor descending from the tree that the shielded +coinbase output had been appended to. That is, all economic activity would be rolled back +in addition to the shielded coinbase output disappearing, so there is no reason to make +shielded coinbase a special-case when the same behaviour occurs in regular shielded notes +already. In the transparent coinbase case, only direct child transactions of the +transparent coinbase would become invalid, and thus it would be possible to end up in a +situation where a logical child transaction (for example, a mining pool paying out miners) +persists in the block chain after its logical parent (the mining pool receiving a block) +disappears. + +Requiring that note commitments are valid when recovering using a fixed outgoing viewing +key implies that target addresses and values for all Sapling outputs within the coinbase +are revealed. This is necessary to enforce funding streams correctly, and it is simpler to +enforce this on all outputs. Additionally, this maintains the ability for network +observers to track miners and mining pools. Meanwhile, the miners and mining pools could +put useful or identifying text in the memo fields of the outputs, instead of storing it +ad-hoc elsewhere in the coinbase transaction. + + +Security and Privacy Considerations +=================================== + +Sapling outputs in coinbase transactions are by design publicly-viewable, in contrast to +Sapling outputs in normal transactions. This does not introduce any privacy regressions, +because coinbase output values and recipient addresses have always been public +information. + +Revealing the coinbase output notes does not enable anyone else to detect when the note is +spent, which removes the need for a separate shielding step like is enforced for +transparent coinbase outputs. + + +Reference Implementation +======================== + +TBD + + +References +========== + +.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ +.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade `_ +.. [#zip-0207] `ZIP 207: Split Founders' Reward `_ From fcb49762f1e1e134ecd62e05806281f639fe7739 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Thu, 2 May 2019 11:49:14 +0100 Subject: [PATCH 02/14] Address Daira's comments --- drafts/zip-str4d-shielded-coinbase.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drafts/zip-str4d-shielded-coinbase.rst b/drafts/zip-str4d-shielded-coinbase.rst index 50378019..42c9e019 100644 --- a/drafts/zip-str4d-shielded-coinbase.rst +++ b/drafts/zip-str4d-shielded-coinbase.rst @@ -103,7 +103,7 @@ The ZIP does not require that all coinbase must be shielded immediately from act the network upgrade, so that miners and mining pools may gradually migrate from their existing transparent addresses to Sapling addresses. This also simplifies the consensus rules, because there are funding streams that target transparent addresses, and thus it -remains necessary for the time being to support them. A future ZIP will require all +remains necessary for the time being to support them. A future ZIP could require all coinbase to be shielded immediately. Enforcing coinbase maturity at the consensus level for Sapling outputs would incur @@ -118,7 +118,7 @@ occurs that would cause a shielded coinbase output to disappear, it will also in every shielded transaction that uses an anchor descending from the tree that the shielded coinbase output had been appended to. That is, all economic activity would be rolled back in addition to the shielded coinbase output disappearing, so there is no reason to make -shielded coinbase a special-case when the same behaviour occurs in regular shielded notes +shielded coinbase a special case when the same behaviour occurs in regular shielded notes already. In the transparent coinbase case, only direct child transactions of the transparent coinbase would become invalid, and thus it would be possible to end up in a situation where a logical child transaction (for example, a mining pool paying out miners) @@ -137,7 +137,7 @@ ad-hoc elsewhere in the coinbase transaction. Security and Privacy Considerations =================================== -Sapling outputs in coinbase transactions are by design publicly-viewable, in contrast to +Sapling outputs in coinbase transactions are by design publicly viewable, in contrast to Sapling outputs in normal transactions. This does not introduce any privacy regressions, because coinbase output values and recipient addresses have always been public information. From df70f410f3eea4b502b867ef76008d96b3768283 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Thu, 2 May 2019 11:50:06 +0100 Subject: [PATCH 03/14] Assigned ZIP number 213 --- drafts/zip-str4d-shielded-coinbase.rst => zip-0213.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename drafts/zip-str4d-shielded-coinbase.rst => zip-0213.rst (99%) diff --git a/drafts/zip-str4d-shielded-coinbase.rst b/zip-0213.rst similarity index 99% rename from drafts/zip-str4d-shielded-coinbase.rst rename to zip-0213.rst index 42c9e019..e8029baa 100644 --- a/drafts/zip-str4d-shielded-coinbase.rst +++ b/zip-0213.rst @@ -1,6 +1,6 @@ :: - ZIP: XXX + ZIP: 213 Title: Shielded Coinbase Owners: Jack Grigg Status: Draft From bc6ee29250177a33f44f74b51c632597bc56cfc2 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Thu, 2 May 2019 12:02:22 +0100 Subject: [PATCH 04/14] Make funding stream consensus rules conditional on ZIP 207 deployment ZIP 207 was withdrawn from the Blossom network upgrade, and this ZIP can no longer assume that it will already be deployed. --- zip-0213.rst | 35 ++++++++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 9 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index e8029baa..b2f537cf 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -39,7 +39,7 @@ Zcash inherited the concept of "coinbase transactions" from Bitcoin: special tra inside each block that are allowed to have no inputs. These transactions are created by miners during block creation, and collect the block reward and transaction fees into new transparent outputs that can then be spent. They are also leveraged in Zcash for the -Founders' Reward and funding streams [#zip-0207]_. +Founders' Reward (and potentially for funding streams [#zip-0207]_). On the path to deprecating and removing Bitcoin-inherited transparent addresses within the Zcash network, a required step is to be able to create coinbase transactions that have no @@ -83,6 +83,14 @@ Once the TODO network upgrade activates: - All Sapling outputs in coinbase transactions MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. + +Interaction with funding streams +-------------------------------- + +If ZIP 207 [#zip-0207]_ is accepted and deployed prior to (or in the same network upgrade +as) this ZIP, the following additional consensus rules are enforced once the TODO network +upgrade activates: + - Funding streams MAY target Sapling addresses in addition to transparent P2SH addresses. - The existing consensus rule from ZIP 207 [#zip-0207]_ requiring coinbase transactions @@ -96,15 +104,24 @@ Once the TODO network upgrade activates: address. +Interaction with the Founders' Reward +------------------------------------- + +This ZIP does not alter the existing Founders' Reward addresses. If a future ZIP proposed +moving to shielded Founders' Reward addresses (instead of, or before, deploying ZIP 207), +the necessary consensus rules would be similar to those specified above for funding +streams. + + Rationale ========= The ZIP does not require that all coinbase must be shielded immediately from activation of the network upgrade, so that miners and mining pools may gradually migrate from their existing transparent addresses to Sapling addresses. This also simplifies the consensus -rules, because there are funding streams that target transparent addresses, and thus it -remains necessary for the time being to support them. A future ZIP could require all -coinbase to be shielded immediately. +rules, because the Founders' Reward targets transparent addresses, and thus it remains +necessary for the time being to support them. A future ZIP could require all coinbase to +be shielded immediately. Enforcing coinbase maturity at the consensus level for Sapling outputs would incur significant complexity in the consensus rules, because it would require special-casing @@ -127,11 +144,11 @@ disappears. Requiring that note commitments are valid when recovering using a fixed outgoing viewing key implies that target addresses and values for all Sapling outputs within the coinbase -are revealed. This is necessary to enforce funding streams correctly, and it is simpler to -enforce this on all outputs. Additionally, this maintains the ability for network -observers to track miners and mining pools. Meanwhile, the miners and mining pools could -put useful or identifying text in the memo fields of the outputs, instead of storing it -ad-hoc elsewhere in the coinbase transaction. +are revealed. This would be necessary to correctly enforce shielded Founders' Reward or +funding stream outputs, and it is simpler to enforce this on all outputs. Additionally, +this maintains the ability for network observers to track miners and mining pools. +Meanwhile, the miners and mining pools could put useful or identifying text in the memo +fields of the outputs, instead of storing it ad-hoc elsewhere in the coinbase transaction. Security and Privacy Considerations From 821bd9f8f18a24a2bc2b3090374b5545f4ac12d4 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Sat, 19 Oct 2019 16:43:35 +1300 Subject: [PATCH 05/14] ZIP 213: Remove hypothetical about Sapling FR addresses If a future ZIP is proposed, it can specify its own consensus rules. --- zip-0213.rst | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index b2f537cf..b9b47d41 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -107,10 +107,7 @@ upgrade activates: Interaction with the Founders' Reward ------------------------------------- -This ZIP does not alter the existing Founders' Reward addresses. If a future ZIP proposed -moving to shielded Founders' Reward addresses (instead of, or before, deploying ZIP 207), -the necessary consensus rules would be similar to those specified above for funding -streams. +This ZIP does not alter the existing Founders' Reward addresses. Rationale From 90ad18ff228e86830da965a5180cfc6e2acac520 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Sat, 19 Oct 2019 16:44:27 +1300 Subject: [PATCH 06/14] s/when a rollback occurs/when a reorg or rollback occurs/ --- zip-0213.rst | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index b9b47d41..9004ae7d 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -127,17 +127,17 @@ spending a note is to select an anchor 10 blocks back from the current chain tip acts as a de-facto 10-block maturity on all notes, coinbase included. This might be proposed as a consensus rule in future. -There is another reason for shielded coinbase maturity being unnecessary: when a rollback -occurs that would cause a shielded coinbase output to disappear, it will also invalidate -every shielded transaction that uses an anchor descending from the tree that the shielded -coinbase output had been appended to. That is, all economic activity would be rolled back -in addition to the shielded coinbase output disappearing, so there is no reason to make -shielded coinbase a special case when the same behaviour occurs in regular shielded notes -already. In the transparent coinbase case, only direct child transactions of the -transparent coinbase would become invalid, and thus it would be possible to end up in a -situation where a logical child transaction (for example, a mining pool paying out miners) -persists in the block chain after its logical parent (the mining pool receiving a block) -disappears. +There is another reason for shielded coinbase maturity being unnecessary: when a reorg or +rollback occurs that would cause a shielded coinbase output to disappear, it will also +invalidate every shielded transaction that uses an anchor descending from the tree that +the shielded coinbase output had been appended to. That is, all economic activity would be +rolled back in addition to the shielded coinbase output disappearing, so there is no +reason to make shielded coinbase a special case when the same behaviour occurs in regular +shielded notes already. In the transparent coinbase case, only direct child transactions +of the transparent coinbase would become invalid, and thus it would be possible to end up +in a situation where a logical child transaction (for example, a mining pool paying out +miners) persists in the block chain after its logical parent (the mining pool receiving a +block) disappears. Requiring that note commitments are valid when recovering using a fixed outgoing viewing key implies that target addresses and values for all Sapling outputs within the coinbase From b09b53bea1c1864f1b9b9ec0d643c585db3b23ce Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 27 Jan 2020 20:15:58 +0000 Subject: [PATCH 07/14] Remove "Interaction with funding streams" ZIP 207 will not be deployed before this ZIP, so interactions should be handled there. --- zip-0213.rst | 20 -------------------- 1 file changed, 20 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index 9004ae7d..d3319e7b 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -84,26 +84,6 @@ Once the TODO network upgrade activates: recovered using a 32-byte array of zeroes as the outgoing viewing key. -Interaction with funding streams --------------------------------- - -If ZIP 207 [#zip-0207]_ is accepted and deployed prior to (or in the same network upgrade -as) this ZIP, the following additional consensus rules are enforced once the TODO network -upgrade activates: - -- Funding streams MAY target Sapling addresses in addition to transparent P2SH addresses. - -- The existing consensus rule from ZIP 207 [#zip-0207]_ requiring coinbase transactions - for block height ``height`` to pay active funding streams with a standard P2SH script, - is amended to only apply to active funding streams that target a transparent address at - ``height``. - -- In the coinbase transaction for block height ``height``, for every active funding stream - that targets a Sapling address at ``height``, the transaction MUST include at least one - Sapling output that pays exactly the funding stream's value to the target Sapling - address. - - Interaction with the Founders' Reward ------------------------------------- From 5d9b1b747d695f8fefdd5fd08121b964a981d022 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 27 Jan 2020 20:18:44 +0000 Subject: [PATCH 08/14] Clarify specification of decryption with all-zero ovk --- zip-0213.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index d3319e7b..361da31a 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -80,8 +80,9 @@ Once the TODO network upgrade activates: they may be spent (coinbase maturity), is amended to only apply to transparent coinbase outputs. -- All Sapling outputs in coinbase transactions MUST have valid note commitments when - recovered using a 32-byte array of zeroes as the outgoing viewing key. +- Full Sapling note decryption MUST succeed using the all-zero outgoing viewing key. More + precisely, all Sapling outputs in coinbase transactions MUST have valid note commitments + when recovered using a 32-byte array of zeroes as the outgoing viewing key. Interaction with the Founders' Reward From c7d1afe2ab4e74497c1eb2e6424e696cd2a3176a Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 27 Jan 2020 20:20:39 +0000 Subject: [PATCH 09/14] Reference Heartwood in ZIP 213 --- zip-0213.rst | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index 361da31a..a7f87bd6 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -61,10 +61,10 @@ order to enable miners to start using Sapling addresses. Specification ============= -Prior to activation of the TODO network upgrade, the existing consensus rule requiring -coinbase transactions to have zero Sapling outputs is enforced. +Prior to activation of the Heartwood network upgrade, the existing consensus rule +requiring coinbase transactions to have zero Sapling outputs is enforced. -Once the TODO network upgrade activates: +Once the Heartwood network upgrade activates: - The above existing consensus rule is no longer active, and coinbase transactions MAY contain Sapling outputs. @@ -142,6 +142,12 @@ spent, which removes the need for a separate shielding step like is enforced for transparent coinbase outputs. +Deployment +========== + +This proposal will be deployed with the Heartwood network upgrade. + + Reference Implementation ======================== From 83e8313045e194d6cf898610b882255fce94846e Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 27 Jan 2020 20:21:05 +0000 Subject: [PATCH 10/14] Add link to reference implementation of ZIP 213 --- zip-0213.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0213.rst b/zip-0213.rst index a7f87bd6..7894f515 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -151,7 +151,7 @@ This proposal will be deployed with the Heartwood network upgrade. Reference Implementation ======================== -TBD +https://github.com/zcash/zcash/pull/4256 References From 84bbeaaed4cceedf786590e39842b7f6040d24c6 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 27 Jan 2020 20:23:23 +0000 Subject: [PATCH 11/14] Clarify that coinbase spending restrictions only apply to transparent outputs --- zip-0213.rst | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index 7894f515..1ba30a5a 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -72,13 +72,16 @@ Once the Heartwood network upgrade activates: - The consensus rules applied to ``valueBalance``, ``vShieldedOutput``, and ``bindingSig`` in non-coinbase transactions MUST also be applied to coinbase transactions. -- The existing consensus rule requiring transactions that spend coinbase outputs to have - an empty ``vout``, is amended to only apply to transactions that spend transparent - coinbase outputs. +- Only transparent outputs in coinbase transactions are subject to the existing + restrictions on spending coinbase funds. More precisely: -- The existing consensus rule requiring coinbase outputs to have 100 confirmations before - they may be spent (coinbase maturity), is amended to only apply to transparent coinbase - outputs. + - The existing consensus rule requiring transactions that spend coinbase outputs to have + an empty ``vout``, is amended to only apply to transactions that spend transparent + coinbase outputs. + + - The existing consensus rule requiring coinbase outputs to have 100 confirmations + before they may be spent (coinbase maturity), is amended to only apply to transparent + coinbase outputs. - Full Sapling note decryption MUST succeed using the all-zero outgoing viewing key. More precisely, all Sapling outputs in coinbase transactions MUST have valid note commitments From 84517efcd1416d44f2706faee1fd509bbd100905 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 27 Jan 2020 20:26:59 +0000 Subject: [PATCH 12/14] Remove unused term --- zip-0213.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index 1ba30a5a..425913dc 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -21,8 +21,8 @@ The term "network upgrade" in this document is to be interpreted as described in The term "Sapling" in this document is to be interpreted as described in ZIP 205 [#zip-0205]_. -The terms "Founders' Reward", "funding stream", and "active funding stream" in this -document are to be interpreted as described in ZIP 207 [#zip-0207]_. +The terms "Founders' Reward" and "funding stream" in this document are to be interpreted +as described in ZIP 207 [#zip-0207]_. Abstract ======== From 4781183ab995d32b6fe34d58002d6cd51abe7364 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 27 Jan 2020 20:32:53 +0000 Subject: [PATCH 13/14] Add a note about post-quantum privacy to ZIP 213 privacy considerations --- zip-0213.rst | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index 425913dc..46fdb124 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -136,9 +136,12 @@ Security and Privacy Considerations =================================== Sapling outputs in coinbase transactions are by design publicly viewable, in contrast to -Sapling outputs in normal transactions. This does not introduce any privacy regressions, -because coinbase output values and recipient addresses have always been public -information. +Sapling outputs in normal transactions. This does not introduce any privacy regressions +relative to existing coinbase transactions, because coinbase output values and recipient +addresses have always been public information. However, users with threat models that rely +on keeping their Sapling address private (for example, to maintain post-quantum privacy), +and who are also miners or mining pools, should use a coinbase-specific address when +creating blocks. Revealing the coinbase output notes does not enable anyone else to detect when the note is spent, which removes the need for a separate shielding step like is enforced for From d388e80a532b53dbe1b7c1a0fae5024ad5b3bd45 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Tue, 28 Jan 2020 17:53:27 +0000 Subject: [PATCH 14/14] Include more precise consensus rule wording matching the protocol spec --- zip-0213.rst | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/zip-0213.rst b/zip-0213.rst index 46fdb124..4a4d2c64 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -61,13 +61,21 @@ order to enable miners to start using Sapling addresses. Specification ============= -Prior to activation of the Heartwood network upgrade, the existing consensus rule -requiring coinbase transactions to have zero Sapling outputs is enforced. +Prior to activation of the Heartwood network upgrade, this existing consensus rule on +coinbase transactions is enforced: + + A coinbase transaction MUST NOT have any JoinSplit descriptions, Spend descriptions, + or Output descriptions. Once the Heartwood network upgrade activates: -- The above existing consensus rule is no longer active, and coinbase transactions MAY - contain Sapling outputs. +- Coinbase transactions MAY contain Sapling outputs. More precisely, the above existing + consensus rule is modified to: + + A coinbase transaction MUST NOT have any JoinSplit descriptions or Spend + descriptions. + + [Pre-Heartwood] A coinbase transaction also MUST NOT have any Output descriptions. - The consensus rules applied to ``valueBalance``, ``vShieldedOutput``, and ``bindingSig`` in non-coinbase transactions MUST also be applied to coinbase transactions. @@ -81,7 +89,12 @@ Once the Heartwood network upgrade activates: - The existing consensus rule requiring coinbase outputs to have 100 confirmations before they may be spent (coinbase maturity), is amended to only apply to transparent - coinbase outputs. + coinbase outputs. Specifically, it becomes: + + A transaction MUST NOT spend a transparent output of a coinbase transaction from a + block less than 100 blocks prior to the spend. Note that outputs of coinbase + transactions include Founders’ Reward outputs [and potentially funding stream + outputs]. - Full Sapling note decryption MUST succeed using the all-zero outgoing viewing key. More precisely, all Sapling outputs in coinbase transactions MUST have valid note commitments