Draft ZIP "Disabling Sprout Outputs": address review comments and correct rST errors.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2019-04-02 22:25:23 +01:00
parent 65443520b5
commit 2465eb6fd8
1 changed files with 5 additions and 4 deletions

View File

@ -55,7 +55,7 @@ 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 both shielded transaction protocols.
Removing the ability to send to Sprout outputs is a first step toward reducing this
complexity and potential risk. This does not prevent extracting value held in Sprout
@ -74,7 +74,7 @@ Sapling v4 transaction format [#v4-tx]_:
- When creating JoinSplit descriptions, the Sprout output notes MUST be either
internal change (i.e. spent in a subsequent JoinSplit of the same transaction),
or dummy notes as described in [#protocol] section 4.7.1.
or dummy notes as described in [#protocol]_ section 4.7.1.
- The output commitments of a JoinSplit description in a v5 transaction MUST NOT
be added to the output Sprout commitment tree. That is, the root of the Sprout note
@ -88,7 +88,7 @@ decryption of those fields to detect incoming payments as described in [#protoco
sections 4.18 and 4.16.2. The processing of nullifiers in the algorithm of section 4.18
is unaffected.
Note that the consensus protcol does not prevent a wallet from incorrectly creating
Note that the consensus protocol does not prevent a wallet from incorrectly creating
a Sprout output note that is neither internal change nor a dummy note. In this case
the value associated with the note cannot be spent and is therefore "burnt".
@ -111,7 +111,7 @@ JoinSplit description in a v5 transaction from 1698 bytes to 464 bytes, and avoi
the need to scan those fields for incoming payments.
During the development of this proposal, an alternative design was considered that
would also have removed the ``commitment'' field from v5 JoinSplit descriptions,
would also have removed the ``commitment`` field from v5 JoinSplit descriptions,
instead computing the commitments in a way that ensured at the consensus level that
they had zero value. This alternative was not adopted because it would have prevented
the use of internal change between JoinSplits, and that would have resulted in an
@ -153,3 +153,4 @@ References
.. [#v4-tx] `Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#zerocash] `Zerocash: Decentralized Anonymous Payments from Bitcoin (extended version) <http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf>`_
.. [#counterfeiting] `Zcash Counterfeiting Vulnerability Successfully Remediated <https://z.cash/blog/zcash-counterfeiting-vulnerability-successfully-remediated/>`_
.. [#migration] `Draft ZIP 308: Sprout to Sapling Migration <https://github.com/zcash/zips/pull/197>`_