zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 211: Address review comments and correct the list of used RFC 2119 keywords. 

Clarify that supporting Sprout outputs is already OPTIONAL.

Signed-off-by: Daira Hopwood <daira@katava.local>
This commit is contained in:
Daira Hopwood 2019-06-05 09:37:52 +01:00 committed by Daira Hopwood
parent dfed189b26
commit 73b3ccb65c
1 changed files with 9 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
zip-0211.rst
View File

@ -13,8 +13,8 @@
Terminology
===========
The key words "MUST" and "MAY" in this document are to be interpreted as described in
RFC 2119. [#RFC2119]_
The key words "MUST", "SHOULD", and "OPTIONAL" 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]_.
@ -55,7 +55,8 @@ by the Sapling upgrade, and we are not aware of others at the time of writing, t
possibility of other cryptographic weaknesses cannot be entirely ruled out.
In addition, the Zcash specification and implementation incurs complexity and
"technical debt" from the requirement to support both shielded transaction protocols.
"technical debt" from the requirement to support and test both shielded transaction
protocols.
Removing the ability to add to the Sprout shielded value pool balance, is a first step
toward reducing this complexity and potential risk. This does not prevent extracting value
@ -72,6 +73,9 @@ MUST be zero.
When this proposal is activated, nodes and wallets MUST disable any facilities to
send to Sprout addresses, and this SHOULD be made clear in user interfaces.
Note that the facility to send to Sprout addresses, before activation of this proposal,
is in any case OPTIONAL for a particular node or wallet implementation.
Rationale
=========
@ -106,8 +110,8 @@ Security and Privacy Considerations
The security motivations for making this change are described in the Motivation section.
Privacy concerns that led to the current design are discussed in the Rationale section.
Since all clients change their behaviour at the same time when this proposal activates,
there is no additional client distinguisher.
Since all clients change their behaviour at the same time from this proposal's activation
height, there is no additional client distinguisher.
Deployment