mirror of https://github.com/zcash/zips.git
Compare commits
11 Commits
2eafd2bb31
...
6cd92d63cf
| Author | SHA1 | Date |
|---|---|---|
Daira-Emma Hopwood
|
6cd92d63cf | |
|
Daira-Emma Hopwood
|
a68370f751 | |
|
Daira-Emma Hopwood
|
ba3b2697bb | |
|
Daira-Emma Hopwood
|
35297e5172 | |
|
Daira-Emma Hopwood
|
7ac81a538a | |
|
Daira-Emma Hopwood
|
5273fc9c99 | |
dependabot[bot]
|
bf6c166940 | |
|
Daira-Emma Hopwood
|
2e9272e850 | |
github-actions
|
6a0a93c020 | |
Andrew Arnott
|
250425e54a | |
|
Andrew Arnott
|
b8ba2282c2 |
|
|
@ -1 +0,0 @@
|
|||
../../../Dockerfile
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
name: Render Zcash Protocol Specification
|
||||
description: GitHub Action to compile Zcash Protocol Specification LaTeX documents
|
||||
author: Deirdre Connolly
|
||||
runs:
|
||||
using: docker
|
||||
# Runs `make all` or something like it
|
||||
image: Dockerfile
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
name: Render ZIPs and Zcash Protocol Specification
|
||||
description: GitHub Action to compile ZIPs and Zcash Protocol Specification LaTeX documents
|
||||
author: Deirdre Connolly
|
||||
runs:
|
||||
using: docker
|
||||
# Runs `make all` or something like it
|
||||
image: ../../../Dockerfile
|
||||
|
|
@ -1,19 +1,23 @@
|
|||
name: Render pdfs
|
||||
name: Build tex and rst
|
||||
|
||||
on: workflow_dispatch
|
||||
on:
|
||||
workflow_dispatch:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
|
||||
jobs:
|
||||
|
||||
render:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Set up Git repository
|
||||
uses: actions/checkout@v4.1.1
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v4.1.2
|
||||
|
||||
- name: Compile Zcash Protocol Specification
|
||||
uses: ./.github/actions/render-protocol-pdf
|
||||
- name: Compile ZIPs and Zcash Protocol Specification
|
||||
uses: ./.github/actions/render
|
||||
|
||||
- uses: EndBug/add-and-commit@v9.1.3
|
||||
with:
|
||||
add: '**/*.pdf'
|
||||
add: 'protocol/*.pdf *.html'
|
||||
default_author: github_actions
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
FROM debian:latest
|
||||
|
||||
RUN apt-get update \
|
||||
&& apt-get install -y \
|
||||
RUN apt-get update
|
||||
RUN apt-get install -y \
|
||||
gawk \
|
||||
perl \
|
||||
sed \
|
||||
|
|
@ -17,7 +17,10 @@ RUN apt-get update \
|
|||
texlive-plain-generic \
|
||||
texlive-bibtex-extra
|
||||
|
||||
RUN pip3 install rst2html5
|
||||
RUN rm /usr/lib/python3.11/EXTERNALLY-MANAGED
|
||||
RUN pip install rst2html5
|
||||
|
||||
ENV PATH=${PATH}:/root/.local/bin
|
||||
|
||||
WORKDIR "/zips"
|
||||
ENTRYPOINT ["make", "all"]
|
||||
|
|
|
|||
|
|
@ -143,7 +143,6 @@ Index of ZIPs
|
|||
<tr> <td>321</td> <td class="left"><a href="zip-0321.rst">Payment Request URIs</a></td> <td>Proposed</td>
|
||||
<tr> <td><span class="reserved">322</span></td> <td class="left"><a class="reserved" href="zip-0322.rst">Generic Signed Message Format</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323.rst">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
|
||||
<tr> <td>324</td> <td class="left"><a href="zip-0324.rst">URI-Encapsulated Payments</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">332</span></td> <td class="left"><a class="reserved" href="zip-0332.rst">Wallet Recovery from zcashd HD Seeds</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339.rst">Wallet Recovery Words</a></td> <td>Reserved</td>
|
||||
<tr> <td>400</td> <td class="left"><a href="zip-0400.rst">Wallet.dat format</a></td> <td>Draft</td>
|
||||
|
|
|
|||
|
|
@ -117,7 +117,6 @@
|
|||
<tr> <td>321</td> <td class="left"><a href="zip-0321">Payment Request URIs</a></td> <td>Proposed</td>
|
||||
<tr> <td><span class="reserved">322</span></td> <td class="left"><a class="reserved" href="zip-0322">Generic Signed Message Format</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
|
||||
<tr> <td>324</td> <td class="left"><a href="zip-0324">URI-Encapsulated Payments</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">332</span></td> <td class="left"><a class="reserved" href="zip-0332">Wallet Recovery from zcashd HD Seeds</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339">Wallet Recovery Words</a></td> <td>Reserved</td>
|
||||
<tr> <td>400</td> <td class="left"><a href="zip-0400">Wallet.dat format</a></td> <td>Draft</td>
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
Binary file not shown.
BIN
protocol/nu5.pdf
BIN
protocol/nu5.pdf
Binary file not shown.
Binary file not shown.
|
|
@ -14811,7 +14811,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
|
|||
\intropart
|
||||
\lsection{Change History}{changehistory}
|
||||
|
||||
\historyentry{2024.4.1}{2024-03-02}
|
||||
\historyentry{Unreleased}{2024-04-14}
|
||||
|
||||
\begin{itemize}
|
||||
\item Add the hyphen in \nh{Daira-Emma} Hopwood.
|
||||
|
|
|
|||
Binary file not shown.
|
|
@ -904,7 +904,7 @@ L. Hernández Encinas and C. Sánchez Ávila},
|
|||
|
||||
@misc{DGKM2011,
|
||||
presort={DGKM2011},
|
||||
author={Dana {Dachman-Soled} and Rosario Gennaro and Hugo Krawczyk and Tal Malkin},
|
||||
author={Dana {Dachman\nbh{}Soled} and Rosario Gennaro and Hugo Krawczyk and Tal Malkin},
|
||||
title={Computational {E}xtractors and {P}seudorandomness},
|
||||
url={https://eprint.iacr.org/2011/708},
|
||||
urldate={2016-09-02},
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
<pre>ZIP: 32
|
||||
Title: Shielded Hierarchical Deterministic Wallets
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Sean Bowe
|
||||
Kris Nuttycombe
|
||||
Ying Tong Lai
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 76
|
||||
Title: Transaction Signature Validation before Overwinter
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Consensus
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/130">https://github.com/zcash/zips/issues/130</a>></pre>
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 143
|
||||
Title: Transaction Signature Validation for Overwinter
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Johnson Lau
|
||||
Pieter Wuille
|
||||
Bitcoin-ABC
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 155
|
||||
Title: addrv2 message
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Wladimir J. van der Laan
|
||||
Zancas Wilcox
|
||||
Status: Proposed
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 173
|
||||
Title: Bech32 Format
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Pieter Wuille <pieter.wuille@gmail.com>
|
||||
Greg Maxwell <greg@xiph.org>
|
||||
Rusty Russell
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 201
|
||||
Title: Network Peer Management for Overwinter
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Simon Liu
|
||||
Status: Final
|
||||
Category: Network
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 202
|
||||
Title: Version 3 Transaction Format for Overwinter
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 203
|
||||
Title: Transaction Expiry
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Jay Graber
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 204
|
||||
Title: Zcash P2P Network Protocol
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Network
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/352">https://github.com/zcash/zips/issues/352</a>></pre>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 205
|
||||
Title: Deployment of the Sapling Network Upgrade
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 206
|
||||
Title: Deployment of the Blossom Network Upgrade
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
<pre>ZIP: 207
|
||||
Title: Funding Streams
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-01-04
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@
|
|||
<section>
|
||||
<pre>ZIP: 208
|
||||
Title: Shorter Block Target Spacing
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Original-Authors: Daira-Emma Hopwood
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Daira Emma Hopwood
|
||||
Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 209
|
||||
Title: Prohibit Negative Shielded Chain Value Pool Balances
|
||||
Owners: Sean Bowe <sean@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-02-25
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 211
|
||||
Title: Disabling Addition of New Value to the Sprout Chain Value Pool
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Sean Bowe
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 214
|
||||
Title: Consensus rules for a Zcash Development Fund
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2020-02-28
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
<pre>ZIP: 216
|
||||
Title: Require Canonical Jubjub Point Encodings
|
||||
Owners: Jack Grigg <jack@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2021-02-11
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 217
|
||||
Title: Aggregate Signatures
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Consensus
|
||||
Discussions-To: <<a href="https://github.com/zcash/zcash/issues/2914">https://github.com/zcash/zcash/issues/2914</a>></pre>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 219
|
||||
Title: Disabling Addition of New Value to the Sapling Chain Value Pool
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Consensus
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/428">https://github.com/zcash/zips/issues/428</a>></pre>
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 220
|
||||
Title: Zcash Shielded Assets
|
||||
Owners: Jack Grigg <jack@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Withdrawn
|
||||
Category: Consensus
|
||||
Discussions-To: <<a href="https://github.com/zcash/zcash/issues/830">https://github.com/zcash/zcash/issues/830</a>>
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Title: Transparent Zcash Extensions
|
|||
Owners: Jack Grigg <jack@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
Credits: Zaki Manian
|
||||
Daira-Emma Hopwood
|
||||
Daira Emma Hopwood
|
||||
Sean Bowe
|
||||
Status: Draft
|
||||
Category: Consensus
|
||||
|
|
@ -282,7 +282,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="footnote-referen
|
|||
</ul>
|
||||
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The handler semantics of <code>tze_verify</code> were suggested by Zaki Manian, drawing on the design of Cosmos. Daira-Emma Hopwood and Sean Bowe gave useful feedback on an early draft of this ZIP, and helped to analyse the various sources of transaction ID malleability.</p>
|
||||
<p>The handler semantics of <code>tze_verify</code> were suggested by Zaki Manian, drawing on the design of Cosmos. Daira Emma Hopwood and Sean Bowe gave useful feedback on an early draft of this ZIP, and helped to analyse the various sources of transaction ID malleability.</p>
|
||||
<p>We would also like to thank the numerous other individuals who participated in discussions at Zcon1 that led to the earlier draft version of this ZIP.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -9,11 +9,11 @@
|
|||
<section>
|
||||
<pre>ZIP: 224
|
||||
Title: Orchard Shielded Protocol
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Sean Bowe <sean@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
Original-Authors: Ying Tong Lai
|
||||
Ying Tong Lai <yingtong@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2021-02-27
|
||||
|
|
|
|||
|
|
@ -9,11 +9,11 @@
|
|||
<section>
|
||||
<pre>ZIP: 225
|
||||
Title: Version 5 Transaction Format
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Sean Bowe <sean@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
Original-Authors: Ying Tong Lai
|
||||
Ying Tong Lai <yingtong@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2021-02-28
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
Title: Transfer and Burn of Zcash Shielded Assets
|
||||
Owners: Pablo Kogan <pablo@qed-it.com>
|
||||
Vivek Arte <vivek@qed-it.com>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <str4d@electriccoin.co>
|
||||
Credits: Daniel Benarroch
|
||||
Aurelien Nicolas
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
Title: Issuance of Zcash Shielded Assets
|
||||
Owners: Pablo Kogan <pablo@qed-it.com>
|
||||
Vivek Arte <vivek@qed-it.com>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <str4d@electriccoin.co>
|
||||
Credits: Daniel Benarroch
|
||||
Aurelien Nicolas
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
Title: Asset Swaps for Zcash Shielded Assets
|
||||
Owners: Pablo Kogan <pablo@qed-it.com>
|
||||
Vivek Arte <vivek@qed-it.com>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <str4d@electriccoin.co>
|
||||
Credits: Daniel Benarroch
|
||||
Aurelien Nicolas
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 230
|
||||
Title: Version 6 Transaction Format
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira-Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Sean Bowe <sean@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
Title: Decouple Memos from Transaction Outputs
|
||||
Owners: Jack Grigg <jack@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Sean Bowe
|
||||
Nate Wilcox
|
||||
Status: Reserved
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 239
|
||||
Title: Relay of Version 5 Transactions
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Network
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 243
|
||||
Title: Transaction Signature Validation for Sapling
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
<pre>ZIP: 244
|
||||
Title: Transaction Identifier Non-Malleability
|
||||
Owners: Kris Nuttycombe <kris@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <str4d@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@
|
|||
<pre>ZIP: 245
|
||||
Title: Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions
|
||||
Owners: Kris Nuttycombe <kris@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Status: Draft
|
||||
Category: Consensus
|
||||
Created: 2021-01-13
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 250
|
||||
Title: Deployment of the Heartwood Network Upgrade
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
Created: 2020-02-28
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 251
|
||||
Title: Deployment of the Canopy Network Upgrade
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
Created: 2020-02-28
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 252
|
||||
Title: Deployment of the NU5 Network Upgrade
|
||||
Owners: teor <teor@zfnd.org>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
Created: 2021-02-23
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 300
|
||||
Title: Cross-chain Atomic Transactions
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Jay Graber
|
||||
Status: Proposed
|
||||
Category: Informational
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
Title: Zcash Stratum Protocol
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Credits: 5a1t
|
||||
Daira-Emma Hopwood
|
||||
Daira Emma Hopwood
|
||||
Marek Palatinus (slush) and colleagues
|
||||
Jelle Bourdeaud'hui (razakal)
|
||||
ocminer
|
||||
|
|
@ -336,7 +336,7 @@ License: MIT</pre>
|
|||
<p>Thanks to:</p>
|
||||
<ul>
|
||||
<li>5a1t for the initial brainstorming session.</li>
|
||||
<li>Daira-Emma Hopwood for hir input on API selection and design.</li>
|
||||
<li>Daira Emma Hopwood for their input on API selection and design.</li>
|
||||
<li>Marek Palatinus (slush) and his colleagues for their refinements, suggestions, and robust discussion.</li>
|
||||
<li>Jelle Bourdeaud'hui (razakal) and ocminer for their help with testing and finding implementation bugs in the specification.</li>
|
||||
</ul>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
<pre>ZIP: 304
|
||||
Title: Sapling Address Signatures
|
||||
Owners: Jack Grigg <jack@electriccoin.co>
|
||||
Credits: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Credits: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Sean Bowe <sean@electriccoin.co>
|
||||
Status: Draft
|
||||
Category: Standards / RPC / Wallet
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 305
|
||||
Title: Best Practices for Hardware Wallets supporting Sapling
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Wallet
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/346">https://github.com/zcash/zips/issues/346</a>></pre>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 306
|
||||
Title: Security Considerations for Anchor Selection
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Informational
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/351">https://github.com/zcash/zips/issues/351</a>></pre>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
<pre>ZIP: 307
|
||||
Title: Light Client Protocol for Payment Detection
|
||||
Owners: Jack Grigg <jack@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: George Tankersley
|
||||
Credits: Matthew Green
|
||||
Category: Standards / Ecosystem
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@
|
|||
<section>
|
||||
<pre>ZIP: 308
|
||||
Title: Sprout to Sapling Migration
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Original-Authors: Daira-Emma Hopwood
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Daira Emma Hopwood
|
||||
Eirik Ogilvie-Wigley
|
||||
Status: Final
|
||||
Category: Standards / RPC / Wallet
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 310
|
||||
Title: Security Properties of Sapling Viewing Keys
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Status: Draft
|
||||
Category: Informational
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 313
|
||||
Title: Reduce Conventional Transaction Fee to 1000 zatoshis
|
||||
Owners: Aditya Bharadwaj <nighthawkwallet@protonmail.com>
|
||||
Credits: Daira-Emma Hopwood
|
||||
Credits: Daira Emma Hopwood
|
||||
Deirdre Connolly
|
||||
Nathan Wilcox
|
||||
Status: Obsolete
|
||||
|
|
@ -81,7 +81,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/408">https://githu
|
|||
<p>In zcashd this fee change is implemented in version 4.2.0 (not dependent on block height), and in that version is limited to transactions created using <cite>z_*</cite> RPC APIs. It is planned to extend this to all transactions in a future version <a id="footnote-reference-10" class="footnote_reference" href="#zcash-2942">7</a>.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Thanks to Nathan Wilcox for suggesting improvements to the denial of service section. Thanks to Daira-Emma Hopwood and Deirdre Connolly for reviewing and fixing the wording in this ZIP.</p>
|
||||
<p>Thanks to Nathan Wilcox for suggesting improvements to the denial of service section. Thanks to Daira Emma Hopwood and Deirdre Connolly for reviewing and fixing the wording in this ZIP.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="bcp14" class="footnote">
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 315
|
||||
Title: Best Practices for Wallet Handling of Multiple Pools
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Wallet
|
||||
|
|
|
|||
|
|
@ -9,14 +9,14 @@
|
|||
<section>
|
||||
<pre>ZIP: 316
|
||||
Title: Unified Addresses and Unified Viewing Keys
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira-Emma Hopwood <daira@electriccoin.co>
|
||||
Nathan Wilcox <nathan@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Sean Bowe <sean@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
Original-Authors: Greg Pfeil
|
||||
Ying Tong Lai
|
||||
Greg Pfeil <greg@electriccoin.co>
|
||||
Credits: Taylor Hornby
|
||||
Ying Tong Lai
|
||||
Stephen Smith
|
||||
Status: Revision 0: Final, Revision 1: Proposed
|
||||
Category: Standards / RPC / Wallet
|
||||
|
|
@ -34,7 +34,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<dt>Consumer</dt>
|
||||
<dd>A wallet or other software that can make use of an Address or Viewing Key that it is given.</dd>
|
||||
<dt>Sender</dt>
|
||||
<dd>A wallet or other software that can send transfers of assets, or other side effects to consensus state that may be defined in future. Senders are a subset of Consumers.</dd>
|
||||
<dd>A wallet or other software that can send transfers of assets, or other consensus state side-effects defined in future. Senders are a subset of Consumers.</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>
|
||||
|
|
@ -197,7 +197,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<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 constituent Receivers, in ascending order of Typecode:</p>
|
||||
encodings of the consituent Receivers, in ascending order of Typecode:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathtt{typecode} : \mathtt{compactSize}\)</span>
|
||||
|
|
@ -255,7 +255,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<ul>
|
||||
<li>An Orchard FVK or IVK Encoding, with Typecode
|
||||
<span class="math">\(\mathtt{0x03},\)</span>
|
||||
is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively.</li>
|
||||
is is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively.</li>
|
||||
<li>A Sapling FVK Encoding, with Typecode
|
||||
<span class="math">\(\mathtt{0x02},\)</span>
|
||||
is the encoding of
|
||||
|
|
@ -362,7 +362,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<section id="rationale-for-making-revision-0-ua-uvks-with-must-understand-typecodes-invalid"><h4><span class="section-heading">Rationale for making Revision 0 UA/UVKs with MUST-understand Typecodes invalid</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-making-revision-0-ua-uvks-with-must-understand-typecodes-invalid"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<details>
|
||||
<summary>Click to show/hide</summary>
|
||||
<p>A Consumer implementing this ZIP prior to <a href="#revision-1">Revision 1</a> will not recognise the Human-Readable Parts beginning with “<code>ur</code>” that mark a <a href="#revision-1">Revision 1</a> UA/UVK. So if a UA/UVK that includes MUST-understand Typecodes is required to use these <a href="#revision-1">Revision 1</a> HRPs, this will ensure that the MUST-understand specification is correctly enforced even for such implementations.</p>
|
||||
<p>A Consumer implementing this ZIP prior to <a href="#revision-1">Revision 1</a> will not recognize the Human-Readable Parts beginning with “<code>ur</code>” that mark a <a href="#revision-1">Revision 1</a> UA/UVK. So if a UA/UVK that includes MUST-understand Typecodes is required to use these <a href="#revision-1">Revision 1</a> HRPs, this will ensure that the MUST-understand specification is correctly enforced even for such implementations.</p>
|
||||
</details></section>
|
||||
</section>
|
||||
<section id="address-expiration-metadata"><h3><span class="section-heading">Address Expiration Metadata</span><span class="section-anchor"> <a rel="bookmark" href="#address-expiration-metadata"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
<pre>ZIP: 317
|
||||
Title: Proportional Transfer Fee Mechanism
|
||||
Owners: Aditya Bharadwaj <nighthawk24@gmail.com>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Madars Virza
|
||||
Kris Nuttycombe
|
||||
Jack Grigg
|
||||
|
|
@ -25,7 +25,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/631">https://githu
|
|||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
|
||||
<p>The term "conventional transaction fee" in this document is in reference to the value of a transaction fee that is conventionally used by wallets, and that a user can reasonably expect miners on the Zcash network to accept for including a transaction in a block.</p>
|
||||
<p>The terms "Mainnet", "Testnet", and "zatoshi" in this document are defined as in <a id="footnote-reference-2" class="footnote_reference" href="#protocol-networks">2</a>.</p>
|
||||
<p>The terms "Mainnet, "Testnet", and "zatoshi" in this document are defined as in <a id="footnote-reference-2" class="footnote_reference" href="#protocol-networks">2</a>.</p>
|
||||
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The goal of this ZIP is to change the conventional fees for transactions by making them dependent on the number of inputs and outputs in a transaction, and to get buy-in for this change from wallet developers, miners and Zcash users.</p>
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 318
|
||||
Title: Associated Payload Encryption
|
||||
Owners: Kris Nuttycombe <kris@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Standards Track
|
||||
Created: 2022-09-19
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 319
|
||||
Title: Options for Shielded Pool Retirement
|
||||
Owners: Nathan Wilcox <nathan@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Informational
|
||||
Created: 2022-09-20
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 320
|
||||
Title: Defining an Address Type to which funds can only be sent from Transparent Addresses
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira-Emma Hopwood <daira@electriccoin.co>
|
||||
Kris Nuttycombe <kris@nutty.land>
|
||||
Credits: Hanh
|
||||
Status: Draft
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@
|
|||
<section>
|
||||
<pre>ZIP: 321
|
||||
Title: Payment Request URIs
|
||||
Owners: Kris Nuttycombe <kris@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Kris Nuttycombe (kris@electriccoin.co)
|
||||
Daira Emma Hopwood (daira@electriccoin.co)
|
||||
Credits: Francisco Gindre
|
||||
Status: Proposed
|
||||
Category: Standards / Wallet
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 322
|
||||
Title: Generic Signed Message Format
|
||||
Owners: Jack Grigg <jack@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Standards / RPC / Wallet
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/429">https://github.com/zcash/zips/issues/429</a>></pre>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 323
|
||||
Title: Specification of getblocktemplate for Zcash
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: RPC / Mining
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@
|
|||
<head>
|
||||
<title>ZIP 324: URI-Encapsulated Payments</title>
|
||||
<meta charset="utf-8" />
|
||||
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
|
|
@ -26,16 +25,16 @@ Status: Draft
|
|||
Category: Standards / Wallet
|
||||
Created: 2019-07-17
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
|
||||
<p>Zcash protocol terms are as defined in the Zcash Protocol Specification. <a id="footnote-reference-2" class="footnote_reference" href="#protocol">3</a></p>
|
||||
<p id="applink">By “applink” we mean a platform mechanism for triggering local applications using HTTPS links, such as App Links <a id="footnote-reference-3" class="footnote_reference" href="#app-links">5</a> on Android, Universal Links <a id="footnote-reference-4" class="footnote_reference" href="#universal-links">6</a> on iOS, or App URI handlers <a id="footnote-reference-5" class="footnote_reference" href="#app-uri-handlers">7</a> on Windows.</p>
|
||||
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<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 specifies a mechanism for sending Zcash payments via any unmodified (secure) messaging service, e.g., Signal or WhatsApp. The sender need not know the recipient's address and the recipient need not have a Zcash wallet already installed. Payments occur via an ordinary text/WhatsApp/Signal message containing a URI. The URI encodes the secret spending key of an ephemeral Zcash “wallet address”, to which the funds have been transferred. Anyone who learns the URI can accept this payment, by a “finalization” process which uses the key given in the URI to transfer the encapsulated funds to their own wallet. After the payment is finalized, via a suitable on-chain transaction by the recipient, it becomes irrevocable.</p>
|
||||
<p>The proposal specifies the syntax and semantics of URI-Encapsulated Payments, the workflow of generating and handling them, and requisite infrastructure.</p>
|
||||
<p>At its core, a URI encapsulated payment communicates the existence of a transaction (specifically a note committing to an amount of funds) to a receiving client. The URI encodes the amount of the payment and a key used to derive all necessary randomness for note construction including the address and secret key needed to spend it.</p>
|
||||
<section id="usage-story"><h3><span class="section-heading">Usage Story</span><span class="section-anchor"> <a rel="bookmark" href="#usage-story"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="usage-story"><h3><span class="section-heading">Usage Story</span><span class="section-anchor"> <a rel="bookmark" href="#usage-story"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Alice wants to send a 1.23 ZEC payment to Bob. She doesn't have Bob's Zcash address — and Bob may not even have a wallet or have heard of Zcash! However, she does have some end-to-end encrypted channel to Bob on a secure messaging app, such as Signal or WhatsApp. She instructs her own Zcash wallet to send 1.23 ZEC on that channel. Her wallet then automatically generates a new ephemeral Zcash address and sends 1.23001 ZEC to this address. It then constructs a payment URI containing the secret key corresponding to the ephemeral address, and sends it to Bob via the secure messaging app.</p>
|
||||
<p>Bob receives the message, which looks as follows:</p>
|
||||
<blockquote>
|
||||
|
|
@ -46,7 +45,7 @@ License: MIT</pre>
|
|||
<p>Bob clicks the link. His Zcash mobile wallet app (which is already installed and has configured itself as a handler for URLs of that form) shows up, and tells Bob that a payment of 1.23 ZEC awaits him. The wallet app confirms the existence of the pertinent transactions on the blockchain, and then offers to finalize the payment. Bob clicks the “Finalize” button, and his wallet app generates a transaction moving the money to his own address (using the extra 0.00001 ZEC he has received to pay the transaction fee). When this transaction is confirmed on-chain, Alice's and Bob's wallets both indicate that the payment is finalized, and thus Bob can send the funds to other parties.</p>
|
||||
</section>
|
||||
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<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>This proposal enables sending of funds without exposing users to the notion of payment addresses and their secure distribution. Instead, funds can be sent using any pre-existing communication channel, by a single message sent unidirectionally from the sender to the recipient. This message conveys all the information needed to obtain control of the funds, compactly expressed as a textual URI.</p>
|
||||
<p>Consequently, all functionality related to contact discovery and secure-channel establishment can be delegated to the message app(s) with which the user is already familiar, and in which the user has already established communication channels to many of their contacts.</p>
|
||||
<p>Moreover, funds can be sent to users who have not yet installed wallet software and who do not yet have a payment address. The recipient can collect the funds at any later time by installing suitable software.</p>
|
||||
|
|
@ -54,7 +53,7 @@ License: MIT</pre>
|
|||
<p>Finally, this avoids the fat-finger problem of sending funds to the wrong address. The user sends funds via a known contact on, e.g., WhatsApp, who they have a relationship with or at least can confirm the recipient's identity. Moreover, even once funds are sent via a URI, they can be recovered if the other party does not claim them.</p>
|
||||
<p>The proposal is complementary to ZIP 321 <a id="footnote-reference-6" class="footnote_reference" href="#zip-0321">4</a>, which will standardize <em>Payment Request URIs</em> using which the payment <em>recipient</em> can convey their persistent payment address to the <em>sender</em>, for subsequent fund transfers (to be done using the normal on-chain mechanism rather than the encapsulated payments described in the current proposal).</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal's specification of URI-Encapsulated Payments, and the intended protocols for using them, is meant to fulfill the following requirements:</p>
|
||||
<ul>
|
||||
<li>The protocol must not require the sender of a payment to stay online until the recipient receives the URI (let alone finalizes the payment).</li>
|
||||
|
|
@ -67,15 +66,15 @@ License: MIT</pre>
|
|||
<li>Don't lose funds, even if wallets crash, or everything but the sending wallet master secret is lost.</li>
|
||||
</ul>
|
||||
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<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>
|
||||
<ul>
|
||||
<li>It is outside the scope of this proposal to establish a secure communication channel for transmission of URI-Encapsulated Payments, or to protect the parties' devices from security compromise.</li>
|
||||
<li>Finalizing the payment may involve significant wait times, on the scale of minutes, as the requisite on-chain transactions are generated, mined and confirmed. This proposal does not try to solve this (though it does try to avoid imposing significant additional delays, and it does address how the intermediate state is conveyed to the user).</li>
|
||||
</ul>
|
||||
</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<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>
|
||||
<p>A Payment-Encapsulating URI represents the capability to claim the Zcash funds from specific on-chain transactions, as long as they're unspent. See <a href="#usage-story">Usage Story</a> for an example.</p>
|
||||
<section id="syntax"><h3><span class="section-heading">Syntax</span><span class="section-anchor"> <a rel="bookmark" href="#syntax"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="syntax"><h3><span class="section-heading">Syntax</span><span class="section-anchor"> <a rel="bookmark" href="#syntax"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Payment-Encapsulating URI is a Universal Resource Locator (URL), as defined in RFC 3986 <a id="footnote-reference-7" class="footnote_reference" href="#rfc3986">2</a>, of the following form.</p>
|
||||
<p>Scheme: <code>https</code></p>
|
||||
<p>Host: <code>pay.withzcash.com</code></p>
|
||||
|
|
@ -88,7 +87,7 @@ License: MIT</pre>
|
|||
<li><code>key=</code> is a 256-bit random number encoded with Bech32 as specified in Section 5.6.9 of the Zcash Protocol Specification <a id="footnote-reference-8" class="footnote_reference" href="#protocol">3</a>). MUST be present.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="semantics"><h3><span class="section-heading">Semantics</span><span class="section-anchor"> <a rel="bookmark" href="#semantics"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="semantics"><h3><span class="section-heading">Semantics</span><span class="section-anchor"> <a rel="bookmark" href="#semantics"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The values of <code>key</code> and <code>amount</code> deterministically imply a unique <em>payment note</em> corresponding to this URI, which is a Zcash Sapling note that carries the given amount and is spendable by a Sapling spending key derived from <code>key</code>. The derivation of this note is done by the following procedure:</p>
|
||||
<p><em>DerivePaymentNote(key,amount)</em>:</p>
|
||||
<ul>
|
||||
|
|
@ -120,7 +119,7 @@ License: MIT</pre>
|
|||
<p>The recipient's wallet software SHOULD convey to the user that the <code>desc</code> value is merely a claim made by the party who sent the URI, and may be tentative, inaccurate or malicious.</p>
|
||||
<p>In particular, the recipient's wallet software SHOULD convey to the user that the amount of ZEC they can successfully transfer to their wallet may be different than that given by the <code>amount</code> parameter, and may change (possibly to zero), until the finalization process has been completed.</p>
|
||||
</section>
|
||||
<section id="centralized-deployment"><h3><span class="section-heading">Centralized Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#centralized-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="centralized-deployment"><h3><span class="section-heading">Centralized Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#centralized-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The owner of the <code>withzcash.com</code> domain name MUST NOT create a DNS record for the <code>pay.withzcash.com</code> domain name, nor a TLS certificate for it. All feasible means SHOULD be taken to ensure this, and to prevent unintended transfer of ownership or control over the <code>withzcash.com</code> domain name. (See <a href="#rationale-for-uri-format">Rationale for URI Format</a> and <a href="#security-considerations">Security Considerations</a> below for discussion.)</p>
|
||||
<p><a href="#applink">Applink</a> mechanisms let domain name owners provide a whitelist, specifying which apps are authorized to handle URLs with that domain name. This is implemented by serving suitable files at well-known paths on the web server of that domain or, in the case of a subdomain, its parent domain. Thus, the owner of the <code>withzcash.com</code> domain effectively controls the whitelist of apps that may be launched by users' platform to handle URI-Encapsulated Payments (see <a href="#security-considerations">Security Considerations</a>). This whitelist should protect users from installing rogue apps that intercept incoming payments. Thus, the domain owner MUST do the following:</p>
|
||||
<ul>
|
||||
|
|
@ -137,17 +136,17 @@ License: MIT</pre>
|
|||
<li>Strive for the whitelist to include all apps that would not place the user at any greater security risk than reputable state-of-the-art wallet apps.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="testing"><h3><span class="section-heading">Testing</span><span class="section-anchor"> <a rel="bookmark" href="#testing"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="testing"><h3><span class="section-heading">Testing</span><span class="section-anchor"> <a rel="bookmark" href="#testing"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>For testing purposes, all of the above specification is duplicated for the Zcash testnet network, substituting <code>TAZ</code> (Zcash testnet coins) for <code>ZEC</code> and <code>testzcash.com</code> for <code>withzcash.com</code>.</p>
|
||||
<p>A separate “testnet whitelist” MUST be maintained by the owner of the <code>testzcash.com</code> domain name, with a separate policy that SHOULD allow any legitimate third-party developer to add their work-in-progress wallet for testing purposes. Integrity and availability MAY be looser.</p>
|
||||
<p>Wallets apps MAY support just one type of payments (ZEC or TAZ), and if they support both then they MUST keep separate accounting and must clearly distinguish the type when payments or balances are conveyed to users.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="lifecycle-specification"><h2><span class="section-heading">Lifecycle Specification</span><span class="section-anchor"> <a rel="bookmark" href="#lifecycle-specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="lifecycle-specification"><h2><span class="section-heading">Lifecycle Specification</span><span class="section-anchor"> <a rel="bookmark" href="#lifecycle-specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The lifecycle of a Payment-Encapsulating URI consists of several stages, which in the usual case culminate in the funds being irrevocably deposited into the recipient's personal wallet irrevocably:</p>
|
||||
<section id="generating-the-notes-and-uri"><h3><span class="section-heading">Generating the notes and URI</span><span class="section-anchor"> <a rel="bookmark" href="#generating-the-notes-and-uri"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="generating-the-notes-and-uri"><h3><span class="section-heading">Generating the notes and URI</span><span class="section-anchor"> <a rel="bookmark" href="#generating-the-notes-and-uri"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The sender's Zcash wallet app creates an ephemeral spending key, sends ZEC funds to the payment addressed derived from that key, and creates a Payment-Encapsulating URI that contains this ephemeral spending key and the newly-generated note commitments.</p>
|
||||
<section id="ephemeral-key-derivation"><h4><span class="section-heading">Ephemeral key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#ephemeral-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="ephemeral-key-derivation"><h4><span class="section-heading">Ephemeral key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#ephemeral-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The ephemeral keys within payment URIs are derived deterministically from the same seed as the main wallet. This ensures that if a wallet is recovered from backup, sent-but-unfinalized payments can be reclaimed.</p>
|
||||
<p>The derivation mechanism is as follows:</p>
|
||||
<ul>
|
||||
|
|
@ -160,17 +159,17 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="uri-transmission"><h3><span class="section-heading">URI Transmission</span><span class="section-anchor"> <a rel="bookmark" href="#uri-transmission"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="uri-transmission"><h3><span class="section-heading">URI Transmission</span><span class="section-anchor"> <a rel="bookmark" href="#uri-transmission"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The sender conveys the Payment-Encapsulating URI to the intended recipient, over some secure channel (e.g., an end-to-end encrypted messaging platform such as Signal, WhatsApp or Magic Wormhole; or a QR code scanned in person).</p>
|
||||
<p>If transmitted via a human-readable medium, such as a messaging app, the Payment-Encapsulating URI MAY be accompanied by a contextual explanation that the URI encapsulates a payment, and a suggested action by the recipient to complete the process (see Usage Story above for an example).</p>
|
||||
<p>When sent via a human-readable medium that consists of discrete messages, the message that contains the URI SHOULD NOT contain any payment-specific or manually-entered information outside the URI itself, since this information may not be visible to the recipient (see “Message Rendering” below).</p>
|
||||
<p>From this point, and until finalization or cancellation (see below), from the sender's perspective the payment is “in progress”; it SHOULD be conveyed as such to the sender; and MUST NOT be conveyed as “finalized” or other phrasing that conveys successful completion.</p>
|
||||
</section>
|
||||
<section id="message-rendering"><h3><span class="section-heading">Message Rendering</span><span class="section-anchor"> <a rel="bookmark" href="#message-rendering"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="message-rendering"><h3><span class="section-heading">Message Rendering</span><span class="section-anchor"> <a rel="bookmark" href="#message-rendering"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The recipient's device renders the Payment-Encapsulating URI, or an indication of its arrival, along with the aforementioned contextual explanation (if any). The user has the option of “opening” the URI (i.e., by clicking it), which results in the device opening a Zcash wallet app, using the local platforms app link mechanism.</p>
|
||||
<p>A messaging app MAY recognize URI-Encapsulated Payments, and render them in a way that conveys their nature more clearly than raw URI strings. If the messaging medium consists of discrete messages, and a message contains one or more URI-Encapsulated Payments, then the messaging app MAY assume that all other content in that message is automatically generated and contains no payment-specific or manually-generated information, and thus may be discarded during rendering.</p>
|
||||
</section>
|
||||
<section id="payment-rendering-and-blockchain-lookup"><h3><span class="section-heading">Payment Rendering and Blockchain Lookup</span><span class="section-anchor"> <a rel="bookmark" href="#payment-rendering-and-blockchain-lookup"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="payment-rendering-and-blockchain-lookup"><h3><span class="section-heading">Payment Rendering and Blockchain Lookup</span><span class="section-anchor"> <a rel="bookmark" href="#payment-rendering-and-blockchain-lookup"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The recipient's Zcash wallet app SHOULD present the payment amount and MAY present the description, as conveyed in the URI, along with an indication of the tentative nature of this information.</p>
|
||||
<p>In parallel, the wallet app SHOULD retrieve the relevant transactions from the Zcash blockchain, by looking up the transaction given by the <code>cmu</code> parameter (this MAY use an efficient index, perhaps assisted by a server), and check whether:</p>
|
||||
<ul>
|
||||
|
|
@ -187,22 +186,22 @@ License: MIT</pre>
|
|||
<p>Within the <em>Pending</em> state, the wallet app MAY also consider “0 confirmations” transactions (i.e., transactions that have been broadcast on the node network but are neither mined nor expired), and convey their existence to the user. These do not suffice for entering the <em>Ready-to-finalize</em> state (since unmined notes cannot be immediately spent.)</p>
|
||||
<p>The aforementioned conditions may change over time (e.g., the transactions may be spent by someone else in the interim), so the status SHOULD be updated periodically.</p>
|
||||
</section>
|
||||
<section id="finalization"><h3><span class="section-heading">Finalization</span><span class="section-anchor"> <a rel="bookmark" href="#finalization"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="finalization"><h3><span class="section-heading">Finalization</span><span class="section-anchor"> <a rel="bookmark" href="#finalization"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When the recipient chooses to finalize the payment, the wallet app generates transactions that spends the aforementioned notes (using the ephemeral spending key) and send these Zcash funds to the user's own persistent payment address. These transactions carry the default expiry time (currently 100 blocks).</p>
|
||||
<p>The recipient's wallet app SHOULD convey the payment status as “Finalizing…” starting at the time that the uses initiates the finalization process. It MAY in addition convey the specific action done or event waited.</p>
|
||||
<p>The sender's wallet SHOULD convey the payment status as “Finalizing…” as soon as it detects that relevant transactions have been broadcast on the peer-to-peer network, or mined to the blockchain.</p>
|
||||
<p>Once these transactions are confirmed (to an extent considered satisfactory by the local wallet app; currently 10 confirmations is common practice), their status SHOULD be conveyed as “Finalized”, by both the sender's wallet app and the recipient's wallet app. Both wallets MUST NOT convey the payment as “finalized”, or other phrasing that conveys irrevocability, until this point.</p>
|
||||
<p>If these transactions expire unmined, or are otherwise rendered irrevocably invalidated (e.g., by a rollback), then both wallets' status SHOULD convey this, and the recipient's wallet SHOULD revert to the “Payment Rendering and Blockchain Lookup” stage above.</p>
|
||||
</section>
|
||||
<section id="payment-cancellation"><h3><span class="section-heading">Payment Cancellation</span><span class="section-anchor"> <a rel="bookmark" href="#payment-cancellation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="payment-cancellation"><h3><span class="section-heading">Payment Cancellation</span><span class="section-anchor"> <a rel="bookmark" href="#payment-cancellation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>At any time prior to the payment being finalized, the sender is capable of cancelling the payment, by themselves finalizing the payment into their own wallet (thereby “clawing back” the funds). If the wallet has not yet sent, for inclusion in the blockchain, any of the transactions associated with the ephemeral spending key, then cancellation can also be done by discarding these transactions or aborting their generation. The sender's wallet app SHOULD offer this feature, and in this case, MUST appropriately handle the race condition where the recipient initiated finalization concurrently.</p>
|
||||
<p>Cancellation requires the sender to know the ephemeral spending key. If the sender has lost this state, it can be recovered deterministically (see <a href="#recovery-from-wallet-crash">Recovery From Wallet Crash</a>, below).</p>
|
||||
</section>
|
||||
<section id="status-view"><h3><span class="section-heading">Status View</span><span class="section-anchor"> <a rel="bookmark" href="#status-view"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="status-view"><h3><span class="section-heading">Status View</span><span class="section-anchor"> <a rel="bookmark" href="#status-view"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Wallet apps SHOULD let the user view the status of all payments they have generated, as well as all inbound payment (i.e., URI-Encapsulated Payments that have been sent to the app, e.g., by invocation from messaging apps). The status includes the available metadata, and the payment's current state. When pertinent, the wallet app SHOULD offer the ability to finalize any <em>Pending</em> inbound payment, and MAY offer the ability to cancel any outbound payment.</p>
|
||||
<p>Wallet apps SHOULD actively alert the user (e.g., via status notifications) if a payment that they sent has not been finalized within a reasonable time period (e.g., 1 week), and offer to cancel the payment.</p>
|
||||
</section>
|
||||
<section id="recovery-from-wallet-crash"><h3><span class="section-heading">Recovery From Wallet Crash</span><span class="section-anchor"> <a rel="bookmark" href="#recovery-from-wallet-crash"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="recovery-from-wallet-crash"><h3><span class="section-heading">Recovery From Wallet Crash</span><span class="section-anchor"> <a rel="bookmark" href="#recovery-from-wallet-crash"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When recovering from a backed-up wallet phrase, wallet implementations already need to scan the entire chain (from the wallet's birthday) to find transactions that were received by or sent from the wallet. Simultaneously with this, the wallet may recover state about previously-created payment URIs, and regain access to non-finalized funds.</p>
|
||||
<p>We define a “gap limit” <em>N</em>, similar to the “address gap limit” in BIP 44. If a wallet implementation observes <em>N</em> sequentially-derived payment URIs that have no corresponding on-chain note, they may safely expect that no payment URIs beyond that point have ever been derived.</p>
|
||||
<p>Given that both the derivation of a payment URI and the action of “filling” it with a note are performed by the same entity (and in most cases sequentially), it is unlikely that there would be a significantly large gap in payment URI usage. As a balance between the cost of scanning multiple <code>ivk</code>s, and the likelihood of missing on-chain funds due to out-of-order payment URI generation, we specify a standard gap limit of <code>N = 3</code>.</p>
|
||||
|
|
@ -223,7 +222,7 @@ License: MIT</pre>
|
|||
<p>For this recovery process to succeed, wallet implementations MUST fund payment URIs with a Sapling spending key in the wallet. Alternatively, wallet implementations MAY include the set of payment URI <code>ivk</code>s within the set of <code>ivk</code>s they are using for normal chain scanning, but this will slow down the recovery process by a factor of 4 (for a gap limit of <code>N = 3</code>, and a wallet with one Sapling account).</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="security-considerations"><h2><span class="section-heading">Security Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="security-considerations"><h2><span class="section-heading">Security Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Anyone who intercepts the URI-Encapsulated Payments may steal the encapsulated funds. Therefore, URI-Encapsulated Payments should be sent over a secure channel, and should be kept secret from anyone but the intended recipient.
|
||||
<ul>
|
||||
|
|
@ -245,8 +244,8 @@ License: MIT</pre>
|
|||
<li>Usage of URI-Encapsulated Payments may train users to, generally, click on other types of URI/URL links sent in other messaging contexts. Malicious links sent via unauthenticated messaging channels (e.g., emails and SMS texts) are a common attack vector, used for exploiting vulnerabilities in the apps triggered to handle these links. Even though the fault for vulnerabilities lies with those other apps, and even though this ZIP uses deep link URIs in the way intended, there are none the less these negative externalities to encouraging such use.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="design-decisions-and-rationale"><h2><span class="section-heading">Design Decisions and Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#design-decisions-and-rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale-for-uri-format"><h3><span class="section-heading">Rationale for URI Format</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-uri-format"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="design-decisions-and-rationale"><h2><span class="section-heading">Design Decisions and Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#design-decisions-and-rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="rationale-for-uri-format"><h3><span class="section-heading">Rationale for URI Format</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-uri-format"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The URI format <code>https://pay.withzcash.com:65536/v1#...</code> was chosen to allow automatic triggering of wallet software on mobile devices, using the platform's <a href="#applink">applink</a> mechanism, while minimizing the risk of payment information being intercepted by third parties. The latter is prevented by a defense in depth, where any of the following suffices to prevent the payment information from being exposed over the network:</p>
|
||||
<ul>
|
||||
<li>The <code>pay.withzcash.com</code> domain should not resolve.</li>
|
||||
|
|
@ -264,22 +263,24 @@ License: MIT</pre>
|
|||
</ol>
|
||||
<p>Another option, which can be added to any of the above, is to add a confirmation code outside the URI that needs to be manually entered by the user into the wallet app, so that merely intercepting the URI link would not suffice. This does not seem to significantly reduce risk in the scenarios considered, and so deemed to not justify the reduced usability.</p>
|
||||
</section>
|
||||
<section id="identifying-notes"><h3><span class="section-heading">Identifying Notes</span><span class="section-anchor"> <a rel="bookmark" href="#identifying-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="identifying-notes"><h3><span class="section-heading">Identifying Notes</span><span class="section-anchor"> <a rel="bookmark" href="#identifying-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The recipient's wallet needs to identify the notes related to the payment (and the on-chain transactions that contain them), in order to verify their validity and then (during the finalization process) spend them.</p>
|
||||
<p><strong>The following is out of date, and reflects an earlier design choice (“0”), while we have transitioned to a different choice (“4”). To be revised.</strong></p>
|
||||
<p>In the above description, we explicitly list the notes involved in the payment (which are easily mapped to the transactions containing them, using a suitable index). This results in long URIs when multiple notes are involved (e.g., when using the aforementioned “powers-of-2 amounts” technique).</p>
|
||||
<p>Instead, we can have the nodes be implicitly identified by the spending key (or similar) included in the URI. This can make URI shorter, thus less scary and less likely to run into length limits (consider SMS). The following alternatives are feasible:</p>
|
||||
<p>
|
||||
<span class="math">\(\hspace{0.9em}\)</span>
|
||||
0. Explicitly list the note commitments within the URI.</p>
|
||||
<ol type="1">
|
||||
<li>Explicitly list the note commitments within the URI.</li>
|
||||
<li>Include only the spending key(s) in the URI, and have the recipient scan the blockchain using the existing mechanism (trial decryption of the encrypted memo field). This is very slow, and risks denial-of-service attacks. Would be faster in the nominal case if the scanning is done backwards (newest block first), or if told by the sender when the transactions were mined; but scanning the whole chain for nonexistent transactions (perhaps induced by a DoS) would still take very long.</li>
|
||||
<li>Derive a tag from a seed included in the URI, and put this tag within the encrypted memo field of the output descriptors in the associated transactions. Put the tag plaintext within the space reserved for the memo field ciphertext (breaking the AEAD abstraction). The recipient's wallet (or the service assisting it) would maintain an index of such tags, and efficiently look up the tags derived from the URI. The tags are publicly-visible and thus may leak information on the payment amount (e.g., when using the powers-of-2 pre-generation technique).</li>
|
||||
<li>Similarly to the above, but place the tag in an additional zero-value output descriptor added to each pertinent transaction. The recipient can recompute this note commitment and use that as the identifier, to be looked up in an index in order to locate the transaction. Here too, the tags are publicly-visible and thus may leak information on the payment amount (e.g., when using the powers-of-2 pre-generation technique).</li>
|
||||
<li>Have the URI include a seed and the amount of the (single) output note. Let the seed determine not only the spending key, but also all randomness involved in the generation of the note. Thus, the recipient can deterministically derive the note commitment from the seed and amount, and look it up to find the relevant transaction. This requires the recipient (or the server assisting them) to maintain an index mapping note commitments (of output descriptors that are the first in their transaction) to the transaction that contains them. Additional notes can be included in the same transaction.</li>
|
||||
</ol>
|
||||
<div>
|
||||
<h1>System Message: INFO/1 (zip-0324.rst line 355)</h1>
|
||||
<p>Enumerated list start value not ordinal-1: "0" (ordinal 0)</p>
|
||||
</div>
|
||||
</section>
|
||||
<section id="additional-rationale"><h3><span class="section-heading">Additional rationale</span><span class="section-anchor"> <a rel="bookmark" href="#additional-rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="additional-rationale"><h3><span class="section-heading">Additional rationale</span><span class="section-anchor"> <a rel="bookmark" href="#additional-rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ol type="1">
|
||||
<li>The metadata (amount and description) is provided within the URI. An alternative would be to encode the description in the encrypted memo fields of the associated shielded transactions, and compute the amount from those transactions. However, in that case the metadata would not be available for presentation to the user until the transactions have been retrieved from the blockchain.</li>
|
||||
<li>We support multiple spending keys and multiple notes in one URI, because these payments may be speculatively generated and mined before the payment amount is determined (to allow payments with no latency). For example, the sending wallets may pre-generate transactions for powers-of-2 amounts, and then include only a subset of them in the URI, totalling to the desired amount.</li>
|
||||
|
|
@ -287,8 +288,8 @@ License: MIT</pre>
|
|||
</ol>
|
||||
</section>
|
||||
</section>
|
||||
<section id="open-questions"><h2><span class="section-heading">Open Questions</span><span class="section-anchor"> <a rel="bookmark" href="#open-questions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="uri-usability"><h3><span class="section-heading">URI Usability</span><span class="section-anchor"> <a rel="bookmark" href="#uri-usability"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="open-questions"><h2><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></h2>
|
||||
<section id="uri-usability"><h3><span class="section-heading">URI Usability</span><span class="section-anchor"> <a rel="bookmark" href="#uri-usability"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The URI could be changed in several ways due to usability concerns:</p>
|
||||
<ol type="1">
|
||||
<li>It may be desirable to prevent the <code>amount</code> and <code>desc</code> parameters from being human readable. This is to discourage people from just looking at the URI, seeing the numbers and text, and mistakenly thinking this is already a confirmation of successful receipt (without going through the finalization process).</li>
|
||||
|
|
@ -301,15 +302,15 @@ License: MIT</pre>
|
|||
</li>
|
||||
</ol>
|
||||
</section>
|
||||
<section id="note-retrieval"><h3><span class="section-heading">Note retrieval</span><span class="section-anchor"> <a rel="bookmark" href="#note-retrieval"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="note-retrieval"><h3><span class="section-heading">Note retrieval</span><span class="section-anchor"> <a rel="bookmark" href="#note-retrieval"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Ideally: a lightweight wallet can receive the funds with the assistance of a more powerful node, with minimal information leakage to that node (e.g., using simple lookups queries that can be implemented via Private Information Retrieval). The open question is how to do this given that most practical PIR are for retrieving an index out of an array, not a key from a key value standpoint.</p>
|
||||
</section>
|
||||
<section id="other-questions"><h3><span class="section-heading">Other Questions</span><span class="section-anchor"> <a rel="bookmark" href="#other-questions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="other-questions"><h3><span class="section-heading">Other Questions</span><span class="section-anchor"> <a rel="bookmark" href="#other-questions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Should senders delay admitting a generated transaction by a random amount to prevent traffic analysis (i.e., so the messaging service operator cannot correlate messages with on-chain transactions)?</p>
|
||||
<p>Consider the behavior in case a chain reorgs invalidates a sent payment. Should we specify a Merkle root or block hash to help detect this reason for payment failure? Or have some servers that maintain a cache of payments that were invalidated by reorgs?</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="bcp14" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
@ -375,7 +376,7 @@ License: MIT</pre>
|
|||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<section id="publication-blockers"><h2><span class="section-heading">Publication Blockers</span><span class="section-anchor"> <a rel="bookmark" href="#publication-blockers"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="publication-blockers"><h2><span class="section-heading">Publication Blockers</span><span class="section-anchor"> <a rel="bookmark" href="#publication-blockers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Clean up semantics.</li>
|
||||
<li>Clean up rationale.</li>
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<pre>ZIP: 332
|
||||
Title: Wallet Recovery from zcashd HD Seeds
|
||||
Owners: Kris Nuttycombe <kris@electriccoin.co>
|
||||
Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Wallet
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/675">https://github.com/zcash/zips/issues/675</a>></pre>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 339
|
||||
Title: Wallet Recovery Words
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Wallet
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/364">https://github.com/zcash/zips/issues/364</a>></pre>
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 401
|
||||
Title: Addressing Mempool Denial-of-Service
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Status: Active
|
||||
Category: Network
|
||||
Created: 2019-09-09
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
<section>
|
||||
<pre>ZIP: 416
|
||||
Title: Support for Unified Addresses in zcashd
|
||||
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||
Owners: Daira Emma Hopwood <daira@electriccoin.co>
|
||||
Jack Grigg <jack@electriccoin.co>
|
||||
Sean Bowe <sean@electriccoin.co>
|
||||
Kris Nuttycombe <kris@electriccoin.co>
|
||||
|
|
|
|||
|
|
@ -167,7 +167,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="https://zfnd.org/grants/">ZF Grants — Funding for Zcash ecosystem projects</a></td>
|
||||
<td><a href="https://grants.zfnd.org/">ZF Grants — Funding for Zcash ecosystem projects</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Original-Authors: Eran Tromer
|
|||
Credits: Matt Luongo
|
||||
@aristarchus
|
||||
@dontbeevil
|
||||
Daira-Emma Hopwood
|
||||
Daira Emma Hopwood
|
||||
George Tankersley
|
||||
Josh Cincinnati
|
||||
Andrew Miller
|
||||
|
|
|
|||
Loading…
Reference in New Issue