mirror of https://github.com/zcash/zips.git
Add support for UFVKs and UIVKs.
Append 16 zero bytes on encoding and check them on decoding, to prevent malleability attacks. Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
f4a3b99589
commit
fbdbead6d5
155
zip-0316.html
155
zip-0316.html
|
@ -27,14 +27,22 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<dl>
|
||||
<dt>Recipient</dt>
|
||||
<dd>A wallet or other software that can receive transfers of assets (such as ZEC) or in the future potentially other transaction-based state changes.</dd>
|
||||
<dt>Producer</dt>
|
||||
<dd>A wallet or other software that can create an Address (normally also a Recipient).</dd>
|
||||
<dt>Sender</dt>
|
||||
<dd>A wallet or other software that can send transfers of assets, or other future consensus state side-effects.</dd>
|
||||
<dd>A wallet or other software that can send transfers of assets, or other consensus state side-effects defined in future.</dd>
|
||||
<dt>Receiver</dt>
|
||||
<dd>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.</dd>
|
||||
<dt>Receiver Encoding</dt>
|
||||
<dd>An encoding of a Receiver as a byte sequence.</dd>
|
||||
<dt>Legacy Address (or LA)</dt>
|
||||
<dd>A transparent, Sprout, or Sapling Address.</dd>
|
||||
<dd>A Transparent, Sprout, or Sapling Address.</dd>
|
||||
<dt>Unified Address (or UA)</dt>
|
||||
<dd>A Unified Address combines multiple Receivers.</dd>
|
||||
<dt>Unified Full Viewing Key (or UFVK)</dt>
|
||||
<dd>A Unified Full Viewing Key combines multiple Full Viewing Keys.</dd>
|
||||
<dt>Unified Incoming Viewing Key (or UIVK)</dt>
|
||||
<dd>A Unified Incoming Viewing Key combines multiple Incoming Viewing Keys.</dd>
|
||||
<dt>Address</dt>
|
||||
<dd>Either a Legacy Address or a Unified Address.</dd>
|
||||
<dt>Transfer Protocol</dt>
|
||||
|
@ -44,26 +52,27 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Up to and including the Canopy network upgrade, Zcash supported the following payment address types:</p>
|
||||
<p>Up to and including the Canopy network upgrade, Zcash supported the following Payment Address types:</p>
|
||||
<ul>
|
||||
<li>Transparent Addresses (P2PKH and P2SH)</li>
|
||||
<li>Sprout Addresses</li>
|
||||
<li>Sapling Addresses</li>
|
||||
</ul>
|
||||
<p>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.)</p>
|
||||
<p>The Orchard proposal <a id="id2" class="footnote_reference" href="#zip-0224">6</a> adds a new address type, Orchard Addresses.</p>
|
||||
<p>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.</p>
|
||||
<p>The Orchard proposal <a id="id2" class="footnote_reference" href="#zip-0224">6</a> adds a new Address type, Orchard Addresses.</p>
|
||||
<p>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.</p>
|
||||
<p>The goals for a Unified Address standard are as follows:</p>
|
||||
<ul>
|
||||
<li>Simplify coordination between Recipients and Senders by removing complexity from negotiating address types.</li>
|
||||
<li>Simplify coordination between Recipients and Senders by removing complexity from negotiating Address types.</li>
|
||||
<li>Provide a “bridging mechanism” to allow shielded wallets to successfully interact with conformant Transparent-Only wallets.</li>
|
||||
<li>Allow older conformant wallets to interact seamlessly with newer wallets.</li>
|
||||
<li>Enable users of newer wallets to upgrade to newer transaction technologies and/or pools while maintaining seamless interactions with counterparties using older wallets.</li>
|
||||
<li>Facilitate wallets to assume more sophisticated responsibilities for shielding and/or migrating user funds.</li>
|
||||
<li>Allow wallets to potentially develop new transfer mechanisms without underlying protocol changes.</li>
|
||||
<li>Support abstractions corresponding to a Unified Address that provide the functionality of Full Viewing Keys and Incoming Viewing Keys.</li>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
|
@ -72,40 +81,40 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<section id="overview"><h3><span class="section-heading">Overview</span><span class="section-anchor"> <a rel="bookmark" href="#overview"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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.</p>
|
||||
<p>Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="id3" class="footnote_reference" href="#zip-0321">7</a> and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new address type.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="id3" class="footnote_reference" href="#zip-0321">7</a> and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type.</p>
|
||||
</section>
|
||||
<section id="concepts"><h3><span class="section-heading">Concepts</span><span class="section-anchor"> <a rel="bookmark" href="#concepts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Wallets follow a model <em>Interaction Flow</em> as follows:</p>
|
||||
<ol type="1">
|
||||
<li>A Recipient <em>generates</em> an Address.</li>
|
||||
<li>The Recipient wallet <em>encodes</em> the Address.</li>
|
||||
<li>The Recipient wallet or human user <em>distributes</em> this Address Encoding, This ZIP leaves distribution mechanisms out of scope.</li>
|
||||
<li>A Producer <em>generates</em> an Address.</li>
|
||||
<li>The Producer <em>encodes</em> the Address.</li>
|
||||
<li>The Producer wallet or human user <em>distributes</em> this Address Encoding, This ZIP leaves distribution mechanisms out of scope.</li>
|
||||
<li>A Sender wallet or user <em>imports</em> the Address Encoding through any of a variety of mechanisms (QR Code scanning, Payment URIs, cut-and-paste, or “in-band” protocols like <code>Reply-To</code> memos).</li>
|
||||
<li>A Sender wallet <em>decodes</em> the Address Encoding and performs validity checks.</li>
|
||||
<li>(Perhaps later in time) the Sender wallet executes a transfer of ZEC (or other assets or future protocol state changes) to the Address.</li>
|
||||
<li>(Perhaps later in time) the Sender wallet executes a transfer of ZEC (or other assets or protocol state changes) to the Address.</li>
|
||||
</ol>
|
||||
<p>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.</p>
|
||||
<p>[TODO: examples]</p>
|
||||
<p>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.</p>
|
||||
<p>Steps 1 to 5 inclusive also apply to Interaction Flows for Unified Full Viewing Keys and Unified Incoming Viewing Keys.</p>
|
||||
</section>
|
||||
<section id="addresses"><h3><span class="section-heading">Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Unified Address (or UA for short) combines one or more Receivers.</p>
|
||||
<p>When new Transport Protocols are introduced to the Zcash protocol after Unified Addresses are standardized, those should introduce new Receiver Types but <em>not</em> 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.</p>
|
||||
<p>When new Transport Protocols are introduced to the Zcash protocol after Unified Addresses are standardized, those should introduce new Receiver Types but <em>not</em> 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.</p>
|
||||
</section>
|
||||
<section id="receivers"><h3><span class="section-heading">Receivers</span><span class="section-anchor"> <a rel="bookmark" href="#receivers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Every Wallet must properly <em>parse</em> a Unified Address containing unrecognized Receiver Types.</p>
|
||||
<p>Every Wallet must properly <em>parse</em> a Unified Address containing unrecognized Receiver Types; and similarly for Unified Full Viewing Keys and Unified Incoming Viewing Keys.</p>
|
||||
<p>A Wallet may process unrecognized Receiver Types by indicating to the user their presence or similar information for usability or diagnostic purposes.</p>
|
||||
</section>
|
||||
<section id="transport-encoding"><h3><span class="section-heading">Transport Encoding</span><span class="section-anchor"> <a rel="bookmark" href="#transport-encoding"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The string encoding is “opaque” to human readers: it does <em>not</em> allow visual identification of which Receivers or Receiver Types are present.</p>
|
||||
<p>The string encoding is resilient against typos, transcription errors, cut-and-paste errors, unanticipated truncation, or other anticipated UX hazards.</p>
|
||||
<p>There is a well-defined encoding of a Unified Address as a QR Code, which produces QR codes that are reasonably compact and robust.</p>
|
||||
<p>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.</p>
|
||||
<p>There is a well-defined transformation between the QR Code and string encodings in either direction.</p>
|
||||
<p>The string encoding fits into ZIP-321 Payment URIs <a id="id4" class="footnote_reference" href="#zip-0321">7</a> and general URIs without introducing parse ambiguities.</p>
|
||||
<p>The encoding must support sufficiently many Recipient Types to allow for reasonable future expansion.</p>
|
||||
<p>The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them.</p>
|
||||
</section>
|
||||
<section id="transfers"><h3><span class="section-heading">Transfers</span><span class="section-anchor"> <a rel="bookmark" href="#transfers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When executing a Transfer the Sender selects a transfer method via a Selection process.</p>
|
||||
<p>When executing a Transfer the Sender selects a Receiver via a Selection process.</p>
|
||||
<p>Given a valid UA, Selection must treat any unrecognized Receiver as though it were absent.</p>
|
||||
<ul>
|
||||
<li>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.</li>
|
||||
|
@ -113,45 +122,46 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>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.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="open-issues-and-known-concerns"><h3><span class="section-heading">Open Issues and Known Concerns</span><span class="section-anchor"> <a rel="bookmark" href="#open-issues-and-known-concerns"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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.</p>
|
||||
<section id="viewing-keys"><h3><span class="section-heading">Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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 <a id="id5" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
|
||||
<p>Transparent Addresses do not have separate corresponding viewing keys, but the address itself can effectively be used as a viewing key. Therefore, a UFVK or UIVK should be able to include a Transparent Address.</p>
|
||||
<p>A wallet should support deriving a Unified Address from a UFVK, by deriving a Receiver from each Full Viewing Key in the UFVK. Any Transparent Address in the UFVK is left as-is.</p>
|
||||
<p>It is not possible to derive a Unified Address from a Unified Incoming Viewing Key.</p>
|
||||
</section>
|
||||
<section id="open-issues-and-known-concerns"><h3><span class="section-heading">Open Issues and Known Concerns</span><span class="section-anchor"> <a rel="bookmark" href="#open-issues-and-known-concerns"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>TODO: We have a few of these that will be added in future edits. This is especially true of privacy impacts of transparent or cross-pool transactions and the associated UX issues.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>...</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="definitions"><h3><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
</section>
|
||||
<section id="encoding-of-unified-payment-addresses"><h3><span class="section-heading">Encoding of Unified Payment Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-payment-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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.</p>
|
||||
<p>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:</p>
|
||||
<section id="encoding-of-unified-addresses"><h3><span class="section-heading">Encoding of Unified Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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.</p>
|
||||
<p>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:</p>
|
||||
<ul>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x03}\)</span>
|
||||
— an Orchard raw address as defined in <a id="id5" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">4</a>;</li>
|
||||
— an Orchard raw address as defined in <a id="id6" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">4</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
— a Sapling raw address as defined in <a id="id6" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">3</a>;</li>
|
||||
— a Sapling raw address as defined in <a id="id7" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">3</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
— a transparent P2SH address, <em>or</em> Typecode
|
||||
— a Transparent P2SH address, <em>or</em> Typecode
|
||||
<span class="math">\(\mathtt{0x00}\)</span>
|
||||
— a transparent P2PKH address.</li>
|
||||
— a Transparent P2PKH address.</li>
|
||||
</ul>
|
||||
<p>We say that a Receiver Type is “better” than another when it appears earlier in this Priority List.</p>
|
||||
<p>We say that a Receiver Type is “preferred” over another when it appears earlier in this Priority List.</p>
|
||||
<p>A Unified Address MUST contain at least one shielded Receiver (Typecodes
|
||||
<span class="math">\(\geq \mathtt{0x02}\)</span>
|
||||
).</p>
|
||||
<p>The Sender of a payment to a Unified Address MUST use the Receiver of the best Receiver Type that it supports from the set.</p>
|
||||
<p>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.</p>
|
||||
<p>The Sender of a payment to a Unified Address MUST use the Receiver of the most preferred Receiver Type that it supports from the set.</p>
|
||||
<p>For example, consider a wallet that supports sending funds to Orchard 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.</p>
|
||||
<p>The raw encoding of a Unified Address is a concatenation of
|
||||
<span class="math">\((\mathtt{typecode}, \mathtt{length}, \mathtt{addr})\)</span>
|
||||
encodings of the consituent Receivers:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathtt{typecode} : \mathtt{byte}\)</span>
|
||||
— the Typecode from the above list;</li>
|
||||
— the Typecode from the above Priority List;</li>
|
||||
<li>
|
||||
<span class="math">\(\mathtt{length} : \mathtt{byte}\)</span>
|
||||
— the length in bytes of
|
||||
|
@ -159,14 +169,26 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
;</li>
|
||||
<li>
|
||||
<span class="math">\(\mathtt{addr} : \mathtt{byte[length]}\)</span>
|
||||
— the raw encoding of a shielded payment address, or the
|
||||
<span class="math">\(160\)</span>
|
||||
-bit script hash of a P2SH address <a id="id7" class="footnote_reference" href="#p2sh">10</a>, or the
|
||||
<span class="math">\(160\)</span>
|
||||
-bit validating key hash of a P2PKH address <a id="id8" class="footnote_reference" href="#p2pkh">9</a>.</li>
|
||||
— the Receiver Encoding.</li>
|
||||
</ul>
|
||||
<p>The result of the concatenation is then encoded with Bech32m <a id="id9" class="footnote_reference" href="#bip-0350">8</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
<p>For unified payment addresses on Mainnet, the Human-Readable Part (as defined in <a id="id10" class="footnote_reference" href="#bip-0350">8</a>) is “<code>u</code>”. For unified payment addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
|
||||
<p>A Receiver Encoding is the raw encoding of a Shielded Payment Address, or the
|
||||
<span class="math">\(160\)</span>
|
||||
-bit script hash of a P2SH address <a id="id8" class="footnote_reference" href="#p2sh">10</a>, or the
|
||||
<span class="math">\(160\)</span>
|
||||
-bit validating key hash of a P2PKH address <a id="id9" class="footnote_reference" href="#p2pkh">9</a>.</p>
|
||||
<p>We append 16 zero bytes to the concatenated encodings, and then apply the
|
||||
<span class="math">\(\mathsf{F4Jumble}\)</span>
|
||||
algorithm as described in <a href="#address-hardening">Address Hardening</a>. The output is then encoded with Bech32m <a id="id10" class="footnote_reference" href="#bip-0350">8</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
<p>To decode a Unified Address Encoding, a Sender MUST use the following procedure:</p>
|
||||
<ul>
|
||||
<li>Decode using Bech32m, rejecting any address with an incorrect checksum.</li>
|
||||
<li>Apply
|
||||
<span class="math">\(\mathsf{F4Jumble}^{-1}\)</span>
|
||||
(this can also reject if the input is not in the correct range of lengths).</li>
|
||||
<li>If the result ends in 16 zero bytes, remove them; otherwise reject.</li>
|
||||
<li>Parse the result as a raw encoding as described above, rejecting any address that does not parse correctly.</li>
|
||||
</ul>
|
||||
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id11" class="footnote_reference" href="#bip-0350">8</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
|
||||
<p>Notes:</p>
|
||||
<ul>
|
||||
<li>The
|
||||
|
@ -174,17 +196,21 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
field is always encoded as a single byte, <em>not</em> as a
|
||||
<span class="math">\(\mathtt{compactSize}\)</span>
|
||||
.</li>
|
||||
<li>For transparent addresses, the
|
||||
<span class="math">\(\mathtt{addr}\)</span>
|
||||
field does not include the first two bytes of a raw encoding.</li>
|
||||
<li>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 <a id="id11" class="footnote_reference" href="#zip-0211">5</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>Consumers MUST ignore constituent addresses with Typecodes they do not recognize.</li>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding.</li>
|
||||
<li>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 <a id="id12" class="footnote_reference" href="#zip-0211">5</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>Senders MUST ignore constituent Addresses with Typecodes they do not recognize.</li>
|
||||
<li>Senders MUST reject Unified 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.</li>
|
||||
<li>Producers SHOULD order the constituent Addresses in the same order as in the Priority List above. However, Senders MUST NOT assume this ordering, and it does not affect which Address should be used by a Sender.</li>
|
||||
<li>There MUST NOT be additional bytes at the end of the raw encoding that cannot be interpreted as specified above.</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="encoding-of-unified-full-incoming-viewing-keys"><h3><span class="section-heading">Encoding of Unified Full/Incoming Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-full-incoming-viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Unified Full or Incoming Viewing Keys are encoded analogously to Unified Addresses. The same Priority List and the same Typecodes are used. For Shielded Addresses, the encoding used in place of the
|
||||
<span class="math">\(\mathtt{addr}\)</span>
|
||||
field is the raw encoding of the Full Viewing Key or Incoming Viewing Key.</p>
|
||||
<p>Transparent Addresses do not have separate corresponding viewing keys, but the address itself can effectively be used as a viewing key. Therefore, a UFVK or UIVK MAY include a Transparent Address, which is encoded using the same Typecode and Receiver Encoding as in a Unified Address.</p>
|
||||
</section>
|
||||
<section id="address-hardening"><h3><span class="section-heading">Address hardening</span><span class="section-anchor"> <a rel="bookmark" href="#address-hardening"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Security goal (<strong>near second preimage resistance</strong>):</p>
|
||||
<ul>
|
||||
|
@ -193,25 +219,25 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
Unified Addresses, generated honestly.</li>
|
||||
<li>The attack goal is to produce a “partially colliding” valid Unified Address that:
|
||||
<ol suffix=")" type="a">
|
||||
<li>has a string encoding matching that of <em>one of</em> the input addresses on some subset of characters (for concreteness, consider the first
|
||||
<li>has a string encoding matching that of <em>one of</em> the input Addresses on some subset of characters (for concreteness, consider the first
|
||||
<span class="math">\(n\)</span>
|
||||
and last
|
||||
<span class="math">\(m\)</span>
|
||||
characters, up to some bound on
|
||||
<span class="math">\(n+m\)</span>
|
||||
);</li>
|
||||
<li>is controlled by the adversary (for concreteness, the adversary knows <em>at least one</em> of the private keys of the constituent addresses).</li>
|
||||
<li>is controlled by the adversary (for concreteness, the adversary knows <em>at least one</em> of the private keys of the constituent Addresses).</li>
|
||||
</ol>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Security goal (<strong>nonmalleability</strong>):</p>
|
||||
<ul>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
<section id="discussion"><h4><span class="section-heading">Discussion</span><span class="section-anchor"> <a rel="bookmark" href="#discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>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
|
||||
<span class="math">\(q\)</span>
|
||||
target addresses. It may be possible to improve on this attack by making use of properties of checksums, etc.</p>
|
||||
target Addresses. It may be possible to improve on this attack by making use of properties of checksums, etc.</p>
|
||||
<p>The generic attack puts an upper bound on the achievable security: if it takes work
|
||||
<span class="math">\(w\)</span>
|
||||
to produce and verify a UA, and the size of the character set is
|
||||
|
@ -220,7 +246,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\sim \frac{w \cdot
|
||||
c^{n+m}}{q}\)</span>
|
||||
.</p>
|
||||
<p>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
|
||||
<p>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
|
||||
<span class="math">\(w\)</span>
|
||||
defined as above, the cost is
|
||||
<span class="math">\(w/p\)</span>
|
||||
|
@ -228,7 +254,7 @@ c^{n+m}}{q}\)</span>
|
|||
<span class="math">\(p\)</span>
|
||||
is the probability that a random decoding is of the required form.</p>
|
||||
</section>
|
||||
<section id="proposed-solution"><h4><span class="section-heading">Proposed solution</span><span class="section-anchor"> <a rel="bookmark" href="#proposed-solution"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="solution"><h4><span class="section-heading">Solution</span><span class="section-anchor"> <a rel="bookmark" href="#solution"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>We use an unkeyed 4-round Feistel construction to approximate a random permutation. (As explained below, 3 rounds would not be sufficient.)</p>
|
||||
<p>Let
|
||||
<span class="math">\(H_i\)</span>
|
||||
|
@ -317,13 +343,13 @@ c^{n+m}}{q}\)</span>
|
|||
bytes.)</p>
|
||||
</section>
|
||||
<section id="usage-for-unified-addresses"><h4><span class="section-heading">Usage for Unified Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#usage-for-unified-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The producer of a unified address appends 16 zero bytes to the encoding of the sequence of (Typecode, length, addr), then applies
|
||||
<p>In order to prevent the generic attack against nonmalleability, there needs to be some redundancy in the encoding. Therefore, the Producer of a Unified Address appends 16 zero bytes to the encoding of the sequence of (Typecode, length, addr), then applies
|
||||
<span class="math">\(\mathsf{F4Jumble}\)</span>
|
||||
before encoding the result with Bech32m.</p>
|
||||
<p>The consumer rejects any Bech32m-decoded byte sequence that is less than 22 bytes or greater than 16448 bytes; otherwise it applies
|
||||
<p>The Sender rejects any Bech32m-decoded byte sequence that is less than 22 bytes or greater than 16448 bytes; otherwise it applies
|
||||
<span class="math">\(\mathsf{F4Jumble}^{-1}\)</span>
|
||||
. It rejects any result that does not end in 16 zero bytes, before stripping these 16 bytes and parsing the result.</p>
|
||||
<p>(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
|
||||
<p>(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
|
||||
<span class="math">\(\mathsf{F4Jumble}\)</span>
|
||||
.)</p>
|
||||
</section>
|
||||
|
@ -401,15 +427,15 @@ c^{n+m}}{q}\)</span>
|
|||
<span class="math">\(y' \neq y\)</span>
|
||||
, all four pieces are randomized.</li>
|
||||
</ul>
|
||||
<p>Note that the size of each piece is at least 11 bytes. TODO: analyze whether this is sufficient when using 4 rounds.</p>
|
||||
<p>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.</p>
|
||||
<p>Note that the size of each piece is at least 11 bytes.</p>
|
||||
<p>It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Sender.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.</p>
|
||||
</section>
|
||||
<section id="efficiency"><h4><span class="section-heading">Efficiency</span><span class="section-anchor"> <a rel="bookmark" href="#efficiency"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The cost is dominated by 4 BLAKE2b compressions for
|
||||
<span class="math">\(\ell_M \leq 128\)</span>
|
||||
bytes. A UA containing a transparent address, a Sapling address, and an Orchard address, would have
|
||||
bytes. A UA containing a Transparent Address, a Sapling Address, and an Orchard Address, would have
|
||||
<span class="math">\(\ell_M = 112\)</span>
|
||||
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.</p>
|
||||
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.</p>
|
||||
<p>For longer UAs (when other Typecodes are added), the cost increases to 6 BLAKE2b compressions for
|
||||
<span class="math">\(128 < \ell_M \leq 192\)</span>
|
||||
, and 10 BLAKE2b compressions for
|
||||
|
@ -436,10 +462,9 @@ c^{n+m}}{q}\)</span>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="open-questions"><h3><span class="section-heading">Open questions</span><span class="section-anchor"> <a rel="bookmark" href="#open-questions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TODO.</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>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.</p>
|
||||
|
|
251
zip-0316.rst
251
zip-0316.rst
|
@ -27,17 +27,26 @@ 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.
|
||||
Producer
|
||||
A wallet or other software that can create an Address (normally also a
|
||||
Recipient).
|
||||
Sender
|
||||
A wallet or other software that can send transfers of assets, or other
|
||||
future consensus state side-effects.
|
||||
consensus state side-effects defined in future.
|
||||
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.
|
||||
Receiver Encoding
|
||||
An encoding of a Receiver as a byte sequence.
|
||||
Legacy Address (or LA)
|
||||
A transparent, Sprout, or Sapling Address.
|
||||
A Transparent, Sprout, or Sapling Address.
|
||||
Unified Address (or UA)
|
||||
A Unified Address combines multiple Receivers.
|
||||
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.
|
||||
Address
|
||||
Either a Legacy Address or a Unified Address.
|
||||
Transfer Protocol
|
||||
|
@ -56,7 +65,7 @@ Address Encoding
|
|||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines Unified Addresses, which bundle together Zcash addresses
|
||||
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.
|
||||
|
@ -66,7 +75,7 @@ Motivation
|
|||
==========
|
||||
|
||||
Up to and including the Canopy network upgrade, Zcash supported the following
|
||||
payment address types:
|
||||
Payment Address types:
|
||||
|
||||
* Transparent Addresses (P2PKH and P2SH)
|
||||
* Sprout Addresses
|
||||
|
@ -76,20 +85,20 @@ 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 Orchard proposal [#zip-0224]_ adds a new Address type, Orchard Addresses.
|
||||
|
||||
The difficulty with defining new Address Encodings for each address type, is
|
||||
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
|
||||
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.
|
||||
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.
|
||||
|
@ -100,6 +109,8 @@ The goals for a Unified Address standard are as follows:
|
|||
shielding and/or migrating user funds.
|
||||
- Allow wallets to potentially develop new transfer mechanisms without
|
||||
underlying protocol changes.
|
||||
- Support abstractions corresponding to a Unified Address that provide the
|
||||
functionality of Full Viewing Keys and Incoming Viewing Keys.
|
||||
- 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
|
||||
|
@ -124,16 +135,16 @@ 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.
|
||||
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,
|
||||
1. A Producer *generates* an Address.
|
||||
2. The Producer *encodes* the Address.
|
||||
3. The Producer 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,
|
||||
|
@ -141,14 +152,15 @@ Wallets follow a model *Interaction Flow* as follows:
|
|||
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.
|
||||
(or other assets or 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
|
||||
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]
|
||||
Steps 1 to 5 inclusive also apply to Interaction Flows for Unified Full Viewing
|
||||
Keys and Unified Incoming Viewing Keys.
|
||||
|
||||
Addresses
|
||||
---------
|
||||
|
@ -157,7 +169,7 @@ 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
|
||||
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.
|
||||
|
@ -166,7 +178,8 @@ Receivers
|
|||
---------
|
||||
|
||||
Every Wallet must properly *parse* a Unified Address containing unrecognized
|
||||
Receiver Types.
|
||||
Receiver Types; and similarly for Unified Full Viewing Keys and Unified
|
||||
Incoming Viewing Keys.
|
||||
|
||||
A Wallet may process unrecognized Receiver Types by indicating to the user
|
||||
their presence or similar information for usability or diagnostic purposes.
|
||||
|
@ -181,8 +194,9 @@ 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 encoding of a Unified Address (or UFVK or UIVK)
|
||||
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.
|
||||
|
@ -199,8 +213,8 @@ unrecognized Receiver Types well enough to ignore them.
|
|||
Transfers
|
||||
---------
|
||||
|
||||
When executing a Transfer the Sender selects a transfer method via a
|
||||
Selection process.
|
||||
When executing a Transfer the Sender selects a Receiver via a Selection
|
||||
process.
|
||||
|
||||
Given a valid UA, Selection must treat any unrecognized Receiver as
|
||||
though it were absent.
|
||||
|
@ -217,42 +231,50 @@ though it were absent.
|
|||
shielded support without re-acquiring counterparty UAs. If they are
|
||||
re-acquired, the user flow and usability will be minimally disrupted.
|
||||
|
||||
Viewing Keys
|
||||
------------
|
||||
|
||||
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]_.
|
||||
|
||||
Transparent Addresses do not have separate corresponding viewing keys,
|
||||
but the address itself can effectively be used as a viewing key.
|
||||
Therefore, a UFVK or UIVK should be able to include a Transparent Address.
|
||||
|
||||
A wallet should support deriving a Unified Address from a UFVK, by
|
||||
deriving a Receiver from each Full Viewing Key in the UFVK. Any
|
||||
Transparent Address in the UFVK is left as-is.
|
||||
|
||||
It is not possible to derive a Unified Address from a Unified Incoming
|
||||
Viewing Key.
|
||||
|
||||
|
||||
Open Issues and Known Concerns
|
||||
------------------------------
|
||||
|
||||
FIXME: We have a few of these I [Nathan] will add in future edits.
|
||||
TODO: We have a few of these that will be added 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 Addresses
|
||||
-----------------------------
|
||||
|
||||
|
||||
|
||||
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
|
||||
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:
|
||||
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:
|
||||
|
||||
* Typecode :math:`\mathtt{0x03}` — an Orchard raw address as defined
|
||||
in [#protocol-orchardpaymentaddrencoding]_;
|
||||
|
@ -260,72 +282,85 @@ fixed Priority List:
|
|||
* 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.
|
||||
* 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
|
||||
We say that a Receiver Type is “preferred” over 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.
|
||||
of the most preferred 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.
|
||||
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.
|
||||
|
||||
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;
|
||||
above Priority 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]_.
|
||||
* :math:`\mathtt{addr} : \mathtt{byte[length]}` — the Receiver Encoding.
|
||||
|
||||
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.
|
||||
A Receiver Encoding is 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]_.
|
||||
|
||||
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``”.
|
||||
We append 16 zero bytes to the concatenated encodings, and then apply
|
||||
the :math:`\mathsf{F4Jumble}` algorithm as described in `Address Hardening`_.
|
||||
The output is then encoded with Bech32m [#bip-0350]_, ignoring any
|
||||
length restrictions. This is chosen over Bech32 in order to better
|
||||
handle variable-length inputs.
|
||||
|
||||
To decode a Unified Address Encoding, a Sender MUST use the following
|
||||
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).
|
||||
* If the result ends in 16 zero bytes, remove them; otherwise reject.
|
||||
* Parse the result as a raw encoding as described above, rejecting any
|
||||
address that does not parse correctly.
|
||||
|
||||
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``”.
|
||||
|
||||
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.
|
||||
* For Transparent Addresses, the Receiver Encoding 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
|
||||
* 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
|
||||
* Senders 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.
|
||||
* Senders MUST reject Unified 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.
|
||||
* Producers SHOULD order the constituent Addresses in the same order
|
||||
as in the Priority List above. However, Senders MUST NOT assume
|
||||
this ordering, and it does not affect which Address should be used
|
||||
by a Sender.
|
||||
|
||||
* There MUST NOT be additional bytes at the end of the raw encoding
|
||||
that cannot be interpreted as specified above.
|
||||
|
@ -335,6 +370,22 @@ Notes:
|
|||
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 analogously to
|
||||
Unified Addresses. The same Priority List and the same Typecodes are
|
||||
used. For Shielded Addresses, the encoding used in place of the
|
||||
:math:`\mathtt{addr}` field is the raw encoding of the Full Viewing
|
||||
Key or Incoming Viewing Key.
|
||||
|
||||
Transparent Addresses do not have separate corresponding viewing keys,
|
||||
but the address itself can effectively be used as a viewing key.
|
||||
Therefore, a UFVK or UIVK MAY include a Transparent Address, which
|
||||
is encoded using the same Typecode and Receiver Encoding as in a
|
||||
Unified Address.
|
||||
|
||||
|
||||
Address hardening
|
||||
-----------------
|
||||
|
||||
|
@ -345,20 +396,20 @@ Security goal (**near second preimage resistance**):
|
|||
Address that:
|
||||
|
||||
a) has a string encoding matching that of *one of* the input
|
||||
addresses on some subset of characters (for concreteness, consider
|
||||
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).
|
||||
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
|
||||
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
|
||||
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
|
||||
|
@ -367,7 +418,7 @@ 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
|
||||
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
|
||||
|
@ -376,14 +427,14 @@ 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
|
||||
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).
|
||||
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
|
||||
'''''''''''''''''
|
||||
Solution
|
||||
''''''''
|
||||
|
||||
We use an unkeyed 4-round Feistel construction to approximate a random
|
||||
permutation. (As explained below, 3 rounds would not be sufficient.)
|
||||
|
@ -429,17 +480,19 @@ 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}`
|
||||
In order to prevent the generic attack against nonmalleability, there
|
||||
needs to be some redundancy in the encoding. Therefore, 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
|
||||
The Sender 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
|
||||
(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
|
||||
|
@ -481,23 +534,22 @@ A 4-round Feistel thwarts this and similar attacks. Defining :math:`x` and
|
|||
* 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.
|
||||
Note that the size of each piece is at least 11 bytes.
|
||||
|
||||
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.
|
||||
done by a Producer more expensive. (This wouldn't necessarily have to
|
||||
increase the work done by the Sender.) However, given that Unified 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.
|
||||
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
|
||||
|
@ -530,13 +582,12 @@ 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
|
||||
========================
|
||||
|
||||
TODO.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
================
|
||||
|
|
Loading…
Reference in New Issue