mirror of https://github.com/zcash/zips.git
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:
parent
65443520b5
commit
2465eb6fd8
|
@ -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>`_
|
||||
|
|
Loading…
Reference in New Issue