zips/zip-0316.rst

::

  ZIP: 316
  Title: Unified Addresses
  Owners: Daira Hopwood <daira@electriccoin.co>
          Nathan Wilcox <nathan@electriccoin.co>
          Taylor Hornby <taylor@electriccoin.co>
          Jack Grigg <jack@electriccoin.co>
          Sean Bowe <sean@electriccoin.co>
          Kris Nuttycombe <kris@electriccoin.co>
          Ying Tong Lai <yingtong@electriccoin.co>
  Status: Proposed
  Category: Standards / RPC / Wallet
  Created: 2021-04-07
  License: MIT
  Discussions-To: <https://github.com/zcash/zips/issues/482>


Terminology
===========

The key words "MUST", "MUST NOT", and "SHOULD" in this document are to
be interpreted as described in RFC 2119. [#RFC2119]_

The terms below are to be interpreted as follows:

Recipient
  A wallet or other software that can receive transfers of assets (such
  as ZEC) or in the future potentially other transaction-based state changes.
Sender
  A wallet or other software that can send transfers of assets, or other
  future consensus state side-effects.
Receiver
  The necessary information to transfer an asset to a Recipient that generated
  that Receiver using a specific Transfer Protocol. Each Receiver is associated
  unambiguously with a specific Receiver Type, identified by an integer Typecode.
Legacy Address (or LA)
  A transparent, Sprout, or Sapling Address.
Unified Address (or UA)
  A Unified Address combines multiple Receivers.
Address
  Either a Legacy Address or a Unified Address.
Transfer Protocol
  A specification of how a Sender can transfer assets to a Recipient.
  For example, the Transfer Protocol for a Sapling Receiver is the subset
  of the Zcash protocol required to successfully transfer ZEC using Sapling
  Spend/Output Transfers as specified in the Zcash Protocol Specification.
  (A single Zcash transaction can contain transfers of multiple
  Transfer Protocols. For example a t→z transaction that shields to the
  Sapling pool requires both Transparent and Sapling Transfer Protocols.)
Address Encoding
  The externally visible encoding of an Address (e.g. as a string of
  characters or a QR code).


Abstract
========

This proposal defines Unified Addresses, which bundle together Zcash addresses
of different types in a way that can be presented as a single Address Encoding.
It also defines Unified Viewing Keys, which perform a similar function for
Zcash viewing keys.


Motivation
==========

Up to and including the Canopy network upgrade, Zcash supported the following
payment address types:

* Transparent Addresses (P2PKH and P2SH)
* Sprout Addresses
* Sapling Addresses

Each of these has its own Address Encodings, as a string and as a QR code.
(Since the QR code is derivable from the string encoding, for many purposes
it suffices to consider the string encoding.)

The Orchard proposal [#zip-0224]_ adds a new address type, Orchard Addresses.

The difficulty with defining new Address Encodings for each address type, is
that end-users are forced to be aware of the various types, and in particular
which types are supported by a given Sender or Recipient. In order to make
sure that transfers are completed successfully, users may be forced to
explicitly generate addresses of different types and re-distribute encodings
of them, which adds significant friction and cognitive overhead to
understanding and using Zcash.

The goals for a Unified Address standard are as follows:

- Simplify coordination between Recipients and Senders by removing complexity
  from negotiating address types.
- Provide a “bridging mechanism” to allow shielded wallets to successfully
  interact with conformant Transparent-Only wallets.
- Allow older conformant wallets to interact seamlessly with newer wallets.
- Enable users of newer wallets to upgrade to newer transaction technologies
  and/or pools while maintaining seamless interactions with counterparties
  using older wallets.
- Facilitate wallets to assume more sophisticated responsibilities for
  shielding and/or migrating user funds.
- Allow wallets to potentially develop new transfer mechanisms without
  underlying protocol changes.
- Provide forward compatibility that is standard for all wallets across a
  range of potential future features. Some examples might include Layer 2
  features, cross-chain interoperability and bridging, and decentralized
  exchange.
- The standard should work well for Zcash today and upcoming potential
  upgrades, and also anticipate even broader use cases down the road such
  as cross-chain functionality.


Requirements
============

Overview
--------

Unified Addresses specify multiple methods for payment to a Recipient's Wallet.
The Sender's Wallet can then non-interactively select the method of payment.

Importantly, any wallet can support Unified Addresses, even when that wallet
only supports a subset of payment methods for receiving and/or sending.

Despite having some similar characteristics, the Unified Address standard is
orthogonal to Payment Request URIs [#zip-0321]_ and similar schemes, and the
Unified Address format is likely to be incorporated into such schemes as a new
address type.

Concepts
--------

Wallets follow a model *Interaction Flow* as follows:

1. A Recipient *generates* an Address.
2. The Recipient wallet *encodes* the Address.
3. The Recipient wallet or human user *distributes* this Address Encoding,
   This ZIP leaves distribution mechanisms out of scope.
4. A Sender wallet or user *imports* the Address Encoding through any of
   a variety of mechanisms (QR Code scanning, Payment URIs, cut-and-paste,
   or “in-band” protocols like ``Reply-To`` memos).
5. A Sender wallet *decodes* the Address Encoding and performs validity
   checks.
6. (Perhaps later in time) the Sender wallet executes a transfer of ZEC
   (or other assets or future protocol state changes) to the Address.

Encodings of the same Address may be distributed zero or more times through
different means. Zero or more Senders may import addresses. Zero or more of
those may execute a Transfer. A single Sender may execute multiple Transfers
over time from a single import.

[TODO: examples]

Addresses
---------

A Unified Address (or UA for short) combines one or more Receivers.

When new Transport Protocols are introduced to the Zcash protocol after
Unified Addresses are standardized, those should introduce new Receiver Types
but *not* different address types outside of the UA standard. There needs
to be a compelling reason to deviate from the standard, since the benefits
of UA come precisely from their applicability across all new protocol
upgrades.

Receivers
---------

Every Wallet must properly *parse* a Unified Address containing unrecognized
Receiver Types.

A Wallet may process unrecognized Receiver Types by indicating to the user
their presence or similar information for usability or diagnostic purposes.

Transport Encoding
------------------

The string encoding is “opaque” to human readers: it does *not* allow
visual identification of which Receivers or Receiver Types are present.

The string encoding is resilient against typos, transcription errors,
cut-and-paste errors, unanticipated truncation, or other anticipated
UX hazards.

There is a well-defined encoding of a Unified Address as a QR Code,
which produces QR codes that are reasonably compact and robust.

There is a well-defined transformation between the QR Code and string
encodings in either direction.

The string encoding fits into ZIP-321 Payment URIs [#zip-0321]_ and
general URIs without introducing parse ambiguities.

The encoding must support sufficiently many Recipient Types to allow
for reasonable future expansion.

The encoding must allow all wallets to safely and correctly parse out
unrecognized Receiver Types well enough to ignore them.

Transfers
---------

When executing a Transfer the Sender selects a transfer method via a
Selection process.

Given a valid UA, Selection must treat any unrecognized Receiver as
though it were absent.

- This property is crucial for forward compatibility to ensure users
  who upgrade to newer protocols / UAs don't lose the ability to smoothly
  interact with older wallets.

- This property is crucial for allowing Transparent-Only UA-Conformant
  wallets to interact with newer shielded wallets, removing a
  disincentive for adopting newer shielded wallets.

- This property also allows Transparent-Only wallets to upgrade to
  shielded support without re-acquiring counterparty UAs. If they are
  re-acquired, the user flow and usability will be minimally disrupted.

Open Issues and Known Concerns
------------------------------

FIXME: We have a few of these I [Nathan] will add in future edits.
This is especially true of privacy impacts of transparent or cross-pool
transactions and the associated UX issues.


Non-requirements
================

...


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

Definitions
-----------



Encoding of Unified Payment Addresses
-------------------------------------

Rather than defining a Bech32 string encoding of Orchard shielded
payment addresses, we instead define a Unified Address format that
is able to encode a set of Receivers of different types. This enables
the consumer of a Unified Address (i.e. the Sender) to choose the
Receiver of the best type it supports, providing a better user
experience as new Receiver Types are added in the future.

Assume that we are given a set of one or more raw encodings of
Receivers of distinct types. That is, the set may optionally
contain one Receiver of each of the Receiver Types in the following
fixed Priority List:

* Typecode :math:`\mathtt{0x03}` — an Orchard raw address as defined
  in [#protocol-orchardpaymentaddrencoding]_;

* Typecode :math:`\mathtt{0x02}` — a Sapling raw address as defined
  in [#protocol-saplingpaymentaddrencoding]_;

* Typecode :math:`\mathtt{0x01}` — a transparent P2SH address, *or*
  Typecode :math:`\mathtt{0x00}` — a transparent P2PKH address.

We say that a Receiver Type is “better” than another when it appears
earlier in this Priority List.

A Unified Address MUST contain at least one shielded Receiver
(Typecodes :math:`\geq \mathtt{0x02}`).

The Sender of a payment to a Unified Address MUST use the Receiver
of the best Receiver Type that it supports from the set.

For example, consider a wallet that supports sending funds to Orchard
Receivers and does not support sending to any better Receiver Type. If
that wallet is given a UA that includes an Orchard Receiver and possibly
other Receivers, it MUST send to the Orchard Receiver.

The raw encoding of a Unified Address is a concatenation of
:math:`(\mathtt{typecode}, \mathtt{length}, \mathtt{addr})` encodings
of the consituent Receivers:

* :math:`\mathtt{typecode} : \mathtt{byte}` — the Typecode from the
  above list;

* :math:`\mathtt{length} : \mathtt{byte}` — the length in bytes of
  :math:`\mathtt{addr}`;

* :math:`\mathtt{addr} : \mathtt{byte[length]}` —
  the raw encoding of a shielded payment address, or the :math:`160`-bit
  script hash of a P2SH address [#P2SH]_, or the :math:`160`-bit
  validating key hash of a P2PKH address [#P2PKH]_.

The result of the concatenation is then encoded with Bech32m
[#bip-0350]_, ignoring any length restrictions. This is chosen over
Bech32 in order to better handle variable-length inputs.

For unified payment addresses on Mainnet, the Human-Readable Part (as
defined in [#bip-0350]_) is “``u``”. For unified payment addresses
on Testnet, the Human-Readable Part is “``utest``”.

Notes:

* The :math:`\mathtt{length}` field is always encoded as a single
  byte, *not* as a :math:`\mathtt{compactSize}`.

* For transparent addresses, the :math:`\mathtt{addr}` field does not
  include the first two bytes of a raw encoding.

* There is intentionally no Typecode defined for a Sprout shielded
  payment address. Since it is no longer possible (since activation
  of ZIP 211 in the Canopy network upgrade [#zip-0211]_) to send
  funds into the Sprout chain value pool, this would not be generally
  useful.

* Consumers MUST ignore constituent addresses with Typecodes they do
  not recognize.

* Consumers MUST reject unified payment addresses in which the same
  Typecode appears more than once, or that include both P2SH and
  P2PKH transparent addresses, or that contain only a transparent
  address.

* Producers SHOULD order the constituent addresses in the same order
  as the list of address types above. However, consumers MUST NOT
  assume this ordering, and it does not affect which address should
  be used by a consumer.

* There MUST NOT be additional bytes at the end of the raw encoding
  that cannot be interpreted as specified above.

* A wallet MAY allow its user(s) to configure which Receiver Types
  it can send to. It MUST NOT allow the user(s) to change the order
  of the Priority List used to choose the Receiver Type.


Address hardening
-----------------

Security goal (**near second preimage resistance**):

* An adversary is given :math:`q` Unified Addresses, generated honestly.
* The attack goal is to produce a “partially colliding” valid Unified
  Address that:

  a) has a string encoding matching that of *one of* the input
     addresses on some subset of characters (for concreteness, consider
     the first :math:`n` and last :math:`m` characters, up to some bound
     on :math:`n+m`);
  b) is controlled by the adversary (for concreteness, the adversary
     knows *at least one* of the private keys of the constituent
     addresses).

Security goal (**nonmalleability**):

* In this variant, part b) above is replaced by the meaning of the new
  address being “usefully” different than the address it is based on, even
  though the adversary does not know any of the private keys. For example,
  if it were possible to delete a shielded constituent address from a UA
  leaving only a transparent address, that would be a significant malleability
  attack.

Discussion
''''''''''

There is a generic brute force attack against near second preimage
resistance. The adversary generates UAs at random with known keys, until
one has an encoding that partially collides with one of the :math:`q` target
addresses. It may be possible to improve on this attack by making use of
properties of checksums, etc.

The generic attack puts an upper bound on the achievable security: if it
takes work :math:`w` to produce and verify a UA, and the size of the character
set is :math:`c`, then the generic attack costs :math:`\sim \frac{w \cdot
c^{n+m}}{q}`.

There is also a generic brute force attack against nonmalleability. The
adversary modifies the target address slightly and computes the corresponding
decoding, then repeats until the decoding is valid and also useful to the
adversary (e.g. it would lead to the Sender using a transparent address).
With :math:`w` defined as above, the cost is :math:`w/p` where :math:`p` is
the probability that a random decoding is of the required form.

Proposed solution
'''''''''''''''''

We use an unkeyed 4-round Feistel construction to approximate a random
permutation. (As explained below, 3 rounds would not be sufficient.)

Let :math:`H_i` be a hash personalized by :math:`i`, with maximum output
length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with
extendable output length) based on :math:`H`, personalized by :math:`i`.

Given input :math:`M` of length :math:`\ell_M` bytes such that
:math:`22 \leq \ell_M \leq 16448`, define :math:`\mathsf{F4Jumble}(M)`
by:

* let :math:`\ell_L = \mathsf{min}(\ell_H, \mathsf{floor}(\ell_M/2))`
* let :math:`\ell_R = \ell_M - \ell_L`
* split :math:`M` into :math:`a` of length :math:`\ell_L` and :math:`b` of length :math:`\ell_R`
* let :math:`x = b \oplus G_0(a)`
* let :math:`y = a \oplus H_0(x)`
* let :math:`d = x \oplus G_1(y)`
* let :math:`c = y \oplus H_1(d)`
* return :math:`c \,||\, d`.
   
The first argument to BLAKE2b below is the personalization.

We instantiate :math:`H_i(u)` by
:math:`\mathsf{BLAKE2b‐}(8\ell_L)(“\mathtt{UA\_F4Jumble\_H\_}” \,||\,`
:math:`[i, 0], u)`.

We instantiate :math:`G_i(u)` as the first :math:`\ell_R` bytes of the
concatenation of
:math:`[\mathsf{BLAKE2b‐}512(“\mathtt{UA\_F4Jumble\_G\_}” \,||\,`
:math:`[i, j], u) \text{ for } j \text{ from } 0 \text{ up to}`
:math:`\mathsf{ceiling}(\ell_R/\ell_H)-1]`.

.. figure:: zip-0316-f4.png
    :align: center
    :figclass: align-center

    Diagram of 4-round unkeyed Feistel construction

(In practice the lengths :math:`\ell_L` and :math:`\ell_R` will be roughly
the same until :math:`\ell_M` is larger than :math:`128` bytes.)

Usage for Unified Addresses
'''''''''''''''''''''''''''

The producer of a unified address appends 16 zero bytes to the encoding of
the sequence of (Typecode, length, addr), then applies :math:`\mathsf{F4Jumble}`
before encoding the result with Bech32m.

The consumer rejects any Bech32m-decoded byte sequence that is less than
22 bytes or greater than 16448 bytes; otherwise it applies
:math:`\mathsf{F4Jumble}^{-1}`. It rejects any result that does not end
in 16 zero bytes, before stripping these 16 bytes and parsing the result.

(22 bytes is the minimum size of a valid encoded address sequence,
corresponding to just a transparent address, and 16448 bytes is the largest
input/output size supported by :math:`\mathsf{F4Jumble}`.)

Heuristic analysis
''''''''''''''''''

A 3-round unkeyed Feistel, as shown, is not sufficient:

.. figure:: zip-0316-f3.png
    :align: center
    :figclass: align-center

    Diagram of 3-round unkeyed Feistel construction

Suppose that an adversary has a target input/output pair
:math:`(a \,||\, b, c \,||\, d)`, and that the input to :math:`G_0` is
:math:`x`. By fixing :math:`x`, we can obtain another pair
:math:`((a \oplus t) \,||\, b', (c \oplus t) \,||\, d')` such that
:math:`a \oplus t` is close to :math:`a` and :math:`c \oplus t` is close
to :math:`c`.
(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d`,
but that isn't necessarily required for a valid attack.)

A 4-round Feistel thwarts this and similar attacks. Defining :math:`x` and
:math:`y` as the intermediate values in the first diagram above:

* if :math:`(x', y')` are fixed to the same values as :math:`(x, y)`, then
  :math:`(a', b', c', d') = (a, b, c, d)`;

* if :math:`x' = x` but :math:`y' \neq y`, then the adversary is able to
  introduce a controlled :math:`\oplus`-difference
  :math:`a \oplus a' = y \oplus y'`, but the other three pieces
  :math:`(b, c, d)` are all randomized, which is sufficient;

* if :math:`y' = y` but :math:`x' \neq x`, then the adversary is able to
  introduce a controlled :math:`\oplus`-difference
  :math:`d \oplus d' = x \oplus x'`, but the other three pieces
  :math:`(a, b, c)` are all randomized, which is sufficient;

* if :math:`x' \neq x` and :math:`y' \neq y`, all four pieces are
  randomized.

Note that the size of each piece is at least 11 bytes. TODO: analyze
whether this is sufficient when using 4 rounds.

It would be possible to make an attack more expensive by making the work
done by an address producer more expensive. (This wouldn't necessarily
have to increase the work done by the consumer.) However, given that
addresses may need to be produced on constrained computing platforms, this
was not considered to be beneficial overall.

Efficiency
''''''''''

The cost is dominated by 4 BLAKE2b compressions for :math:`\ell_M \leq 128`
bytes. A UA containing a transparent address, a Sapling address, and an
Orchard address, would have :math:`\ell_M = 112` bytes. The restriction
to a single address with a given Typecode (and at most one transparent
address) means that  this is also the maximum length as of NU5 activation.

For longer UAs (when other Typecodes are added), the cost increases to 6
BLAKE2b compressions for :math:`128 < \ell_M \leq 192`, and 10 BLAKE2b
compressions for :math:`192 < \ell_M \leq 256`, for example. The maximum
cost for which the algorithm is defined would be 768 BLAKE2b compressions
at :math:`\ell_M = 16448` bytes. We will almost certainly never add enough
Typecodes to reach that, and we might want to define a smaller limit.

The memory usage, for a memory-optimized implementation, is roughly
:math:`\ell_M` bytes plus the size of a BLAKE2b hash state.

Dependencies
''''''''''''

BLAKE2b, with personalization and variable output length, is the only
external dependency. TODO: would it be useful to remove the requirement
for variable output length?

Related work
''''''''''''

[Eliminating Random Permutation Oracles in the Even–Mansour Cipher](https://www.iacr.org/cryptodb/data/paper.php?pubkey=218)

* This paper argues that a 4-round unkeyed Feistel is sufficient to
  replace a random permutation in the Even–Mansour cipher construction.

[On the Round Security of Symmetric-Key Cryptographic Primitives](https://www.iacr.org/archive/crypto2000/18800377/18800377.pdf)

LIONESS: https://www.cl.cam.ac.uk/~rja14/Papers/bear-lion.pdf

* LIONESS is a similarly structured 4-round unbalanced Feistel cipher.

Open questions
--------------


Reference implementation
========================


Acknowledgements
================

The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre,
Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, and Teor for
discussions on the subject of Unified Addresses.


References
==========

.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.1.22 or later [NU5 proposal] <protocol/nu5.pdf>`_
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.22 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses <protocol/nu5.pdf#saplingpaymentaddrencoding>`_
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.22 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses <protocol/nu5.pdf#orchardpaymentaddrencoding>`_
.. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool <zip-0211.rst>`_
.. [#zip-0224] `ZIP 224: Orchard Shielded Protocol <zip-0224.rst>`_
.. [#zip-0321] `ZIP 321: Payment Request URIs <zip-0321.rst>`_
.. [#bip-0350] `BIP 350: Bech32m format for v1+ witness addresses <https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki>`_
.. [#P2PKH] `Transactions: P2PKH Script Validation — Bitcoin Developer Guide <https://developer.bitcoin.org/devguide/transactions.html#p2pkh-script-validation>`_
.. [#P2SH] `Transactions: P2SH Scripts — Bitcoin Developer Guide <https://developer.bitcoin.org/devguide/transactions.html#pay-to-script-hash-p2sh>`_