mirror of https://github.com/zcash/zips.git
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:
parent
dfed189b26
commit
73b3ccb65c
14
zip-0211.rst
14
zip-0211.rst
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue