zips/zip-0211.rst

::

  ZIP: 211
  Title: Disabling Sprout Outputs
  Owners: Daira Hopwood <daira@z.cash>
  Credits: Sean Bowe <sean@z.cash>
  Status: Draft
  Category: Consensus
  Created: 2019-03-29
  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 term "Sprout value pool balance" in this document is to be interpreted as described
in ZIP 209 [#zip-0209]_.


Abstract
========

This proposal disables the ability to add new value to the Sprout shielded value pool
balance. This takes a step toward being able to remove the Sprout protocol, thus reducing
the overall complexity and attack surface of Zcash.


Motivation
==========

The first iteration of the Zcash network, called Sprout, provided a shielded payment
protocol that was relatively closely based on the original Zerocash proposal. [#zerocash]_

The Sapling network upgrade [#zip-0205]_ introduced significant efficiency and
functionality improvements for shielded transactions. It is expected that over time,
the use of Sapling shielded transactions will replace the use of Sprout.

The Sapling and Sprout shielded protocols employ different cryptographic designs.
Since an adversary could potentially exploit any vulnerability in either design,
supporting both presents additional risk over supporting only the newer Sapling protocol.

For example, a vulnerability was discovered in the zero-knowledge proving system
originally used by Zcash that could have allowed counterfeiting [#counterfeiting]_.
While this particular vulnerability was addressed (also for Sprout shielded transactions)
by the Sapling upgrade, and we are not aware of others at the time of writing, the
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.

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
held in Sprout addresses and sending it to transparent addresses, or to Sapling addresses
via the migration tool [#zip-0308]_.


Specification
=============

From the relevant activation height, the ``vpub_old`` field of each JoinSplit decription
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.


Rationale
=========

This design does not require any change to the JoinSplit circuit, thus minimizing
the risk of security regressions, and avoiding the need for a new ceremony to generate
circuit parameters.

The code changes needed are very small and simple, and their security is easy to
analyse.

During the development of this proposal, alternative designs were considered that
would have removed some fields of a JoinSplit description. These alternatives were
abandoned for several reasons:

* Privacy concerns raised as a consequence of preventing the use of internal change
  between JoinSplits, and/or change sent back to the input Sprout addresses. This
  would have required the total value of the input Sprout notes (or, for some considered
  designs, the total value of the two Sprout inputs to each JoinSplit) to be leaked.
  As it is, there is an unavoidable leak of the total value extracted from the Sprout
  value pool, but not of the sum of values of particular subsets of notes.

* Modifications would have been needed to the design of the Sprout to Sapling migration
  procedure described in [#zip-0308]_.

* A new transaction version would have been required.


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.


Deployment
==========

At the time of writing it has not been decided which network upgrade (if any) will
implement this proposal. Since the proposal is a purely contracting consensus change,
it could also be implemented as a "soft fork".


Reference Implementation
========================

TBD


References
==========

.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0205.rst>`_
.. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Value Pool <https://github.com/zcash/zips/blob/master/zip-0209.rst>`_
.. [#zip-0308] `ZIP 308: Sprout to Sapling Migration <https://github.com/zcash/zips/blob/master/zip-0308.rst>`_
.. [#protocol] `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/>`_