From 4aefbb8a17d168042df012e695b00a7c8e2c5243 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Wed, 27 Mar 2019 07:23:06 +1300 Subject: [PATCH] Draft ZIP: Sapling Anchor Deduplication within Transactions Part of https://github.com/zcash/zcash/issues/3375 --- drafts/zip-str4d-sapling-anchor.rst | 110 ++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) create mode 100644 drafts/zip-str4d-sapling-anchor.rst diff --git a/drafts/zip-str4d-sapling-anchor.rst b/drafts/zip-str4d-sapling-anchor.rst new file mode 100644 index 00000000..a9bc26e8 --- /dev/null +++ b/drafts/zip-str4d-sapling-anchor.rst @@ -0,0 +1,110 @@ +:: + + ZIP: XXX + Title: Sapling Anchor Deduplication within Transactions + Owners: Jack Grigg + Status: Draft + Category: Consensus + Created: 2019-03-27 + 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]_. + +Abstract +======== + +This proposal defines a modification to the transaction format whereby a single Sapling +anchor is used for all Sapling spends. This change removes a potential implementation +fingerprint, and reduces the size of Sapling transactions within the block chain. + + +Motivation +========== + +The Sapling network upgrade [#zip-0205]_ introduced new shielded inputs (spends) and +outputs. Each spend proves the existence of the note being spent by including the anchor +of a Merkle tree that contains the note's commitment, and proving in zero knowledge the +existence of a path from the commitment to the anchor (a witness). Valid anchors +correspond to the state of the Sapling commitment tree after each block in the chain. + +The choice of anchor leaks information about the note being spent, namely that the note +was created no later than the anchor's block height. This is an unavoidable outcome of the +Zcash design, and the least information it is possible to leak about a note being spent. +However, the Sapling v4 transaction format [#v4-tx]_ includes a separate anchor for each +Sapling spend, and thus it is possible to leak additional information by using different +anchors for different notes. The anchor selection choices could also be used as a +fingerprint to identify transactions created by particular wallet implementations, +reducing the privacy set. + +Modifying the transaction format to have a single Sapling anchor field, instead of one +field per Sapling spend, removes the ability (within the new transaction format version) +to create transactions with this fingerprint. It also reduces the size of the transaction, +costing 32 bytes per transaction instead of 32 bytes per spend. + + +Specification +============= + +A new transaction format is defined, identical to the Sapling v4 transaction format +except for two changes: + +- The ``anchor`` field in ``SpendDescription`` is removed. +- A new field ``saplingAnchor`` is placed between ``vShieldedOutput`` and ``vJoinSplit``, + if and only if ``vShieldedSpend`` is not empty. + +Consensus rules that previously applied to individual ``anchor`` entries MUST be applied +to ``saplingAnchor``. + +TODO: If this is the only ZIP updating the transaction format in a NU, specify the full +transaction format here. Otherwise, reference the new transaction format when specified. + +Implementations that support older transaction formats MAY copy ``saplingAnchor`` into +each spend's in-memory representation during parsing to reduce code duplication, and MUST +ensure that these per-spend in-memory anchors are all identical prior to serialization. + + +Rationale +========= + +Placing the ``saplingAnchor`` field after ``vShieldedOutput`` means that it can be +conditionally included (saving space when there are no Sapling spends), while ensuring +that the transaction can still be parsed unambiguously. + +Requiring all Sapling spends to use the same anchor removes a possible performance +optimisation in certain classes of (particularly light) wallets, where witnesses for older +notes are only updated periodically instead of every block. This optimisation is exactly +the kind of behaviour that can be used as a fingerprint in the v4 transaction format, and +that we are choosing to prevent with this proposal. + + +Security and Privacy Considerations +=================================== + +This proposal eliminates a possible avenue for distinguishing transactions based on the +client implementation that created them. + + +Reference Implementation +======================== + +TBD + + +References +========== + +.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ +.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade `_ +.. [#v4-tx] `Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling] `_