2021-04-07 02:12:11 -07:00
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
ZIP: 316
|
2021-06-05 08:52:41 -07:00
|
|
|
|
Title: Unified Addresses and Unified Viewing Keys
|
2021-04-07 02:12:11 -07:00
|
|
|
|
Owners: Daira Hopwood <daira@electriccoin.co>
|
2021-04-08 15:59:30 -07:00
|
|
|
|
Nathan Wilcox <nathan@electriccoin.co>
|
|
|
|
|
Taylor Hornby <taylor@electriccoin.co>
|
2021-04-07 02:12:11 -07:00
|
|
|
|
Jack Grigg <jack@electriccoin.co>
|
|
|
|
|
Sean Bowe <sean@electriccoin.co>
|
|
|
|
|
Kris Nuttycombe <kris@electriccoin.co>
|
|
|
|
|
Ying Tong Lai <yingtong@electriccoin.co>
|
2021-04-08 15:59:30 -07:00
|
|
|
|
Status: Proposed
|
2021-04-07 02:12:11 -07:00
|
|
|
|
Category: Standards / RPC / Wallet
|
2021-04-08 15:59:30 -07:00
|
|
|
|
Created: 2021-04-07
|
|
|
|
|
License: MIT
|
2021-04-07 02:12:11 -07:00
|
|
|
|
Discussions-To: <https://github.com/zcash/zips/issues/482>
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Producer
|
2021-08-26 11:51:18 -07:00
|
|
|
|
A wallet or other software that can create an Address (in which case it is
|
|
|
|
|
normally also a Recipient) or a Viewing Key.
|
2021-07-12 05:18:31 -07:00
|
|
|
|
Consumer
|
2021-08-26 11:51:18 -07:00
|
|
|
|
A wallet or other software that can make use of an Address or Viewing Key
|
|
|
|
|
that it is given.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
Sender
|
|
|
|
|
A wallet or other software that can send transfers of assets, or other
|
2021-07-12 05:18:31 -07:00
|
|
|
|
consensus state side-effects defined in future. Senders are a subset of
|
|
|
|
|
Consumers.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
Receiver
|
|
|
|
|
The necessary information to transfer an asset to a Recipient that generated
|
|
|
|
|
that Receiver using a specific Transfer Protocol. Each Receiver is associated
|
2021-04-20 16:11:55 -07:00
|
|
|
|
unambiguously with a specific Receiver Type, identified by an integer Typecode.
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Receiver Encoding
|
|
|
|
|
An encoding of a Receiver as a byte sequence.
|
2021-08-26 11:51:18 -07:00
|
|
|
|
Viewing Key
|
2021-09-17 05:30:54 -07:00
|
|
|
|
The necessary information to view information about payments to an Address,
|
|
|
|
|
or (in the case of a Full Viewing Key) from an Address. An Incoming Viewing
|
|
|
|
|
Key can be derived from a Full Viewing Key, and an Address can be derived
|
|
|
|
|
from an Incoming Viewing Key.
|
2021-08-26 11:51:18 -07:00
|
|
|
|
Viewing Key Encoding
|
|
|
|
|
An encoding of a Viewing Key as a byte sequence.
|
|
|
|
|
Legacy Address
|
2021-04-22 14:00:33 -07:00
|
|
|
|
A Transparent, Sprout, or Sapling Address.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
Unified Address (or UA)
|
|
|
|
|
A Unified Address combines multiple Receivers.
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Unified Full Viewing Key (or UFVK)
|
|
|
|
|
A Unified Full Viewing Key combines multiple Full Viewing Keys.
|
|
|
|
|
Unified Incoming Viewing Key (or UIVK)
|
|
|
|
|
A Unified Incoming Viewing Key combines multiple Incoming Viewing Keys.
|
2021-08-26 11:51:18 -07:00
|
|
|
|
Unified Viewing Key
|
|
|
|
|
Either a Unified Full Viewing Key or a Unified Incoming Viewing Key.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
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
|
|
|
|
|
========
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
This proposal defines Unified Addresses, which bundle together Zcash Addresses
|
2021-04-20 16:11:55 -07:00
|
|
|
|
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.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Motivation
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
Up to and including the Canopy network upgrade, Zcash supported the following
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Payment Address types:
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
* 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.)
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
The Orchard proposal [#zip-0224]_ adds a new Address type, Orchard Addresses.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
The difficulty with defining new Address Encodings for each Address type, is
|
2021-04-08 15:59:30 -07:00
|
|
|
|
that end-users are forced to be aware of the various types, and in particular
|
2021-07-12 05:18:31 -07:00
|
|
|
|
which types are supported by a given Consumer or Recipient. In order to make
|
2021-04-08 15:59:30 -07:00
|
|
|
|
sure that transfers are completed successfully, users may be forced to
|
2021-04-22 14:00:33 -07:00
|
|
|
|
explicitly generate Addresses of different types and re-distribute encodings
|
2021-04-08 15:59:30 -07:00
|
|
|
|
of them, which adds significant friction and cognitive overhead to
|
|
|
|
|
understanding and using Zcash.
|
|
|
|
|
|
|
|
|
|
The goals for a Unified Address standard are as follows:
|
|
|
|
|
|
2021-07-12 05:18:31 -07:00
|
|
|
|
- Simplify coordination between Recipients and Consumers by removing complexity
|
2021-04-22 14:00:33 -07:00
|
|
|
|
from negotiating Address types.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
- 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.
|
2021-04-20 16:11:55 -07:00
|
|
|
|
- Facilitate wallets to assume more sophisticated responsibilities for
|
|
|
|
|
shielding and/or migrating user funds.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
- Allow wallets to potentially develop new transfer mechanisms without
|
|
|
|
|
underlying protocol changes.
|
2021-04-22 14:00:33 -07:00
|
|
|
|
- Support abstractions corresponding to a Unified Address that provide the
|
|
|
|
|
functionality of Full Viewing Keys and Incoming Viewing Keys.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
- 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
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Address type.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
Concepts
|
|
|
|
|
--------
|
|
|
|
|
|
|
|
|
|
Wallets follow a model *Interaction Flow* as follows:
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
1. A Producer *generates* an Address.
|
|
|
|
|
2. The Producer *encodes* the Address.
|
|
|
|
|
3. The Producer wallet or human user *distributes* this Address Encoding,
|
2021-04-20 16:11:55 -07:00
|
|
|
|
This ZIP leaves distribution mechanisms out of scope.
|
2021-07-12 05:18:31 -07:00
|
|
|
|
4. A Consumer wallet or user *imports* the Address Encoding through any of
|
2021-04-08 15:59:30 -07:00
|
|
|
|
a variety of mechanisms (QR Code scanning, Payment URIs, cut-and-paste,
|
2021-04-20 16:11:55 -07:00
|
|
|
|
or “in-band” protocols like ``Reply-To`` memos).
|
2021-07-12 05:18:31 -07:00
|
|
|
|
5. A Consumer wallet *decodes* the Address Encoding and performs validity
|
2021-04-20 16:11:55 -07:00
|
|
|
|
checks.
|
2021-07-12 05:18:31 -07:00
|
|
|
|
6. (Perhaps later in time) if the Consumer wallet is a Sender, it can execute
|
|
|
|
|
a transfer of ZEC (or other assets or protocol state changes) to the
|
|
|
|
|
Address.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
Encodings of the same Address may be distributed zero or more times through
|
2021-07-12 05:18:31 -07:00
|
|
|
|
different means. Zero or more Consumers may import Addresses. Zero or more of
|
|
|
|
|
those (that are Senders) may execute a Transfer. A single Sender may execute
|
|
|
|
|
multiple Transfers over time from a single import.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Steps 1 to 5 inclusive also apply to Interaction Flows for Unified Full Viewing
|
|
|
|
|
Keys and Unified Incoming Viewing Keys.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
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
|
2021-04-22 14:00:33 -07:00
|
|
|
|
but *not* different Address types outside of the UA standard. There needs
|
2021-04-08 15:59:30 -07:00
|
|
|
|
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
|
|
|
|
|
---------
|
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
Every Wallet must properly *parse* a Unified Address containing unrecognized
|
2021-08-26 11:51:18 -07:00
|
|
|
|
Receiver Types; and similarly for Unified Viewing Keys containing unrecognized
|
|
|
|
|
Viewing Key Types.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-08-26 11:51:18 -07:00
|
|
|
|
A Wallet may process unrecognized Receiver Types or Viewing Key Types by
|
|
|
|
|
indicating to the user their presence or similar information for usability or
|
|
|
|
|
diagnostic purposes.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
There is a well-defined encoding of a Unified Address (or UFVK or UIVK)
|
|
|
|
|
as a QR Code, which produces QR codes that are reasonably compact and
|
|
|
|
|
robust.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
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
|
2021-04-20 16:11:55 -07:00
|
|
|
|
unrecognized Receiver Types well enough to ignore them.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
Transfers
|
|
|
|
|
---------
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
When executing a Transfer the Sender selects a Receiver via a Selection
|
|
|
|
|
process.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
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
|
2021-04-20 16:11:55 -07:00
|
|
|
|
shielded support without re-acquiring counterparty UAs. If they are
|
|
|
|
|
re-acquired, the user flow and usability will be minimally disrupted.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:51:04 -07:00
|
|
|
|
Experimental Usage
|
|
|
|
|
------------------
|
|
|
|
|
|
|
|
|
|
Unified Addresses and Unified Viewing Keys must be able to include
|
|
|
|
|
Receivers and Viewing Keys of experimental types, possibly alongside
|
|
|
|
|
non-experimental ones. These experimental Receivers or Viewing Keys
|
|
|
|
|
must be used only by wallets whose users have explicitly opted into
|
|
|
|
|
the corresponding experiment.
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Viewing Keys
|
|
|
|
|
------------
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
A Unified Full Viewing Key (resp. Unified Incoming Viewing Key) can be
|
|
|
|
|
used in a similar way to a Full Viewing Key (resp. Incoming Viewing Key)
|
|
|
|
|
as described in the Zcash Protocol Specification [#protocol-nu5]_.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:30:54 -07:00
|
|
|
|
For a Transparent P2PKH Address that is derived according to BIP 32
|
|
|
|
|
[#bip-0032]_ and BIP 44 [#bip-0044]_, the nearest equivalent to a
|
|
|
|
|
Full Viewing Key or Incoming Viewing Key for a given BIP 44 account
|
|
|
|
|
is an extended public key, as defined in the section “Extended keys”
|
|
|
|
|
of BIP 32. Therefore, UFVKs and UIVKs should be able to include such
|
|
|
|
|
extended public keys.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:30:54 -07:00
|
|
|
|
A wallet should support deriving a UIVK from a UFVK, and a Unified
|
|
|
|
|
Address from a UIVK.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Open Issues and Known Concerns
|
|
|
|
|
------------------------------
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:38:32 -07:00
|
|
|
|
Privacy impacts of transparent or cross-pool transactions, and the
|
|
|
|
|
associated UX issues, will be addressed in ZIP 315 (in preparation).
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Specification
|
|
|
|
|
=============
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Encoding of Unified Addresses
|
|
|
|
|
-----------------------------
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Rather than defining a Bech32 string encoding of Orchard Shielded
|
|
|
|
|
Payment Addresses, we instead define a Unified Address format that
|
2021-04-20 16:11:55 -07:00
|
|
|
|
is able to encode a set of Receivers of different types. This enables
|
2021-07-12 05:18:31 -07:00
|
|
|
|
the Consumer of a Unified Address to choose the Receiver of the best
|
|
|
|
|
type it supports, providing a better user experience as new Receiver
|
|
|
|
|
Types are added in the future.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Assume that we are given a set of one or more Receiver Encodings
|
|
|
|
|
for distinct types. That is, the set may optionally contain one
|
|
|
|
|
Receiver of each of the Receiver Types in the following fixed
|
|
|
|
|
Priority List:
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
* Typecode :math:`\mathtt{0x03}` — an Orchard raw address as defined
|
2021-04-08 15:59:30 -07:00
|
|
|
|
in [#protocol-orchardpaymentaddrencoding]_;
|
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
* Typecode :math:`\mathtt{0x02}` — a Sapling raw address as defined
|
2021-04-08 15:59:30 -07:00
|
|
|
|
in [#protocol-saplingpaymentaddrencoding]_;
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
* Typecode :math:`\mathtt{0x01}` — a Transparent P2SH address, *or*
|
|
|
|
|
Typecode :math:`\mathtt{0x00}` — a Transparent P2PKH address.
|
2021-04-20 16:11:55 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
We say that a Receiver Type is “preferred” over another when it appears
|
2021-04-20 16:11:55 -07:00
|
|
|
|
earlier in this Priority List.
|
|
|
|
|
|
|
|
|
|
The Sender of a payment to a Unified Address MUST use the Receiver
|
2021-04-22 14:00:33 -07:00
|
|
|
|
of the most preferred Receiver Type that it supports from the set.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
For example, consider a wallet that supports sending funds to Orchard
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Receivers, and does not support sending to any Receiver Type that is
|
|
|
|
|
preferred over Orchard. If that wallet is given a UA that includes an
|
|
|
|
|
Orchard Receiver and possibly other Receivers, it MUST send to the
|
|
|
|
|
Orchard Receiver.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
The raw encoding of a Unified Address is a concatenation of
|
2021-04-08 15:59:30 -07:00
|
|
|
|
:math:`(\mathtt{typecode}, \mathtt{length}, \mathtt{addr})` encodings
|
2021-04-20 16:11:55 -07:00
|
|
|
|
of the consituent Receivers:
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:51:04 -07:00
|
|
|
|
* :math:`\mathtt{typecode} : \mathtt{compactSize}` — the Typecode from the
|
2021-04-22 14:00:33 -07:00
|
|
|
|
above Priority List;
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:51:04 -07:00
|
|
|
|
* :math:`\mathtt{length} : \mathtt{compactSize}` — the length in bytes of
|
2021-09-17 05:52:55 -07:00
|
|
|
|
:math:`\mathtt{addr};`
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
* :math:`\mathtt{addr} : \mathtt{byte[length]}` — the Receiver Encoding.
|
|
|
|
|
|
2021-09-17 05:39:28 -07:00
|
|
|
|
The values of the :math:`\mathtt{typecode}` and :math:`\mathtt{length}`
|
|
|
|
|
fields MUST be less than or equal to :math:`\mathtt{0x2000000}.`
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
A Receiver Encoding is the raw encoding of a Shielded Payment Address,
|
2021-09-17 05:52:55 -07:00
|
|
|
|
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]_.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-07-13 15:51:02 -07:00
|
|
|
|
Let ``padding`` be the Human-Readable Part of the Unified Address in
|
|
|
|
|
US-ASCII, padded to 16 bytes with zero bytes. We append ``padding`` to
|
|
|
|
|
the concatenated encodings, and then apply the :math:`\mathsf{F4Jumble}`
|
2021-09-17 05:30:54 -07:00
|
|
|
|
algorithm as described in `Jumbling`_. The output is then encoded with
|
|
|
|
|
Bech32m [#bip-0350]_, ignoring any length restrictions. This is chosen
|
2021-07-13 15:51:02 -07:00
|
|
|
|
over Bech32 in order to better handle variable-length inputs.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-07-12 05:18:31 -07:00
|
|
|
|
To decode a Unified Address Encoding, a Consumer MUST use the following
|
2021-04-22 14:00:33 -07:00
|
|
|
|
procedure:
|
|
|
|
|
|
|
|
|
|
* Decode using Bech32m, rejecting any address with an incorrect checksum.
|
|
|
|
|
* Apply :math:`\mathsf{F4Jumble}^{-1}` (this can also reject if the input
|
|
|
|
|
is not in the correct range of lengths).
|
2021-07-13 15:51:02 -07:00
|
|
|
|
* Let ``padding`` be the Human-Readable Part, padded to 16 bytes as for
|
|
|
|
|
encoding. If the result ends in ``padding``, remove these 16 bytes;
|
|
|
|
|
otherwise reject.
|
2021-04-22 14:10:41 -07:00
|
|
|
|
* Parse the result as a raw encoding as described above, rejecting the
|
|
|
|
|
entire Unified Address if it does not parse correctly.
|
2021-04-22 14:00:33 -07:00
|
|
|
|
|
|
|
|
|
For Unified Addresses on Mainnet, the Human-Readable Part (as defined
|
|
|
|
|
in [#bip-0350]_) is “``u``”. For Unified Addresses on Testnet, the
|
|
|
|
|
Human-Readable Part is “``utest``”.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-07-12 05:18:31 -07:00
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Encoding of Unified Full/Incoming Viewing Keys
|
|
|
|
|
----------------------------------------------
|
|
|
|
|
|
|
|
|
|
Unified Full or Incoming Viewing Keys are encoded and decoded
|
|
|
|
|
analogously to Unified Addresses. A Consumer MUST use the decoding
|
2021-09-17 05:30:54 -07:00
|
|
|
|
procedure from the previous section. For Viewing Keys, a Consumer
|
|
|
|
|
will normally take the union of information provided by all contained
|
|
|
|
|
Receivers, and therefore the Priority List defined in the previous
|
|
|
|
|
section is not used.
|
|
|
|
|
|
|
|
|
|
For each UFVK Type or UIVK Type currently defined in this specification,
|
|
|
|
|
the same Typecode is used as for the corresponding Receiver Type in a
|
|
|
|
|
Unified Address. Additional UFVK Types and UIVK Types MAY be defined in
|
|
|
|
|
future, and these will not necessarily use the same Typecode as the
|
|
|
|
|
corresponding Unified Address.
|
|
|
|
|
|
|
|
|
|
The following UFVK or UIVK Encodings are used in place of the
|
|
|
|
|
:math:`\mathtt{addr}` field:
|
|
|
|
|
|
|
|
|
|
* An Orchard UFVK or UIVK Encoding, with Typecode :math:`\mathtt{0x03},`
|
|
|
|
|
is the raw encoding of the Full Viewing Key or Incoming Viewing Key
|
|
|
|
|
respectively.
|
|
|
|
|
|
|
|
|
|
* A Sapling UFVK Encoding, with Typecode :math:`\mathtt{0x02},` is
|
|
|
|
|
the encoding of a Sapling Extended Full Viewing Key defined in
|
|
|
|
|
[#zip-0032-sapling-extfvk]_.
|
|
|
|
|
|
|
|
|
|
* A Sapling UIVK Encoding, also with Typecode :math:`\mathtt{0x02},`
|
|
|
|
|
is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by
|
|
|
|
|
:math:`\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).`
|
|
|
|
|
|
|
|
|
|
* There is no defined way to represent a viewing key for a Transparent
|
|
|
|
|
P2SH Address in a UFVK or UIVK. The Typecode :math:`\mathtt{0x01}`
|
|
|
|
|
MUST not be included in a UFVK or UIVK by Producers, and MUST be
|
|
|
|
|
treated as unrecognized by Consumers.
|
|
|
|
|
|
|
|
|
|
* For Transparent P2PKH Addresses that are derived according to BIP 32
|
|
|
|
|
[#bip-0032]_ and BIP 44 [#bip-0044]_, the UFVK and UIVK Encodings
|
|
|
|
|
have Typecode :math:`\mathtt{0x00}.` These encodings are identical
|
|
|
|
|
and are the serialization of an extended public key, defined in the
|
|
|
|
|
section “Serialization format” of BIP 32 [#bip-0032-serialization-format]_.
|
|
|
|
|
|
|
|
|
|
The Human-Readable Parts (as defined in [#bip-0350]_) of Unified Viewing
|
2021-07-13 15:40:23 -07:00
|
|
|
|
Keys are defined as follows:
|
|
|
|
|
|
|
|
|
|
* “``uivk``” for Unified Incoming Viewing Keys on Mainnet;
|
|
|
|
|
* “``uivktest``” for Unified Incoming Viewing Keys on Testnet;
|
|
|
|
|
* “``uview``” for Unified Full Viewing Keys on Mainnet;
|
|
|
|
|
* “``uviewtest``” for Unified Full Viewing Keys on Testnet.
|
|
|
|
|
|
2021-07-12 05:18:31 -07:00
|
|
|
|
|
|
|
|
|
Requirements for both Unified Addresses and Unified Viewing Keys
|
|
|
|
|
----------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
* A Unified Address or Unified Viewing Key MUST NOT contain only
|
|
|
|
|
transparent P2SH or P2PKH addresses (Typecodes :math:`\mathtt{0x00}`
|
|
|
|
|
and :math:`\mathtt{0x01}`). The rationale is that the existing
|
|
|
|
|
P2SH and P2PKH transparent-only address formats suffice for this
|
|
|
|
|
purpose and are already supported by the existing ecosystem.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:39:28 -07:00
|
|
|
|
* The :math:`\mathtt{typecode}` and :math:`\mathtt{length}` fields are
|
|
|
|
|
encoded as :math:`\mathtt{compactSize}.` [#Bitcoin-CompactSize]_
|
|
|
|
|
(Although existing Receiver Encodings and Viewing Key Encodings are
|
|
|
|
|
all less than 256 bytes and so could use a one-byte length field,
|
|
|
|
|
encodings for experimental types may be longer.)
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:30:54 -07:00
|
|
|
|
* Each Receiver, UFVK, or UIVK SHOULD represent an Address or
|
|
|
|
|
Viewing Key at the ZIP 32 or BIP 44 Account level.
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
* For Transparent Addresses, the Receiver Encoding does not include
|
|
|
|
|
the first two bytes of a raw encoding.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
* There is intentionally no Typecode defined for a Sprout Shielded
|
2021-07-12 05:18:31 -07:00
|
|
|
|
Payment Address or Sprout Incoming Viewing Key. 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.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-07-12 08:04:10 -07:00
|
|
|
|
* Consumers MUST ignore constituent Addresses/Viewing Keys with
|
2021-07-12 05:18:31 -07:00
|
|
|
|
Typecodes they do not recognize.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-07-12 08:04:10 -07:00
|
|
|
|
* Consumers MUST reject Unified Addresses/Viewing Keys in which the
|
2021-07-12 05:18:31 -07:00
|
|
|
|
same Typecode appears more than once, or that include both P2SH and
|
|
|
|
|
P2PKH Transparent Addresses, or that contain only a Transparent
|
|
|
|
|
Address.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-07-12 08:04:10 -07:00
|
|
|
|
* Consumers MUST reject Unified Addresses/Viewing Keys in which *any*
|
2021-07-12 05:18:31 -07:00
|
|
|
|
constituent address does not meet the validation requirements of its
|
2021-04-22 14:10:41 -07:00
|
|
|
|
Receiver Encoding, as specified in the Zcash Protocol Specification
|
|
|
|
|
[#protocol-nu5]_.
|
|
|
|
|
|
2021-07-12 05:18:31 -07:00
|
|
|
|
* Producers SHOULD order the constituent Addresses/Viewing Keys in
|
|
|
|
|
the same order as in the Priority List above. However, Consumers
|
|
|
|
|
MUST NOT assume this ordering, and it does not affect which Address
|
|
|
|
|
should be used by a Sender.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
* There MUST NOT be additional bytes at the end of the raw encoding
|
|
|
|
|
that cannot be interpreted as specified above.
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
|
2021-09-17 05:51:04 -07:00
|
|
|
|
Adding new types
|
|
|
|
|
----------------
|
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
It is intended that new Receiver Types and Viewing Key Types SHOULD
|
|
|
|
|
be introduced either by a modification to this ZIP or by a new ZIP,
|
|
|
|
|
in accordance with the ZIP Process [#zip-0000]_.
|
2021-09-17 05:51:04 -07:00
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
Experimental types MAY be added using the reserved Typecodes
|
|
|
|
|
:math:`\mathtt{0xFFFA}` to :math:`\mathtt{0xFFFF}` inclusive. This
|
|
|
|
|
provides for six simultaneous experiments, which can be referred to
|
|
|
|
|
as experiments A to F. This should be sufficient because experiments
|
|
|
|
|
are expected to be reasonably short-term, and should otherwise be
|
|
|
|
|
either standardized in a ZIP (and allocated a Typecode outside this
|
2021-09-17 05:51:04 -07:00
|
|
|
|
reserved range) or discontinued.
|
|
|
|
|
|
|
|
|
|
|
2021-09-17 05:30:54 -07:00
|
|
|
|
Deriving a UIVK from a UFVK
|
|
|
|
|
---------------------------
|
|
|
|
|
|
|
|
|
|
Each UIVK Encoding can straightforwardly be derived from the
|
|
|
|
|
corresponding UFVK Encoding, without changing the Typecode. In the
|
|
|
|
|
case of a Transparent P2PKH UFVK Encoding, the UIVK Encoding is the
|
|
|
|
|
same.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deriving a Unified Address from a UIVK
|
|
|
|
|
--------------------------------------
|
|
|
|
|
|
|
|
|
|
To derive a Unified Address from a UIVK we need to choose a diversifier
|
|
|
|
|
index, which MUST be valid for all of the Viewing Key Types in the
|
|
|
|
|
UIVK. That is,
|
|
|
|
|
|
|
|
|
|
* A Sapling diversifier index MUST generate a valid diversifier as
|
|
|
|
|
defined in ZIP 32 section “Sapling diversifier derivation”
|
|
|
|
|
[#zip-0032-sapling-diversifier-derivation]_.
|
|
|
|
|
* A Transparent diversifier index MUST be in the range :math:`0` to
|
|
|
|
|
:math:`2^{31}` inclusive.
|
|
|
|
|
|
|
|
|
|
There are no additional constraints on an Orchard diversifier index.
|
|
|
|
|
|
|
|
|
|
In the case of deriving a Transparent P2PKH Receiver from a Transparent
|
|
|
|
|
P2PKH UIVK, the diversifier index is used as a BIP 44 child key index
|
|
|
|
|
at the Index level to derive the address. As is usual for derivations
|
|
|
|
|
below the BIP 44 Account level, non-hardened (public) derivation
|
|
|
|
|
[#bip-0032-public-to-public]_ MUST be used, with the Change element
|
|
|
|
|
of the path being 0, and the Index element of the path being the
|
|
|
|
|
diversifier index [#bip-0044-path-index]_. That is, the BIP 44 path of
|
|
|
|
|
the Transparent P2PKH Receiver MUST be:
|
|
|
|
|
|
|
|
|
|
* :math:`m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jumbling
|
|
|
|
|
---------
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
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
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Addresses on some subset of characters (for concreteness, consider
|
2021-04-08 15:59:30 -07:00
|
|
|
|
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
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Addresses).
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
Security goal (**nonmalleability**):
|
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
* In this variant, part b) above is replaced by the meaning of the new
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Address being “usefully” different than the Address it is based on, even
|
2021-04-20 16:11:55 -07:00
|
|
|
|
though the adversary does not know any of the private keys. For example,
|
2021-04-22 14:00:33 -07:00
|
|
|
|
if it were possible to delete a shielded constituent Address from a UA
|
|
|
|
|
leaving only a Transparent Address, that would be a significant malleability
|
2021-04-20 16:11:55 -07:00
|
|
|
|
attack.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
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
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Addresses. It may be possible to improve on this attack by making use of
|
2021-04-08 15:59:30 -07:00
|
|
|
|
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
|
2021-09-17 05:52:55 -07:00
|
|
|
|
set is :math:`c,` then the generic attack costs :math:`\sim \frac{w \cdot
|
|
|
|
|
c^{n+m}}{q}.`
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
There is also a generic brute force attack against nonmalleability. The
|
2021-04-22 14:00:33 -07:00
|
|
|
|
adversary modifies the target Address slightly and computes the corresponding
|
2021-04-20 16:11:55 -07:00
|
|
|
|
decoding, then repeats until the decoding is valid and also useful to the
|
2021-04-22 14:00:33 -07:00
|
|
|
|
adversary (e.g. it would lead to the Sender using a Transparent Address).
|
2021-04-20 16:11:55 -07:00
|
|
|
|
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.
|
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
Solution
|
|
|
|
|
''''''''
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
We use an unkeyed 4-round Feistel construction to approximate a random
|
|
|
|
|
permutation. (As explained below, 3 rounds would not be sufficient.)
|
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
Let :math:`H_i` be a hash personalized by :math:`i,` with maximum output
|
2021-04-08 15:59:30 -07:00
|
|
|
|
length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with
|
2021-09-17 05:52:55 -07:00
|
|
|
|
extendable output length) based on :math:`H,` personalized by :math:`i.`
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
Given input :math:`M` of length :math:`\ell_M` bytes such that
|
2021-09-17 05:51:04 -07:00
|
|
|
|
:math:`48 \leq \ell_M \leq 4194368,` define :math:`\mathsf{F4Jumble}(M)`
|
2021-04-08 15:59:30 -07:00
|
|
|
|
by:
|
|
|
|
|
|
|
|
|
|
* let :math:`\ell_L = \mathsf{min}(\ell_H, \mathsf{floor}(\ell_M/2))`
|
|
|
|
|
* let :math:`\ell_R = \ell_M - \ell_L`
|
2021-05-12 11:15:20 -07:00
|
|
|
|
* split :math:`M` into :math:`a` of length :math:`\ell_L` bytes and :math:`b` of length :math:`\ell_R` bytes
|
2021-04-08 15:59:30 -07:00
|
|
|
|
* 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)`
|
2021-09-17 05:52:55 -07:00
|
|
|
|
* return :math:`c \,||\, d.`
|
2021-05-12 02:29:11 -07:00
|
|
|
|
|
|
|
|
|
The inverse function :math:`\mathsf{F4Jumble}^{-1}` is obtained in the usual
|
2021-09-17 05:52:55 -07:00
|
|
|
|
way for a Feistel construction, by observing that :math:`r = p \oplus q` implies :math:`p = r \oplus q.`
|
2021-05-12 02:29:11 -07:00
|
|
|
|
|
2021-04-08 15:59:30 -07:00
|
|
|
|
The first argument to BLAKE2b below is the personalization.
|
|
|
|
|
|
|
|
|
|
We instantiate :math:`H_i(u)` by
|
2021-09-17 05:51:04 -07:00
|
|
|
|
:math:`\mathsf{BLAKE2b‐}(8\ell_L)(\texttt{“UA_F4Jumble_H”} \,||\,`
|
|
|
|
|
:math:`[i, 0, 0], u).`
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
We instantiate :math:`G_i(u)` as the first :math:`\ell_R` bytes of the
|
|
|
|
|
concatenation of
|
2021-09-17 05:51:04 -07:00
|
|
|
|
:math:`[\mathsf{BLAKE2b‐}512(\texttt{“UA_F4Jumble_G”} \,||\, [i] \,||\,`
|
|
|
|
|
:math:`\mathsf{I2LEOSP}_{16}(j), u) \text{ for } j \text{ from}`
|
|
|
|
|
:math:`0 \text{ up to } \mathsf{ceiling}(\ell_R/\ell_H)-1].`
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
.. figure:: zip-0316-f4.png
|
2021-05-12 07:26:08 -07:00
|
|
|
|
:width: 372px
|
2021-04-08 15:59:30 -07:00
|
|
|
|
: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.)
|
|
|
|
|
|
2021-04-22 14:23:41 -07:00
|
|
|
|
Usage for Unified Addresses, UFVKs, and UIVKs
|
|
|
|
|
'''''''''''''''''''''''''''''''''''''''''''''
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 14:00:33 -07:00
|
|
|
|
In order to prevent the generic attack against nonmalleability, there
|
|
|
|
|
needs to be some redundancy in the encoding. Therefore, the Producer of
|
2021-07-13 15:51:02 -07:00
|
|
|
|
a Unified Address, UFVK, or UIVK appends the HRP, padded to 16 bytes with
|
|
|
|
|
zero bytes, to the raw encoding, then applies :math:`\mathsf{F4Jumble}`
|
|
|
|
|
before encoding the result with Bech32m.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-07-12 08:04:10 -07:00
|
|
|
|
The Consumer rejects any Bech32m-decoded byte sequence that is less than
|
2021-09-17 05:51:04 -07:00
|
|
|
|
48 bytes or greater than 4194368 bytes; otherwise it applies
|
|
|
|
|
:math:`\mathsf{F4Jumble}^{-1}.` It rejects any result that does not end
|
2021-07-13 15:51:02 -07:00
|
|
|
|
in the expected padding, before stripping these 16 bytes and parsing the
|
|
|
|
|
result.
|
2021-04-20 16:11:55 -07:00
|
|
|
|
|
2021-04-22 14:23:41 -07:00
|
|
|
|
(48 bytes is the minimum size of a valid UA, UFVK, or UIVK raw encoding
|
|
|
|
|
plus 16 zero bytes, corresponding to a single Sapling Incoming Viewing Key.
|
2021-09-17 05:51:04 -07:00
|
|
|
|
4194368 bytes is the largest input/output size supported by :math:`\mathsf{F4Jumble}.`)
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
Heuristic analysis
|
|
|
|
|
''''''''''''''''''
|
|
|
|
|
|
|
|
|
|
A 3-round unkeyed Feistel, as shown, is not sufficient:
|
|
|
|
|
|
|
|
|
|
.. figure:: zip-0316-f3.png
|
2021-05-12 07:26:08 -07:00
|
|
|
|
:width: 372px
|
2021-04-08 15:59:30 -07:00
|
|
|
|
:align: center
|
|
|
|
|
:figclass: align-center
|
|
|
|
|
|
|
|
|
|
Diagram of 3-round unkeyed Feistel construction
|
|
|
|
|
|
|
|
|
|
Suppose that an adversary has a target input/output pair
|
2021-09-17 05:52:55 -07:00
|
|
|
|
:math:`(a \,||\, b, c \,||\, d),` and that the input to :math:`H_0` is
|
|
|
|
|
:math:`x.` By fixing :math:`x,` we can obtain another pair
|
2021-04-08 15:59:30 -07:00
|
|
|
|
: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
|
2021-09-17 05:52:55 -07:00
|
|
|
|
to :math:`c.`
|
|
|
|
|
(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d,`
|
2021-04-08 15:59:30 -07:00
|
|
|
|
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:
|
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
* if :math:`(x', y')` are fixed to the same values as :math:`(x, y),` then
|
|
|
|
|
:math:`(a', b', c', d') = (a, b, c, d);`
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
* 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
|
2021-04-08 15:59:30 -07:00
|
|
|
|
:math:`(b, c, d)` are all randomized, which is sufficient;
|
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
* 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
|
2021-04-08 15:59:30 -07:00
|
|
|
|
:math:`(a, b, c)` are all randomized, which is sufficient;
|
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
* if :math:`x' \neq x` and :math:`y' \neq y,` all four pieces are
|
2021-04-08 15:59:30 -07:00
|
|
|
|
randomized.
|
|
|
|
|
|
2021-04-22 15:18:34 -07:00
|
|
|
|
Note that the size of each piece is at least 24 bytes.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
It would be possible to make an attack more expensive by making the work
|
2021-04-22 14:00:33 -07:00
|
|
|
|
done by a Producer more expensive. (This wouldn't necessarily have to
|
2021-07-12 08:04:10 -07:00
|
|
|
|
increase the work done by the Consumer.) However, given that Unified Addresses
|
2021-04-22 14:00:33 -07:00
|
|
|
|
may need to be produced on constrained computing platforms, this was not
|
|
|
|
|
considered to be beneficial overall.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-07-13 15:51:02 -07:00
|
|
|
|
The padding contains the HRP so that the HRP has the same protection against
|
|
|
|
|
malleation as the rest of the address. This may help against cross-network
|
|
|
|
|
attacks, or attacks that confuse addresses with viewing keys.
|
|
|
|
|
|
2021-04-08 15:59:30 -07:00
|
|
|
|
Efficiency
|
|
|
|
|
''''''''''
|
|
|
|
|
|
|
|
|
|
The cost is dominated by 4 BLAKE2b compressions for :math:`\ell_M \leq 128`
|
2021-04-22 14:00:33 -07:00
|
|
|
|
bytes. A UA containing a Transparent Address, a Sapling Address, and an
|
2021-04-22 15:18:34 -07:00
|
|
|
|
Orchard Address, would have :math:`\ell_M = 128` bytes. The restriction
|
2021-04-22 14:00:33 -07:00
|
|
|
|
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.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-20 16:11:55 -07:00
|
|
|
|
For longer UAs (when other Typecodes are added), the cost increases to 6
|
2021-09-17 05:51:04 -07:00
|
|
|
|
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 196608 BLAKE2b compressions
|
|
|
|
|
at :math:`\ell_M = 4194368` bytes.
|
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
A naïve implementation of the :math:`\mathsf{F4Jumble}^{-1}` function would
|
|
|
|
|
require roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state.
|
|
|
|
|
However, it is possible to reduce this by streaming the :math:`d` part of
|
|
|
|
|
the jumbled encoding three times from a less memory-constrained device. It
|
|
|
|
|
is essential that the streamed value of :math:`d` is the same on each pass,
|
|
|
|
|
which can be verified using a MAC (with key held only by the Consumer) or
|
2021-09-17 05:44:03 -07:00
|
|
|
|
collision-resistant hash function. After the first pass of :math:`d`, the
|
2021-09-17 05:52:55 -07:00
|
|
|
|
implementation is able to compute :math:`y;` after the second pass it is
|
|
|
|
|
able to compute :math:`a;` and the third allows it to compute and
|
2021-09-17 05:44:03 -07:00
|
|
|
|
incrementally parse :math:`b.` The maximum memory usage during this process
|
2021-09-17 05:40:59 -07:00
|
|
|
|
would be 128 bytes plus two BLAKE2b hash states.
|
2021-09-17 05:51:04 -07:00
|
|
|
|
|
2021-09-17 05:52:55 -07:00
|
|
|
|
Since this streaming implementation of :math:`\mathsf{F4Jumble}^{-1}` is
|
|
|
|
|
quite complicated, we do not require all Consumers to support it. If a
|
|
|
|
|
Consumer implementation cannot support UAs / UVKs up to the maximum length,
|
|
|
|
|
it MUST nevertheless support UAs / UVKs with :math:`\ell_M` of at least
|
|
|
|
|
:math:`256` bytes.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dependencies
|
|
|
|
|
''''''''''''
|
|
|
|
|
|
|
|
|
|
BLAKE2b, with personalization and variable output length, is the only
|
2021-05-12 07:34:52 -07:00
|
|
|
|
external dependency.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
Related work
|
|
|
|
|
''''''''''''
|
|
|
|
|
|
2021-04-22 15:23:27 -07:00
|
|
|
|
`Eliminating Random Permutation Oracles in the Even–Mansour Cipher <https://www.iacr.org/cryptodb/data/paper.php?pubkey=218>`_
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
* This paper argues that a 4-round unkeyed Feistel is sufficient to
|
|
|
|
|
replace a random permutation in the Even–Mansour cipher construction.
|
|
|
|
|
|
2021-04-22 15:23:27 -07:00
|
|
|
|
`On the Round Security of Symmetric-Key Cryptographic Primitives <https://www.iacr.org/archive/crypto2000/18800377/18800377.pdf>`_
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
2021-04-22 15:23:27 -07:00
|
|
|
|
`LIONESS <https://www.cl.cam.ac.uk/~rja14/Papers/bear-lion.pdf>`_ is a similarly structured 4-round unbalanced Feistel cipher.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reference implementation
|
|
|
|
|
========================
|
|
|
|
|
|
2021-07-12 04:20:09 -07:00
|
|
|
|
* https://github.com/zcash/librustzcash/pull/352
|
|
|
|
|
* https://github.com/zcash/librustzcash/pull/416
|
2021-04-22 14:00:33 -07:00
|
|
|
|
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
Acknowledgements
|
|
|
|
|
================
|
|
|
|
|
|
|
|
|
|
The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre,
|
2021-09-17 05:51:04 -07:00
|
|
|
|
Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, Teor, and
|
|
|
|
|
Eran Tromer for discussions on the subject of Unified Addresses.
|
2021-04-08 15:59:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
References
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
2021-09-17 05:51:04 -07:00
|
|
|
|
.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.2.14 or later [NU5 proposal] <protocol/protocol.pdf>`_
|
|
|
|
|
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_
|
|
|
|
|
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses <protocol/protocol.pdf#orchardpaymentaddrencoding>`_
|
|
|
|
|
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
|
2021-09-17 05:30:54 -07:00
|
|
|
|
.. [#zip-0032-sapling-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys <zip-0032#sapling-extended-full-viewing-keys>`_
|
|
|
|
|
.. [#zip-0032-sapling-diversifier-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation <zip-0032#sapling-diversifier-derivation>`_
|
2021-04-08 15:59:30 -07:00
|
|
|
|
.. [#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>`_
|
2021-09-17 05:30:54 -07:00
|
|
|
|
.. [#bip-0032] `BIP 32: Hierarchical Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>`_
|
|
|
|
|
.. [#bip-0032-serialization-format] `BIP 32: Hierarchical Deterministic Wallets — Serialization Format <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format>`_
|
|
|
|
|
.. [#bip-0032-public-to-public] `BIP 32: Hierarchical Deterministic Wallets — Child key derivation (CKD) functions: Public parent key → public child key <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#public-parent-key--public-child-key>`_
|
|
|
|
|
.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>`_
|
|
|
|
|
.. [#bip-0044-path-index] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Index <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#index>`_
|
2021-04-08 15:59:30 -07:00
|
|
|
|
.. [#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>`_
|
2021-09-17 05:51:04 -07:00
|
|
|
|
.. [#Bitcoin-CompactSize] `Variable length integer. Bitcoin Wiki <https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer>`_
|