zips/zip-0308.rst

140 lines
3.6 KiB
ReStructuredText
Raw Normal View History

::
ZIP: 308
Title: Sprout to Sapling Migration
Author: Daira Hopwood <daira@z.cash>
Eirik Ogilvie-Wigley <eirik@z.cash>
Category: RPC/Wallet
Created: 2018-11-27
License: MIT
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
interpreted as described in RFC 2119. [#RFC2119]_
The terms below are to be interpreted as follows:
Sprout protocol
Code-name for the Zcash shielded protocol at launch.
Sapling protocol
Code-name for the Zcash shielded protocol added by the second Zcash network upgrade,
also known as Network Upgrade 1.
Abstract
========
This proposal describes privacy-preserving procedures for transferring funds between
Sprout and Sapling z-addresses, and supporting RPC operations.
Motivation
==========
Sapling good, Sprout bad. Summarize why. We assume users will therefore want
to migrate all their shielded funds to Sapling.
Transfers from Sprout to Sapling can't be fully private because turnstile.
We want to hide migration txes among all users that are doing the migration.
Requirements
============
It must be possible to enable or disable migration.
Will eventually transfer all shielded funds in Sprout z-addresses to
Sapling z-addresses, provided the node is working.
Takes a "reasonable" length of time to do so.
Mitigates information leakage about:
* linkage between particular z-addresses or users, and the amounts held
* the distribution of amounts of individual notes
via timing information and transaction data.
Does not interfere with other concurrent usage of the node.
Stateless, to the extent possible. (This is required for the previous point.)
Provides visibility for the wallet/node user into the progress of the
migration.
Provides sufficient information to debug failed transactions that are part
of the migration.
Recovers from failed operations to the extent possible.
Send a variable number of txns for each migration block.
Each user sends not too small number of txns (to obscure their total amount).
Non-requirements
================
No need for breakfast. Or a pony.
Does not require or assume network layer anonymity (but user can configure Tor if they want).
What is leaked?
---------------
Amount sent through transparent pool.
Fee.
Dev fee if any.
Number of Sprout JoinSplits.
Number of Sapling Outputs.
Arrival times of transactions into mempool.
Expiry height.
That this is a migration tx (because it has both JoinSplits and Sapling Outputs).
Not leaked
----------
Transparent inputs/outputs (there are none)
vpub_out of each JoinSplit (because we only have one nonzero vpub_out)
Specification
=============
Support in zcashd
=================
Support for Sapling consensus rules was implemented in zcashd version 2.0.0.
The majority of support for RPC calls and persistence of Sapling z-addresses
was implemented in version 2.0.1. Both of these versions advertise protocol
version 170007.
References
==========
.. [#protocol] `Zcash Protocol Specification, Version 2018.0-beta-32 [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#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-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling <https://github.com/zcash/zips/blob/master/zip-0243.rst>`_