diff --git a/.github/actions/render-protocol-pdf/Dockerfile b/.github/actions/render-protocol-pdf/Dockerfile deleted file mode 120000 index dcbd8a2a1..000000000 --- a/.github/actions/render-protocol-pdf/Dockerfile +++ /dev/null @@ -1 +0,0 @@ -../../../Dockerfile \ No newline at end of file diff --git a/.github/actions/render-protocol-pdf/action.yml b/.github/actions/render-protocol-pdf/action.yml deleted file mode 100644 index 121bbfab0..000000000 --- a/.github/actions/render-protocol-pdf/action.yml +++ /dev/null @@ -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 diff --git a/.github/actions/render/action.yml b/.github/actions/render/action.yml new file mode 100644 index 000000000..2f58d4860 --- /dev/null +++ b/.github/actions/render/action.yml @@ -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 diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml new file mode 100644 index 000000000..75b2c1a6a --- /dev/null +++ b/.github/workflows/deploy.yml @@ -0,0 +1,42 @@ +# Simple workflow for deploying static content to GitHub Pages +name: Deploy pre-rendered static content to Pages + +on: + # Runs on pushes targeting the default branch + push: + branches: ["main"] + + # Allows you to run this workflow manually from the Actions tab + workflow_dispatch: + +# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages +permissions: + contents: read + pages: write + id-token: write + +# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. +# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. +concurrency: + group: "pages" + cancel-in-progress: false + +jobs: + # Single deploy job since we're just deploying + deploy: + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + - name: Setup Pages + uses: actions/configure-pages@v5 + - name: Upload artifact + uses: actions/upload-pages-artifact@v3 + with: + path: 'rendered' + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4 diff --git a/.github/workflows/render.yml b/.github/workflows/render.yml index c84e9432f..11fbb8ccc 100644 --- a/.github/workflows/render.yml +++ b/.github/workflows/render.yml @@ -1,19 +1,25 @@ -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.7 + with: + token: ${{ secrets.CI_TOKEN }} - - 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 + - uses: EndBug/add-and-commit@v9.1.4 with: - add: '**/*.pdf' + add: 'protocol/*.pdf *.html' default_author: github_actions diff --git a/.gitignore b/.gitignore index e8b7500bc..aa5d76d21 100644 --- a/.gitignore +++ b/.gitignore @@ -22,6 +22,7 @@ .Makefile.uptodate .zipfilelist.* +.draftfilelist.* protocol/aux/ protocol/html/ diff --git a/Dockerfile b/Dockerfile index c5e624c24..48fd6085e 100644 --- a/Dockerfile +++ b/Dockerfile @@ -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"] diff --git a/Makefile b/Makefile index e0bb8d493..660e2d7aa 100644 --- a/Makefile +++ b/Makefile @@ -2,11 +2,14 @@ .PHONY: all all-zips tag-release protocol discard all-zips: .Makefile.uptodate - find . -name 'zip-*.rst' -o -name 'zip-*.md' |sort >.zipfilelist.new + echo "$(patsubst zips/%,%,$(sort $(wildcard zips/zip-*.rst) $(wildcard zips/zip-*.md)))" >.zipfilelist.new diff .zipfilelist.current .zipfilelist.new || cp -f .zipfilelist.new .zipfilelist.current rm -f .zipfilelist.new + echo "$(patsubst zips/%,%,$(sort $(wildcard zips/draft-*.rst) $(wildcard zips/draft-*.md)))" >.draftfilelist.new + diff .draftfilelist.current .draftfilelist.new || cp -f .draftfilelist.new .draftfilelist.current + rm -f .draftfilelist.new $(MAKE) README.rst - $(MAKE) index.html $(addsuffix .html,$(filter-out README,$(basename $(sort $(wildcard *.rst) $(wildcard *.md))))) + $(MAKE) rendered/index.html $(addprefix rendered/,$(addsuffix .html,$(basename $(patsubst zips/%,%,$(sort $(wildcard zips/*.rst) $(wildcard zips/*.md)))))) all: all-zips protocol @@ -17,41 +20,41 @@ protocol: $(MAKE) -C protocol discard: - git checkout -- '*.html' 'README.rst' 'protocol/*.pdf' + git checkout -- 'rendered/*.html' 'README.rst' 'rendered/protocol/*.pdf' -.Makefile.uptodate: Makefile +.Makefile.uptodate: Makefile edithtml.sh $(MAKE) clean touch .Makefile.uptodate define PROCESSRST -$(eval TITLE := $(shell echo '$(basename $<)' | sed -E 's|zip-0{0,3}|ZIP |;s|draft-|Draft |')$(shell grep -E '^(\.\.)?\s*Title: ' $< |sed -E 's|.*Title||')) +$(eval TITLE := $(shell echo '$(patsubst zips/%,%,$(basename $<))' | sed -E 's|zip-0{0,3}|ZIP |;s|draft-|Draft |')$(shell grep -E '^(\.\.)?\s*Title: ' $< |sed -E 's|.*Title||')) rst2html5 -v --title="$(TITLE)" $< >$@ ./edithtml.sh --rst $@ endef define PROCESSMD -$(eval TITLE := $(shell echo '$(basename $<)' | sed -E 's|zip-0{0,3}|ZIP |;s|draft-|Draft |')$(shell grep -E '^(\.\.)?\s*Title: ' $< |sed -E 's|.*Title||')) +$(eval TITLE := $(shell echo '$(patsubst zips/%,%,$(basename $<))' | sed -E 's|zip-0{0,3}|ZIP |;s|draft-|Draft |')$(shell grep -E '^(\.\.)?\s*Title: ' $< |sed -E 's|.*Title||')) pandoc --from=markdown --to=html $< --output=$@ ./edithtml.sh --md $@ "${TITLE}" endef -index.html: README.rst edithtml.sh +rendered/index.html: README.rst edithtml.sh $(PROCESSRST) -%.html: %.rst edithtml.sh +rendered/%.html: zips/%.rst edithtml.sh $(PROCESSRST) -%.html: %.md edithtml.sh +rendered/%.html: zips/%.md edithtml.sh $(PROCESSMD) -README.rst: .zipfilelist.current makeindex.sh README.template $(sort $(wildcard zip-*.rst) $(wildcard zip-*.md)) +README.rst: .zipfilelist.current .draftfilelist.current makeindex.sh README.template $(wildcard zips/zip-*.rst) $(wildcard zips/zip-*.md) $(wildcard zips/draft-*.rst) $(wildcard zips/draft-*.md) ./makeindex.sh | cat README.template - >README.rst .PHONY: linkcheck linkcheck: all-zips $(MAKE) -C protocol all-specs - ./links_and_dests.py --check $(filter-out $(wildcard draft-*.html),$(wildcard *.html)) protocol/protocol.pdf protocol/canopy.pdf protocol/heartwood.pdf protocol/blossom.pdf protocol/sapling.pdf + ./links_and_dests.py --check $(filter-out $(wildcard rendered/draft-*.html),$(wildcard rendered/*.html)) rendered/protocol/protocol.pdf rendered/protocol/canopy.pdf rendered/protocol/heartwood.pdf rendered/protocol/blossom.pdf rendered/protocol/sapling.pdf .PHONY: clean clean: - rm -f .zipfilelist.* README.rst index.html $(addsuffix .html,$(basename $(sort $(wildcard *.rst) $(wildcard *.md)))) + rm -f .zipfilelist.* README.rst rendered/index.html $(addprefix rendered/,$(addsuffix .html,$(basename $(patsubst zips/%,%,$(sort $(wildcard zips/*.rst) $(wildcard zips/*.md)))))) diff --git a/README.rst b/README.rst index 292f69850..6a9101c99 100644 --- a/README.rst +++ b/README.rst @@ -26,39 +26,19 @@ to talk about your idea. Participation in the Zcash project is subject to a `Code of Conduct `__. -The Zcash protocol is documented in its `Protocol Specification `__. +The Zcash protocol is documented in its `Protocol Specification `__. -To start contributing, first read `ZIP 0 `__ which documents the ZIP process. +To start contributing, first read `ZIP 0 `__ which documents the ZIP process. Then clone `this repo `__ from GitHub, and start adding -your draft ZIP, formatted either as reStructuredText or as Markdown. +your draft ZIP, formatted either as reStructuredText or as Markdown, into the `zips/` directory. -For example, if using reStructuredText, use a filename matching ``draft-*.rst``. +For example, if using reStructuredText, use a filename matching ``zips/draft-*.rst``. Use ``make`` to check that you are using correct `reStructuredText `__ or `Markdown `__ syntax, -and double-check the generated ``draft-*.html`` file before filing a Pull Request. +and double-check the generated ``rendered/draft-*.html`` file before filing a Pull Request. See `here `__ for the project dependencies. -NU5 ZIPs --------- - -This is the list of ZIPs relevant to the NU5 Upgrade, which `activated on 31st May 2022 `__: - -- `ZIP 32: Shielded Hierarchical Deterministic Wallets `__ (updated) -- `ZIP 203: Transaction Expiry `__ (updated) -- `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances `__ (updated) -- `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext `__ (updated) -- `ZIP 213: Shielded Coinbase `__ (updated) -- `ZIP 216: Require Canonical Jubjub Point Encodings `__ -- `ZIP 221: FlyClient - Consensus-Layer Changes `__ (updated) -- `ZIP 224: Orchard Shielded Protocol `__ -- `ZIP 225: Version 5 Transaction Format `__ -- `ZIP 239: Relay of Version 5 Transactions `__ -- `ZIP 244: Transaction Identifier Non-Malleability `__ -- `ZIP 252: Deployment of the NU5 Network Upgrade `__ -- `ZIP 316: Unified Addresses and Unified Viewing Keys `__ -- `ZIP 401: Addressing Mempool Denial-of-Service `__ (clarified) - License ------- @@ -68,6 +48,158 @@ contents of this repository are released under the terms of the MIT license. See `COPYING `__ for more information or see https://opensource.org/licenses/MIT . +Released ZIPs +------------- + +.. raw:: html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZIP Title Status
0 ZIP Process Active
32 Shielded Hierarchical Deterministic Wallets Final
143 Transaction Signature Validation for Overwinter Final
155 addrv2 message Proposed
173 Bech32 Format Final
200 Network Upgrade Mechanism Final
201 Network Peer Management for Overwinter Final
202 Version 3 Transaction Format for Overwinter Final
203 Transaction Expiry Final
205 Deployment of the Sapling Network Upgrade Final
206 Deployment of the Blossom Network Upgrade Final
207 Funding Streams Final
208 Shorter Block Target Spacing Final
209 Prohibit Negative Shielded Chain Value Pool Balances Final
211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
213 Shielded Coinbase Final
214 Consensus rules for a Zcash Development Fund Final
215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
216 Require Canonical Jubjub Point Encodings Final
221 FlyClient - Consensus-Layer Changes Final
224 Orchard Shielded Protocol Final
225 Version 5 Transaction Format Final
239 Relay of Version 5 Transactions Final
243 Transaction Signature Validation for Sapling Final
244 Transaction Identifier Non-Malleability Final
250 Deployment of the Heartwood Network Upgrade Final
251 Deployment of the Canopy Network Upgrade Final
252 Deployment of the NU5 Network Upgrade Final
300 Cross-chain Atomic Transactions Proposed
301 Zcash Stratum Protocol Final
308 Sprout to Sapling Migration Final
316 Unified Addresses and Unified Viewing Keys Revision 0: Final, Revision 1: Proposed
317 Proportional Transfer Fee Mechanism Active
320 Defining an Address Type to which funds can only be sent from Transparent Addresses Proposed
321 Payment Request URIs Proposed
401 Addressing Mempool Denial-of-Service Active
1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
+ +Draft ZIPs +---------- + +These are works-in-progress that have been assigned ZIP numbers. These will +eventually become either Proposed (and thus Released), or one of Withdrawn, +Rejected, or Obsolete. + +In some cases a ZIP number is reserved by the ZIP Editors before a draft is +written. + +.. raw:: html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZIP Title Status
1 Network Upgrade Policy and Scheduling Reserved
2 Design Considerations for Network Upgrades Reserved
68 Relative lock-time using consensus-enforced sequence numbers Draft
76 Transaction Signature Validation before Overwinter Reserved
112 CHECKSEQUENCEVERIFY Draft
113 Median Time Past as endpoint for lock-time calculations Draft
204 Zcash P2P Network Protocol Reserved
217 Aggregate Signatures Reserved
219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
222 Transparent Zcash Extensions Draft
226 Transfer and Burn of Zcash Shielded Assets Draft
227 Issuance of Zcash Shielded Assets Draft
228 Asset Swaps for Zcash Shielded Assets Reserved
230 Version 6 Transaction Format Draft
231 Decouple Memos from Transaction Outputs Reserved
236 Blocks should balance exactly Draft
245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
253 Deployment of the NU6 Network Upgrade Draft
302 Standardized Memo Field Format Draft
303 Sprout Payment Disclosure Reserved
304 Sapling Address Signatures Draft
305 Best Practices for Hardware Wallets supporting Sapling Reserved
306 Security Considerations for Anchor Selection Reserved
307 Light Client Protocol for Payment Detection Draft
309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
310 Security Properties of Sapling Viewing Keys Draft
311 Zcash Payment Disclosures Draft
312 FROST for Spend Authorization Multisignatures Draft
314 Privacy upgrades to the Zcash light client protocol Reserved
315 Best Practices for Wallet Implementations Draft
318 Associated Payload Encryption Reserved
319 Options for Shielded Pool Retirement Reserved
322 Generic Signed Message Format Reserved
323 Specification of getblocktemplate for Zcash Reserved
324 URI-Encapsulated Payments Draft
332 Wallet Recovery from zcashd HD Seeds Reserved
339 Wallet Recovery Words Reserved
400 Wallet.dat format Draft
402 New Wallet Database Format Reserved
403 Verification Behaviour of zcashd Reserved
416 Support for Unified Addresses in zcashd Reserved
2001 Lockbox Funding Streams Draft
guide-markdown {Something Short and To the Point} Draft
guide {Something Short and To the Point} Draft
+ +Drafts without assigned ZIP numbers +----------------------------------- + +These are works-in-progress, and may never be assigned ZIP numbers if their +ideas become obsoleted or abandoned. Do not assume that these drafts will exist +in perpetuity; instead assume that they will either move to a numbered ZIP, or +be deleted. + +.. raw:: html + + + + + + +
Title
Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
Block Reward Allocation for Non-Direct Development Funding
Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
+ +Withdrawn, Rejected, or Obsolete ZIPs +------------------------------------- + +.. raw:: html + +
+ Click to show/hide + + + + + + + + + + + + + + + + + + +
ZIP Title Status
210 Sapling Anchor Deduplication within Transactions Withdrawn
220 Zcash Shielded Assets Withdrawn
313 Reduce Conventional Transaction Fee to 1000 zatoshis Obsolete
1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
1002 Opt-in Donation Feature Obsolete
1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
1004 Miner-Directed Dev Fund Obsolete
1005 Zcash Community Funding System Obsolete
1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
1008 Fund ECC for Two More Years Obsolete
1009 Five-Entity Strategic Council Obsolete
1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
1011 Decentralize the Dev Fee Obsolete
1012 Dev Fund to ECC + ZF + Major Grants Obsolete
1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
+
+ Index of ZIPs ------------- @@ -75,94 +207,102 @@ Index of ZIPs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZIP Title Status
0 ZIP Process Active
1 Network Upgrade Policy and Scheduling Reserved
2 Design Considerations for Network Upgrades Reserved
32 Shielded Hierarchical Deterministic Wallets Final
76 Transaction Signature Validation before Overwinter Reserved
143 Transaction Signature Validation for Overwinter Final
155 addrv2 message Proposed
173 Bech32 Format Final
200 Network Upgrade Mechanism Final
201 Network Peer Management for Overwinter Final
202 Version 3 Transaction Format for Overwinter Final
203 Transaction Expiry Final
204 Zcash P2P Network Protocol Reserved
205 Deployment of the Sapling Network Upgrade Final
206 Deployment of the Blossom Network Upgrade Final
207 Funding Streams Final
208 Shorter Block Target Spacing Final
209 Prohibit Negative Shielded Chain Value Pool Balances Final
210 Sapling Anchor Deduplication within Transactions Withdrawn
211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
213 Shielded Coinbase Final
214 Consensus rules for a Zcash Development Fund Final
215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
216 Require Canonical Jubjub Point Encodings Final
217 Aggregate Signatures Reserved
219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
220 Zcash Shielded Assets Withdrawn
221 FlyClient - Consensus-Layer Changes Final
222 Transparent Zcash Extensions Draft
224 Orchard Shielded Protocol Final
225 Version 5 Transaction Format Final
226 Transfer and Burn of Zcash Shielded Assets Draft
227 Issuance of Zcash Shielded Assets Draft
228 Asset Swaps for Zcash Shielded Assets Reserved
230 Version 6 Transaction Format Draft
231 Decouple Memos from Transaction Outputs Reserved
239 Relay of Version 5 Transactions Final
243 Transaction Signature Validation for Sapling Final
244 Transaction Identifier Non-Malleability Final
245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
250 Deployment of the Heartwood Network Upgrade Final
251 Deployment of the Canopy Network Upgrade Final
252 Deployment of the NU5 Network Upgrade Final
300 Cross-chain Atomic Transactions Proposed
301 Zcash Stratum Protocol Final
302 Standardized Memo Field Format Draft
303 Sprout Payment Disclosure Reserved
304 Sapling Address Signatures Draft
305 Best Practices for Hardware Wallets supporting Sapling Reserved
306 Security Considerations for Anchor Selection Reserved
307 Light Client Protocol for Payment Detection Draft
308 Sprout to Sapling Migration Final
309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
310 Security Properties of Sapling Viewing Keys Draft
311 Sapling Payment Disclosure Reserved
312 Shielded Multisignatures using FROST Reserved
313 Reduce Conventional Transaction Fee to 1000 zatoshis Obsolete
314 Privacy upgrades to the Zcash light client protocol Reserved
315 Best Practices for Wallet Handling of Multiple Pools Reserved
316 Unified Addresses and Unified Viewing Keys Final
317 Proportional Transfer Fee Mechanism Active
318 Associated Payload Encryption Reserved
319 Options for Shielded Pool Retirement Reserved
320 Defining an Address Type to which funds can only be sent from Transparent Addresses Draft
321 Payment Request URIs Proposed
322 Generic Signed Message Format Reserved
323 Specification of getblocktemplate for Zcash Reserved
332 Wallet Recovery from zcashd HD Seeds Reserved
339 Wallet Recovery Words Reserved
400 Wallet.dat format Draft
401 Addressing Mempool Denial-of-Service Active
402 New Wallet Database Format Reserved
403 Verification Behaviour of zcashd Reserved
416 Support for Unified Addresses in zcashd Reserved
1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
1002 Opt-in Donation Feature Obsolete
1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
1004 Miner-Directed Dev Fund Obsolete
1005 Zcash Community Funding System Obsolete
1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
1008 Fund ECC for Two More Years Obsolete
1009 Five-Entity Strategic Council Obsolete
1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
1011 Decentralize the Dev Fee Obsolete
1012 Dev Fund to ECC + ZF + Major Grants Obsolete
1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
guide {Something Short and To the Point} Draft
0 ZIP Process Active
1 Network Upgrade Policy and Scheduling Reserved
2 Design Considerations for Network Upgrades Reserved
32 Shielded Hierarchical Deterministic Wallets Final
68 Relative lock-time using consensus-enforced sequence numbers Draft
76 Transaction Signature Validation before Overwinter Reserved
112 CHECKSEQUENCEVERIFY Draft
113 Median Time Past as endpoint for lock-time calculations Draft
143 Transaction Signature Validation for Overwinter Final
155 addrv2 message Proposed
173 Bech32 Format Final
200 Network Upgrade Mechanism Final
201 Network Peer Management for Overwinter Final
202 Version 3 Transaction Format for Overwinter Final
203 Transaction Expiry Final
204 Zcash P2P Network Protocol Reserved
205 Deployment of the Sapling Network Upgrade Final
206 Deployment of the Blossom Network Upgrade Final
207 Funding Streams Final
208 Shorter Block Target Spacing Final
209 Prohibit Negative Shielded Chain Value Pool Balances Final
210 Sapling Anchor Deduplication within Transactions Withdrawn
211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
213 Shielded Coinbase Final
214 Consensus rules for a Zcash Development Fund Final
215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
216 Require Canonical Jubjub Point Encodings Final
217 Aggregate Signatures Reserved
219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
220 Zcash Shielded Assets Withdrawn
221 FlyClient - Consensus-Layer Changes Final
222 Transparent Zcash Extensions Draft
224 Orchard Shielded Protocol Final
225 Version 5 Transaction Format Final
226 Transfer and Burn of Zcash Shielded Assets Draft
227 Issuance of Zcash Shielded Assets Draft
228 Asset Swaps for Zcash Shielded Assets Reserved
230 Version 6 Transaction Format Draft
231 Decouple Memos from Transaction Outputs Reserved
236 Blocks should balance exactly Draft
239 Relay of Version 5 Transactions Final
243 Transaction Signature Validation for Sapling Final
244 Transaction Identifier Non-Malleability Final
245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
250 Deployment of the Heartwood Network Upgrade Final
251 Deployment of the Canopy Network Upgrade Final
252 Deployment of the NU5 Network Upgrade Final
253 Deployment of the NU6 Network Upgrade Draft
300 Cross-chain Atomic Transactions Proposed
301 Zcash Stratum Protocol Final
302 Standardized Memo Field Format Draft
303 Sprout Payment Disclosure Reserved
304 Sapling Address Signatures Draft
305 Best Practices for Hardware Wallets supporting Sapling Reserved
306 Security Considerations for Anchor Selection Reserved
307 Light Client Protocol for Payment Detection Draft
308 Sprout to Sapling Migration Final
309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
310 Security Properties of Sapling Viewing Keys Draft
311 Zcash Payment Disclosures Draft
312 FROST for Spend Authorization Multisignatures Draft
313 Reduce Conventional Transaction Fee to 1000 zatoshis Obsolete
314 Privacy upgrades to the Zcash light client protocol Reserved
315 Best Practices for Wallet Implementations Draft
316 Unified Addresses and Unified Viewing Keys Revision 0: Final, Revision 1: Proposed
317 Proportional Transfer Fee Mechanism Active
318 Associated Payload Encryption Reserved
319 Options for Shielded Pool Retirement Reserved
320 Defining an Address Type to which funds can only be sent from Transparent Addresses Proposed
321 Payment Request URIs Proposed
322 Generic Signed Message Format Reserved
323 Specification of getblocktemplate for Zcash Reserved
324 URI-Encapsulated Payments Draft
332 Wallet Recovery from zcashd HD Seeds Reserved
339 Wallet Recovery Words Reserved
400 Wallet.dat format Draft
401 Addressing Mempool Denial-of-Service Active
402 New Wallet Database Format Reserved
403 Verification Behaviour of zcashd Reserved
416 Support for Unified Addresses in zcashd Reserved
1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
1002 Opt-in Donation Feature Obsolete
1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
1004 Miner-Directed Dev Fund Obsolete
1005 Zcash Community Funding System Obsolete
1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
1008 Fund ECC for Two More Years Obsolete
1009 Five-Entity Strategic Council Obsolete
1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
1011 Decentralize the Dev Fee Obsolete
1012 Dev Fund to ECC + ZF + Major Grants Obsolete
1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
2001 Lockbox Funding Streams Draft
guide-markdown {Something Short and To the Point} Draft
guide {Something Short and To the Point} Draft
diff --git a/README.template b/README.template index f838ffac0..2c6f9219a 100644 --- a/README.template +++ b/README.template @@ -26,39 +26,19 @@ to talk about your idea. Participation in the Zcash project is subject to a `Code of Conduct `__. -The Zcash protocol is documented in its `Protocol Specification `__. +The Zcash protocol is documented in its `Protocol Specification `__. -To start contributing, first read `ZIP 0 `__ which documents the ZIP process. +To start contributing, first read `ZIP 0 `__ which documents the ZIP process. Then clone `this repo `__ from GitHub, and start adding -your draft ZIP, formatted either as reStructuredText or as Markdown. +your draft ZIP, formatted either as reStructuredText or as Markdown, into the `zips/` directory. -For example, if using reStructuredText, use a filename matching ``draft-*.rst``. +For example, if using reStructuredText, use a filename matching ``zips/draft-*.rst``. Use ``make`` to check that you are using correct `reStructuredText `__ or `Markdown `__ syntax, -and double-check the generated ``draft-*.html`` file before filing a Pull Request. +and double-check the generated ``rendered/draft-*.html`` file before filing a Pull Request. See `here `__ for the project dependencies. -NU5 ZIPs --------- - -This is the list of ZIPs relevant to the NU5 Upgrade, which `activated on 31st May 2022 `__: - -- `ZIP 32: Shielded Hierarchical Deterministic Wallets `__ (updated) -- `ZIP 203: Transaction Expiry `__ (updated) -- `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances `__ (updated) -- `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext `__ (updated) -- `ZIP 213: Shielded Coinbase `__ (updated) -- `ZIP 216: Require Canonical Jubjub Point Encodings `__ -- `ZIP 221: FlyClient - Consensus-Layer Changes `__ (updated) -- `ZIP 224: Orchard Shielded Protocol `__ -- `ZIP 225: Version 5 Transaction Format `__ -- `ZIP 239: Relay of Version 5 Transactions `__ -- `ZIP 244: Transaction Identifier Non-Malleability `__ -- `ZIP 252: Deployment of the NU5 Network Upgrade `__ -- `ZIP 316: Unified Addresses and Unified Viewing Keys `__ -- `ZIP 401: Addressing Mempool Denial-of-Service `__ (clarified) - License ------- diff --git a/_config.yml b/_config.yml deleted file mode 100644 index 0bacc557a..000000000 --- a/_config.yml +++ /dev/null @@ -1,3 +0,0 @@ -theme: jekyll-theme-tactile -url: "https://zips.z.cash" -markdown: GFM diff --git a/edithtml.sh b/edithtml.sh index 5a76dd2eb..27c11943d 100755 --- a/edithtml.sh +++ b/edithtml.sh @@ -34,8 +34,13 @@ EOF fi sed -i.sedbak 's|||g' "$2" +sed -i.sedbak 's|||g' "$2" sed -i.sedbak 's|<\(https:[^&]*\)>|\<\1\>|g' "$2" +sed -i.sedbak 's|src="../rendered/|src="|g' "$2" +sed -i.sedbak 's|\s*.?\s*([^<]*(?:[^<]*[^<]*)?)|
\3 |g' "$2" -rm -f *.sedbak +rm -f rendered/*.sedbak diff --git a/index.html b/index.html deleted file mode 100644 index f2f0bafe0..000000000 --- a/index.html +++ /dev/null @@ -1,145 +0,0 @@ - - - - README: Specifications and Zcash Improvement Proposals - - - -
- -

What are ZIPs?

-

Zcash Improvement Proposals (ZIPs) are the way to:

-
    -
  • propose new features for the Zcash cryptocurrency and their rationale,
    • -
  • specify the implementation details of the feature,
    • -
  • collect community input on the proposal, and
    • -
  • document design decisions.
    • -
-
-

Contributing

-

The authors of a ZIP are responsible for building consensus within the community and documenting / addressing dissenting opinions.

-

Anyone can write a ZIP! We encourage community contributions and decentralization of work on the Zcash protocol. If you’d like to bounce ideas off people before formally writing a ZIP, we encourage it! Visit the ZcashCommunity Discord chat to talk about your idea.

-

Participation in the Zcash project is subject to a Code of Conduct.

-

The Zcash protocol is documented in its Protocol Specification.

-

To start contributing, first read ZIP 0 which documents the ZIP process. Then clone this repo from GitHub, and start adding your draft ZIP, formatted either as reStructuredText or as Markdown.

-

For example, if using reStructuredText, use a filename matching draft-*.rst. Use make to check that you are using correct reStructuredText or Markdown syntax, and double-check the generated draft-*.html file before filing a Pull Request. See here for the project dependencies.

-
-

NU5 ZIPs

-

This is the list of ZIPs relevant to the NU5 Upgrade, which activated on 31st May 2022:

- -
-

License

-

Unless otherwise stated in this repository’s individual files, the contents of this repository are released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT .

-
-

Index of ZIPs

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ZIP Title Status
0 ZIP Process Active
1 Network Upgrade Policy and Scheduling Reserved
2 Design Considerations for Network Upgrades Reserved
32 Shielded Hierarchical Deterministic Wallets Final
76 Transaction Signature Validation before Overwinter Reserved
143 Transaction Signature Validation for Overwinter Final
155 addrv2 message Proposed
173 Bech32 Format Final
200 Network Upgrade Mechanism Final
201 Network Peer Management for Overwinter Final
202 Version 3 Transaction Format for Overwinter Final
203 Transaction Expiry Final
204 Zcash P2P Network Protocol Reserved
205 Deployment of the Sapling Network Upgrade Final
206 Deployment of the Blossom Network Upgrade Final
207 Funding Streams Final
208 Shorter Block Target Spacing Final
209 Prohibit Negative Shielded Chain Value Pool Balances Final
210 Sapling Anchor Deduplication within Transactions Withdrawn
211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
213 Shielded Coinbase Final
214 Consensus rules for a Zcash Development Fund Final
215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
216 Require Canonical Jubjub Point Encodings Final
217 Aggregate Signatures Reserved
219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
220 Zcash Shielded Assets Withdrawn
221 FlyClient - Consensus-Layer Changes Final
222 Transparent Zcash Extensions Draft
224 Orchard Shielded Protocol Final
225 Version 5 Transaction Format Final
226 Transfer and Burn of Zcash Shielded Assets Draft
227 Issuance of Zcash Shielded Assets Draft
228 Asset Swaps for Zcash Shielded Assets Reserved
230 Version 6 Transaction Format Draft
231 Decouple Memos from Transaction Outputs Reserved
239 Relay of Version 5 Transactions Final
243 Transaction Signature Validation for Sapling Final
244 Transaction Identifier Non-Malleability Final
245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
250 Deployment of the Heartwood Network Upgrade Final
251 Deployment of the Canopy Network Upgrade Final
252 Deployment of the NU5 Network Upgrade Final
300 Cross-chain Atomic Transactions Proposed
301 Zcash Stratum Protocol Final
302 Standardized Memo Field Format Draft
303 Sprout Payment Disclosure Reserved
304 Sapling Address Signatures Draft
305 Best Practices for Hardware Wallets supporting Sapling Reserved
306 Security Considerations for Anchor Selection Reserved
307 Light Client Protocol for Payment Detection Draft
308 Sprout to Sapling Migration Final
309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
310 Security Properties of Sapling Viewing Keys Draft
311 Sapling Payment Disclosure Reserved
312 Shielded Multisignatures using FROST Reserved
313 Reduce Conventional Transaction Fee to 1000 zatoshis Obsolete
314 Privacy upgrades to the Zcash light client protocol Reserved
315 Best Practices for Wallet Handling of Multiple Pools Reserved
316 Unified Addresses and Unified Viewing Keys Final
317 Proportional Transfer Fee Mechanism Active
318 Associated Payload Encryption Reserved
319 Options for Shielded Pool Retirement Reserved
320 Defining an Address Type to which funds can only be sent from Transparent Addresses Draft
321 Payment Request URIs Proposed
322 Generic Signed Message Format Reserved
323 Specification of getblocktemplate for Zcash Reserved
332 Wallet Recovery from zcashd HD Seeds Reserved
339 Wallet Recovery Words Reserved
400 Wallet.dat format Draft
401 Addressing Mempool Denial-of-Service Active
402 New Wallet Database Format Reserved
403 Verification Behaviour of zcashd Reserved
416 Support for Unified Addresses in zcashd Reserved
1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
1002 Opt-in Donation Feature Obsolete
1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
1004 Miner-Directed Dev Fund Obsolete
1005 Zcash Community Funding System Obsolete
1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
1008 Fund ECC for Two More Years Obsolete
1009 Five-Entity Strategic Council Obsolete
1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
1011 Decentralize the Dev Fee Obsolete
1012 Dev Fund to ECC + ZF + Major Grants Obsolete
1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
guide {Something Short and To the Point} Draft
-
- - \ No newline at end of file diff --git a/makeindex.sh b/makeindex.sh index cf234da5b..92c61ea58 100755 --- a/makeindex.sh +++ b/makeindex.sh @@ -2,7 +2,7 @@ cat < EndOfHeader -for zipfile in zip-*.rst; do +for zipfile in $(cat .zipfilelist.current); do + zipfile=zips/$zipfile + if grep -E '^\s*Status:\s*(Reserved|Draft|Withdrawn|Rejected|Obsolete)' $zipfile >/dev/null; then + # Handled below. + true + else + echo Adding $zipfile to released index. >/dev/stderr + echo " " + fi +done +cat < + +Draft ZIPs +---------- + +These are works-in-progress that have been assigned ZIP numbers. These will +eventually become either Proposed (and thus Released), or one of Withdrawn, +Rejected, or Obsolete. + +In some cases a ZIP number is reserved by the ZIP Editors before a draft is +written. + +.. raw:: html + +
ZIP Title Status
`basename $(basename $zipfile .rst) .md | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
+ +EndOfDraftZipHeader +for zipfile in $(cat .zipfilelist.current); do + zipfile=zips/$zipfile + if grep -E '^\s*Status:\s*Reserved' $zipfile >/dev/null; then + echo Adding $zipfile to draft index. >/dev/stderr + echo " " + elif grep -E '^\s*Status:\s*Draft' $zipfile >/dev/null; then + echo Adding $zipfile to draft index. >/dev/stderr + echo " " + fi +done +echo "
ZIP Title Status
`basename $(basename $zipfile .rst) .md | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
`basename $(basename $zipfile .rst) .md | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
" + +if [ $(wc -c <.draftfilelist.current) -gt 1 ] +then + cat < + +EndOfDraftHeader + for draftfile in $(cat .draftfilelist.current); do + draftfile=zips/$draftfile + echo Adding $draftfile to index of drafts. >/dev/stderr + echo " " + done + echo "
Title
`grep '^\s*Title:' $draftfile | sed -E 's@\s*Title:\s*@@'`
" +fi + +cat < + Click to show/hide + + +EndOfStrikeHeader +for zipfile in $(cat .zipfilelist.current); do + zipfile=zips/$zipfile + if grep -E '^\s*Status:\s*(Withdrawn|Rejected|Obsolete)' $zipfile >/dev/null; then + echo Adding $zipfile to struck index. >/dev/stderr + echo " " + fi +done + +cat < + + +Index of ZIPs +------------- + +.. raw:: html + +
ZIP Title Status
`basename $(basename $zipfile .rst) .md | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
+ +EndOfIndexHeader +for zipfile in $(cat .zipfilelist.current); do + zipfile=zips/$zipfile echo Adding $zipfile to index. >/dev/stderr if grep -E '^\s*Status:\s*Reserved' $zipfile >/dev/null; then - echo " " + echo " " elif grep -E '^\s*Status:\s*(Withdrawn|Rejected|Obsolete)' $zipfile >/dev/null; then - echo " " + echo " " else - echo " " + echo " " fi done echo "
ZIP Title Status
`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
`basename $(basename $zipfile .rst) .md | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
`basename $(basename $zipfile .rst) .md | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
`basename $(basename $zipfile .rst) .md | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`
" diff --git a/protocol/Makefile b/protocol/Makefile index e252f681f..72b82bdab 100644 --- a/protocol/Makefile +++ b/protocol/Makefile @@ -15,6 +15,8 @@ LATEXMK=max_print_line=10000 latexmk $(LATEXMKOPT_$(ENGINE)) --halt-on-error --f LATEX=$(ENGINE) --halt-on-error --file-line-error NOCRUFT?=|perl -pe 's|[{\<\(]\/[^ ]* ?||g;s|^.* has been referenced but does not exist.*||g;s|^\n||g' +PDFDIR=../rendered/protocol + # Use EXTRAOPT=-pvc for "continuous preview" mode. For example, "make auxblossom EXTRAOPT=-pvc". # In this case the updated .pdf will be in the aux/ directory. @@ -23,7 +25,7 @@ all: .Makefile.uptodate $(MAKE) nu5 canopy heartwood blossom sapling all-specs: .Makefile.uptodate - $(MAKE) nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf + $(MAKE) $(PDFDIR)/nu5.pdf $(PDFDIR)/canopy.pdf $(PDFDIR)/heartwood.pdf $(PDFDIR)/blossom.pdf $(PDFDIR)/sapling.pdf tag-release: ifeq ($(shell git tag --points-at HEAD |wc -l),0) @@ -33,31 +35,31 @@ else git fetch origin git merge-base --is-ancestor origin/main HEAD || (echo "The current branch is dirty and/or not up-to-date with origin's main branch."; false) $(MAKE) clean all - git add *.pdf - git commit -m "Regenerate PDFs." *.pdf + git add $(PDFDIR)/*.pdf + git commit -m "Regenerate PDFs." $(PDFDIR)/*.pdf git tag "v$(TAG)" endif discard: - git checkout -- '*.pdf' + git checkout -- "$(PDFDIR)/*.pdf" .Makefile.uptodate: Makefile $(MAKE) clean touch .Makefile.uptodate -sapling.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/sapling.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png $(MAKE) sapling -blossom.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/blossom.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png $(MAKE) blossom -heartwood.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/heartwood.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png $(MAKE) heartwood -canopy.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/canopy.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png $(MAKE) canopy -nu5.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/nu5.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png $(MAKE) nu5 .PHONY: auxsapling @@ -71,7 +73,7 @@ auxsapling: .PHONY: sapling sapling: $(MAKE) auxsapling - mv -f aux/sapling.pdf . + mv -f aux/sapling.pdf $(PDFDIR) .PHONY: auxblossom auxblossom: @@ -84,7 +86,7 @@ auxblossom: .PHONY: blossom blossom: $(MAKE) auxblossom - mv -f aux/blossom.pdf . + mv -f aux/blossom.pdf $(PDFDIR) .PHONY: auxheartwood auxheartwood: @@ -97,7 +99,7 @@ auxheartwood: .PHONY: heartwood heartwood: $(MAKE) auxheartwood - mv -f aux/heartwood.pdf . + mv -f aux/heartwood.pdf $(PDFDIR) .PHONY: auxcanopy auxcanopy: @@ -110,7 +112,7 @@ auxcanopy: .PHONY: canopy canopy: $(MAKE) auxcanopy - mv -f aux/canopy.pdf . + mv -f aux/canopy.pdf $(PDFDIR) .PHONY: auxnu5 auxnu5: @@ -123,8 +125,8 @@ auxnu5: .PHONY: nu5 nu5: $(MAKE) auxnu5 - mv -f aux/nu5.pdf . - cp -f nu5.pdf protocol.pdf + mv -f aux/nu5.pdf $(PDFDIR) + cp -f $(PDFDIR)/nu5.pdf $(PDFDIR)/protocol.pdf .PHONY: nolatexmk-sapling nolatexmk-sapling: @@ -189,4 +191,4 @@ nolatexmk-nu5: .PHONY: clean clean: - rm -f aux/* html/* protocol.ver protocol.pdf nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf + rm -f aux/* html/* protocol.ver $(PDFDIR)/protocol.pdf $(PDFDIR)/nu5.pdf $(PDFDIR)/canopy.pdf $(PDFDIR)/heartwood.pdf $(PDFDIR)/blossom.pdf $(PDFDIR)/sapling.pdf diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 8beb82882..53f3a283e 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -38,7 +38,7 @@ \usepackage[nobottomtitles,explicit]{titlesec} \usepackage[hang]{footmisc} \usepackage{xstring} -\usepackage[usenames,dvipsnames]{xcolor} +\usepackage[dvipsnames]{xcolor} \usepackage{etoolbox} \usepackage{subdepth} \usepackage{fix-cm} @@ -59,6 +59,14 @@ % \newcommand{\increment}[1]{\the\numexpr #1+1\relax} +% Shortcut for \nohyphens from hyphenat. +\newcommand{\nh}[1]{\nohyphens{#1}} + +% \nh doesn't work in the bibliography. +% +\makeatletter +\newcommand*\nbh{\hbox{-}\nobreak\hskip\z@skip} +\makeatother % The destlabel option creates "destination names" in the PDF, which allows % linking to sections in URL fragments when viewing the PDF in a web browser: @@ -335,7 +343,7 @@ \newcommand{\addparttocontents}[1]{\phantomsection\addcontentsline{toc}{section}{\larger{#1}}} \newcommand{\phantompart}[2]{\def\sectionlabel{#2} \addparttocontents{#1}\label{#2}} -\newcommand{\lpart}[2]{\def\sectionlabel{#2} \intropart\vspace{20ex}\addparttocontents{#1}\section*{#1}\label{#2}} +\newcommand{\lpart}[2]{\def\sectionlabel{#2} \intropart\vspace{20ex}\addparttocontents{#1}\section*{\nh{#1}}\label{#2}} \newcommand{\lsection}[2]{\def\sectionlabel{#2} \section{#1}\label{#2}} \newcommand{\lsubsection}[2]{\def\sectionlabel{#2} \subsection{#1}\label{#2}} \newcommand{\lsubsubsection}[2]{\def\sectionlabel{#2} \subsubsection{#1}\label{#2}} @@ -557,7 +565,7 @@ \InputIfFileExists{protocol.ver}{}{} \newcommand{\doctitle}{Zcash Protocol Specification} -\newcommand{\leadauthor}{Daira Emma Hopwood} +\newcommand{\leadauthor}{Daira-Emma Hopwood} \newcommand{\coauthora}{Sean Bowe} \newcommand{\coauthorb}{Taylor Hornby} \newcommand{\coauthorc}{Nathan Wilcox} @@ -692,7 +700,7 @@ \newcommand{\consensuslink}[1]{\fcolorbox{black}{\labelcolor}{% \normalfont\normalsize\noborders{\href{\codesearchurl{#1}}{\color{black}\raisebox{0.2ex}{\linkstrut}\smash{{\small \search}\, #1}}}}\,} -\newcommand{\rawterm}[1]{\textsl{#1}\kern 0.05em} +\newcommand{\rawterm}[1]{\textsl{\nh{#1}}\kern 0.05em} \newcommand{\termnoindex}[1]{\rawterm{#1}\xspace} \newcommand{\termandindex}[2]{\indexlink{\rawterm{#1}}{#2}{#2}} \newcommand{\termandindexx}[2]{\indexlink{#1}{#2}{#1}} @@ -756,25 +764,58 @@ \newcommand{\OPTIONAL}{\conformance{OPTIONAL}} \newcommand{\ALLCAPS}{\conformance{ALL CAPS}} -\newcommand{\collisionResistant}{\termandindex{collision\hyp resistant}{collision resistance}} +\newcommand{\collisionResistant}{\termandindex{collision-resistant}{collision resistance}} \newcommand{\collisionResistance}{\term{collision resistance}} \newcommand{\xCollisionResistance}{\termx{collision resistance}} \newcommand{\binding}{\termandindex{binding}{binding (commitment scheme)}} \newcommand{\hiding}{\termandindex{hiding}{hiding (commitment scheme)}} \newcommand{\quotedBinding}{\quotedtermandindex{binding}{binding (commitment scheme)}} \newcommand{\quotedHiding}{\quotedtermandindex{hiding}{hiding (commitment scheme)}} +\newcommand{\reRandomized}{\term{re-randomized}} +\newcommand{\xReRandomized}{\termx{re-randomized}} +\newcommand{\reRandomizable}{\termandindex{re-randomizable}{re-randomized}} +\newcommand{\reRandomization}{\termandindex{re-randomization}{re-randomized}} \newcommand{\randomOracle}{\term{random oracle}} \newcommand{\randomOracles}{\terms{random oracle}} \newcommand{\randomOracleAdjective}{\termandindex{random-oracle}{random oracle}} -\newcommand{\nonCanonicalPoint}{\termandindex{non\hyp canonical}{non-canonical (compressed encoding of a point)}} -\newcommand{\nonCanonicalFieldElement}{\termandindex{non\hyp canonical}{non-canonical (encoding of a field element)}} -\newcommand{\nonCanonicallyFieldElement}{\termandindex{non\hyp canonically}{non-canonical (encoding of a field element)}} +\newcommand{\nonCanonicalPoint}{\termandindex{non-canonical}{non-canonical (compressed encoding of a point)}} +\newcommand{\nonCanonicalFieldElement}{\termandindex{non-canonical}{non-canonical (encoding of a field element)}} +\newcommand{\nonCanonicallyFieldElement}{\termandindex{non-canonically}{non-canonical (encoding of a field element)}} +\newcommand{\smallOrder}{\termandindex{small order}{small order (of a group element)}} +\newcommand{\smallOrderAdjective}{\termandindex{small-order}{small order (of a group element)}} +\newcommand{\primeOrder}{\termandindex{prime order}{prime order (of a group element)}} +\newcommand{\primeOrderAdjective}{\termandindex{prime-order}{prime order (of a group element)}} +\newcommand{\primeOrderGroup}{\term{prime-order group}} +\newcommand{\primeOrderSubgroup}{\term{prime-order subgroup}} +\newcommand{\primeOrderCurve}{\term{prime-order curve}} +\newcommand{\primeOrderCurves}{\terms{prime-order curve}} +\newcommand{\hashToCurve}{\term{hash-to-curve}} \newcommand{\xDiscreteLogarithmProblem}{\term{Discrete Logarithm Problem}} \newcommand{\xDiscreteLogarithm}{\termandindex{Discrete Logarithm}{Discrete Logarithm Problem}} \newcommand{\xDecisionalDiffieHellmanProblem}{\term{Decisional Diffie--Hellman Problem}} \newcommand{\xDecisionalDiffieHellman}{\termandindex{Decisional Diffie--Hellman}{Decisional Diffie--Hellman Problem}} \newcommand{\partitioningOracleAttack}{\term{partitioning oracle attack}} \newcommand{\partitioningOracleAttacks}{\terms{partitioning oracle attack}} +\newcommand{\sideChannel}{\term{side-channel}} +\newcommand{\multiPartyComputation}{\term{multi-party computation}} + +\newcommand{\doubleSpend}{\term{double-spend}} +\newcommand{\doubleSpends}{\terms{double-spend}} +\newcommand{\doubleSpending}{\termandindex{double-spending}{double-spend}} +\newcommand{\proofOfWork}{\term{proof-of-work}} +\newcommand{\peerToPeerProtocol}{\term{peer-to-peer protocol}} +\newcommand{\peerToPeerNetwork}{\termandindex{peer-to-peer network}{peer-to-peer protocol}} +\newcommand{\inBand}{\term{in-band}} +\newcommand{\outOfBand}{\term{out-of-band}} +\newcommand{\xUSASCII}{\term{US-ASCII}} +\newcommand{\bitSequence}{\term{bit sequence}} +\newcommand{\bitSequences}{\terms{bit sequence}} +\newcommand{\bitSequenceAdjective}{\termandindex{bit-sequence}{bit sequence}} +\newcommand{\byteSequence}{\term{byte sequence}} +\newcommand{\byteSequences}{\terms{byte sequence}} +\newcommand{\byteSequenceAdjective}{\termandindex{byte-sequence}{byte sequence}} +\newcommand{\littleEndian}{\term{little-endian}} +\newcommand{\bigEndian}{\term{big-endian}} \newcommand{\shaHash}{\termandindexx{$\SHAFull$}{SHA-256}} \newcommand{\shadHash}{\termandindexx{$\SHAFulld$}{SHA-256d}} @@ -791,8 +832,8 @@ \newcommand{\privateKeys}{\terms{private key}} \newcommand{\keyPrivacy}{\term{key privacy}} \newcommand{\xKeyPrivacy}{\termx{key privacy}} -\newcommand{\keyPrivate}{\termandindex{key\hyp private}{key privacy}} -\newcommand{\xKeyPrivate}{\termandindex{Key\hyp private}{key privacy}} +\newcommand{\keyPrivate}{\termandindex{key-private}{key privacy}} +\newcommand{\xKeyPrivate}{\termandindex{Key-private}{key privacy}} \newcommand{\ephemeralPublicKey}{\term{ephemeral public key}} \newcommand{\ephemeralPrivateKey}{\term{ephemeral private key}} @@ -896,6 +937,8 @@ \newcommand{\provingSystem}{\termandindex{proving system}{proving system (preprocessing zk-SNARK)}} \newcommand{\provingSystems}{\termandindex{proving systems}{proving system (preprocessing zk-SNARK)}} \newcommand{\zeroKnowledgeProvingSystem}{\termandindex{zero-knowledge proving system}{proving system (preprocessing zk-SNARK)}} +\newcommand{\zeroKnowledgeProvingSystems}{\termandindex{zero-knowledge proving systems}{proving system (preprocessing zk-SNARK)}} +\newcommand{\zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge}{\termandindex{zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs)}{proving system (preprocessing zk-SNARK)}} \newcommand{\quadraticConstraintProgram}{\term{quadratic constraint program}} \newcommand{\quadraticConstraintPrograms}{\terms{quadratic constraint program}} \newcommand{\quadraticArithmeticProgram}{\term{Quadratic Arithmetic Program}} @@ -1169,11 +1212,13 @@ \newcommand{\merkleIndices}{\termandindex{indices}{index (of a Merkle tree node)}} \newcommand{\zkSNARK}{\termandindex{zk-SNARK}{proving system (preprocessing zk-SNARK)}} \newcommand{\zkSNARKs}{\termandindex{zk-SNARKs}{proving system (preprocessing zk-SNARK)}} -\newcommand{\zkProof}{\termandindex{zk proof}{zk-SNARK proof}} -\newcommand{\zkSNARKProof}{\term{zk-SNARK proof}} -\newcommand{\zkSNARKProofs}{\terms{zk-SNARK proof}} -\newcommand{\zkSNARKCircuit}{\term{zk-SNARK circuit}} -\newcommand{\zkSNARKCircuits}{\terms{zk-SNARK circuit}} +\newcommand{\zkProof}{\termandindex{zk~proof}{zk-SNARK proof}} +\newcommand{\zeroKnowledgeProof}{\termandindex{zero-knowledge proof}{zk-SNARK proof}} +\newcommand{\zeroKnowledgeProofs}{\termandindex{zero-knowledge proofs}{zk-SNARK proof}} +\newcommand{\zkSNARKProof}{\termandindex{zk-SNARK proof}{zk-SNARK proof}} +\newcommand{\zkSNARKProofs}{\termandindex{zk-SNARK proofs}{zk-SNARK proof}} +\newcommand{\zkSNARKCircuit}{\termandindex{zk-SNARK circuit}{zk-SNARK circuit}} +\newcommand{\zkSNARKCircuits}{\termandindex{zk-SNARK circuits}{zk-SNARK circuit}} \newcommand{\libsnark}{\termandindex{libsnark}{libsnark (Zcash fork)}} \newcommand{\bellman}{\term{bellman}} \newcommand{\memo}{\term{memo field}} @@ -1190,7 +1235,7 @@ \newcommand{\signatureScheme}{\term{signature scheme}} \newcommand{\signatureSchemes}{\terms{signature scheme}} \newcommand{\oneTimeSignatureScheme}{\termandindex{one-time signature scheme}{one-time (signature scheme)}} -\newcommand{\rerandomizableSignatureScheme}{\termandindex{signature scheme with re\hyp randomizable keys}{signature scheme with re-randomizable keys}} +\newcommand{\rerandomizableSignatureScheme}{\termandindex{signature scheme with re-randomizable keys}{signature scheme with re-randomizable keys}} \newcommand{\keyMonomorphicSignatureScheme}{\term{signature scheme with key monomorphism}} \newcommand{\monomorphism}{\term{monomorphism}} \newcommand{\sigNonmalleable}{\termandindex{nonmalleable}{nonmalleability (of signatures)}} @@ -2484,7 +2529,7 @@ \begin{center} \hspace{0.6em}\includegraphics[scale=.1]{jubjub} -\footnote{Jubjub bird image credit: Peter Newell 1902; Daira Emma Hopwood 2018.} +\footnote{Jubjub bird image credit: Peter Newell 1902; \nh{Daira-Emma} Hopwood 2018.} \end{center} \vspace{-6ex} @@ -2492,12 +2537,11 @@ \begin{abstract} \normalsize \noindent \textbf{Abstract.} \defining{\Zcash} is an implementation of the \term{Decentralized Anonymous Payment scheme} -\Zerocash, with security fixes and improvements to performance and -functionality. It bridges the existing transparent payment scheme used by -\Bitcoin with a \emph{shielded} payment scheme secured by zero-knowledge -succinct non-interactive arguments of knowledge (\zkSNARKs). It attempted -to address the problem of mining centralization by use of the \Equihash -memory-hard proof-of-work algorithm. +\Zerocash, with security fixes and improvements to performance and functionality. +It bridges the existing transparent payment scheme used by \Bitcoin with a \emph{shielded} +payment scheme secured by \zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge. +It attempted to address the problem of mining centralization by use of the \Equihash +memory-hard \proofOfWork algorithm. \vspace{1.5ex} \notblossom{\sapling{\noindent This specification defines the \Zcash consensus protocol @@ -2554,8 +2598,7 @@ \Zerocash \cite{BCGGMTV2014}}, with security fixes and improvements to performance and functionality. It bridges the existing transparent payment scheme used by \defining{\Bitcoin \cite{Nakamoto2008}} with a -\emph{shielded} payment scheme secured by zero-knowledge succinct -non-interactive arguments of knowledge (\zkSNARKs). +\emph{shielded} payment scheme secured by \zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge. \vspace{1ex} In this document, technical terms for concepts that play an important rôle in \Zcash are @@ -2600,7 +2643,7 @@ \begin{itemize} \item Notation — definitions of notation used throughout the document; \item Concepts — the principal abstractions needed to understand the protocol; - \item Abstract Protocol — a high-level description of the protocol in terms + \item Abstract Protocol — a \nh{high-level} description of the protocol in terms of ideal cryptographic components; \item Concrete Protocol — how the functions and encodings of the abstract protocol are instantiated; @@ -2757,7 +2800,7 @@ or \CryptoNote \cite{vanSaberh2014}, that are based on mixing of a limited number of transactions and that therefore have smaller \noteTraceabilitySets. -The \nullifiers are necessary to prevent double-spending: each \note on the +The \nullifiers are necessary to prevent \doubleSpending: each \note on the \blockChain only has one valid \nullifier, and so attempting to spend a \note twice would reveal the \nullifier twice, which would cause the second \transaction to be rejected. @@ -2821,7 +2864,7 @@ $\bitseq{\ell}$ means the set of sequences of $\ell$ bits, and $\byteseq{k}$ means the set of sequences of $k$ bytes. -$\byteseqs$ means the type of byte sequences of arbitrary length. +$\byteseqs$ means the type of \byteSequences of arbitrary length. $\length(S)$ means the length of (number of elements in) $S$. @@ -2832,8 +2875,8 @@ $\zerobytes{\ell}$ means the sequence of $\ell$ zero bytes. $\ascii{...}$ means the given string represented as a -sequence of bytes in US-ASCII. For example, $\ascii{abc}$ represents the -byte sequence $\hexarray{61,62,63}$. +sequence of bytes in \xUSASCII. For example, $\ascii{abc}$ represents the +\byteSequence $\hexarray{61,62,63}$. $\zeros{\ell}$ means the sequence of $\ell$ zero bits. $\ones{\ell}$ means the sequence of $\ell$ one bits. @@ -2859,7 +2902,7 @@ $a \bconcat b$ means the concatenation of sequences $a$ then $b$. $\concatbits(S)$ means the sequence of bits obtained by -concatenating the elements of $S$ as bit sequences. +concatenating the elements of $S$ as \bitSequences. $\sorted(S)$ means the sequence formed by sorting the elements of $S$. @@ -2905,19 +2948,19 @@ conflict with the notation above for the unique representative of a field element.) -$a \xor b$ means the bitwise-exclusive-or of $a$ and $b$, -and $a \band b$ means the bitwise-and of $a$ and $b$. These are +$a \xor b$ means the \nh{bitwise-exclusive-or} of $a$ and $b$, +and $a \band b$ means the \nh{bitwise-and} of $a$ and $b$. These are defined on integers (which include bits and bytes), or elementwise on equal-length sequences of integers, according to context. \vspace{-0.5ex} $\!\vsum{i=1}{\rmN} a_i$ means the sum of $a_{\allN{}}$.\; $\vproduct{i=1}{\rmN} a_i$ means the product of $a_{\allN{}}$.\; -$\vxor{i=1}{\rmN} a_i$ means the bitwise exclusive-or of $a_{\allN{}}$. +$\vxor{i=1}{\rmN} a_i$ means the \nh{bitwise-exclusive-or} of $a_{\allN{}}$. When $N = 0$ these yield the appropriate neutral element, i.e. $\ssum{i=1}{0} a_i = 0$, $\sproduct{i=1}{0} a_i = 1$, and -$\sxor{i=1}{0} a_i = 0$ or the all-zero bit sequence of length given +$\sxor{i=1}{0} a_i = 0$ or the \nh{all-zero} \bitSequence of length given by the type of $a$. $\possqrt{a}$, where $a \typecolon \GF{q}$, means the positive square root @@ -2943,7 +2986,7 @@ defined in \crossref{abstractgroup}. The convention of affixing $\Repr$ to a variable name is used -for variables that denote bit-sequence representations of group elements. +for variables that denote \bitSequence representations of group elements. The binary relations $<$, $\leq$, $=$, $\geq$, and $>$ have their conventional meanings on integers and rationals, and are defined lexicographically on @@ -2973,7 +3016,7 @@ \end{formulae} The rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$;\notnufive{ and} -the bit sequence constants $\Uncommitted{Sprout} \typecolon \bitseq{\smash{\MerkleHashLength{Sprout}}}$\sapling{ and +the \bitSequenceAdjective constants $\Uncommitted{Sprout} \typecolon \bitseq{\smash{\MerkleHashLength{Sprout}}}$\sapling{ and $\Uncommitted{Sapling} \typecolon \bitseq{\smash{\MerkleHashLength{Sapling}}}$}\nufive{; and the constant $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$} will also be defined in that section. @@ -3208,7 +3251,7 @@ A \notePlaintext also includes a $\MemoByteLength$-byte \defining{\memo} associated with this \note. The usage of the \memo is by agreement between the sender and recipient -of the \note. \RECOMMENDED non-consensus constraints on the \memo contents are specified +of the \note. \RECOMMENDED{} \nh{non-consensus} constraints on the \memo contents are specified in \cite{ZIP-302}. For \Sprout, the \notePlaintexts in each \joinSplitDescription are encrypted to the respective @@ -3355,7 +3398,7 @@ \lsubsubsection{Nullifiers}{nullifierconcept} The \nullifier for a \note, denoted $\nf$, is a value unique to the \note that is used -to prevent double-spends. When a \transaction that contains one or more +to prevent \doubleSpends. When a \transaction that contains one or more \joinSplitDescriptions\sapling{ or \spendDescriptions}\nufive{ or \actionDescriptions} is entered into the \blockChain, all of the \defining{\nullifiers} for \notes spent by that \transaction are added to the \nullifierSet of the associated \treestate. A \transaction @@ -3366,14 +3409,14 @@ in \crossref{nullifierset}. \vspace{1.5ex} -In more detail, when a \note is spent, the spender creates a zero-knowledge proof that +In more detail, when a \note is spent, the spender creates a \zeroKnowledgeProof that it knows $(\NoteUniqueRand, \AuthPrivate)$\sapling{ or $(\NoteUniqueRand, \AuthSignPublic, \AuthProvePrivate)$}\nufive{ or $(\NoteUniqueRand, \AuthSignPublic, \NullifierKey)$}, consistent with the publically disclosed \nullifier and some previously committed \noteCommitment. Because each \note can have only a single \nullifier, and the same \nullifier value -cannot appear more than once in a \validBlockChain, double-spending is prevented. +cannot appear more than once in a \validBlockChain, \doubleSpending is prevented. \vspace{1.5ex} The \nullifier for a \Sprout \note is derived from the $\NoteUniqueRand$ value and @@ -3422,7 +3465,7 @@ The consensus protocol is designed to ensure that for any given \blockHeight, the vast majority of well-connected nodes should eventually agree on their \bestValidBlockChain up to that height. A \fullValidator\footnote{There is reason to follow the requirements -in this section also for non-full validators, but those are outside the scope of this +in this section also for \nh{non-full~validators}, but those are outside the scope of this protocol specification.} \SHOULD attempt to obtain candidate \blocks from multiple sources in order to increase the likelihood that it will find a \validBlockChain that reflects a recent consensus state. @@ -3450,7 +3493,7 @@ rooted at $\hashMerkleRoot$, and in other parts of the ecosystem; for example they are shown in \blockChain explorers and can be used in higher-level protocols. \nufive{Version 5 \transactions also have a \defining{\wtxid}, which is used instead of -the \transactionID when gossiping \transactions in the peer-to-peer protocol \cite{ZIP-239}.} +the \transactionID when gossiping \transactions in the \peerToPeerProtocol \cite{ZIP-239}.} The computation of \transactionIDs\nufive{ and \wtxids} is described in \crossref{txnidentifiers}. \nufive{For more detail on the distinction between these two identifiers and when to use each of them, see \cite{ZIP-239} and \cite{ZIP-244}.} @@ -3532,7 +3575,7 @@ \Sprout \treestate. For each of the $\NOld$ \shieldedInputs, a \nullifier is revealed. This allows -detection of double-spends as described in \crossref{nullifierset}. +detection of \doubleSpends as described in \crossref{nullifierset}. For each \joinSplitDescription in a \transaction, an interstitial output \treestate is constructed which adds the \noteCommitments and \nullifiers specified in that @@ -3600,7 +3643,7 @@ each other, potentially increasing opportunities for precomputation. A \spendDescription specifies an \anchor, which refers to the output \Sapling \treestate -of a previous \block. It also reveals a \nullifier, which allows detection of double-spends +of a previous \block. It also reveals a \nullifier, which allows detection of \doubleSpends as described in \crossref{nullifierconcept}. \vspace{-2ex} @@ -3689,7 +3732,7 @@ \noteCommitments that \joinSplitTransfers\sapling{ or \spendTransfers}\nufive{ or \actionTransfers} produce. Just as the \defining{\utxoSetFull} used in \Bitcoin, it is used to express the existence of value and the capability to spend it. However, unlike the \utxoSet, -it is \emph{not} the job of this tree to protect against double-spending, as it is +it is \emph{not} the job of this tree to protect against \doubleSpending, as it is append-only. A \defining{\merkleRoot} of a \noteCommitmentTree is associated with each \treestate @@ -3728,7 +3771,7 @@ revealed in \joinSplitDescriptions\sapling{ and \spendDescriptions}\nufive{ and \actionDescriptions} are inserted into the \nullifierSet associated with the new \treestate. \xNullifiers are enforced to be unique within a \validBlockChain, in order to prevent -double-spends. +\doubleSpends. \consensusrule{ A \nullifier \MUSTNOT repeat either within a \transaction, or across \transactions @@ -3869,7 +3912,7 @@ An abstraction can also be incomplete (not quite the same thing as being leaky): it intentionally --usually for simplicity-- does not model an aspect of behaviour that is important to security or correctness. An example -would be resistance to side-channel attacks; this specification says little about side-channel defence, among +would be resistance to \sideChannel attacks; this specification says little about \sideChannel defence, among many other implementation concerns. @@ -4087,7 +4130,7 @@ $\bot$ is used to represent the decryption of an invalid ciphertext. \securityrequirement{ -$\Sym$ must be \defining{\oneTime} (INT-CTXT $\wedge$ IND-CPA)-secure \cite{BN2007}. +$\Sym$ must be \defining{\oneTime} \nh{(INT-CTXT $\wedge$ IND-CPA)-secure} \cite{BN2007}. \quotedtermnoindex{One-time} here means that an honest protocol participant will almost surely encrypt only one message with a given key; however, the adversary may make many adaptive chosen ciphertext queries for a given key. @@ -4176,12 +4219,12 @@ \vspace{-1.5ex} \begin{securityrequirements} \item The asymmetric encryption scheme in \crossref{sproutinband}, constructed - from $\KA{Sprout}$, $\KDF{Sprout}$ and $\Sym$, is required to be IND-CCA2-secure + from $\KA{Sprout}$, $\KDF{Sprout}$ and $\Sym$, is required to be \nh{IND-CCA2-secure} and \keyPrivate. \item \sapling{ The asymmetric encryption scheme in \crossref{saplingandorchardinband}, constructed from $\KA{Sapling}$, $\KDF{Sapling}$ and $\Sym$\nufive{ or from $\KA{Orchard}$, - $\KDF{Orchard}$ and $\Sym$}, is required to be IND-CCA2-secure and \keyPrivate. + $\KDF{Orchard}$ and $\Sym$}, is required to be \nh{IND-CCA2-secure} and \keyPrivate. } %sapling \end{securityrequirements} @@ -4248,7 +4291,7 @@ \vspace{-1ex} \securityrequirement{ $\JoinSplitSig$\sapling{ and\nufive{ each instantiation of} $\BindingSig{}$} must be -Strongly Unforgeable under (non-adaptive) Chosen Message Attack (SU-CMA), as defined for example in +Strongly Unforgeable under (non-adaptive) Chosen Message Attack \nh{(SU-CMA)}, as defined for example in \cite[Definition 6]{BDEHR2011}.\footnote{The scheme defined in that paper was attacked in \cite{LM2017}, but this has no impact on the applicability of the definition.} This allows an adversary to obtain signatures on chosen messages, and then requires it to be @@ -4279,7 +4322,7 @@ in the same distribution as of freshly generated key pairs, for each \transaction containing \spendDescriptions or \outputDescriptions\nufive{ or \actionDescriptions}.} - \item SU-CMA security requires it to be infeasible for the adversary, not + \item \nh{SU-CMA} security requires it to be infeasible for the adversary, not knowing the \defining{\privateKey}, to forge a distinct signature on a previously seen message. That is, \joinSplitSignatures\sapling{ and \saplingBindingSignatures}\nufive{ and \orchardBindingSignatures} @@ -4332,13 +4375,13 @@ \vspace{-1.5ex} The following security requirement for such \signatureSchemes is based on that -given in \cite[section 3]{FKMSSS2016}. Note that we require Strong Unforgeability -with Re-randomized Keys, not Existential Unforgeability with Re-randomized Keys -(the latter is called ``Unforgeability under Re-randomized Keys'' in -\cite[Definition 8]{FKMSSS2016}). Unlike the case for $\JoinSplitSig$, we require +given in \cite[section 3]{FKMSSS2016}. \defining{Note that we require Strong Unforgeability +with \xReRandomized Keys, not Existential Unforgeability with \xReRandomized Keys +(the latter is called ``Unforgeability under \xReRandomized Keys'' in +\cite[Definition 8]{FKMSSS2016}).} Unlike the case for $\JoinSplitSig$, we require security under adaptive chosen message attack with multiple messages signed using -a given key. (Although each \note uses a different re-randomized key pair, the same -original key pair can be re-randomized for multiple \notes, and also it can happen +a given key. (Although each \note uses a different \reRandomized key pair, the same +original key pair can be \reRandomized for multiple \notes, and also it can happen that multiple \transactions spending the same \note are revealed to an adversary.) \introlist @@ -4373,15 +4416,15 @@ are swapped relative to \cite[section 3]{FKMSSS2016}. \vspace{-0.5ex} \item The requirement for the identity \randomizer $\SigRandomizerId$ simplifies the - definition of SURK-CMA by removing the need for two oracles (because the oracle for + definition of \nh{SURK-CMA} by removing the need for two oracles (because the oracle for original keys, called $\Oracle_1$ in \cite{FKMSSS2016}, is a special case of the oracle for randomized keys). \vspace{-0.5ex} \item Since $\SigRandomizePrivate(\SigRandomizer, \sk) : \SigRandomizer \leftarrowR \SigRandom$ has an identical distribution to $\SigGenPrivate()$, - and since $\SigDerivePublic$ is a deterministic function, the combination of a re-randomized + and since $\SigDerivePublic$ is a deterministic function, the combination of a \reRandomized \validatingKey and signature(s) under that key do not reveal the key from which it was - re-randomized. + \reRandomized. \vspace{-0.5ex} \item Since $\SigRandomizePrivate_{\SigRandomizer}$ is injective and easily invertible, knowledge of $\SigRandomizePrivate(\SigRandomizer, \sk)$ @@ -4908,7 +4951,7 @@ Let $\KA{Sprout}$ be a \keyAgreementScheme, instantiated in \crossref{concretesproutkeyagreement}. \vspace{0.3ex} -A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a bit sequence +A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a \bitSequence uniformly at random from $\bitseq{\AuthPrivateLength}$. \introlist @@ -4966,7 +5009,7 @@ Define $\ToScalar{Sapling}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamJ{r}}$. \introlist -A new \Sapling \spendingKey $\SpendingKey$ is generated by choosing a bit sequence +A new \Sapling \spendingKey $\SpendingKey$ is generated by choosing a \bitSequence uniformly at random from $\SpendingKeyType$. \vspace{-0.2ex} @@ -5143,7 +5186,7 @@ Define $\ToScalar{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{r}}$. \introlist -A new \Orchard \spendingKey $\SpendingKey$ is generated by choosing a bit sequence +A new \Orchard \spendingKey $\SpendingKey$ is generated by choosing a \bitSequence uniformly at random from $\SpendingKeyType$. From this \spendingKey, the \authSigningKey $\AuthSignPrivate \typecolon \GFstar{\ParamP{r}}$, @@ -5383,7 +5426,7 @@ \vspace{-1ex} \begin{consensusrules} \item Elements of a \spendDescription \MUST be valid encodings of the types given above. - \item $\cv$ and $\AuthSignRandomizedPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ + \item $\cv$ and $\AuthSignRandomizedPublic$ \MUSTNOT be of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\AuthSignRandomizedPublic}$ \MUSTNOT be $\ZeroJ$. \item The proof $\Proof{\Spend}$ \MUST be valid given a \primaryInput formed from the other fields except $\spendAuthSig$ --- @@ -5404,7 +5447,7 @@ \item As stated in \shortcrossref{concretehomomorphiccommit}, an implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$. \vspace{-0.25ex} - \item The rule that $\cv$ and $\AuthSignRandomizedPublic$ \MUST not be small-order has the effect + \item The rule that $\cv$ and $\AuthSignRandomizedPublic$ \MUST not be \smallOrderAdjective has the effect of also preventing \nonCanonicalFieldElement encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and $\reprJ\Of{\abstJ\Of{\AuthSignRandomizedPublic}\kern0.05em} = \AuthSignRandomizedPublic$. @@ -5466,7 +5509,7 @@ \begin{consensusrules} \item Elements of an \outputDescription \MUST be valid encodings of the types given above. \vspace{-0.3ex} - \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ + \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\EphemeralPublic}$ \MUSTNOT be $\ZeroJ$. \vspace{-0.3ex} \item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed @@ -5479,7 +5522,7 @@ \item As stated in \shortcrossref{concretehomomorphiccommit}, an implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$. \vspace{-0.25ex} - \item The rule that $\cv$ and $\EphemeralPublic$ \MUST not be small-order has the effect + \item The rule that $\cv$ and $\EphemeralPublic$ \MUST not be \smallOrderAdjective has the effect of also preventing \nonCanonicalFieldElement encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and $\reprJ\Of{\abstJ\Of{\EphemeralPublic}\kern0.05em} = \AuthSignRandomizedPublic$. @@ -5549,9 +5592,9 @@ the \outgoingCipherKey (which can be derived from a \fullViewingKey) to recover the recipient \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey $\EphemeralPrivate$, hence the entire \notePlaintext; - \item $\enableSpends \typecolon \bit$ is a flag that is set in order to enable non-zero-valued + \item $\enableSpends \typecolon \bit$ is a flag that is set in order to enable \nh{non-zero-valued} spends in this Action; - \item $\enableOutputs \typecolon \bit$ is a flag that is set in order to enable non-zero-valued + \item $\enableOutputs \typecolon \bit$ is a flag that is set in order to enable \nh{non-zero-valued} outputs in this Action; \vspace{-0.25ex} \item $\Proof{} \typecolon \ActionProof$ is a \zkSNARKProof with \primaryInput @@ -5661,7 +5704,7 @@ \end{formulae} \vspace{-0.5ex} -Then the encoded \transaction including $\joinSplitSig$ is submitted to the peer-to-peer network. +Then the encoded \transaction including $\joinSplitSig$ is submitted to the \peerToPeerNetwork. \canopyonwardpnote{\cite{ZIP-211} specifies that nodes and wallets \MUST disable any facilities to send to \Sprout addresses. This \SHOULD be made clear in user interfaces and API documentation.} @@ -5781,7 +5824,7 @@ In order to minimize information leakage, the sender \SHOULD randomize the order of \outputDescriptions in a \transaction. Other considerations relating to information leakage from the structure of \transactions are beyond the scope of this specification. -The encoded \transaction is submitted to the peer-to-peer network. +The encoded \transaction is submitted to the \peerToPeerNetwork. } %sapling @@ -5870,7 +5913,7 @@ In order to minimize information leakage, the sender \SHOULD randomize the order of \actionDescriptions in a \transaction. Other considerations relating to information leakage from the structure of \transactions are beyond the scope of this specification. -The encoded \transaction is submitted to the peer-to-peer network. +The encoded \transaction is submitted to the \peerToPeerNetwork. \pnote{ The domain separators $[4]$ and $[5]$ used in the input to $\PRFexpand{\NoteSeedBytes}$ are @@ -6075,7 +6118,7 @@ \noteCommitmentTrees. Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash, -which is a bit sequence. +which is a \bitSequence. The \merkleLayer numbered $h$, counting from \merkleLayer $0$ at the \merkleRoot, has $2^h$ \merkleNodes with \merkleIndices $0$ to $2^h-1$ inclusive. @@ -6124,7 +6167,7 @@ \sapling{ \begin{pnotes} - \item For \Sapling, Merkle \merkleHashes are specified to be encoded as bit sequences, but the + \item For \Sapling, Merkle \merkleHashes are specified to be encoded as \bitSequences, but the \merkleRoot $\rt{Sapling}$ is encoded for the \primaryInput of a \spendProof as an element of $\GF{\ParamJ{q}}$, as specified in \crossref{cctsaplingspend}. The \spendCircuit allows inputs to $\MerkleCRH{Sapling}$ at each \merkleNode to be \nonCanonicallyFieldElement encoded, @@ -6153,7 +6196,7 @@ \introsection \lsubsection{SIGHASH Transaction Hashing}{sighash} -\Bitcoin and \Zcash use signatures and/or non-interactive proofs associated +\Bitcoin and \Zcash use signatures and/or \nh{non-interactive} proofs associated with \transaction inputs to authorize spending. Because these signatures or proofs could otherwise be replayed in a different \transaction, it is necessary to ``bind'' them to the \transaction for which they are intended. This is done by hashing information @@ -6384,7 +6427,7 @@ \crossref{abstractsigmono} specifies these operations and the derived notation $\combminus$, $\scombsum{i=1}{\rmN}$, $\grpminus$, and $\sgrpsum{i=1\vphantom{p}}{\rmN}$, which in this section are to be interpreted as -operating on the prime-order subgroup of the \jubjubCurve and its scalar field. +operating on the \primeOrderSubgroup of points on the \jubjubCurve and on its scalar field. \vspace{1ex} \introlist @@ -6734,7 +6777,7 @@ signature can be checked by validators. To ensure that the \validatingKey cannot be linked to the \shieldedPaymentAddress or \spendingKey from which the \note was spent, we use a \rerandomizableSignatureScheme. The \spendStatement\nufive{ or \actionStatement} proves that -this \validatingKey is a re-randomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ +this \validatingKey is a \reRandomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ with a \randomizer known to the signer. The \defining{\spendAuthSignature} is over the \sighashTxHash, so that it cannot be replayed in other \transactions. @@ -7036,7 +7079,7 @@ \snarkcondition{Small order checks}{spendnonsmall} $\DiversifiedTransmitBase$ and $\AuthSignPublic$ -are not of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$ +are not of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$ and $\scalarmult{\ParamJ{h}}{\AuthSignPublic} \neq \ZeroJ$. \snarkcondition{Nullifier integrity}{spendnullifierintegrity} @@ -7073,11 +7116,11 @@ i.e.\ $\GroupJ$. \vspace{-0.5ex} \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its - input bit sequence is a canonical encoding (in $\range{0}{\ParamJ{q}-1}$) of the integer + input \bitSequence is a canonical encoding (in $\range{0}{\ParamJ{q}-1}$) of the integer from the previous \merkleLayer. \vspace{-0.5ex} \item It is \emph{not} checked in the \spendStatement that $\AuthSignRandomizedPublic$ is not of - small order. However, this \emph{is} checked outside the \spendStatement, as specified in + \smallOrder. However, this \emph{is} checked outside the \spendStatement, as specified in \crossref{spenddesc}. \vspace{-0.5ex} \item It is \emph{not} checked that $\ValueCommitRandOld{} < \ParamJ{r}$ or that $\NoteCommitRandOld{} < \ParamJ{r}$. @@ -7140,7 +7183,7 @@ $\cvNew{} = \ValueCommit{Sapling}{\ValueCommitRandNew{}}(\vNew{})$. \snarkcondition{Small order check}{outputnonsmall} -$\DiversifiedTransmitBase$ is not of small order, +$\DiversifiedTransmitBase$ is not of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$. \vspace{0.5ex} @@ -7158,7 +7201,7 @@ The $\ValueCommitOutput{Sapling}$ type also represents points, i.e. $\GroupJ$. \vspace{-0.5ex} \item The validity of $\DiversifiedTransmitPublicRepr$ is \emph{not} checked in this circuit (which is the reason - why it is typed as a bit sequence rather than as a point). + why it is typed as a \bitSequence rather than as a point). \vspace{-0.5ex} \item It is \emph{not} checked that $\ValueCommitRandOld{} < \ParamJ{r}$ or that $\NoteCommitRandOld{} < \ParamJ{r}$. \end{pnotes} @@ -7293,7 +7336,7 @@ range $\SignedValueDifferenceType$, which is different to the range $\SignedValueFieldType$ of $\vBalance{Orchard}$. \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its - input bit sequence is a canonical encoding (in $\MerkleHashOrchard$) of the integer + input \bitSequence is a canonical encoding (in $\MerkleHashOrchard$) of the integer from the previous \merkleLayer. \item As specified in \crossref{merklepath}, the validity check is permitted to be implemented in such a way that it can pass if any $\MerkleCRH{Orchard}$ hash on the \merklePath outputs $0$. @@ -7322,7 +7365,7 @@ $\SpendAuthSigRandomizePublic{Orchard}$. In particular, the representation of $(\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand) + \NoteNullifierRand) \bmod \ParamP{q}$ that is used for the scalar multiplication in $\DeriveNullifierAlg$ \MUST be checked to be - canonical in order to avoid a potential double-spend vulnerability, and similarly for the + canonical in order to avoid a potential \doubleSpend vulnerability, and similarly for the representation of $\InViewingKey$ in $\scalarmult{\InViewingKey}{\DiversifiedTransmitBaseOld}$. \end{pnotes} @@ -7365,7 +7408,7 @@ is also transmitted. To transmit these secrets securely to a recipient -\emph{without} requiring an out-of-band communication channel, the +\emph{without} requiring an \outOfBand communication channel, the \transmissionKey $\TransmitPublic$ is used to encrypt them. The recipient's possession of the associated \incomingViewingKey $\InViewingKey$ is used to reconstruct the original \note and \memo. @@ -7427,12 +7470,12 @@ \introlist \pnote{ It is technically possible to replace $\TransmitCiphertext{i}$ for a given \note -with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band +with a random (and undecryptable) dummy ciphertext, relying instead on \outOfBand transmission of the \note to the recipient. In this case the ephemeral key \MUST -still be generated as a random \publicKey (rather than a random bit sequence) to ensure +still be generated as a random \publicKey (rather than a random \bitSequence) to ensure indistinguishability from other \joinSplitDescriptions. This mode of operation raises further security considerations, for example of how to validate a \Sprout{} -\note received out-of-band, which are not addressed in this document. +\note received \outOfBand, which are not addressed in this document. } \lsubsubsection{Decryption (\SproutText)}{sproutdecrypt} @@ -7514,7 +7557,7 @@ is also transmitted. To transmit these secrets securely to a recipient \emph{without} requiring -an out-of-band communication channel, the \diversifiedTransmissionKey +an \outOfBand communication channel, the \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ is used to encrypt them. The recipient's possession of the associated $\KA{Sapling}$\nufive{ or $\KA{Orchard}$} \privateKey $\InViewingKey$ is used to reconstruct the original \note and \memo. @@ -7618,12 +7661,12 @@ \introlist \pnote{ It is technically possible to replace $\TransmitCiphertext{}$ for a given \note -with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band +with a random (and undecryptable) dummy ciphertext, relying instead on \outOfBand transmission of the \note to the recipient. In this case the ephemeral key \MUST -still be generated as a random \publicKey (rather than a random bit sequence) to ensure +still be generated as a random \publicKey (rather than a random \bitSequence) to ensure indistinguishability from other \outputDescriptions. This mode of operation raises further security considerations, for example of how to validate a \SaplingOrOrchard \note -received out-of-band, which are not addressed in this document. +received \outOfBand, which are not addressed in this document. } %pnote } %sapling @@ -7841,7 +7884,7 @@ \notnufive{\introlist} \vspace{-0.5ex} \item A previous version of this specification did not have the requirement for the decoded point - $\DiversifiedTransmitPublic$ of a \Sapling \note to be in the set of prime-order points + $\DiversifiedTransmitPublic$ of a \Sapling \note to be in the set of \primeOrderAdjective points \smash{$\SubgroupJstar$ (i.e.\ ``if ... $\DiversifiedTransmitPublic \not\in \SubgroupJstar$}, return $\bot$''). That did not match the implementation in \zcashd. In fact the history is a little more complicated. The current specification matches the implementation in \librustzcash as of @@ -7867,7 +7910,7 @@ After \NUFive activation, the above algorithm explicitly returns $\bot$ if $\reprP\big(\DiversifiedTransmitPublic\big) \neq \DiversifiedTransmitPublicRepr$. However, this is technically redundant with the later check that returns $\bot$ if - $\DiversifiedTransmitPublic \not\in \smash{\SubgroupJstar}$, because only small-order \jubjubCurve + $\DiversifiedTransmitPublic \not\in \smash{\SubgroupJstar}$, because only \smallOrderAdjective \jubjubCurve points have \nonCanonicalPoint encodings. This check is enforced retrospectively for consensus by current \zcashd and \zebra versions, and for wallet rescanning by current \zcashd. Versions of \zcashd prior to \cite{zcashd-6725} could however @@ -7965,8 +8008,8 @@ \vspace{-1ex} In \SaplingAndOrchard, \blockChain scanning requires only the $\NullifierKey$ and $\InViewingKey$ key components, rather than a \spendingKey as in \Sprout. -Typically, these components are derived from a \fullViewingKey as described in -\crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}. +Typically, these components are derived from a \fullViewingKey +(\crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}). \vspace{0.5ex} Let $\PRFOutputLengthNfSapling$ be as defined in \crossref{constants}. @@ -8029,7 +8072,7 @@ \item When scanning only part of a \blockChain, it may be useful to augment the above algorithm with decryption of $\OutCiphertext$ components for each \transaction, in order to obtain information about \notes that were spent in the scanned period but received outside it. - \item The above algorithm does not detect \notes that were sent ``out-of-band'' or with incorrect + \item The above algorithm does not detect \notes that were sent ``\outOfBand'' or with incorrect \noteCiphertextsSapling. It is possible to detect whether such \notes were spent only if their \nullifiers are known. \end{nnotes} @@ -8062,14 +8105,14 @@ big-endian order. \item $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \binaryrange{\ell}$ such that $\LEBStoIPOf{\ell}{S}$ is the integer represented in little-endian order by the - bit sequence $S$ of length $\ell$. + \bitSequence $S$ of length $\ell$. \item $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ such that $\LEOStoIPOf{\ell}{S}$ is the integer represented in little-endian order by the - byte sequence $S$ of length $\ell/8$. + \byteSequence $S$ of length $\ell/8$. \notbeforenufive{ \item $\BEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ such that $\BEOStoIPOf{\ell}{S}$ is the integer represented in big-endian order by the - byte sequence $S$ of length $\ell/8$. + \byteSequence $S$ of length $\ell/8$. } %notbeforenufive \item $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$ defined as follows: pad the input on the right with $8 \mult \ceiling{\ell/8} - \ell$ zero bits @@ -8086,19 +8129,19 @@ \extralabel{boxnotation}{\lsubsection{Bit layout diagrams}{bitlayout}} We sometimes use bit layout diagrams, in which each box of the diagram represents -a sequence of bits. Diagrams are read from left-to-right, with lines read from -top-to-bottom; the breaking of boxes across lines has no significance. +a sequence of bits. Diagrams are read from left to right, with lines read from +top to bottom; the breaking of boxes across lines has no significance. The bit length $\ell$ is given explicitly in each box, except when it is obvious (e.g. for a single bit, or for the notation $\zeros{\ell}$ representing the sequence of $\ell$ zero bits, or for the output of $\LEBStoOSP{\ell}$). The entire diagram represents the sequence of \emph{bytes} formed by first -concatenating these bit sequences, and then treating each subsequence of 8 bits +concatenating these \bitSequences, and then treating each subsequence of 8 bits as a byte with the bits ordered from \emph{most significant} to \emph{least significant}. Thus the \emph{most significant} bit in each byte is toward the left of a diagram. \sapling{(This convention is used only in descriptions of the $\Sprout$ design; in the \SaplingAndOrchard additions, -bit/byte sequence conversions are always specified explicitly.)} Where bit fields +\bitSequence/\byteSequence conversions are always specified explicitly.)} Where bit fields are used, the text will clarify their position in each case. @@ -8217,11 +8260,11 @@ \end{formulae} \cite{NIST2015} strictly speaking only specifies the application of SHA-256 to -messages that are bit sequences, producing outputs (``message digests'') that -are also bit sequences. In practice, SHA-256 is universally implemented with a +messages that are \bitSequences, producing outputs (``message digests'') that +are also \bitSequences. In practice, SHA-256 is universally implemented with a byte-sequence interface for messages and outputs, such that the \emph{most significant} bit of each byte corresponds to the first bit of the -associated bit sequence. (In the NIST specification ``first'' is conflated with +associated \bitSequence. (In the NIST specification ``first'' is conflated with ``leftmost''.) \introlist @@ -8351,7 +8394,7 @@ \begin{pnotes} \item The $\layerInput$ argument does not affect the output. \item \shaCompress is not the same as the \shaHash function, which hashes arbitrary-length - byte sequences. + \byteSequences. \end{pnotes} \sapling{ @@ -8560,27 +8603,27 @@ return $\bot$) is modelled as a \randomOracle from \diversifiers to points of order $\ParamJ{r}$ on the \jubjubCurve. In this model, Unlinkability of $\DiversifyHash{Sapling}$ holds under the \xDecisionalDiffieHellman assumption on the - prime-order subgroup of the \jubjubCurve. + \primeOrderSubgroup of points on the \jubjubCurve. To prove this, consider the ElGamal encryption scheme \cite{ElGamal1985} - on this prime-order subgroup, restricted to encrypting plaintexts encoded + on this \primeOrderSubgroup, restricted to encrypting plaintexts encoded as the group identity $\ZeroJ$. (ElGamal was originally defined for $\GFstar{p}$ - but works in any prime-order group.) ElGamal \publicKeys then have the same form + but works in any \primeOrderGroup.) ElGamal \publicKeys then have the same form as \diversifiedPaymentAddresses. If we make the assumption above on $\GroupJHash{}$, then generating a new \diversifiedPaymentAddress from a given address $\pk$, gives the same distribution of $(\DiversifiedTransmitBase', \DiversifiedTransmitPublic')$ pairs as the distribution of ElGamal ciphertexts obtained by encrypting $\ZeroJ$ under $\pk$. \todo{check whether this is justified.} - Then, the definition of \keyPrivacy (IK-CPA as defined in \cite[Definition 1]{BBDP2001}) + Then, the definition of \keyPrivacy (\nh{IK-CPA} as defined in \cite[Definition 1]{BBDP2001}) for ElGamal corresponds to the definition of Unlinkability for $\DiversifyHash{Sapling}$. - (IK-CCA corresponds to the potentially stronger requirement that $\DiversifyHash{Sapling}$ + (\nh{IK-CCA} corresponds to the potentially stronger requirement that $\DiversifyHash{Sapling}$ remains Unlinkable when given Diffie--Hellman key agreement oracles for each of the candidate \diversifiedPaymentAddresses.) So if ElGamal is \keyPrivate, then $\DiversifyHash{Sapling}$ is Unlinkable under the same conditions. \cite[Appendix A]{BBDP2001} gives a security proof for \keyPrivacy - (both IK-CPA and IK-CCA) of ElGamal under the \xDecisionalDiffieHellman + (both \nh{IK-CPA} and \nh{IK-CCA}) of ElGamal under the \xDecisionalDiffieHellman assumption on the relevant group. (In fact the proof needed is the ``small modification'' described in the last paragraph in which the generator is chosen at random for each key.) @@ -8643,7 +8686,7 @@ \cite{CDvdG1987}, \cite{BCP1988} and \cite{CvHP1991}, and of Mihir Bellare, Oded Goldreich, and Shafi Goldwasser in \cite{BGG1995}, with optimizations for efficient instantiation in \zkSNARKCircuits -by Sean Bowe and Daira Emma Hopwood. +by Sean Bowe and \nh{Daira-Emma} Hopwood. $\PedersenHash$ is used in the definitions of \xPedersenCommitments (\crossref{concretewindowedcommit}), and of the \defining{\xPedersenHash} for the @@ -8814,7 +8857,7 @@ \vspace{-2ex} \defining{$\SinsemillaHash$} is an algebraic \hashFunction with \collisionResistance (for fixed input length) derived from assumed hardness -of the \xDiscreteLogarithmProblem. It is designed by Sean Bowe and Daira Emma Hopwood. +of the \xDiscreteLogarithmProblem. It is designed by Sean Bowe and \nh{Daira-Emma} Hopwood. The motivation for introducing a new discrete-logarithm-based hash function (rather than using $\PedersenHash$) is to make efficient use of the lookups available in recent proof systems including \HaloTwo. @@ -8838,7 +8881,7 @@ \vspace{-0.25ex} Let $\ItoLEOSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$ -and $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ +and $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \binaryrange{\ell}$ be as defined in \crossref{endian}. \vspace{0.5ex} @@ -9024,7 +9067,7 @@ \begin{nnotes} \item \cite[Lemma 3]{JT2020} proves a tight reduction from finding a nontrivial discrete logarithm - relation in a prime-order group to solving the \xDiscreteLogarithmProblem in that group. + relation in a \primeOrderGroup to solving the \xDiscreteLogarithmProblem in that group. \item The above theorem easily extends to the case where additional scalar multiplication terms with independent bases may be added to the $\SinsemillaHashToPoint$ output before applying $\ExtractPbot$. This is needed to show security of the $\SinsemillaShortCommitAlg$ \commitmentScheme defined in @@ -9099,14 +9142,14 @@ implementation were inconsistent with the paper. For verifying the parameters used in Zcash, we recommend the fork \cite{Poseidon-Zc1.1} which avoids use of the obsolete PyCrypto library.}} -The S-box function is $x \mapsto x^5$. The number of full rounds $R_F$ is $8$, and +The \nh{S-box} function is $x \mapsto x^5$. The number of full rounds $R_F$ is $8$, and the number of partial rounds $R_P$ is $56$. We use $\Poseidon$ in a sponge configuration \cite{BDPA2011} (with elementwise addition in $\GF{\ParamP{q}}$ replacing exclusive-or of bit strings\footnote{\nufive{The sponge construction was originally proposed as operating on an arbitrary group. \cite{BDPA2007}}}) to construct a \hashFunction. The sponge capacity is one field element, the rate is two field elements, and -the output is one field element. We use the ``Constant-Input-Length''\strut mode described in +the output is one field element. We use the \nh{``Constant-Input-Length''} \strut mode described in \cite[section 4.2]{GKRRS2019}: for a $2$-element input, the initial value of the capacity element is $2^{65}$, and no padding of the input message is needed. @@ -9137,14 +9180,14 @@ $2^{32} \mult 3 \mult 463 \mult 539204044132271846773 \mult 8999194758858563409123804352480028797519453$. Furthermore, previous cryptanalysis of $\Poseidon$ has focussed mainly on the case - of S-box $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because + of \nh{S-box} $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because $x \mapsto x^3$ would not be a permutation. $\alpha = 5$ is the smallest integer for which $x \mapsto x^\alpha$ is a permutation in $\GF{\ParamP{q}}$. On the other hand, the number of rounds chosen includes a significant security margin, even taking into account these considerations. For small $t$, such as $t = 3$ as used here, the results of \cite{KR2020} are positive for security since they indicate that - the number of active S-boxes through the middle rounds is larger than originally + the number of active \nh{S-boxes} through the middle rounds is larger than originally estimated by the $\Poseidon$ designers (and the number of rounds is based on this original conservative estimate). @@ -9163,7 +9206,7 @@ on the \Pallas curve, even if the $\Poseidon$-based PRF were distinguishable from an ideal PRF. \item The constant $2^{65}$ comes from \cite[section 4.2]{GKRRS2019}: - ``Constant-Input-Length Hashing. The capacity value is $\mathit{length} \mult (2^{64}) + (o - 1)$ + ``\nh{Constant-Input-Length} Hashing. The capacity value is $\mathit{length} \mult (2^{64}) + (o - 1)$ where $o$ is the output length.'' In this case the input length ($\mathit{length}$) is $2$ field elements, and the output length is $1$ field element. \end{nnotes} @@ -9390,7 +9433,7 @@ \vspace{-2ex} \securityrequirement{ -$\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a +The function $\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a \collisionResistant \xPRF for output range $\byteseq{32}$ when keyed by the bits corresponding to $\NullifierKeyRepr$, with input in the bits corresponding to $\NoteUniqueRandRepr$. Note that @@ -9480,7 +9523,7 @@ Similarly, let $\SymDecrypt{\Key}(\Ctext)$ be $\SymSpecific$ decryption of ciphertext $\Ctext \in \Ciphertext$, with empty ``associated data", all-zero nonce $\zeros{96}$, and $256$-bit key -$\Key \in \Keyspace$. The result is either the plaintext byte sequence, +$\Key \in \Keyspace$. The result is either the plaintext \byteSequence, or $\bot$ indicating failure to decrypt. \pnote{ @@ -9539,13 +9582,13 @@ Let $\KASproutCurveMultiply(\bytes{n}, \bytes{q})$ be the result of point multiplication of the $\KASproutCurve$ \publicKey represented by the byte sequence $\bytes{q}$ by the $\KASproutCurve$ secret key represented by the -byte sequence $\bytes{n}$, as defined in \cite[section 2]{Bernstein2006}. +\byteSequence $\bytes{n}$, as defined in \cite[section 2]{Bernstein2006}. -Let $\KABase{Sprout} := \KASproutCurveBase$ be the public byte sequence representing +Let $\KABase{Sprout} := \KASproutCurveBase$ be the public \byteSequence representing the $\KASproutCurve$ base point. Let $\KASproutCurveClamp(\bytes{x})$ take a 32-byte sequence $\bytes{x}$ as input -and return a byte sequence representing a $\KASproutCurve$ \privateKey, with +and return a \byteSequence representing a $\KASproutCurve$ \privateKey, with bits ``clamped'' as described in \cite[section 3]{Bernstein2006}: ``clear bits $0, 1, 2$ of the first byte, clear bit $7$ of the last byte, and set bit $6$ of the last byte.'' Here the bits of a byte are numbered @@ -9740,7 +9783,7 @@ Let $d = -121665/121666 \pmod{p}$. Let $\ell = 2^{252} + 27742317777372353535851937790883648493$ (the order of the \EdSpecific -curve's prime-order subgroup). +curve's \primeOrderSubgroup). Let $\EdDSABase$ be the base point given in \cite{BDLSY2012}. @@ -9854,7 +9897,7 @@ \sapling{ \extralabel{concreteredjubjub}{\lsubsubsection{\RedDSAText{}\notnufive{ and \RedJubjubText{}}\notbeforenufive{, \RedJubjubText{}, and \RedPallasText{}}}{concretereddsa}} -$\RedDSA$ is a Schnorr-based \signatureScheme, optionally supporting key re-randomization +$\RedDSA$ is a Schnorr-based \signatureScheme, optionally supporting key \reRandomization as described in \crossref{abstractsigrerand}. It also supports a Secret Key to Public Key Monomorphism as described in \crossref{abstractsigmono}. It is based on a scheme from \cite[section 3]{FKMSSS2016}, with some ideas from @@ -9867,7 +9910,7 @@ parameters defined in \crossref{concretespendauthsig}. The \bindingSignatureScheme $\BindingSig{Sapling}$ is instantiated by $\RedJubjub$ without -key re-randomization, using parameters defined in \crossref{concretebindingsig}. +key \reRandomization, using parameters defined in \crossref{concretebindingsig}. \nufive{ $\RedPallas$ is a specialization of $\RedDSA$ to the \pallasCurve defined in \crossref{pallasandvesta}, @@ -9877,7 +9920,7 @@ parameters defined in \crossref{concretespendauthsig}. The \bindingSignatureScheme $\BindingSig{Orchard}$ is instantiated by $\RedPallas$ without -key re-randomization, using parameters defined in \crossref{concretebindingsig}. +key \reRandomization, using parameters defined in \crossref{concretebindingsig}. } %nufive Let $\ItoLEBSP{}$, $\ItoLEOSP{}$, $\LEOStoIP{}$, and $\LEBStoOSP{}$ be as defined in \crossref{endian}. @@ -9931,7 +9974,7 @@ \introlist Define $\RedDSAGenRandom \typecolon () \rightarrowR \RedDSARandom$ as: \begin{formulae} - \item Choose a byte sequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. + \item Choose a \byteSequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. \item Return $\RedDSAHashToScalar(T)$. \end{formulae} @@ -9953,7 +9996,7 @@ \introlist Define $\RedDSASign{} \typecolon (\sk \typecolon \RedDSAPrivate) \times (M \typecolon \RedDSAMessage) \rightarrowR \RedDSASignature$ as: \begin{algorithm} - \item Choose a byte sequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. + \item Choose a \byteSequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. \item Let $\vkBytes{} = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\RedDSADerivePublic(\sk)}\kern 0.05em}$. \vspace{-0.75ex} \item Let $r = \RedDSAHashToScalar(T \bconcat \vkBytes{} \bconcat M)$. @@ -10042,8 +10085,8 @@ \end{tabular} \vspace{0.5ex} -A $\RedDSA$ \validatingKey $\vk$ can be encoded as a bit sequence $\reprG{}\Of{\vk}$\, of -length $\ellG{}$ bits (or as a corresponding byte sequence $\vkBytes{}$ by then applying $\LEBStoOSP{\ellG{}}$). +A $\RedDSA$ \validatingKey $\vk$ can be encoded as a \bitSequence $\reprG{}\Of{\vk}$\, of +length $\ellG{}$ bits (or as a corresponding \byteSequence $\vkBytes{}$ by then applying $\LEBStoOSP{\ellG{}}$). \vspace{0.5ex} \introlist @@ -10087,7 +10130,7 @@ Define $\AuthSignBase{Sapling} := \FindGroupJHash\Of{\ascii{Zcash\_G\_}, \ascii{}}$. The \defining{\spendAuthSignatureScheme} $\SpendAuthSig{Sapling}$ is instantiated as $\RedJubjub$ -with key re-randomization and with generator $\GenG{} = \AuthSignBase{Sapling}$. +with key \reRandomization and with generator $\GenG{} = \AuthSignBase{Sapling}$. \nufive{ Let $\RedPallas$ be as defined in \crossref{concretereddsa}. @@ -10095,7 +10138,7 @@ Define $\AuthSignBase{Orchard} := \GroupPHash\Of{\ascii{z.cash:Orchard}, \ascii{G}}$. The \defining{\spendAuthSignatureScheme} $\SpendAuthSig{Orchard}$ is instantiated as $\RedPallas$ -with key re-randomization and with generator $\GenG{} = \AuthSignBase{Orchard}$. +with key \reRandomization and with generator $\GenG{} = \AuthSignBase{Orchard}$. } %nufive \vspace{0.5ex} @@ -10103,7 +10146,7 @@ \vspace{-2ex} \securityrequirement{ -\nufive{Each instantiation of} $\SpendAuthSig{}$ must be a SURK-CMA secure \rerandomizableSignatureScheme +\nufive{Each instantiation of} $\SpendAuthSig{}$ must be a \nh{SURK-CMA-secure} \rerandomizableSignatureScheme as defined in \crossref{abstractsigrerand}. } %securityrequirement } %sapling @@ -10117,18 +10160,18 @@ Let $\RedJubjub$\nufive{ and $\RedPallas$} be as defined in \crossref{concreteredjubjub}. The \Sapling{} \defining{\bindingSignatureScheme}, $\BindingSig{Sapling}$, is instantiated as $\RedJubjub$ -without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Sapling}$ defined in +without key \reRandomization, using generator $\GenG{} = \ValueCommitRandBase{Sapling}$ defined in \crossref{concretevaluecommit}. See \crossref{saplingbalance} for details on the use of this \signatureScheme. \nufive{ The \Orchard{} \defining{\bindingSignatureScheme}, $\BindingSig{Orchard}$, is instantiated as $\RedPallas$ -without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Orchard}$ defined in +without key \reRandomization, using generator $\GenG{} = \ValueCommitRandBase{Orchard}$ defined in \crossref{concretevaluecommit}. See \crossref{orchardbalance} for details on the use of this \signatureScheme. } %nufive \vspace{-2ex} \securityrequirement{ -\nufive{Each instantiation of} $\BindingSig{}$ must be a SUF-CMA secure \keyMonomorphicSignatureScheme +\nufive{Each instantiation of} $\BindingSig{}$ must be a \nh{SUF-CMA-secure} \keyMonomorphicSignatureScheme as defined in \crossref{abstractsigmono}. A signature must prove knowledge of the discrete logarithm of the \validatingKey with respect to the base $\ValueCommitRandBase{Sapling}$\nufive{ or $\ValueCommitRandBase{Orchard}$}. @@ -10223,7 +10266,7 @@ (see \crossref{saplingmerklecrh}). The prefix $\ones{6}$ distinguishes the use of $\WindowedPedersenCommitAlg$ in $\NoteCommitAlg{Sapling}$ from the layer prefix used in $\MerkleCRH{Sapling}$. - That layer prefix is a $6$-bit little-endian encoding of an integer + That layer prefix is a $6$-bit \littleEndian encoding of an integer in the range $\range{0}{\MerkleDepth{Sapling}-1}$; because $\MerkleDepth{Sapling} < 64$, it cannot collide with $\ones{6}$. \item The arguments to $\NoteCommitAlg{Sapling}$ are in a different order to their encodings @@ -10346,7 +10389,7 @@ \vspace{-1ex} \nnote{The output of $\HomomorphicPedersenCommit{Sapling}{}$ may (with negligible probability for a randomly -chosen \commitmentTrapdoor) be the zero point $\ZeroJ$. This would be rejected by consensus if it appeared as +chosen \commitmentTrapdoor) be the zero point of the curve, $\ZeroJ$. This would be rejected by consensus if it appeared as the $\cv$ field of a \spendDescription (\crossref{spenddesc}) or \outputDescription (\crossref{outputdesc}). An implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$.} @@ -10610,7 +10653,7 @@ \item A rational point $P \neq \ZeroG{2}$ on the curve $\CurveG{2}$ can be verified to be of order $\ParamG{r}$, and therefore in $\SubgroupGstar{2}$, by checking that $\ParamG{r} \mult P = \ZeroG{2}$. - \item The use of big-endian order by $\ItoBEBSP{}$ is different from the encoding + \item The use of \bigEndian order by $\ItoBEBSP{}$ is different from the encoding of most other integers in this protocol. The encodings for $\SubgroupGstar{1, 2}$ are consistent with the definition of $\ECtoOSP{}$ for compressed curve points in @@ -10757,11 +10800,11 @@ \item The points at infinity $\ZeroS{1, 2}$ never occur in proofs and have no defined encodings in this protocol. \item In contrast to the corresponding \BNPairing curve, $\CurveS{1}$ over $\GF{\ParamS{q}}$ - is \emph{not} of prime order. + is \emph{not} a \primeOrderCurve. \item A rational point $P \neq \ZeroS{i}$ on the curve $\CurveS{i}$ for $i \in \setof{1, 2}$ can be verified to be of order $\ParamS{r}$, and therefore in $\SubgroupSstar{i}$, by checking that $\ParamS{r} \mult P = \ZeroS{i}$. - \item The use of big-endian order by $\ItoBEBSP{}$ is different from the encoding + \item The use of \bigEndian order by $\ItoBEBSP{}$ is different from the encoding of most other integers in this protocol. \item The encodings for $\SubgroupSstar{1, 2}$ are specific to \Zcash. \item Algorithms for decompressing points from the encodings of @@ -11160,8 +11203,8 @@ \Orchard uses the ``simplified SWU'' algorithm for \randomOracleAdjective hashing to elliptic curves with $j$-invariant $0$, consistent with \cite[section 6.6.3]{ID-hashtocurve}, based on a method by Riad Wahby and Dan Boneh \cite{WB2019}. -It is adapted from work of Eric Brier, Jean-Sébastien Coron, Thomas Icart, David Madore, -Hugues Randriam, and Mehdi Tibouchi in \cite{BCIMRT2010}; Andrew Shallue and Christiaan {van de Woestijne} +It is adapted from work of Eric Brier, \nh{Jean-Sébastien} Coron, Thomas Icart, David Madore, +Hugues Randriam, and Mehdi Tibouchi in \cite{BCIMRT2010}; Andrew Shallue and Christiaan van~de~Woestijne in \cite{SvdW2006}; and Maciej Ulas in \cite{Ulas2007}. Let $\GroupP$ and $\GroupV$ be the represented groups of points on the \pallasCurve and the @@ -11291,7 +11334,7 @@ \item Unlike other uses of $\BlakeTwobGeneric$ in \Zcash, zero bytes are used for the $\BlakeTwobGeneric$ personalization, in order to follow the Internet Draft which encodes $\DST$ in the hash inputs instead. - \item The conversion from bytes to field elements uses big-endian order, again in order + \item The conversion from bytes to field elements uses \bigEndian order, again in order to follow the Internet Draft\rlap{.} \item A minor optimization is to cache the state of the $\BlakeTwob{512}$ instance used to compute $b_0$ after processing $\zerobytes{128}$, since this state does @@ -11349,7 +11392,7 @@ The first input element acts as a domain separator to distinguish uses of the \groupHash for different purposes; the second input element is the message. -This hash-to-curve algorithm does not have a URS, i.e.\ $\GroupGHashURSType := ()$. +This \hashToCurve algorithm does not have a URS, i.e.\ $\GroupGHashURSType := ()$. \introlist The hash $\GroupGHash(D \typecolon \byteseqs, M \typecolon \byteseqs) \typecolon \GroupG{}$ @@ -11374,7 +11417,7 @@ to the Internet Draft, the definition here takes precedence. \item It is not necessary to use the $\clearcofactor$ function specified in the Internet Draft, because \Pallas and \Vesta (and therefore \IsoPallas and \IsoVesta) - are prime-order. + are \primeOrderCurves. \item The above description incorporates optimizations from \cite{WB2019} that avoid inversions and unnecessary square tests in the computation of $\maptocurvesimpleswuIsoG$. In order to fully avoid inversions, the output of $\maptocurvesimpleswuIsoG$ can be @@ -11502,7 +11545,7 @@ \vspace{-0.5ex} \item the lead byte is of the required form; \vspace{-0.5ex} - \item the remaining bytes encode a big-endian representation of an integer in + \item the remaining bytes encode a \bigEndian representation of an integer in $\range{0}{\ParamS{q}\!-\!1}$ or (for $\Proof{B}$) $\range{0}{\ParamSexp{q}{2}\!-\!1}$; \vspace{-0.5ex} @@ -11577,7 +11620,7 @@ \vspace{-0.5ex} \item the leading bitfield is of the required form; \vspace{-0.5ex} - \item the remaining bits encode a big-endian representation of an integer + \item the remaining bits encode a \bigEndian representation of an integer in $\range{0}{\ParamS{q}\!-\!1}$ or (in the case of $\Proof{B}$) two integers in that range; \vspace{-0.5ex} @@ -11600,7 +11643,7 @@ \lsubsubsubsubsection{Encoding of \HaloTwoText{} Proofs}{halo2encoding} \vspace{-1ex} -\HaloTwo proofs are defined as byte sequences, and so the encoding is the proof itself. +\HaloTwo proofs are defined as \byteSequences, and so the encoding is the proof itself. } %nufive @@ -11664,9 +11707,9 @@ This section describes how \Zcash encodes \shieldedPaymentAddresses, \incomingViewingKeys, and \spendingKeys. -Addresses and keys can be encoded as a byte sequence; this is called +Addresses and keys can be encoded as a \byteSequence; this is called the \defining{\rawEncoding}. For \Sprout \shieldedPaymentAddresses, this -byte sequence can then be further encoded using \BaseFiftyEightCheck. The \BaseFiftyEightCheck +\byteSequence can then be further encoded using \BaseFiftyEightCheck. The \BaseFiftyEightCheck layer is the same as for upstream \Bitcoin addresses \cite{Bitcoin-Base58}. \sapling{ @@ -11946,7 +11989,7 @@ considered invalid if $\abstJ$ returns $\bot$. \nufive{\cite{ZIP-216} specifies that the address \MUST also be considered invalid if the -resulting $\DiversifiedTransmitPublic$ is not in the prime-order subgroup $\SubgroupJ$, or +resulting $\DiversifiedTransmitPublic$ is not in the \primeOrderSubgroup $\SubgroupJ$, or if it is a \nonCanonicalPoint encoding as defined in \crossref{abstractgroup}. This \MAY be enforced in advance of activation of \NUFive.} @@ -11982,7 +12025,7 @@ \vspace{-1.5ex} \begin{itemize} - \item $32$ bytes (little-endian) specifying $\InViewingKey$, padded with zeros in the most + \item $32$ bytes (\littleEndian) specifying $\InViewingKey$, padded with zeros in the most significant bits. \end{itemize} @@ -12187,7 +12230,7 @@ \vspace{-2.5ex} \begin{itemize} \item $32$ bytes specifying $\DiversifierKey$. - \item $32$ bytes (little-endian) specifying $\InViewingKey$. + \item $32$ bytes (\littleEndian) specifying $\InViewingKey$. \end{itemize} \vspace{-1.5ex} @@ -12234,9 +12277,9 @@ \vspace{-2.5ex} \begin{itemize} - \item $32$ bytes (little-endian) specifying $\AuthSignPublic$. - \item $32$ bytes (little-endian) specifying $\NullifierKey$. - \item $32$ bytes (little-endian) specifying $\CommitIvkRand$. + \item $32$ bytes (\littleEndian) specifying $\AuthSignPublic$. + \item $32$ bytes (\littleEndian) specifying $\NullifierKey$. + \item $32$ bytes (\littleEndian) specifying $\CommitIvkRand$. \end{itemize} \introlist @@ -12297,7 +12340,7 @@ \end{lines} \vspace{-0.5ex} -These parameters were obtained by a multi-party computation described in +These parameters were obtained by a \multiPartyComputation described in \cite{BGG-mpc} and \cite{BGG2017}. \sapling{They are used only before \Sapling activation.} Due to the security vulnerability described in \crossref{bctv}, it is not recommended to use these parameters in new protocols, and it is recommended to @@ -12323,7 +12366,7 @@ \texttt{d5054e371842b3f88fa1b9d7e8e075249b3ebabd167fa8b0f3161292d36c180a sprout-groth16.params} \end{lines} -These parameters were obtained by a multi-party computation described in \cite{BGM2017}. +These parameters were obtained by a \multiPartyComputation described in \cite{BGM2017}. } %sapling @@ -12334,7 +12377,7 @@ Let $\URS := \ascii{096b36a5804bfacef1691e173c366a47ff5ba84a44f26ddd7e8d9f79d5b42df0}$. This value is used in the definition of $\GroupJHash{}$ in \crossref{concretegrouphashjubjub}, -and in the multi-party computation to obtain the \Sapling parameters given in +and in the \multiPartyComputation to obtain the \Sapling parameters given in \crossref{grothparameters}. \introlist @@ -12342,13 +12385,13 @@ \begin{itemize} \item Take the hash of the \Bitcoin \block at height $514200$ in \rpcByteOrder, - i.e.\ the big-endian $32$-byte representation of $\hexint{00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58}$. + i.e.\ the \bigEndian $32$-byte representation of $\hexint{00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58}$. \item Apply \shaHash $2^{42}$ times. - \item Convert to a US-ASCII lowercase hexadecimal string. + \item Convert to a \xUSASCII lowercase hexadecimal string. \end{itemize} \vspace{-2ex} -\pnote{$\URS$ is a $64$-byte US-ASCII string, i.e.\ the first byte is \hexint{30}, not \hexint{09}.} +\pnote{$\URS$ is a $64$-byte \xUSASCII string, i.e.\ the first byte is \hexint{30}, not \hexint{09}.} } %sapling @@ -12408,7 +12451,7 @@ \end{itemize} Full support for each \networkUpgrade is indicated by a minimum version -of the peer-to-peer protocol. At the planned \activationHeight, +of the \peerToPeerProtocol. At the planned \activationHeight, nodes that support a given upgrade will disconnect from (and will not reconnect to) nodes with a protocol version lower than this minimum. \overwinter{See \cite{ZIP-201} for how this applies to the \Overwinter @@ -12675,7 +12718,7 @@ \nufive{ The \transactionID of a version 5 \transaction is as defined in \cite{ZIP-244}. A v5 -\transaction also has a \wtxid (used for example in the peer-to-peer protocol) as defined +\transaction also has a \wtxid (used for example in the \peerToPeerProtocol) as defined in \cite{ZIP-239}. } %nufive @@ -12756,7 +12799,7 @@ \item A \coinbaseTransaction for a \block at \blockHeight greater than $0$ \MUST have a script that, as its first item, encodes the \blockHeight $\BlockHeight$ as follows. For $\BlockHeight$ in the range $\range{1}{16}$, the encoding is a single byte of value $\hexint{50} + \BlockHeight$. - Otherwise, let $\heightBytes$ be the signed little-endian representation of $\BlockHeight$, + Otherwise, let $\heightBytes$ be the signed \littleEndian representation of $\BlockHeight$, using the minimum nonzero number of bytes such that the most significant byte is $< \hexint{80}$. The length of $\heightBytes$ \MUST be in the range $\range{1}{5}$. Then the encoding is the length of $\heightBytes$ encoded as one byte, followed by $\heightBytes$ itself. This matches @@ -13206,7 +13249,7 @@ \vspace{2ex} A \block consists of a \blockHeader and a sequence of \transactions. How transactions -are encoded in a \block is part of the Zcash peer-to-peer protocol but not part of +are encoded in a \block is part of the Zcash \peerToPeerProtocol but not part of the consensus protocol. \vspace{1ex} @@ -13342,12 +13385,12 @@ \introsection \lsubsection{Proof of Work}{pow} -\Zcash uses \Equihash \cite{BK2016} as its Proof of Work. The original motivations for -changing the Proof of Work from \shadHash used by \Bitcoin were described in \cite{WG2016}. +\Zcash uses \Equihash \cite{BK2016} as its \proofOfWork. The original motivations for +changing the \proofOfWork from \shadHash used by \Bitcoin were described in \cite{WG2016}. \vspace{1ex} \introlist -A \block satisfies the Proof of Work if and only if: +A \block satisfies the \proofOfWork if and only if: \begin{itemize} \item The $\solution$ field encodes a \validEquihashSolution according to \crossref{equihash}. @@ -13473,10 +13516,10 @@ $[0, 2, 32, 0, 10, 127, 255]$. \pnote{ -$\ItoBEBSP{}$ is big-endian, while integer field encodings in $\powheader$ -and in the instantiation of $\EquihashGen{}$ are little-endian. -The rationale for this is that little-endian serialization of -\blockHeaders is consistent with \Bitcoin, but little-endian +$\ItoBEBSP{}$ is \bigEndian, while integer field encodings in $\powheader$ +and in the instantiation of $\EquihashGen{}$ are \littleEndian. +The rationale for this is that \littleEndian serialization of +\blockHeaders is consistent with \Bitcoin, but \littleEndian ordering of bits in the solution encoding would require bit-reversal (as opposed to only shifting). } @@ -13490,7 +13533,7 @@ The difficulty filter is unchanged from \Bitcoin, and is calculated using \shadHash on the whole \blockHeader (including $\solutionSize$ and $\solution$). -The result is interpreted as a $256$-bit integer represented in little-endian +The result is interpreted as a $256$-bit integer represented in \littleEndian byte order, which \MUST be less than or equal to the \targetThreshold given by $\ToTarget(\nBitsField)$. @@ -13999,7 +14042,7 @@ in \crossref{transparentaddrencoding}. \introlist -\cite{BIP-111} applies from peer-to-peer network protocol version $170004$ onward; that is: +\cite{BIP-111} applies from \peerToPeerProtocol version $170004$ onward; that is: \begin{itemize} \item references to protocol version $70002$ are to be replaced by $170003$; \item references to protocol version $70011$ are to be replaced by $170004$; @@ -14078,7 +14121,7 @@ Mints. An advantage of this is that a \Zcash \transaction that takes input from a \utxo can produce up to $\NNew$ output \notes, improving the indistinguishability properties of the protocol. A related change -conceals the input arity of the \joinSplitTransfer: an unused (zero-value) +conceals the input arity of the \joinSplitTransfer: an unused (zero-valued) input is indistinguishable from an input that takes value from a \note. } @@ -14290,7 +14333,7 @@ pairs $(\AuthPublic, \NoteUniqueRand)$ and $(\AuthPublic\!', \NoteUniqueRand')$ with colliding outputs of the truncated hash, and therefore the same \noteCommitment. This would have allowed such an attacker to break the -Balance property by double-spending \notes, potentially creating arbitrary +Balance property by \doubleSpending \notes, potentially creating arbitrary amounts of currency for themself \cite{HW2016}. \Zcash uses a simpler construction with a single hash evaluation for the @@ -14444,8 +14487,8 @@ \lsubsection{In-band secret distribution}{inbandrationale} \Zerocash specified ECIES (referencing Certicom's SEC 1 standard) as the -encryption scheme used for the in-band secret distribution. This has been -changed to a key agreement scheme based on $\KASproutCurve$ (for \Sprout)\sapling{ or +encryption scheme used for the \inBand secret distribution. This has been +changed to a \keyAgreementScheme based on $\KASproutCurve$ (for \Sprout)\sapling{ or \Jubjub (for \Sapling)} and the authenticated encryption algorithm $\SymSpecific$. This scheme is still loosely based on ECIES, and on the $\CryptoBoxSeal$ scheme defined in libsodium \cite{libsodium-Seal}. @@ -14455,7 +14498,7 @@ \begin{itemize} \item The \Zerocash paper did not specify the curve to be used. - We believe that $\KASproutCurve$ has significant side-channel resistance, + We believe that $\KASproutCurve$ has significant \sideChannel resistance, performance, implementation complexity, and robustness advantages over most other available curve choices, as explained in \cite{Bernstein2006}. \sapling{For \Sapling, the \jubjubCurve was designed according to a @@ -14463,7 +14506,7 @@ \cite{BL-SafeCurves} \cite{Hopwood2018}. This retains $\KASproutCurve$'s advantages while keeping \shieldedPaymentAddress sizes short, because the same \publicKey material supports both encryption and - spend authentication.} \nufive{For \Orchard, we define a prime-order curve + spend authentication.} \nufive{For \Orchard, we define a \primeOrderCurve \Pallas \cite{Hopwood2020}, with similar advantages to \Jubjub.} \item ECIES permits many options, which were not specified. There are at least --counting conservatively-- 576 possible combinations of options and @@ -14545,7 +14588,7 @@ For all shielded protocols, the checking of \noteCommitments makes \defining{\partitioningOracleAttacks} \cite{LGR2021} against the \noteCiphertext -infeasible, at least in the absence of side-channel attacks. \sapling{The following +infeasible, at least in the absence of \sideChannel attacks. \sapling{The following argument applies to \Sapling\nufive{ and \Orchard}, but can be adapted to \Sprout by replacing $\InViewingKey$ with $\TransmitPrivate$, $\DiversifiedTransmitPublic$ with $\TransmitPublic$, and using a fixed base. The decryption procedure @@ -14588,7 +14631,7 @@ $\AuthPrivateSup{1}$ and $\AuthPrivateSup{2}$ are distinct \spendingKeys for the same $\AuthPublic$. Because the \noteCommitment is to $\AuthPublic$, but the \nullifier is computed from $\AuthPrivate$ (and $\NoteUniqueRand$), -the adversary is able to double-spend the note, once with each $\AuthPrivate$. +the adversary is able to \doubleSpend the note, once with each $\AuthPrivate$. This is not detected because each Spend reveals a different \nullifier. The \joinSplitStatements are still valid because they can only check that the $\AuthPrivate$ in the witness is \emph{some} preimage of @@ -14665,15 +14708,15 @@ \introlist \lsection{Acknowledgements}{acknowledgements} -The inventors of \Zerocash are Eli Ben-Sasson, Alessandro Chiesa, +The inventors of \Zerocash are Eli \nh{Ben-Sasson}, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. The designers of the \Zcash protocol are the \Zerocash inventors -and also Daira Emma Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornby, -Nathan Wilcox, Zooko Wilcox, Jay Graber, Eirik Ogilvie-Wigley, Ariel Gabizon, +and also \nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornby, +Nathan Wilcox, Zooko Wilcox, Jay Graber, Eirik \nh{Ogilvie-Wigley}, Ariel Gabizon, George Tankersley, Ying~Tong Lai, Kris Nuttycombe, Jack Gavigan, Steven Smith, and Greg Pfeil. -The \Equihash proof-of-work algorithm was designed by Alex Biryukov and +The \Equihash \proofOfWork algorithm was designed by Alex Biryukov and Dmitry Khovratovich. The authors would like to thank everyone with whom they have discussed the @@ -14683,12 +14726,12 @@ John Tromp, Paige Peterson, jl777, Alison Stevenson, Maureen Walsh, Filippo Valsorda, Zaki Manian, Kexin Hu, Brian Warner, Mary Maller, Michael Dixon, Andrew Poelstra, Benjamin Winston, Josh Cincinnati, -Kobi Gurkan, Weikeng Chen, Henry de Valence, Deirdre Connolly, Chelsea Komlo, -Zancas Wilcox, Jane Lusby, Teor, Izaak Meckler, Zac Williamson, Vitalik Buterin, +Kobi Gurkan, Weikeng Chen, Henry de~Valence, Deirdre Connolly, Chelsea Komlo, +Zancas Wilcox, Jane Lusby, teor, Izaak Meckler, Zac Williamson, Vitalik Buterin, Jakub Zalewski, Oana Ciobotaru, Andre Serrano, Brad Miller, Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, -Kevin Gorham, Larry Ruane, Marshall Gaucher, Ryan Taylor, Sasha Meyer, and no -doubt others. +Kevin Gorham, Larry Ruane, Marshall Gaucher, Ryan Taylor, Sasha Meyer, +Conrado Gouvea, and no doubt others. We would also like to thank the designers and developers of \Bitcoin and \BitcoinCore. @@ -14699,12 +14742,16 @@ The Faerie Gold attack was found by Zooko Wilcox (who also came up with the name) and Brian Warner. The fix for this attack in \Sprout was proposed by -Daira Emma Hopwood; subsequent analysis of variations on the attack was -performed by Daira Emma Hopwood and Sean Bowe. The internal hash collision -attack was found by Taylor Hornby. The error in the \Zerocash proof of -Balance relating to \collisionResistance of $\PRFaddr{}$ was found by -Daira Emma Hopwood. The errors in the proof of Ledger Indistinguishability -mentioned in \crossref{truncation} were also found by Daira Emma Hopwood. +\nh{Daira-Emma} Hopwood; subsequent analysis of variations on the attack was +performed by \nh{Daira-Emma} Hopwood and Sean Bowe. + +The internal hash collision attack was found by Taylor Hornby. + +The error in the \Zerocash proof of Balance relating to \collisionResistance +of $\PRFaddr{}$ was found by \nh{Daira-Emma} Hopwood. + +The errors in the proof of Ledger Indistinguishability mentioned in +\crossref{truncation} were also found by \nh{Daira-Emma} Hopwood. The 2015 Soundness vulnerability in \BCTV \cite{Parno2015} was found by Bryan Parno. An additional condition needed to resist this attack was @@ -14713,11 +14760,11 @@ was found by Ariel Gabizon. The design of \Sapling is primarily due to Matthew Green, Ian Miers, -Daira Emma Hopwood, Sean Bowe, Jack Grigg, and Jack Gavigan. A potential attack +\nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, and Jack Gavigan. A potential attack linking \diversifiedPaymentAddresses, avoided in the adopted design, was found by Brian Warner. -The design of \Orchard is primarily due to Daira Emma Hopwood, Sean Bowe, Jack Grigg, +The design of \Orchard is primarily due to \nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, Kris Nuttycombe, Ying~Tong Lai, and Steven Smith. The observation in \crossref{concretediversifyhash} that @@ -14730,8 +14777,8 @@ The arithmetization used by \HaloTwo is based on that used by \PLONK \cite{GWC2019}, which was designed by Ariel Gabizon, Zachary Williamson, and Oana Ciobotaru. -Numerous people have contributed to the science of zero-knowledge proving -systems, but we would particularly like to acknowledge the work of +Numerous people have contributed to the science of \zeroKnowledgeProvingSystems, +but we would particularly like to acknowledge the work of Shafi Goldwasser, Silvio Micali, Oded Goldreich, Mihir Bellare, Charles Rackoff, Rosario Gennaro, Bryan Parno, Jon Howell, Craig Gentry, Mariana Raykova, Jens Groth, Rafail Ostrovsky, and Amit Sahai. @@ -14742,12 +14789,12 @@ work on the Zero Knowledge Podcast, ZK Summits, and ZK Study Club. These efforts have enriched the zero knowledge community immeasurably. -Many of the ideas used in \Zcash{} ---including the use of zero-knowledge proofs +Many of the ideas used in \Zcash{} ---including the use of \zeroKnowledgeProofs to resolve the tension between privacy and auditability, Merkle trees over note commitments (using Pedersen hashes as in \Sapling), and the use of ``serial numbers'' or \nullifiers to detect or prevent -double-spends--- were first applied to privacy-preserving digital currencies -by Tomas Sander and Amnon Ta-Shma. To a large extent \Zcash is a refinement +\doubleSpends--- were first applied to privacy-preserving digital currencies +by Tomas Sander and Amnon \nh{Ta-Shma}. To a large extent \Zcash is a refinement of their ``Auditable, Anonymous Electronic Cash'' proposal in \cite{ST1999}. We thank Alexandra Elbakyan for her tireless work in dismantling barriers @@ -14764,6 +14811,17 @@ \intropart \lsection{Change History}{changehistory} +\historyentry{Unreleased}{2024-04-14} + +\begin{itemize} + \item Add the hyphen in \nh{Daira-Emma} Hopwood. + \item Correct some author lists in the References. + \item Prevent incorrect line-breaking on hyphens. + \item In \crossref{concretesinsemillahash}, declare use of $\LEBStoIP{}$ instead of $\LEOStoIP{}$. + \item Add an acknowledgement to Conrado Gouvea for discussions on the Zcash protocol. +\end{itemize} + + \historyentry{2023.4.0}{2023-12-19} \begin{itemize} @@ -14795,14 +14853,14 @@ \item In the discussion of partitioning oracle attacks on \note encryption in \crossref{inbandrationale}, we now use the fact that $\DiversifiedTransmitBase$ has order greater than the maximum value of $\InViewingKey$, rather than assuming that $\DiversifiedTransmitBase$ is a non-zero point - in the prime-order subgroup. (In the case of \Sapling, the circuits only enforce that - $\DiversifiedTransmitBase$ is not a small-order point, not that it is in the prime-order - subgroup. It is true that honestly generated addresses have prime-order $\DiversifiedTransmitBase$ + in the \primeOrderSubgroup. (In the case of \Sapling, the circuits only enforce that + $\DiversifiedTransmitBase$ is not a \smallOrderAdjective point, not that it is in the \primeOrderSubgroup. + It is true that honestly generated addresses have \primeOrderAdjective $\DiversifiedTransmitBase$ which would have been sufficient for the security argument against this class of attacks, but the chosen fix is more direct.) \item Delete a confusing claim in \crossref{spenddesc} that ``The check that $\AuthSignRandomizedPublic$ - is not of small order is technically redundant with a check in the \spendCircuit ...''. - The small-order check excludes the zero point $\ZeroJ$, which the \snarkref{Spend authority}{spendauthority} + is not of \smallOrder is technically redundant with a check in the \spendCircuit ...''. + The \smallOrderAdjective check excludes the zero point $\ZeroJ$, which the \snarkref{Spend authority}{spendauthority} check that this claim was intending to reference does not. \item An implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$, in order to avoid @@ -14822,11 +14880,11 @@ \item The abstract no longer describes the \NUFive version of the specification as a draft. } \item Acknowledge Greg Pfeil as a co-designer of the \Zcash protocol. - \item Acknowledge Daira Emma Hopwood for the fix to the Faerie Gold attack in \Sprout, and add a reference + \item Acknowledge \nh{Daira-Emma} Hopwood for the fix to the Faerie Gold attack in \Sprout, and add a reference to hir \textsl{Explaining the Security of Zcash} talk at Zcon3 \cite{Hopwood2022} for repairs to the \Zerocash security definitions. \item Acknowledge the font designers Pablo Impallari and Morris Fuller. - \item Change Daira Emma Hopwood's name. + \item Change \nh{Daira-Emma} Hopwood's name. \end{itemize} @@ -14917,7 +14975,7 @@ apply only when $\effectiveVersion \geq 5$ (since v4 \transactions did not explicitly encode the \nConsensusBranchId{} field). \item Correction in \crossref{constants}: - $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$ is not a bit sequence. + $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$ is not a \bitSequence. \item In \crossref{txnencoding}, add the calculation for \sizeProofsOrchard{} to the v5 \transaction format table. } @@ -15046,8 +15104,7 @@ may be sampled from $\range{0}{2^{128}-1}$ instead of $\range{1}{2^{128}-1}$. \item Add note in \crossref{inbandrationale} about resistance of \note encryption to \partitioningOracleAttacks \cite{LGR2021}. - \item Add acknowledgement to Mihir Bellare for contributions to the science of zero-knowledge - proofs. + \item Add acknowledgement to Mihir Bellare for contributions to the science of \zeroKnowledgeProofs. \item Add acknowledgement to Sasha Meyer. \end{itemize} @@ -15065,7 +15122,7 @@ $\rt{Orchard} \in \GroupP_{\!x}$ would require a square root and is unnecessary. \item Witness $\DiversifiedTransmitBaseNew$ and $\DiversifiedTransmitPublicNew$ in the \Orchard \actionCircuit as $\GroupPstar$, i.e.\ non-identity Pallas points, - rather than witnessing their representations as bit sequences. This reflects + rather than witnessing their representations as \bitSequences. This reflects the existing \zcashd implementation. \item Note that $\AuthSignPublicPoint$ in \Orchard cannot be the identity. } %nufive @@ -15108,9 +15165,8 @@ \historyentry{2021.2.13}{2021-07-29} \begin{itemize} - \item Add consensus rules in \crossref{notecommitmenttrees} that a \block \MUSTNOT add - \noteCommitments that exceed the capacity of any of the \Sprout\sapling{ or - \Sapling}\nufive{ or \Orchard} \noteCommitmentTrees. + \item Add consensus rules in \crossref{notecommitmenttrees} that, for each \noteCommitmentTree, + a \block \MUSTNOT add \noteCommitments that exceed the capacity of that tree. \end{itemize} @@ -15217,7 +15273,7 @@ \begin{itemize} \nufive{ \item Correct the type of $\Uncommitted{Orchard}$, which should be $\GroupP_{\!x}$ rather than a - bit sequence. + \bitSequence. \item Explicitly say that padding in \crossref{concretesinsemillahash} is by appending zero bits. \item Add a step to the algorithm for generating an \Orchard \note in \crossref{orchardsend}, to restart if $\EphemeralPrivate = 0$. @@ -15301,7 +15357,7 @@ $\barerange{1}{16}$. \item Clarify, in \crossref{blockchain}, requirements on the range of \blockHeights that should be supported. - \item Delete the sentence ``All conversions between \EdSpecific points, byte sequences, + \item Delete the sentence ``All conversions between \EdSpecific points, \byteSequences, and integers used in this section are as specified in \cite{BDLSY2012}.'' from \crossref{concreteed25519}. This sentence was misleading given that the conversions in $\cite{BDLSY2012}$ are not sufficiently well-specified for a consensus @@ -15447,7 +15503,7 @@ } %nufive \sapling{ \item Fix type error in $\kdfinput$ for $\KDF{Sapling}$\nufive{ and $\KDF{Orchard}$} - ($\ephemeralKey$ is already a byte sequence). + ($\ephemeralKey$ is already a \byteSequence). \item Make a note in \crossref{inbandrationale} of the divergence of $\InViewingKey$ for \SaplingAndOrchard from a uniform scalar. } %sapling @@ -15462,7 +15518,7 @@ \historyentry{2021.1.20}{2021-03-25} \begin{itemize} - \item Credit Eirik Ogilvie-Wigley as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller, + \item Credit Eirik \nh{Ogilvie-Wigley} as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller, Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, Kevin Gorham, Larry Ruane, Marshall Gaucher, and Ryan Taylor to the acknowledgements. \nufive{ @@ -15643,10 +15699,10 @@ \sapling{ \item Correct the \Sapling \note decryption algorithms: \begin{itemize} - \item $\ephemeralKey$ is kept as a byte sequence rather than immediately converted to a + \item $\ephemeralKey$ is kept as a \byteSequence rather than immediately converted to a curve point; this matters because of \nonCanonicalPoint encoding. \item The representation of $\DiversifiedTransmitPublic$ in a \notePlaintext may also be - \nonCanonicalPoint and need not be in the prime subgroup. + \nonCanonicalPoint and need not be in the \primeOrderSubgroup. \item Move checking of $\cmU$ in decryption with $\InViewingKey$ to the end of the algorithm, to more closely match the implementation. \item The note about decryption of outputs in \mempool \transactions should have been @@ -15675,7 +15731,7 @@ (This rule was correctly implemented in \zcashd.) \sapling{ \item Fix a type error in the output of $\PRFnf{Sapling}{}$; a \Sapling \nullifier is a - sequence of $32$ bytes, not a bit sequence. + sequence of $32$ bytes, not a \bitSequence. \item Correct an off-by-one in an expression used in the definition of $c$ in \crossref{concretepedersenhash} (this does not change the value of $c$). } %sapling @@ -15745,12 +15801,12 @@ \historyentry{2020.1.9}{2020-07-05} \begin{itemize} \item Add \crossref{networks}. - \item Acknowledge Jane Lusby and Teor. + \item Acknowledge Jane Lusby and teor. \item Precisely specify the encoding and decoding of \EdSpecific points. \sapling{ \item Correct an error introduced in \historyref{2020.1.8}; ``$-\ZeroJ$'' was incorrectly used when the point $(0, -1)$ on \Jubjub was meant. - \item Precisely specify the conversion from a bit sequence in $\abstJ$. + \item Precisely specify the conversion from a \bitSequence in $\abstJ$. } %sapling \end{itemize} @@ -16097,9 +16153,9 @@ Bryan Parno. \item Specify the difficulty adjustment change that occurred on \Testnet at \blockHeight $299188$. - \item Add Eirik Ogilvie-Wigley and Benjamin Winston to acknowledgements. + \item Add Eirik \nh{Ogilvie-Wigley} and Benjamin Winston to acknowledgements. \sapling{ - \item Rename zk-SNARK Parameters sections to be named according to the proving + \item Rename \zkSNARK Parameters sections to be named according to the proving system (\BCTV or \Groth), not the shielded protocol construction (\Sprout or \Sapling). \item In \crossref{networkupgrades}, say when \Sapling activated. @@ -16125,7 +16181,7 @@ to match sapling-crypto. \item Describe $2$-bit window lookup with conditional negation in \crossref{cctpedersenhash}. \item Fix or complete various calculations of constraint costs. - \item Adjust the notation used for scalar multiplication in Appendix A to allow bit sequences + \item Adjust the notation used for scalar multiplication in Appendix A to allow \bitSequences as scalars. } %sapling \end{itemize} @@ -16238,7 +16294,7 @@ how verification depends on \primaryInputs. } %sapling \item Add Charles Rackoff, Rafail Ostrovsky, and Amit Sahai to the acknowledgements - section for their work on zero-knowledge proofs. + section for their work on \zeroKnowledgeProofs. \end{itemize} \historyentry{2018.0-beta-26}{2018-08-05} @@ -16318,8 +16374,8 @@ \item Clarify attribution of the \Zcash protocol design. \item Acknowledge Alex Biryukov and Dmitry Khovratovich as the designers of \Equihash. \item Acknowledge Shafi Goldwasser, Silvio Micali, Oded Goldreich, Rosario Gennaro, Bryan Parno, Jon Howell, - Craig Gentry, Mariana Raykova, and Jens Groth for their work on zero-knowledge proving systems. - \item Acknowledge Tomas Sander and Amnon Ta–Shma for \cite{ST1999}. + Craig Gentry, Mariana Raykova, and Jens Groth for their work on \zeroKnowledgeProvingSystems. + \item Acknowledge Tomas Sander and Amnon \nh{Ta-Shma} for \cite{ST1999}. \item Acknowledge Kudelski Security's audit. \sapling{ \item Use the more precise subgroup types $\SubgroupG{}$ and $\SubgroupJ$ in preference to @@ -16332,7 +16388,7 @@ field of an \outputDescription{} must be canonical encodings. \item Enforce that $\EphemeralPrivate$ in $\outCiphertext$ is a canonical encoding. \item Add consensus rules that $\cv$ in a \spendDescription, and $\cv$ and $\EphemeralPublic$ in an - \outputDescription, are not of small order. Exclude $0$ from the range of $\EphemeralPrivate$ + \outputDescription, are not of \smallOrder. Exclude $0$ from the range of $\EphemeralPrivate$ when encrypting \Sapling notes. \item Add a consensus rule that $\valueBalance{Sapling}$ is in the range $\range{-\MAXMONEY}{\MAXMONEY}$. \item Enforce stronger constraints on the types of key components $\DiversifiedTransmitPublic$, @@ -16402,7 +16458,7 @@ \item Change the notation $\RedDSAHash^{\star}$ to $\RedDSAHashToScalar$ in \crossref{concreteredjubjub}, to avoid confusion with the $^{\Repr}$ convention for representations of group elements. \item $\cmuField$ encodes only the $u$-coordinate of the \noteCommitment, not the full curve point. - \item $\AuthSignRandomizedPublic$ is checked to be not of small order outside the \spendStatement, + \item $\AuthSignRandomizedPublic$ is checked to be not of \smallOrder outside the \spendStatement, not in the \spendStatement. \item Change terminology describing constraint systems. } %sapling @@ -16446,10 +16502,10 @@ \item Explicitly note that outputs from \coinbaseTransactions include \foundersReward outputs. \item The point represented by $\EdDSAReprR{}$ in an \EdSpecific signature is checked - to not be of small order; this is not the same as checking that it is of - prime order $\ell$. + to not be of \smallOrder; this is not the same as checking that it is of + \primeOrder $\ell$. \item Specify support for \cite{BIP-111} (the \texttt{NODE\_BLOOM} service bit) - in peer-to-peer network protocol version $170004$. + in \peerToPeerProtocol version $170004$. \item Give references \cite{Vercauter2009} and \cite{AKLGL2010} for the optimal ate pairing. \item Give references for BLS \cite{BLS2002} and BN \cite{BN2005} curves. \item Define $\KADerivePublic{Sprout}$ for $\KASproutCurve$. @@ -16494,7 +16550,7 @@ \item Updates to \Sapling construction, changing how the \nullifier is computed and separating it from the \authRandomizedValidatingKey ($\AuthSignRandomizedPublic$). - \item Clarify conversions between bit and byte sequences for + \item Clarify conversions between \bitSequences and \byteSequences for $\SpendingKey$, $\reprJ\Of{\AuthSignPublic}$, and $\reprJ\Of{\NullifierKey}$. } %sapling \item Change the \Makefile to avoid multiple reloads in PDF readers while @@ -16531,7 +16587,7 @@ \item delete not-all-one component which is no longer needed \item factor out xor into its own component \item specify [un]packing more precisely; separate it from boolean constraints - \item optimize checking for non-small order + \item optimize checking for non-\smallOrder \item notation in variable-base multiplication algorithm. \end{itemize} } @@ -16631,7 +16687,7 @@ collision with $\KASproutCurve$ scalar ``clamping''. \item Change uses of the term \term{full node} to \fullValidator. A \defining{\term{full node}} by definition participates in the - peer-to-peer network, whereas a \fullValidator just needs a copy + \peerToPeerNetwork, whereas a \fullValidator just needs a copy of the \blockChain from somewhere. The latter is what was meant. \sapling{ \item Add an explanation of how \Sapling prevents Faerie Gold and @@ -16721,7 +16777,7 @@ \historyentry{2017.0-beta-2.5}{2017-03-07} \begin{itemize} - \item Clarify the consensus rule preventing double-spends. + \item Clarify the consensus rule preventing \doubleSpends. \item Clarify what a \noteCommitment opens to in \crossref{crprf}. \item Correct the order of arguments to $\CommitAlg$ in \crossref{concretesproutnotecommit}. \item Correct a statement about indistinguishability of \joinSplitDescriptions. @@ -16849,7 +16905,7 @@ \item Update the section on encoding of \transparentAddresses. (The precise prefixes are not decided yet.) \item Clarify why $\BlakeTwob{\ell}$ is different from truncated $\BlakeTwob{512}$. - \item Clarify a note about SU-CMA security for signatures. + \item Clarify a note about \nh{SU-CMA} security for signatures. \item Add a note about $\PRFnf{Sprout}{}$ corresponding to $\PRFsn{}$ in \Zerocash. \item Add a paragraph about key length in \crossref{inbandrationale}. \item Add acknowledgements for John Tromp, Paige Peterson, Maureen Walsh, @@ -16860,7 +16916,7 @@ \begin{itemize} \item Update the \foundersReward address list. - \item Add some clarifications based on Eli Ben-Sasson's review. + \item Add some clarifications based on Eli \nh{Ben-Sasson}'s review. \end{itemize} \historyentry{2016.0-beta-1.4}{2016-09-19} @@ -16905,7 +16961,7 @@ \item Major reorganization to separate the abstract cryptographic protocol from the algorithm instantiations. \item Add type declarations. - \item Add a ``High-level Overview'' section. + \item Add a ``\nh{High-level} Overview'' section. \item Add a section specifying the \zeroKnowledgeProvingSystem and the encoding of proofs. Change the encoding of points in proofs to follow IEEE Std 1363[a]. @@ -16920,7 +16976,7 @@ match the implemented protocol. \item Add a consensus rule about the ranges of $\vpubOld$ and $\vpubNew$. \item Clarify cryptographic security requirements and added definitions - relating to the in-band secret distribution. + relating to the \inBand secret distribution. \item Add various citations: the ``Fixing Vulnerabilities in the Zcash Protocol'' and ``Why Equihash?'' blog posts, several crypto papers for security definitions, the \Bitcoin whitepaper, the \CryptoNote @@ -17045,9 +17101,9 @@ we name as $(P^u, P^{\spv})$ for an \affineCtEdwards point, for instance. The implementations of scalar multiplication require the scalar to be represented -as a bit sequence. We therefore allow the notation $\scalarmult{k\Repr}{P}$ meaning +as a \bitSequence. We therefore allow the notation $\scalarmult{k\Repr}{P}$ meaning $\scalarmult{\LEBStoIPOf{\length(k\Repr)}{k\Repr}}{P}$. There will be no ambiguity -because variables representing bit sequences are named with a $\Repr$ suffix. +because variables representing \bitSequences are named with a $\Repr$ suffix. \introlist The \defining{\MontgomeryCurve} $\MontCurve$ has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = 1$. @@ -17082,7 +17138,7 @@ \item $\CompressedCtEdwardsJubjub := (\tilde{u} \typecolon \bit) \times (\varv \typecolon \GF{\ParamS{r}})$ \end{formulae} \vspace{-1.5ex} -See \crossref{jubjub} for how this type is represented as a byte sequence in +See \crossref{jubjub} for how this type is represented as a \byteSequence in external encodings. \vspace{2ex} @@ -17328,7 +17384,7 @@ So all of $a_{\barerange{0}{n-1}}$ are at least boolean-constrained. To prove the rest of the theorem we proceed by induction on decreasing $m$, -i.e.\ taking successively longer prefixes of the big-endian binary representations +i.e.\ taking successively longer prefixes of the \bigEndian binary representations of $a$ and $c$. Base case $m = n-1$: since $c_{n-1} = 1$, the constraint system has @@ -17647,7 +17703,7 @@ \end{formulae} \introlist -We use an optimized implementation found by Daira Emma Hopwood making use of an +We use an optimized implementation found by \nh{Daira-Emma} Hopwood making use of an observation by Bernstein and Lange in \cite[last paragraph of section 4.5.2]{BL2017}: \begin{formulae} @@ -17692,11 +17748,11 @@ \lsubsubsubsection{Affine-ctEdwards nonsmall-order check}{cctednonsmallorder} In order to avoid small-subgroup attacks, we check that certain points used in the -circuit are not of small order. In practice the \Sapling circuit uses this +circuit are not of \smallOrder. In practice the \Sapling circuit uses this in combination with a check that the coordinates are on the curve (\crossref{cctedvalidate}), so we combine the two operations. -The \jubjubCurve has a large prime-order subgroup with a cofactor of $8$. +The \jubjubCurve has a large \primeOrderSubgroup with a cofactor of $8$. To check for a point $P$ of order $8$ or less, the \Sapling circuit doubles three times (as in \crossref{cctedarithmetic}) and checks that the resulting $u$-coordinate is not $0$ (as in \crossref{cctnonzero}). @@ -17708,7 +17764,7 @@ The total cost, including the curve check, is $4 + 3 \mult 5 + 1 = 20$ constraints. -\pnote{This \emph{does not} ensure that the point is in the prime-order subgroup.} +\pnote{This \emph{does not} ensure that the point is in the \primeOrderSubgroup.} \begin{nnotes} \item It would have been sufficient to do two doublings rather than three, because @@ -17759,8 +17815,8 @@ - \spv_2 \smult s_1 \plus \spv_4 \smult s\suband - \spv_4 \smult s_2 - \spv_6 \smult s\suband}$ \end{formulae} -For a full-length ($252$-bit) scalar this costs $3$ constraints for each of $84$ window lookups, -plus $6$ constraints for each of $83$ ctEdwards additions (as in \crossref{cctedarithmetic}), for +For a \nh{full-length ($252$-bit)} scalar this costs $3$ constraints for each of $84$ window lookups, +plus $6$ constraints for each of $83$ \xCtEdwards additions (as in \crossref{cctedarithmetic}), for a total of $750$ constraints. Fixed-base scalar multiplication is also used in two places with shorter scalars: @@ -17829,8 +17885,8 @@ \item let $R = \Acc_{250}$. \end{algorithm} -This costs $5$ constraints for each of $250$ ctEdwards doublings, $6$ constraints for each -of $250$ ctEdwards additions, and $2$ constraints for each of $251$ point selections, +This costs $5$ constraints for each of $250$ \xCtEdwards doublings, $6$ constraints for each +of $250$ \xCtEdwards additions, and $2$ constraints for each of $251$ point selections, for a total of $3252$ constraints. \nnote{ @@ -17895,7 +17951,7 @@ \vspace{1ex} We have to prove that: \begin{itemize} - \item the Montgomery-to-ctEdwards conversions can be implemented without + \item the Montgomery-to-\xCtEdwards conversions can be implemented without exceptional cases; \item the \distinctXCriterion is met for all Montgomery additions within a segment. @@ -17906,10 +17962,10 @@ $\bigrangenozero{-\frac{\ParamJ{r}-1}{2}}{\frac{\ParamJ{r}-1}{2}}$. Because the $\PedersenGen(D, j)$ (which are outputs of $\GroupJHash{}$) -are all of prime order, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$, +are all of \primeOrder, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$, it is guaranteed that all of the terms $\scalarmult{\PedersenEncode{M_j}}{\PedersenGen(D, j)}$ -to be converted to ctEdwards form are of prime order. +to be converted to \xCtEdwards form are of \primeOrder. From \theoremref{thmconversiontoedwardsnoexcept}, we can infer that the conversions will not encounter exceptional cases. @@ -18027,8 +18083,8 @@ \begin{itemize} \item $2 \smult c$ constraints for the lookups; \item $3 \smult (c-n)$ constraints for incomplete additions on the \MontgomeryCurve; - \item $2 \smult n$ constraints for Montgomery-to-ctEdwards conversions; - \item $6 \smult (n-1)$ constraints for ctEdwards additions; + \item $2 \smult n$ constraints for Montgomery-to-\xCtEdwards conversions; + \item $6 \smult (n-1)$ constraints for \xCtEdwards additions; \end{itemize} \vspace{-1ex} @@ -18065,7 +18121,7 @@ \end{formulae} This costs $92$ constraints for a scalar multiplication -(\crossref{cctfixedscalarmult}), and $6$ constraints for a ctEdwards addition +(\crossref{cctfixedscalarmult}), and $6$ constraints for a \xCtEdwards addition (\crossref{cctedarithmetic}), for a total of $98$ constraints. @@ -18089,7 +18145,7 @@ hash represent integers in the range $\range{0}{\ParamS{r}-1}$. Since the root of the Merkle tree is calculated outside the circuit using the canonical representations, and since the \xPedersenHashes are \collisionResistant -on arbitrary bit-sequence inputs, an attempt by an adversarial prover to use a +on arbitrary \bitSequenceAdjective inputs, an attempt by an adversarial prover to use a \nonCanonicalFieldElement input would result in the wrong root being calculated, and the overall path check would fail. @@ -18122,7 +18178,7 @@ $\ell = 6 + \length(s)$ bits, where $c = \ceiling{\hfrac{\ell}{3}}$ and $n = \ceiling{\hfrac{\ell}{3 \mult 63}}$; \item $750$ constraints for the fixed-base scalar multiplication; - \item $6$ constraints for the final ctEdwards addition. + \item $6$ constraints for the final \xCtEdwards addition. \end{itemize} When $\WindowedPedersenCommit{}$ is used to instantiate $\NoteCommitAlg{Sapling}$, @@ -18158,7 +18214,7 @@ \begin{itemize} \item $750$ constraints for the $252$-bit fixed-base multiplication by $\ValueCommitRand$; \item $191$ constraints for the $64$-bit fixed-base multiplication by $\Value$; - \item $6$ constraints for the ctEdwards addition + \item $6$ constraints for the \xCtEdwards addition \end{itemize} \vspace{-1.5ex} for a total cost of $947$ constraints. This does not include the cost to boolean-constrain @@ -18249,7 +18305,7 @@ \item return $\LEBStoOSPOf{256}{\concatbits\Of{\listcomp{\ItoLEBSPOf{32}{h_i \xor v_i \xor v_{i+8}} \for i \from 0 \upto 7}}}$ \end{formulae} -In practice the message and output will be expressed as bit sequences. In the \Sapling +In practice the message and output will be expressed as \bitSequences. In the \Sapling circuit, the personalization string will be constant for each use. Each 32-bit exclusive-or is implemented in $32$ constraints, one for each bit position @@ -18397,7 +18453,7 @@ $\AuthSignPublic$ is on the curve \small\todo{FIXME also decompressed below} & $\AuthSignPublic \typecolon \SpendAuthSigPublic{Sapling}$ & 4 & \shortcrossref{cctedvalidate} \\ \hline - $\AuthSignPublic$ is not small order + $\AuthSignPublic$ is not \smallOrderAdjective & \snarkref{Small order checks}{spendnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\AuthSignRandomizerRepr \typecolon \bitseq{\ScalarLength{Sapling}}$ @@ -18431,7 +18487,7 @@ $\DiversifiedTransmitBase$ is on the curve & $\DiversifiedTransmitBase \typecolon \GroupJ$ & 4 & \shortcrossref{cctedvalidate} \\ \hline - $\DiversifiedTransmitBase$ is not small order + $\DiversifiedTransmitBase$ is not \smallOrderAdjective & \snarkref{Small order checks}{spendnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\DiversifiedTransmitPublic = \scalarmult{\InViewingKeyRepr}{\DiversifiedTransmitBase}$ @@ -18488,12 +18544,12 @@ \end{center} \vspace{1ex} -$\dagger$ This is implemented by taking the output of $\BlakeTwos{256}$ as a bit sequence and dropping the most -significant $5$~bits, not by converting to an integer and back to a bit sequence as literally specified. +$\dagger$ This is implemented by taking the output of $\BlakeTwos{256}$ as a \bitSequence and dropping the most +significant $5$~bits, not by converting to an integer and back to a \bitSequence as literally specified. \pnote{The implementation represents $\AuthSignRandomizerRepr$, $\AuthProvePrivateRepr$, $\InViewingKeyRepr$, -$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as bit sequences rather than integers. It -represents $\nf$ as a bit sequence rather than a byte sequence.} +$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as \bitSequences rather than integers. It +represents $\nf$ as a \bitSequence rather than a \byteSequence.} \introsection @@ -18569,7 +18625,7 @@ $\DiversifiedTransmitBaseRepr = \reprJ(\DiversifiedTransmitBase \typecolon \GroupJ)$ & \snarkref{Note commitment integrity}{outputnotecommitmentintegrity} & 392 & \shortcrossref{ccteddecompressvalidate} \\ \hline - $\DiversifiedTransmitBase$ is not small order + $\DiversifiedTransmitBase$ is not \smallOrderAdjective & \snarkref{Small order checks}{outputnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\EphemeralPrivateRepr \typecolon \bitseq{\ScalarLength{Sapling}}$ @@ -18598,7 +18654,7 @@ \end{center} \pnote{The implementation represents $\EphemeralPrivateRepr$, $\DiversifiedTransmitPublicRepr$, -$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as bit sequences rather than integers.} +$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as \bitSequences rather than integers.} \lsection{Batching Optimizations}{batching} diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 650b6f527..3efa7d4d1 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -1,6 +1,6 @@ @misc{BCGGMTV2014, presort={BCGGMTV2014}, - author={Eli Ben-Sasson and Alessandro Chiesa and Christina Garman and Matthew Green and Ian Miers and Eran Tromer and Madars Virza}, + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Christina Garman and Matthew Green and Ian Miers and Eran Tromer and Madars Virza}, title={Zerocash: Decentralized {A}nonymous {P}ayments from {B}itcoin (extended version)}, url={https://eprint.iacr.org/2014/349}, urldate={2021-04-05}, @@ -12,18 +12,18 @@ @misc{BCGGMTV2014 @misc{BCTV2014a, presort={BCTV2014a}, - author={Eli Ben-Sasson and Alessandro Chiesa and Eran Tromer and Madars Virza}, - title={Succinct\, {N}on\hyp {I}nteractive\, {Z}ero\, {K}nowledge\, for\, a\, von\, {N}eumann\, {A}rchitecture}, + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Eran Tromer and Madars Virza}, + title={Succinct {N}on-{I}nteractive {Z}ero {K}nowledge for a von~{N}eumann {A}rchitecture}, url={https://eprint.iacr.org/2013/879}, urldate={2019-02-08}, - howpublished={Cryptology\, ePrint\, Archive:\, Report\, 2013/879. + howpublished={Cryptology ePrint Archive: Report 2013/879. Last revised February~5, 2019.} } @misc{BCTV2014a-old, presort={BCTV2014a-old}, - author={Eli Ben-Sasson and Alessandro Chiesa and Eran Tromer and Madars Virza}, - title={Succinct {N}on-{I}nteractive {Z}ero {K}nowledge for a von {N}eumann {A}rchitecture + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Eran Tromer and Madars Virza}, + title={Succinct {N}on-{I}nteractive {Z}ero {K}nowledge for a von~{N}eumann {A}rchitecture ({M}ay~19, 2015 version)}, url={https://eprint.iacr.org/2013/879/20150519:172604}, urldate={2019-02-08}, @@ -61,7 +61,7 @@ @misc{PHGR2013 @misc{BCGTV2013, presort={BCGTV2013}, - author={Eli Ben-Sasson and Alessandro Chiesa and Daniel Genkin and Eran Tromer and Madars Virza}, + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Daniel Genkin and Eran Tromer and Madars Virza}, title={{SNARK}s for {C}: {V}erifying {P}rogram {E}xecutions {S}uccinctly and in {Z}ero {K}nowledge}, url={https://eprint.iacr.org/2013/507}, urldate={2016-08-31}, @@ -85,7 +85,7 @@ @misc{GGPR2013 @inproceedings{BCTV2014b, presort={BCTV2014b}, - author={Eli Ben-Sasson and Alessandro Chiesa and Eran Tromer and Madars Virza}, + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Eran Tromer and Madars Virza}, title={Scalable {Z}ero {K}nowledge via {C}ycles of {E}lliptic {C}urves (extended version)}, booktitle={Advances in Cryptology - CRYPTO~2014}, volume={8617}, @@ -191,7 +191,7 @@ @misc{GWC2019 % Capitalized De/Di is correct @inproceedings{DSDCOPS2001, presort={DSDCOPS2001}, - author={Alfredo {De Santis} and Giovanni {Di Crescenzo} and Rafail Ostrovsky and Guiseppe Persiano and Amit Sahai}, + author={Alfredo {De~Santis} and \;Giovanni {Di~Crescenzo} and \;Rafail Ostrovsky and \;Guiseppe Persiano and \;Amit Sahai}, title={Robust {N}on-{I}nteractive {Z}ero {K}nowledge}, booktitle={Advances in Cryptology - CRYPTO~2001. Proceedings of the 21st Annual International Cryptology Conference @@ -304,7 +304,7 @@ @inproceedings{Bernstein2006 booktitle={Public Key Cryptography -- PKC 2006. Proceedings of the 9th International Conference on Theory and Practice in Public-Key Cryptography (New York, NY, USA, April~24--26, 2006)}, - publisher={Springer-Verlag}, + publisher={Springer}, date={2006-02-09}, url={https://cr.yp.to/papers.html#curve25519}, urldate={2021-04-05}, @@ -313,7 +313,7 @@ @inproceedings{Bernstein2006 @article{BDLSY2012, presort={BDLSY2012}, - author={Daniel Bernstein and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang}, + author={Daniel Bernstein and Niels Duif and Tanja Lange and Peter Schwabe and {Bo\nbh{}Yin} Yang}, title={High-speed high-security signatures}, journal={Journal of Cryptographic Engineering}, volume={2}, @@ -336,14 +336,14 @@ @misc{Bernstein2001 @inproceedings{deRooij1995, presort={deRooij1995}, - author={Peter {de Rooij}}, + author={Peter {de~Rooij}}, title={Efficient exponentiation using precomputation and vector addition chains}, booktitle={Advances in Cryptology - EUROCRYPT~'94. Proceedings, Workshop on the Theory and Application of Cryptographic Techniques (Perugia, Italy, May~9--12, 1994)}, volume={950}, series={Lecture Notes in Computer Science}, - editor={Alfredo {De Santis}}, + editor={Alfredo {De~Santis}}, pages={389--399}, publisher={Springer}, isbn={978-3-540-60176-0}, @@ -375,7 +375,7 @@ @misc{BL2017 @misc{BJLSY2015, presort={BJLSY2015}, - author={Daniel Bernstein and Simon Josefsson and Tanja Lange and Peter Schwabe and Bo-Yin Yang}, + author={Daniel Bernstein and Simon Josefsson and Tanja Lange and Peter Schwabe and {Bo\nbh{}Yin} Yang}, title={{EdDSA} for more curves}, url={https://cr.yp.to/papers.html#eddsa}, urldate={2018-01-22}, @@ -394,7 +394,7 @@ @misc{BL-SafeCurves @misc{FKMSSS2016, presort={FKMSSS2016}, author={Nils Fleischhacker and Johannes Krupp and Giulio Malavolta and Jonas Schneider and Dominique Schröder and Mark Simkin}, - title={Efficient\; {U}nlinkable\; {S}anitizable\; {S}ignatures\; from\; {S}ignatures\; with\; {R}e\hyp {R}andomizable\; {K}eys}, + title={Efficient\; {U}nlinkable\; {S}anitizable\; {S}ignatures\; from\; {S}ignatures\; with\; {R}e-{R}andomizable\; {K}eys}, url={https://eprint.iacr.org/2015/395}, urldate={2018-03-03}, howpublished={Cryptology ePrint Archive: Report 2012/159. @@ -402,7 +402,7 @@ @misc{FKMSSS2016 addendum={An extended abstract appeared in \textsl{Public Key Cryptography -- PKC 2016: 19th IACR International Conference on Practice and Theory in Public-Key Cryptography (Taipei, Taiwan, March~6--9, 2016), Proceedings, Part~1};\, -Ed. by Chen-Mou Cheng, Kai-Min Chung, Giuseppe Persiano, and Bo-Yin Yang;\, +Ed. by {Chen\nbh{}Mou} Cheng, {Kai\nbh{}Min} Chung, Giuseppe Persiano, and {Bo\nbh{}Yin} Yang;\, Vol.~9614, Lecture Notes in Computer Science, pages 301--330; Springer, 2016; ISBN 978-3-662-49384-7.} } @@ -410,7 +410,7 @@ @misc{FKMSSS2016 @misc{DS2016, presort={DS2016}, author={David Derler and Daniel Slamanig}, - title={Key\hyp {H}omomorphic {S}ignatures and {A}pplications to {M}ultiparty {S}ignatures and {N}on\hyp {I}nteractive {Z}ero\hyp {K}nowledge}, + title={Key-{H}omomorphic {S}ignatures and {A}pplications to {M}ultiparty {S}ignatures and {N}on-{I}nteractive {Z}ero-{K}nowledge}, url={https://eprint.iacr.org/2016/792}, urldate={2018-04-09}, howpublished={Cryptology ePrint Archive: Report 2016/792. @@ -524,8 +524,7 @@ @misc{RIPEMD160 @misc{ANWW2013, presort={ANWW2013}, - author={Jean-Philippe Aumasson and \;Samuel Neves and \;Zooko Wilcox-O'Hearn and -\;Christian Winnerlein}, + author={{Jean\nbh{}Philippe} Aumasson and Samuel Neves and Zooko Wilcox and Christian Winnerlein}, date={2013-01-29}, title={{BLAKE2}: simpler, smaller, fast as {MD5}}, url={https://blake2.net/#sp}, @@ -553,7 +552,7 @@ @misc{Poseidon-1.1 @misc{Poseidon-Zc1.1, presort={Poseidon-Zc1.1}, - author={Lorenzo Grassi and Dmitry Khovratovich and Christian Rechberger and Arnab Roy and Markus Schofnegger and Daira Emma Hopwood}, + author={Lorenzo Grassi and Dmitry Khovratovich and Christian Rechberger and Arnab Roy and Markus Schofnegger and {Daira\nbh{}Emma} Hopwood}, title={Poseidon reference implementation, Zcash fork, Version 1.1}, date={2021-07-28}, url={https://github.com/daira/pasta-hadeshash}, @@ -562,7 +561,7 @@ @misc{Poseidon-Zc1.1 @misc{BDPA2007, presort={BDPA2007}, - author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}}, + author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van~Assche}}, title={Sponge functions}, url={https://keccak.team/files/SpongeFunctions.pdf}, urldate={2022-08-31}, @@ -572,7 +571,7 @@ @misc{BDPA2007 @misc{BDPA2011, presort={BDPA2011}, - author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}}, + author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van~Assche}}, title={Cryptographic sponge functions}, url={https://keccak.team/files/CSF-0.1.pdf}, urldate={2021-03-01}, @@ -581,7 +580,7 @@ @misc{BDPA2011 @misc{ADMA2015, presort={ADMA2015}, - author={Elena Andreeva and Joan Daemen and Bart Mennink and Gilles {Van Assche}}, + author={Elena Andreeva and Joan Daemen and Bart Mennink and Gilles {Van~Assche}}, title={Security of Keyed Sponge Constructions Using a Modular Proof Approach}, url={https://keccak.team/files/ModularKeyedSponge.pdf}, urldate={2021-03-01}, @@ -649,7 +648,7 @@ @misc{KR2020 @misc{BCD+2020, presort={BCD+2020}, author={Tim Beyne and Anne Canteaut and Itai Dinur and Maria Eichlseder and Gregor Leander and Gaëtan Leurent and -María Naya-Plasencia and Léo Perrin and Yu Sasaki and Yosuke Todo and Friedrich Wiemer}, +María {Naya\nbh{}Plasencia} and Léo Perrin and Yu Sasaki and Yosuke Todo and Friedrich Wiemer}, title={Out of Oddity --- New Cryptanalytic Techniques against Symmetric Primitives Optimized for Integrity Proof Systems}, url={https://eprint.iacr.org/2020/188}, urldate={2021-03-01}, @@ -684,7 +683,7 @@ @misc{AGRRT2017 @misc{RFC-7693, presort={RFC-7693}, - author={Markku-Juhani Saarinen (ed.)}, + author={{Markku\nbh{}Juhani} Saarinen (ed.) and {Jean\nbh{}Philippe} Aumasson}, title={Request for {C}omments 7693: {T}he {BLAKE2} {C}ryptographic {H}ash and {M}essage {A}uthentication {C}ode ({MAC})}, howpublished={Internet Engineering Task Force (IETF)}, @@ -718,7 +717,7 @@ @misc{RFC-2119 @misc{ID-hashtocurve, presort={ID-hashtocurve}, - author={Armando Faz-Hernández and Sam Scott and Nick Sullivan and Riad Wahby and Christopher Wood}, + author={Armando {Faz\nbh{}Hernández} and Sam Scott and Nick Sullivan and Riad Wahby and Christopher Wood}, title={Internet {D}raft: {H}ashing to Elliptic Curves, version 10}, howpublished={Internet Research Task Force (IRTF) Crypto Forum Research Group (CFRG). Work in progress. Last revised December~22, 2020.}, url={https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html}, @@ -736,7 +735,7 @@ @misc{WB2019 @inproceedings{BCIMRT2010, presort={BCIMRT2010}, - author={Eric Brier and Jean-Sébastien Coron and Thomas Icart and David Madore and Hugues Randriam and Mehdi Tibouchi}, + author={Eric Brier and {Jean\nbh{}Sébastien} Coron and Thomas Icart and David Madore and Hugues Randriam and Mehdi Tibouchi}, title={Efficient Indifferentiable Hashing into Ordinary Elliptic Curves}, booktitle={Advances in Cryptology - CRYPTO~2010. Proceedings of the 30th Annual International Cryptology Conference @@ -755,12 +754,12 @@ @inproceedings{BCIMRT2010 @inproceedings{SvdW2006, presort={SvdW2006}, - author={Andrew Shallue and Christiaan E. van de Woestijne}, + author={Andrew Shallue and Christiaan E. {van~de~Woestijne}}, title={Construction of Rational Points on Elliptic Curves over Finite Fields}, - booktitle={Algorithmic Number Theory: 7th International Symposium, ANTS-VII (Berlin, Germany, July~23--28, 2006)}, + booktitle={Algorithmic Number Theory: 7th International Symposium, {ANTS-VII} (Berlin, Germany, July~23--28, 2006)}, volume={4076}, series={Lecture Notes in Computer Science}, - editor={F. Hess and S. Pauli and M. Pohst}, + editor={Florian Hess and Sebastian Pauli and Michael Pohst}, pages={510--524}, year={2006}, publisher={Springer}, @@ -786,7 +785,7 @@ @article{Ulas2007 @article{FFSTV2013, presort={FFSTV2013}, - author={Reza Farashahi and Pierre-Alain Fouque and Igor Shparlinski and Mehdi Tibouchi and J. Felipe Voloch}, + author={Reza Farashahi and {Pierre\nbh{}Alain} Fouque and Igor Shparlinski and Mehdi Tibouchi and J. Felipe Voloch}, title={Indifferentiable deterministic hashing to elliptic and hyperelliptic curves}, journal={Mathematics of Computation}, volume={82}, @@ -802,14 +801,14 @@ @inproceedings{KT2015 author={Taechan Kim and Mehdi Tibouchi}, title={Improved Elliptic Curve Hashing and Point Representation}, booktitle={Proceedings of WCC2015 - 9th International Workshop on Coding and Cryptography (Paris, France, April 2015)}, - editor={Anne Canteaut and Gaëtan Leurent and Maria Naya-Plasencia}, + editor={Anne Canteaut and Gaëtan Leurent and Maria {Naya\nbh{}Plasencia}}, url={https://hal.inria.fr/hal-01275711}, urldate={2021-01-28} } @article{BGHOZ2013, presort={BGHOZ2013}, - author={Gilles Barthe and Benjamin Grégoire and Sylvain Heraud and Frederico Olmedo and Santiago Zanella-Béguelin}, + author={Gilles\; Barthe and \;\;Benjamin\; Grégoire and \;\;Sylvain\; Heraud and \;\;Frederico\; Olmedo and \;\;Santiago {Zanella\nbh{}Béguelin}}, title={Verified indifferentiable hashing into elliptic curves}, journal={Journal of Computer Security, Security and Trust Principles}, volume={21}, @@ -896,7 +895,7 @@ @article{ElGamal1985 @misc{ABR1999, presort={ABR1999}, author={Michel Abdalla and Mihir Bellare and Phillip Rogaway}, - title={{DHAES}: {A}n {E}ncryption {S}cheme {B}ased on the {D}iffie-{H}ellman {P}roblem}, + title={{DHAES}: {A}n {E}ncryption {S}cheme {B}ased on the {D}iffie--{H}ellman {P}roblem}, url={https://eprint.iacr.org/1999/007}, urldate={2016-08-21}, date={1998-09}, @@ -905,7 +904,7 @@ @misc{ABR1999 @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}, @@ -934,7 +933,7 @@ @misc{LM2017 @misc{vanSaberh2014, presort={vanSaberh2014}, - author={Nicolas {van Saberhagen}}, + author={Nicolas {van~Saberhagen}}, title={CryptoNote v 2.0}, note={Date disputed.}, url={https://bytecoin.org/old/whitepaper.pdf}, @@ -952,7 +951,7 @@ @misc{Jedusor2016 @misc{Dalek-notes, presort={Dalek-notes}, - author={Cathie Yun and Henry {de Valence} and Oleg Andreev and Dimitris Apostolou}, + author={Cathie Yun and Henry {de~Valence} and Oleg Andreev and Dimitris Apostolou}, title={Dalek bulletproofs notes, module r1cs\_proof}, url={https://doc-internal.dalek.rs/bulletproofs/notes/r1cs_proof/index.html}, urldate={2021-04-07} @@ -1170,8 +1169,8 @@ @misc{BIP-66 @misc{BIP-68, presort={BIP-0068}, - author={Mark Friedenbach and BtcDrak and Nicolas Dorier and kinoshitajona}, - title={Relative lock-time using consensus\hyp enforced sequence numbers}, + author={Mark\; Friedenbach and \;BtcDrak and \;Nicolas\; Dorier and \;kinoshitajona}, + title={\;Relative\, lock-time\, using consensus-enforced sequence numbers}, howpublished={Bitcoin Improvement Proposal 68. Last revised November~21, 2015}, url={https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki}, urldate={2020-07-13} @@ -1206,7 +1205,7 @@ @misc{BIP-350 @misc{ZIP-32, presort={ZIP-0032}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Shielded Hierarchical Deterministic Wallets}, howpublished={Zcash Improvement Proposal 32.}, url={https://zips.z.cash/zip-0032}, @@ -1215,14 +1214,14 @@ @misc{ZIP-32 @misc{ZIP-76, presort={ZIP-0076}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Transaction Signature Validation before {O}verwinter}, howpublished={Zcash Improvement Proposal 76 (in progress).}, } @misc{ZIP-143, presort={ZIP-0143}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Transaction Signature Validation for {O}verwinter}, howpublished={Zcash Improvement Proposal 143. Created December~27, 2017.}, url={https://zips.z.cash/zip-0143}, @@ -1231,7 +1230,7 @@ @misc{ZIP-143 @misc{ZIP-173, presort={ZIP-0173}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Bech32 Format}, howpublished={Zcash Improvement Proposal 173. Created June~13, 2018.}, url={https://zips.z.cash/zip-0173}, @@ -1249,7 +1248,7 @@ @misc{ZIP-200 @misc{ZIP-201, presort={ZIP-0201}, - author={Simon Liu}, + author={Simon Liu and {Daira\nbh{}Emma} Hopwood}, title={Network Peer Management for {O}verwinter}, howpublished={Zcash Improvement Proposal 201. Created January~15, 2018.}, url={https://zips.z.cash/zip-0201}, @@ -1258,7 +1257,7 @@ @misc{ZIP-201 @misc{ZIP-202, presort={ZIP-0202}, - author={Simon Liu}, + author={Simon Liu and {Daira\nbh{}Emma} Hopwood}, title={Version 3 Transaction Format for {O}verwinter}, howpublished={Zcash Improvement Proposal 202. Created January~10, 2018.}, url={https://zips.z.cash/zip-0202}, @@ -1267,7 +1266,7 @@ @misc{ZIP-202 @misc{ZIP-203, presort={ZIP-0203}, - author={Jay Graber}, + author={Jay Graber and {Daira\nbh{}Emma} Hopwood}, title={Transaction Expiry}, howpublished={Zcash Improvement Proposal 203. Created January~9, 2018.}, url={https://zips.z.cash/zip-0203}, @@ -1276,7 +1275,7 @@ @misc{ZIP-203 @misc{ZIP-205, presort={ZIP-0205}, - author={Daira Emma Hopwood}, + author={Simon Liu and {Daira\nbh{}Emma} Hopwood}, title={Deployment of the {S}apling Network Upgrade}, howpublished={Zcash Improvement Proposal 205. Created October~8, 2018.}, url={https://zips.z.cash/zip-0205}, @@ -1285,7 +1284,7 @@ @misc{ZIP-205 @misc{ZIP-206, presort={ZIP-0206}, - author={Daira Emma Hopwood}, + author={Simon Liu and {Daira\nbh{}Emma} Hopwood}, title={Deployment of the {B}lossom Network Upgrade}, howpublished={Zcash Improvement Proposal 206. Created July~29, 2019.}, url={https://zips.z.cash/zip-0206}, @@ -1294,7 +1293,7 @@ @misc{ZIP-206 @misc{ZIP-207, presort={ZIP-0207}, - author={Jack Grigg}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Funding Streams}, howpublished={Zcash Improvement Proposal 207. Created January~4, 2019.}, url={https://zips.z.cash/zip-0207}, @@ -1303,7 +1302,7 @@ @misc{ZIP-207 @misc{ZIP-208, presort={ZIP-0208}, - author={Simon Liu and Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood and Simon Liu}, title={Shorter Block Target Spacing}, howpublished={Zcash Improvement Proposal 208. Created January~10, 2019.}, url={https://zips.z.cash/zip-0208}, @@ -1312,7 +1311,7 @@ @misc{ZIP-208 @misc{ZIP-209, presort={ZIP-0209}, - author={Sean Bowe}, + author={Sean Bowe and {Daira\nbh{}Emma} Hopwood}, title={Prohibit Negative Shielded Value Pool Balances}, howpublished={Zcash Improvement Proposal 209. Created February~25, 2019.}, url={https://zips.z.cash/zip-0209}, @@ -1321,7 +1320,7 @@ @misc{ZIP-209 @misc{ZIP-211, presort={ZIP-0211}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Disabling Addition of New Value to the {S}prout Value Pool}, howpublished={Zcash Improvement Proposal 211. Created March~29, 2019.}, url={https://zips.z.cash/zip-0211}, @@ -1348,7 +1347,7 @@ @misc{ZIP-213 @misc{ZIP-214, presort={ZIP-0214}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Consensus rules for a {Z}cash Development Fund}, howpublished={Zcash Improvement Proposal 214. Created February~28, 2020.}, url={https://zips.z.cash/zip-0214}, @@ -1357,7 +1356,7 @@ @misc{ZIP-214 @misc{ZIP-215, presort={ZIP-0215}, - author={Henry de Valance}, + author={Henry {de~Valence}}, title={Explicitly Defining and Modifying {Ed25519} Validation Rules}, howpublished={Zcash Improvement Proposal 215. Created April~27, 2020.}, url={https://zips.z.cash/zip-0215}, @@ -1366,7 +1365,7 @@ @misc{ZIP-215 @misc{ZIP-216, presort={ZIP-0216}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Require Canonical Point Encodings}, howpublished={Zcash Improvement Proposal 216. Created February~11, 2021.}, url={https://zips.z.cash/zip-0216}, @@ -1375,7 +1374,7 @@ @misc{ZIP-216 @misc{ZIP-221, presort={ZIP-0221}, - author={Jack Grigg}, + author={{Ying~Tong} Lai and James Prestwich and Georgios Konstantopoulos and Jack Grigg}, title={{FlyClient} - Consensus-Layer Changes}, howpublished={Zcash Improvement Proposal 221. Created March~30, 2019.}, url={https://zips.z.cash/zip-0221}, @@ -1393,7 +1392,7 @@ @misc{ZIP-222 @misc{ZIP-224, presort={ZIP-0224}, - author={Daira Emma Hopwood and Jack Grigg and Sean Bowe and Kris Nuttycombe and Ying Tong Lai}, + author={{Daira\nbh{}Emma} Hopwood and Jack Grigg and Sean Bowe and Kris Nuttycombe and {Ying~Tong} Lai}, title={Orchard Shielded Protocol}, howpublished={Zcash Improvement Proposal 224. Created February~27, 2021.}, url={https://zips.z.cash/zip-0225}, @@ -1402,7 +1401,7 @@ @misc{ZIP-224 @misc{ZIP-225, presort={ZIP-0225}, - author={Daira Emma Hopwood and Jack Grigg and Sean Bowe and Kris Nuttycombe and Ying Tong Lai}, + author={{Daira\nbh{}Emma} Hopwood and Jack Grigg and Sean Bowe and Kris Nuttycombe and {Ying~Tong} Lai}, title={Version 5 Transaction Format}, howpublished={Zcash Improvement Proposal 225. Created February~28, 2021.}, url={https://zips.z.cash/zip-0225}, @@ -1411,7 +1410,7 @@ @misc{ZIP-225 @misc{ZIP-239, presort={ZIP-0239}, - author={Daira Emma Hopwood and Jack Grigg}, + author={{Daira\nbh{}Emma} Hopwood and Jack Grigg}, title={Relay of Version 5 Transactions}, howpublished={Zcash Improvement Proposal 239. Created May~29, 2021.}, url={https://zips.z.cash/zip-0239}, @@ -1420,7 +1419,7 @@ @misc{ZIP-239 @misc{ZIP-243, presort={ZIP-0243}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Transaction Signature Validation for {S}apling}, howpublished={Zcash Improvement Proposal 243. Created April~10, 2018.}, url={https://zips.z.cash/zip-0243}, @@ -1429,7 +1428,7 @@ @misc{ZIP-243 @misc{ZIP-244, presort={ZIP-0244}, - author={Kris Nuttycombe and Daira Emma Hopwood}, + author={Kris Nuttycombe and {Daira\nbh{}Emma} Hopwood and Jack Grigg}, title={Transaction Identifier Non-Malleability}, howpublished={Zcash Improvement Proposal 244. Created January~6, 2021.}, url={https://zips.z.cash/zip-0244}, @@ -1438,7 +1437,7 @@ @misc{ZIP-244 @misc{ZIP-245, presort={ZIP-0245}, - author={Daira Emma Hopwood and Kris Nuttycombe}, + author={Kris Nuttycombe and {Daira\nbh{}Emma} Hopwood}, title={Transaction Identifier Digests & Signature Validation for {T}ransparent {Z}cash {E}xtensions}, howpublished={Zcash Improvement Proposal 245. Created January~13, 2021.}, url={https://zips.z.cash/zip-0245}, @@ -1447,7 +1446,7 @@ @misc{ZIP-245 @misc{ZIP-250, presort={ZIP-0250}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Deployment of the {H}eartwood Network Upgrade}, howpublished={Zcash Improvement Proposal 250. Created February~28, 2020.}, url={https://zips.z.cash/zip-0250}, @@ -1456,7 +1455,7 @@ @misc{ZIP-250 @misc{ZIP-251, presort={ZIP-0251}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Deployment of the {C}anopy Network Upgrade}, howpublished={Zcash Improvement Proposal 251. Created February~28, 2020.}, url={https://zips.z.cash/zip-0251}, @@ -1465,7 +1464,7 @@ @misc{ZIP-251 @misc{ZIP-252, presort={ZIP-0252}, - author={Teor and Daira Emma Hopwood}, + author={teor and {Daira\nbh{}Emma} Hopwood}, title={Deployment of the {NU5} Network Upgrade}, howpublished={Zcash Improvement Proposal 252. Created February~23, 2021.}, url={https://zips.z.cash/zip-0252}, @@ -1483,7 +1482,7 @@ @misc{ZIP-302 @misc{ZIP-316, presort={ZIP-0316}, - author={Daira Emma Hopwood and Nathan Wilcox and Taylor Hornby and Jack Grigg and Sean Bowe and Kris Nuttycombe and Ying Tong Lai}, + author={{Daira\nbh{}Emma} Hopwood and Nathan Wilcox and Taylor Hornby and Jack Grigg and Sean Bowe and Kris Nuttycombe and Greg Pfeil and {Ying~Tong} Lai}, title={Unified Addresses and Unified Viewing Keys}, howpublished={Zcash Improvement Proposal 316. Created April~7, 2021.}, url={https://zips.z.cash/zip-0316}, @@ -1501,14 +1500,14 @@ @misc{DigiByte-PoW @misc{BGG-mpc, presort={BGG-mpc}, author={Sean Bowe and Ariel Gabizon and Matthew Green}, - title={GitHub repository `\hairspace zcash/mpc'\hairspace: zk-SNARK parameter multi-party computation protocol}, + title={GitHub repository `\hairspace zcash/mpc'\hairspace: zk-{SNARK} parameter multi-party computation protocol}, url={https://github.com/zcash/mpc}, urldate={2017-01-06} } @misc{Hopwood2018, presort={Hopwood2018}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={GitHub repository `\hairspace daira/jubjub'\hairspace: {S}upporting evidence for security of the {J}ubjub curve to be used in {Z}cash}, url={https://github.com/daira/jubjub}, @@ -1518,7 +1517,7 @@ @misc{Hopwood2018 @misc{Hopwood2020, presort={Hopwood2020}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={GitHub repository `\hairspace zcash/pasta'\hairspace: {G}enerator and supporting evidence for security of the {P}allas/{V}esta pair of elliptic curves suitable for {H}alo}, url={https://github.com/zcash/pasta}, @@ -1528,7 +1527,7 @@ @misc{Hopwood2020 @misc{Hopwood2022, presort={Hopwood2022}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Explaining the Security of Zcash}, howpublished={Presentation at Zcon3. Slides and a link to the video are available at: \textit{GitHub repository `\hairspace daira/zcash-security'\hairspace: Code and documentation supporting security analysis of Zcash}.}, @@ -1737,7 +1736,7 @@ @misc{Zcash-Nu5 @misc{WCBTV2015, presort={WCBTV2015}, - author={Zooko Wilcox and Alessandro Chiesa and Eli Ben-Sasson and Eran Tromer and Madars Virza}, + author={Zooko Wilcox and Alessandro Chiesa and Eli {Ben\nbh{}Sasson} and Eran Tromer and Madars Virza}, title={A {B}ug in libsnark}, howpublished={Least Authority blog}, date={2015-05-16}, @@ -1842,7 +1841,7 @@ @misc{BDJR2000 @misc{KvE2013, presort={KvE2013}, - author={Kaa1el and Hagen von Eitzen}, + author={Kaa1el and Hagen {von~Eitzen}}, title={If a group $G$ has odd order, then the square function is injective (answer).}, howpublished={Mathematics Stack Exchange}, url={https://math.stackexchange.com/a/522277/185422}, @@ -1873,7 +1872,7 @@ @inproceedings{BGG1995 @misc{CvHP1991, presort={CvHP1991}, - author={David Chaum and Eugène {van Heijst} and Birgit Pfitzmann}, + author={David Chaum and Eugène {van~Heijst} and Birgit Pfitzmann}, title={Cryptographically {S}trong {U}ndeniable {S}ignatures, {U}nconditionally {S}ecure for the {S}igner}, date={1991-02}, publisher={Universität Karlsruhe Fakultät für Informatik}, @@ -1898,7 +1897,7 @@ @unpublished{BCP1988 @inproceedings{CDvdG1987, presort={CDvdG1987}, - author={David Chaum and Ivan Damgård and Jeroen {van de Graaf}}, + author={David Chaum and Ivan Damgård and Jeroen {van~de~Graaf}}, title={Multiparty\, computations\, ensuring\, privacy\, of\, each\, party's\, input\, and\, correctness\, of\, the\, result}, date={1988-01}, booktitle={Advances\, in\, Cryptology - CRYPTO~'87. @@ -1937,7 +1936,8 @@ @misc{Carroll1902 @inproceedings{ST1999, presort={ST1999}, - author={Tomas Sander and Amnon Ta--Shma}, + author={Tomas Sander and Amnon {Ta\nbh{}Shma}}, +% paper uses em-dash but e.g. https://simons.berkeley.edu/people/amnon-ta-shma uses Ta-Shma title={Auditable, {A}nonymous {E}lectronic {C}ash}, year={1999}, booktitle={Advances in Cryptology - CRYPTO~'99. @@ -1982,7 +1982,7 @@ @misc{ECCZF2019 @misc{Zcash-Orchard, presort={Zcash-Orchard}, - author={Daira Emma Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and Ying Tong Lai and Steven Smith}, + author={{Daira\nbh{}Emma} Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and {Ying~Tong} Lai and Steven Smith}, title={The {O}rchard Book}, url={https://zcash.github.io/orchard/}, urldate={2021-03-02} @@ -1990,7 +1990,7 @@ @misc{Zcash-Orchard @misc{Zcash-halo2, presort={Zcash-halo2}, - author={Daira Emma Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and Ying Tong Lai and Steven Smith}, + author={{Daira\nbh{}Emma} Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and {Ying~Tong} Lai and Steven Smith}, title={The halo2 Book}, url={https://zcash.github.io/halo2/}, urldate={2021-03-23} @@ -1998,7 +1998,7 @@ @misc{Zcash-halo2 @misc{zcashd-6459, presort={Zcashd-6459}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={zcashd PR 6459: Migrate to zcash\_primitives 0.10}, comment={Merged on 2023-03-17.}, url={https://github.com/zcash/zcash/pull/6459}, diff --git a/CNAME b/rendered/CNAME similarity index 100% rename from CNAME rename to rendered/CNAME diff --git a/COPYING.html b/rendered/COPYING.html similarity index 100% rename from COPYING.html rename to rendered/COPYING.html diff --git a/assets/fonts/Roboto-Bold-webfont.woff b/rendered/assets/fonts/Roboto-Bold-webfont.woff similarity index 100% rename from assets/fonts/Roboto-Bold-webfont.woff rename to rendered/assets/fonts/Roboto-Bold-webfont.woff diff --git a/assets/fonts/Roboto-Light-webfont.woff b/rendered/assets/fonts/Roboto-Light-webfont.woff similarity index 100% rename from assets/fonts/Roboto-Light-webfont.woff rename to rendered/assets/fonts/Roboto-Light-webfont.woff diff --git a/assets/fonts/Roboto-Medium-webfont.woff b/rendered/assets/fonts/Roboto-Medium-webfont.woff similarity index 100% rename from assets/fonts/Roboto-Medium-webfont.woff rename to rendered/assets/fonts/Roboto-Medium-webfont.woff diff --git a/assets/fonts/Roboto-Regular-webfont.woff b/rendered/assets/fonts/Roboto-Regular-webfont.woff similarity index 100% rename from assets/fonts/Roboto-Regular-webfont.woff rename to rendered/assets/fonts/Roboto-Regular-webfont.woff diff --git a/assets/images/section-anchor.copyright b/rendered/assets/images/section-anchor.copyright similarity index 100% rename from assets/images/section-anchor.copyright rename to rendered/assets/images/section-anchor.copyright diff --git a/assets/images/section-anchor.png b/rendered/assets/images/section-anchor.png similarity index 100% rename from assets/images/section-anchor.png rename to rendered/assets/images/section-anchor.png diff --git a/assets/images/section-anchor.svg b/rendered/assets/images/section-anchor.svg similarity index 100% rename from assets/images/section-anchor.svg rename to rendered/assets/images/section-anchor.svg diff --git a/zip-0032-orchard-internal-key-derivation.png b/rendered/assets/images/zip-0032-orchard-internal-key-derivation.png similarity index 100% rename from zip-0032-orchard-internal-key-derivation.png rename to rendered/assets/images/zip-0032-orchard-internal-key-derivation.png diff --git a/zip-0032-sapling-internal-key-derivation.png b/rendered/assets/images/zip-0032-sapling-internal-key-derivation.png similarity index 100% rename from zip-0032-sapling-internal-key-derivation.png rename to rendered/assets/images/zip-0032-sapling-internal-key-derivation.png diff --git a/rendered/assets/images/zip-0068-encoding.png b/rendered/assets/images/zip-0068-encoding.png new file mode 100644 index 000000000..a244e6ba6 Binary files /dev/null and b/rendered/assets/images/zip-0068-encoding.png differ diff --git a/zip-0227-asset-identifier-relation.png b/rendered/assets/images/zip-0227-asset-identifier-relation.png similarity index 100% rename from zip-0227-asset-identifier-relation.png rename to rendered/assets/images/zip-0227-asset-identifier-relation.png diff --git a/zip-0227-key-components-zsa.png b/rendered/assets/images/zip-0227-key-components-zsa.png similarity index 100% rename from zip-0227-key-components-zsa.png rename to rendered/assets/images/zip-0227-key-components-zsa.png diff --git a/zip-0307-arch.png b/rendered/assets/images/zip-0307-arch.png similarity index 100% rename from zip-0307-arch.png rename to rendered/assets/images/zip-0307-arch.png diff --git a/zip-0316-f3.png b/rendered/assets/images/zip-0316-f3.png similarity index 100% rename from zip-0316-f3.png rename to rendered/assets/images/zip-0316-f3.png diff --git a/zip-0316-f4.png b/rendered/assets/images/zip-0316-f4.png similarity index 100% rename from zip-0316-f4.png rename to rendered/assets/images/zip-0316-f4.png diff --git a/css/style.css b/rendered/css/style.css similarity index 96% rename from css/style.css rename to rendered/css/style.css index 1eee84aa0..77af4d69f 100644 --- a/css/style.css +++ b/rendered/css/style.css @@ -18,6 +18,9 @@ #index-of-zips table tr:hover { background-color: #eff1f2; } + #drafts-without-assigned-zip-numbers table tr:hover { + background-color: #eff1f2; + } aside.note { background-color: #a0a0ff; color: #111519; @@ -72,6 +75,9 @@ #index-of-zips table tr:hover { background-color: #303030; } + #drafts-without-assigned-zip-numbers table tr:hover { + background-color: #303030; + } aside.note { background-color: #6060e0; color: #ffffff; @@ -370,6 +376,10 @@ td:first-child { text-align: center; } +#drafts-without-assigned-zip-numbers table td:first-child { + text-align: left; +} + #index-of-zips table td:first-child + td { padding: 0; } diff --git a/rendered/draft-hopwood-coinbase-balance.html b/rendered/draft-hopwood-coinbase-balance.html new file mode 100644 index 000000000..8c72eba08 --- /dev/null +++ b/rendered/draft-hopwood-coinbase-balance.html @@ -0,0 +1,10 @@ + + + + ZIP 236: Blocks should balance exactly (redirect) + + + +

This draft was assigned ZIP number 236.

+ + \ No newline at end of file diff --git a/rendered/draft-noamchom67-manufacturing-consent.html b/rendered/draft-noamchom67-manufacturing-consent.html new file mode 100644 index 000000000..e5bdf1b9c --- /dev/null +++ b/rendered/draft-noamchom67-manufacturing-consent.html @@ -0,0 +1,291 @@ + + + + Draft noamchom67-manufacturing-consent: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub + + + +
+ 
ZIP: ####
+Title: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
+Owner: Noam Chom <noamchom1967@gmail.com>
+Credits: The ZIP-1014 Authors
+Status: Active
+Category: Consensus Process
+Created: 2024-06-25
+License: MIT
+Discussions-To: <https://forum.zcashcommunity.com/t/manufacturing-consent-noamchoms-nu6-block-reward-proposal/47155>
+Pull-Request: TBD
+

Terminology

+

The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

+

The term "network upgrade" in this document is to be interpreted as described in ZIP 200 6 and the Zcash Trademark Donation and License Agreement (4 or successor agreement).

+

The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. 2

+

"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric Coin Company, LLC.

+

"Bootstrap Project", also called "BP", refers to the 501(c)(3) nonprofit corporation of that name.

+

"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit corporation of that name.

+

"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). 12

+

"Community Advisory Panel" refers to the panel of community members assembled by the Zcash Foundation and described at 11.

+

"Zcash Community Grants", also called "ZCG", refers to grants program (formerly known as ZOMG) that funds independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem. <https://zcashcommunitygrants.org/>

+

"Financial Privacy Foundation", also called "FPF" refers to the start-up non-profit organization incorporated and based in the Cayman Islands. <https://www.financialprivacyfoundation.org/>

+

"Qedit" refers to the company founded in 2016 by a world-class team of accomplished tech entrepreneurs, researchers, and developers; QEDIT has emerged as a global leader in the field of Zero-Knowledge Proofs. <https://qed-it.com/about-us/>

+

"ZecHub" refers to the team of content creators who have supported Zcash through a series of ZCG approved grants. <https://forum.zcashcommunity.com/t/zechub-an-education-hub-for-zcash-2024-continued/47947>

+

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.

+

The term "ZSA" is to be interpreted as "Zcash Shielded Assets" the protocol feature enhancement (and subsequent application layer, legal, maintenance efforts, et al) on-going by Qedit, et al. <https://forum.zcashcommunity.com/t/grant-update-zcash-shielded-assets-monthly-updates/41153>

+

✳️ is used to denote elements of the process part of the ZIP that are still to-be-determined.

+
+

Abstract

+

This proposal describes a structure for the Zcash Development Fund, to be enacted in Network Upgrade 6 and last for 4 years. This Dev Fund would consist of 15% of the block subsidies, as the following allocations:

+
    +
  • 5% for the Zcash Foundation (for internal work and grants);
    • +
  • 4% for the Bootstrap Project (the parent of the Electric Coin Company) for the 1st year only;
    • +
  • 4% for Zcash Community Grants for continuation of their current activities as-is;
    • +
  • 2% for Qedit in support of their ZSA activities, and other Zcash protocol support;
    • +
+

Following the first year, when ECC will no longer receive their 4% allocation, those block subsidies will be distributed as 1% to ZCG, 1% to ZecHub, 1% to FPF, and 1% to ZF.

+

Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged. This proposal mandates the ecosystem to design and deploy a "non-direct funding model" as generally recommended in Josh Swihart's proposal. 13

+

Upon creation/ activation of a "non-direct funding model" this ZIP should be reconsidered (potentially terminated) by the Zcash ecosystem, to determine if its ongoing direct block subsidies are preferred for continuation. Discussions/ solications/ sentiment gathering from the Zcash ecosystem should be initiated ~6 months in advance of the presumed activation of a "non-direct funding model", such that the Zcash ecosystem preference can be expediently realized.

+

Block subsidies will be administered through two organizations:

+
    +
  1. Zcash Foundation (✳️ for ECC, ZCG)
    2. +
  2. Financial Privacy Foundation (✳️ for Qedit, ZecHub)
    3. +
+

✳️ ZF and FPF adminstration of block subsidy details, costs, et al are currently under debate 14

+
+

Motivation

+

As of Zcash's second halving in November 2024, by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, no new funding may be available to existing teams dedicated to furthering charitable, educational, or scientific purposes, such as research, development, and outreach: the Electric Coin Company (ECC), the Zcash Foundation (ZF), the ZCG, and the many entities funded by the ZF and ZCG grant programs.

+

There is a need to strike a balance between incentivizing the security of the consensus protocol (i.e., mining) versus crucial charitable, educational, and/or scientific aspects, such as research, development and outreach.

+

Furthermore, there is a need to balance the sustenance of ongoing work by the current teams dedicated to Zcash, with encouraging decentralization and growth of independent development teams.

+

For these reasons, the Zcash Community desires to allocate and contribute a portion of the block subsidies otherwise allocated to miners as a donation to support charitable, educational, and scientific activities within the meaning of Section 501(c)(3).

+

This proposal also introduces the benefit of a non-USA based entity (FPF) as the administrator for block subsidies to two organizations that are also non-USA based (Qedit and ZecHub). USA based regulatory risk continues to (negatively) impact the Zcash project, which has been predominantly based in the USA.

+
+

Requirements

+

The Dev Fund should encourage decentralization of the work and funding, by supporting new teams dedicated to Zcash.

+

The Dev Fund should maintain the existing teams and capabilities in the Zcash ecosystem, unless and until concrete opportunities arise to create even greater value for the Zcash ecosystem.

+

There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.

+

Major funding decisions should be based, to the extent feasible, on inputs from domain experts and pertinent stakeholders.

+

The Dev Fund mechanism should not modify the monetary emission curve (and in particular, should not irrevocably burn coins).

+

In case the value of ZEC jumps, the Dev Fund recipients should not wastefully use excessive amounts of funds. Conversely, given market volatility and eventual halvings, it is desirable to create rainy-day reserves.

+

The Dev Fund mechanism should not reduce users' financial privacy or security. In particular, it should not cause them to expose their coin holdings, nor cause them to maintain access to secret keys for much longer than they would otherwise. (This rules out some forms of voting, and of disbursing coins to past/future miners.)

+

The Dev Fund system should be simple to understand and realistic to implement. In particular, it should not assume the creation of new mechanisms (e.g., election systems) or entities (for governance or development) for its execution; but it should strive to support and use these once they are built.

+

Dev Fund recipients should comply with legal, regulatory, and taxation constraints in their pertinent jurisdiction(s).

+
+

Non-requirements

+

General on-chain governance is outside the scope of this proposal.

+

Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or one-person-one-vote) are outside the scope of this proposal, however this proposal does mandate the undertaking of the project to build a "non-direct funding model" as generally described in 13.

+
+

Specification

+

Consensus changes implied by this specification are applicable to the Zcash Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be applied to the Zcash Testnet for testing purposes.

+

Dev Fund allocation

+

Starting at the second Zcash halving in 2024, until the third halving in 2028, 15% of the block subsidy of each block SHALL be allocated to a "Dev Fund" that consists of the following allocations:

+
    +
  • 5% for the Zcash Foundation (for internal work and grants);
    • +
  • 4% for the Bootstrap Project (the parent of the Electric Coin Company) for the 1st year only;
    • +
  • 4% for Zcash Community Grants for continuation of their current activities as-is;
    • +
  • 2% for Qedit in support of their ZSA activities, and other Zcash protocol support;
    • +
+

Following the first year, when ECC will no longer receive their 4% allocation, those block subsidies will be distributed as 1% to ZCG, 1% to ZecHub, 1% to FPF, and 1% to ZF.

+

This proposal mandates the ecosystem to design and deploy a "non-direct funding model" as generally recommended in Josh Swihart's proposal 13.

+

"Dev Fund" block subsidies will be administered through two organizations:

+
    +
  1. Zcash Foundation (✳️ for ECC, ZCG)
    2. +
  2. Financial Privacy Foundation (✳️ for Qedit, ZecHub)
    3. +
+

✳️ ZF and FPF adminstration of block subsidy details, costs, et al are currently under debate 14

+

The allocations are described in more detail below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address(es) for each block. This Dev Fund will end at the third halving (unless extended/modified by a future ZIP).

+

BP allocation (Bootstrap Project)

+

✳️ These funds SHALL be received and administered by ZF.

+

This allocation of the Dev Fund will flow as charitable contributions from the Zcash Community to the Bootstrap Project, the newly formed parent organization to the Electric Coin Company. The Bootstrap Project is organized for exempt educational, charitable, and scientific purposes in compliance with Section 501(c)(3), including but not limited to furthering education, information, resources, advocacy, support, community, and research relating to cryptocurrency and privacy, including Zcash. This allocation will be used at the discretion of the Bootstrap Project for any purpose within its mandate to support financial privacy and the Zcash platform as permitted under Section 501(c)(3). The BP allocation will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.

+
+

ZF allocation (Zcash Foundation's general use)

+

This allocation of the Dev Fund will flow as charitable contributions from the Zcash Community to ZF, to be used at its discretion for any purpose within its mandate to support financial privacy and the Zcash platform, including: development, education, supporting community communication online and via events, gathering community sentiment, and awarding external grants for all of the above, subject to the requirements of Section 501(c)(3). The ZF allocation will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.

+
+

Zcash Community Grants (ZCG)

+

This allocation of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major and minor ongoing development (or other work) for the public good of the Zcash ecosystem, to the extent that such teams are available and effective.

+

✳️ These funds SHALL be received and administered by ZF (or FPF, pending TBD outcomes of FPF proposal: 14). ZF MUST disburse them for "Major Grants" and expenses reasonably related to the administration of Major Grants, but subject to the following additional constraints:

+
    +
  1. These funds MUST only be used to issue Major Grants to external parties that are independent of ZF, and to pay for expenses reasonably related to the administration of Major Grants. They MUST NOT be used by ZF for its internal operations and direct expenses not related to administration of Major Grants. Additionally, BP, ECC, and ZF are ineligible to receive Major Grants.
    2. +
  2. Major Grants SHOULD support well-specified work proposed by the grantee, at reasonable market-rate costs. They can be of any duration or ongoing without a duration limit. Grants of indefinite duration SHOULD have semiannual review points for continuation of funding.
    3. +
  3. Priority SHOULD be given to Major Grants that bolster teams with substantial (current or prospective) continual existence, and set them up for long-term success, subject to the usual grant award considerations (impact, ability, risks, team, cost-effectiveness, etc.). Priority SHOULD be given to Major Grants that support ecosystem growth, for example through mentorship, coaching, technical resources, creating entrepreneurial opportunities, etc. If one proposal substantially duplicates another's plans, priority SHOULD be given to the originator of the plans.
    4. +
  4. Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general) as permitted under Section 501(c)(3).
    5. +
  5. Major Grants awards are subject to approval by a five-seat Major Grant Review Committee. The Major Grant Review Committee SHALL be selected by the ZF's Community Advisory Panel or successor process.
    6. +
  6. The Major Grant Review Committee's funding decisions will be final, requiring no approval from the ZF Board, but are subject to veto if the Foundation judges them to violate U.S. law or the ZF's reporting requirements and other (current or future) obligations under U.S. IRS 501(c)(3).
    7. +
  7. Major Grant Review Committee members SHALL have a one-year term and MAY sit for reelection. The Major Grant Review Committee is subject to the same conflict of interest policy that governs the ZF Board of Directors (i.e. they MUST recuse themselves when voting on proposals where they have a financial interest). At most one person with association with the BP/ECC, and at most one person with association with the ZF, are allowed to sit on the Major Grant Review Committee. "Association" here means: having a financial interest, full-time employment, being an officer, being a director, or having an immediate family relationship with any of the above. The ZF SHALL continue to operate the Community Advisory Panel and SHOULD work toward making it more representative and independent (more on that below).
    8. +
  8. From 1st January 2022, a portion of the MG allocation shall be allocated to a Discretionary Budget, which may be disbursed for expenses reasonably related to the administration of Major Grants. The amount of funds allocated to the Discretionary Budget SHALL be decided by the ZF's Community Advisory Panel or successor process. Any disbursement of funds from the Discretionary Budget MUST be approved by the Major Grant Review Committee. Expenses related to the administration of Major Grants include, without limitation the following: +
      +
    • Paying third party vendors for services related to domain name registration, or the design, website hosting and administration of websites for the Major Grant Review Committee.
      • +
    • Paying independent consultants to develop requests for proposals that align with the Major Grants program.
      • +
    • Paying independent consultants for expert review of grant applications.
      • +
    • Paying for sales and marketing services to promote the Major Grants program.
      • +
    • Paying third party consultants to undertake activities that support the purpose of the Major Grants program.
      • +
    • Reimbursement to members of the Major Grant Review Committee for reasonable travel expenses, including transportation, hotel and meals allowance.
      • +
    +

    The Major Grant Review Committee's decisions relating to the allocation and disbursement of funds from the Discretionary Budget will be final, requiring no approval from the ZF Board, but are subject to veto if the Foundation judges them to violate U.S. law or the ZF's reporting requirements and other (current or future) obligations under U.S. IRS 501(c)(3).

    +
    9. +
+

ZF SHALL recognize the MG allocation of the Dev Fund as a Restricted Fund donation under the above constraints (suitably formalized), and keep separate accounting of its balance and usage under its Transparency and Accountability obligations defined below.

+

ZF SHALL strive to define target metrics and key performance indicators, and the Major Grant Review Committee SHOULD utilize these in its funding decisions.

+
+

Qedit

+

✳️ These funds SHALL be received and administered by FPF.

+

This allocation of the Dev Fund will flow as charitable contributions from the Zcash Community to Qedit, for the purposes of supporting their ongoing activities related to Zcash Shielded Assets, and related protocol/ application/ legal/ and other efforts.

+
+

ZecHub

+

✳️ These funds SHALL be received and administered by FPF.

+

This allocation of the Dev Fund will flow as charitable contributions from the Zcash Community to ZecHub, for the purposes of continuing their ongoing content contributions, community organizing, et al within the Zcash ecosystem.

+
+
+

Transparency and Accountability

+

Obligations

+

BP, ECC, ZF, ZCG, Qedit, FPF and ZecHub are recommended to accept the obligations in this section.

+

Ongoing public reporting requirements:

+
    +
  • Quarterly reports, detailing future plans, execution on previous plans, and finances (balances, and spending broken down by major categories).
    • +
  • Monthly developer calls, or a brief report, on recent and forthcoming tasks. (Developer calls may be shared.)
    • +
  • Annual detailed review of the organization performance and future plans.
    • +
  • Annual financial report (IRS Form 990, or substantially similar information).
    • +
+

These reports may be either organization-wide, or restricted to the income, expenses, and work associated with the receipt of Dev Fund. As BP is the parent organization of ECC it is expected they may publish joint reports.

+

It is expected that ECC, ZF, and ZCG will be focused primarily (in their attention and resources) on Zcash. Thus, they MUST promptly disclose:

+
    +
  • Any major activity they perform (even if not supported by the Dev Fund) that is not in the interest of the general Zcash ecosystem.
    • +
  • Any conflict of interest with the general success of the Zcash ecosystem.
    • +
+

BP, ECC, ZF, and grant recipients MUST promptly disclose any security or privacy risks that may affect users of Zcash (by responsible disclosure under confidence to the pertinent developers, where applicable).

+

BP's reports, ECC's reports, and ZF's annual report on its non-grant operations, SHOULD be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.

+

All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative 5), preferably the MIT license.

+
+

Enforcement

+

For grant recipients, these conditions SHOULD be included in their contract with ZF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to ZF.

+

BP, ECC, and ZF MUST contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other party to issue a modified version of Zcash node software that removes the violating party's Dev Fund allocation, and use the Zcash trademark for this modified version. The allocation's funds will be reassigned to MG (whose integrity is legally protected by the Restricted Fund treatment).

+
+
+

Future Community Governance

+

It is highly desirable to develop robust means of decentralized community voting and governance –either by expanding the Zcash Community Advisory Panel or a successor mechanism– and to integrate them into this process by the end of 2025. BP, ECC, ZCG, and ZF SHOULD place high priority on such development and its deployment, in their activities and grant selection.

+
+

ZF Board Composition

+

Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC, except as provided for by the grace period described below.

+

Grace period: members of the ZF board who hold ECC equity (but do not have other current relationships to ECC) may dispose of their equity, or quit the Board, by 21 November 2024. (The grace period is to allow for orderly replacement, and also to allow time for ECC corporate reorganization related to Dev Fund receipt, which may affect how disposition of equity would be executed.)

+

The Zcash Foundation SHOULD endeavor to use the Community Advisory Panel (or successor mechanism) as advisory input for future board elections.

+
+
+

Acknowledgements

+

This proposal is a modification of ZIP 1014 10 and a modification from the original "Manufacturing Consent" proposal as described in the Zcash Forum, in response to observable Zcash community sentiment.

+

The author is grateful to everyone in the Zcash ecosystem.

+
+

References

+ + + + + + + +
1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
+ + + + + + + +
2Zcash Protocol Specification, Version 2021.2.16 or later
+ + + + + + + +
3Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet
+ + + + + + + +
4Zcash Trademark Donation and License Agreement
+ + + + + + + +
5The Open Source Definition
+ + + + + + + +
6ZIP 200: Network Upgrade Mechanism
+ + + + + + + +
7ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
+ + + + + + + +
8ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams
+ + + + + + + +
9ZIP 1011: Decentralize the Dev Fee
+ + + + + + + +
10ZIP 1012: Dev Fund to ECC + ZF + Major Grants
+ + + + + + + +
11ZF Community Advisory Panel
+ + + + + + + +
12U.S. Code, Title 26, Section 501(c)(3)
+ + + + + + + +
13Zcash Funding Bloc : A Dev Fund Proposal from Josh at ECC
+ + + + + + + +
14Proposal: ZCG under FPF
+
+
+ + \ No newline at end of file diff --git a/rendered/draft-nuttycom-funding-allocation.html b/rendered/draft-nuttycom-funding-allocation.html new file mode 100644 index 000000000..873d30463 --- /dev/null +++ b/rendered/draft-nuttycom-funding-allocation.html @@ -0,0 +1,328 @@ + + + + Draft nuttycom-funding-allocation: Block Reward Allocation for Non-Direct Development Funding + + + +
+ 
ZIP: Unassigned
+Title: Block Reward Allocation for Non-Direct Development Funding
+Owners: Kris Nuttycombe <kris@nutty.land>
+        Jason McGee <aquietinvestor@gmail.com>
+Original-Authors: Skylar Saveland <skylar@free2z.com>
+Credits: Daira-Emma Hopwood
+         Jack Grigg
+         @Peacemonger (Zcash Forum)
+Status: Draft
+Category: Consensus
+Created: 2024-07-03
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/866>
+

Terminology

+

The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

+
+

Abstract

+

This ZIP proposes several options for the allocation of a percentage of the Zcash block subsidy, post-November 2024 halving, to an in-protocol "lockbox." The "lockbox" will be a separate pool of issued funds tracked by the protocol, as described in ZIP 2001: Lockbox Funding Streams 4. No disbursement mechanism is currently defined for this "lockbox"; the Zcash community will need to decide upon and specify a suitable decentralized mechanism for permitting withdrawals from this lockbox in a future ZIP in order to make these funds available for funding grants to ecosystem participants.

+

The proposed lockbox addresses significant issues observed with ZIP 1014 3, such as regulatory risks, inefficiencies due to funding of organizations instead of projects, and centralization. While the exact disbursement mechanism for the lockbox funds is yet to be determined and will be addressed in a future ZIP, the goal is to employ a decentralized mechanism that ensures community involvement and efficient, project-specific funding. This approach is intended to potentially improve regulatory compliance, reduce inefficiencies, and enhance the decentralization of Zcash's funding structure.

+
+

Motivation

+

Starting at Zcash's second halving in November 2024, by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, unless the community takes action to approve new block-reward based funding, existing teams dedicated to development or outreach or furthering charitable, educational, or scientific purposes will likely need to seek other sources of funding; failure to obtain such funding would likely impair their ability to continue serving the Zcash ecosystem. Setting aside a portion of the block subsidy to fund development will help ensure that both existing teams and new contributors can obtain funding in the future.

+

It is important to balance the incentives for securing the consensus protocol through mining with funding crucial charitable, educational, and scientific activities like research, development, and outreach. Additionally, there is a need to continue to promote decentralization and the growth of independent development teams.

+

For these reasons, the Zcash Community wishes to establish a new Zcash Development Fund after the second halving in November 2024, with the intent to put in place a more decentralized mechanism for allocation of development funds. The alternatives presented here are intended to address the following:

+
    +
  1. Regulatory Risks: The current model involves direct funding of US-based organizations, which can potentially attract regulatory scrutiny from entities such as the SEC, posing legal risks to the Zcash ecosystem.
    2. +
  2. Funding Inefficiencies: The current model directly funds organizations rather than specific projects, leading to a potential mismatch between those organizations' development priorities and the priorities of the community. Furthermore, if organizations are guaranteed funds regardless of performance, there is little incentive to achieve key performance indicators (KPIs) or align with community sentiment. A future system that allocates resources directly to projects rather than organizations may help reduce inefficiencies and better align development efforts with community priorities.
    3. +
  3. Centralization Concerns: The current model centralizes decision-making power within a few organizations, contradicting the decentralized ethos of blockchain technology. Traditional organizational structures with boards and executives introduce single points of failure and limit community involvement in funding decisions.
    4. +
  4. Community Involvement: The current system provides minimal formal input from the community regarding what projects should be funded, leading to a misalignment between funded projects and community priorities.
    5. +
  5. Moving Towards a Non-Direct Funding Model: There is strong community support for a non-direct Dev Fund funding model. Allocating funds to a Deferred Dev Fund Lockbox incentivizes the development of a decentralized mechanism for the disbursement of the locked funds.
    6. +
+

By addressing these issues, this proposal aims to ensure sustainable, efficient, and decentralized funding for essential activities within the Zcash ecosystem.

+
+

Requirements

+
    +
  1. In-Protocol Lockbox: The alternatives presented in this ZIP depend upon the Lockbox Funding Streams proposal 4.
    2. +
  2. Regulatory Considerations: The allocation of funds should minimize regulatory risks by avoiding direct funding of specific organizations. The design should enable and encourage compliance with applicable laws and regulations to support the long-term sustainability of the funding model.
    3. +
+
+

Non-requirements

+

The following considerations are explicitly deferred to future ZIPs and are not covered by this proposal:

+
    +
  1. Disbursement Mechanism: The exact method for disbursing the accumulated funds from the lockbox is not defined in this ZIP. The design, implementation, and governance of the disbursement mechanism will be addressed in a future ZIP. This includes specifics on how funds will be allocated, the voting or decision-making process, and the structure of the decentralized mechanism (such as a DAO).
    2. +
  2. Regulatory Compliance Details: The proposal outlines the potential to reduce regulatory risks by avoiding direct funding of US-based organizations, but it does not detail specific regulatory compliance strategies. Future ZIPs will need to address how the disbursement mechanism complies with applicable laws and regulations.
    3. +
  3. Impact Assessment: The long-term impact of reallocating a portion of the block subsidy to the lockbox on the Zcash ecosystem, including its effect on miners, developers, and the broader community, is not analyzed in this ZIP. Subsequent proposals will need to evaluate the outcomes and make necessary adjustments based on real-world feedback and data.
    4. +
+
+

Specification

+

The following alternatives all depend upon the Lockbox Funding Streams proposal 4 for storage of funds into a deferred value pool.

+

Some of the alternatives described below do not specify a termination height for the funding streams they propose. In these cases, the termination height is set to u32::MAX_VALUE. A future network upgrade that alters the maximum possible block height MUST also alter these termination heights.

+
+

Alternatives

+

Alternative 1: Lockbox For Decentralized Grants Allocation (perpetual 50% option)

+

Proposed by Skylar Saveland

+
    +
  • 50% of the block subsidy is to be distributed to the lockbox.
    • +
+

As of block height 2726400, and continuing until modified by a future ZIP, the complete set of funding streams will be:

+ + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_DEFERRED501002726400u32::MAX
+

Motivations for Alternative 1

+

This alternative proposes allocating a significantly larger portion of the block subsidy to development funding than is currently allocated, aiming to establish a long-term source of funding for protocol improvements. The disbursement of these funds will be governed by a mechanism to be determined by the community in the future, ensuring that the funds are released under agreed-upon constraints to maintain availability for years to come.

+

The proposed lockbox funding model for Zcash's post-NU6 halving period allocates 50% of the block reward to a deferred reserve, or "lockbox," designated for future decentralized grants funding. This approach is designed to address several critical motivations:

+ +
    +
  1. Regulatory Compliance: +
      +
    • Reduction of Regulatory Risks: Direct funding to legal entities poses significant regulatory risks. Allocating funds to a decentralized lockbox mitigates these risks by avoiding direct funding of any specific organizations. This alternative represents the strongest regulatory posture, as it reduces the likelihood of legal challenges associated with funding centralized entities directly.
      • +
    • Potential Minimization of KYC Requirements: The current funding mechanism involves 100% KYC for recipients, which can be detrimental to security, privacy, resilience, and participation. A sufficiently decentralized disbursement mechanism could reduce the need for recipients to undergo KYC with a controlling entity. This would preserve privacy and encourage broader participation from developers and contributors who value anonymity and privacy. By shifting from direct funding of specific legal entities to a decentralized funding model, we create a more secure, private, and resilient ecosystem. This potential future difference enhances the robustness of the Zcash network by fostering a diverse and engaged community without the constraints of centralized direct funding.
      • +
    +
    2. +
  2. Ensuring Sustainable Development Funding: +
      +
    • Need for Continuous Funding: Zcash has numerous ongoing and future projects essential for its ecosystem's growth and security. Without a change, the expiration of the devfund will result in 100% of the block reward going to miners, jeopardizing funding for development. The proposed 50% lockbox allocation ensures that funds are directed towards sustaining and improving the Zcash ecosystem through a wide array of initiatives. These include protocol development, new features, security audits, legal support, marketing, ZSAs (Zcash Shielded Assets), stablecoins, programmability, transitioning to a modern Rust codebase, wallets, integrations with third-party services, improved node software, block explorers, supporting ambassadors, and educational initiatives like ZecHub.
      • +
    • Balanced Incentives for Network and Protocol Security: While miners have been essential in providing network security through hashpower, allocating 100% of the block reward to mining alone overlooks the crucial need for development, innovation, and protocol security. By investing in these priorities, we enhance the long-term health and value of the protocol, which ultimately benefits miners. A well-maintained and innovative protocol increases the overall value of the network, making miners' rewards more valuable. This balanced approach aligns the interests of miners with the broader community, ensuring sustainable growth and security for Zcash.
      • +
    +
    3. +
  3. Efficiency, Accountability, and Decentralization: +
      +
    • Reduction of Inefficiencies: Traditional funding models often involve significant corporate overhead and centralized decision-making, leading to inefficiencies. The prior model provided two 501(c)(3) organizations with constant funding for four years, which reduced accountability and allowed for potential misalignment with the community's evolving priorities. By funding projects directly rather than organizations, we can allocate resources more efficiently, ensuring that funds are used for tangible development rather than administrative costs. This approach minimizes the influence of corporate executives, whose decisions have sometimes failed to address critical issues promptly.
      • +
    • Increased Accountability: A presumed grants-only mechanism, to be defined in a future ZIP, would necessitate continuous accountability and progress for continuous funding. Unlike the prior model, where organizations received guaranteed funding regardless of performance, a grants-based approach would require projects to demonstrate ongoing success and alignment with community goals to secure funding. This continuous evaluation fosters a more responsive and responsible allocation of resources, ensuring that funds are directed towards initiatives that provide the most value to the Zcash ecosystem. By increasing accountability, this model promotes a culture of excellence and innovation, driving sustained improvements and advancements in the protocol.
      • +
    • Promotion of Decentralization: The proposed non-direct funding model stores deferred funds for future use, with the specifics of the disbursement mechanism to be determined by a future ZIP. This could allow the community to have a greater influence over funding decisions, aligning more closely with the ethos of the Zcash project. By decentralizing the allocation process, this approach has the potential to foster innovation and community involvement, ensuring that development priorities are more reflective of the community's needs and desires, promoting a more open, transparent, and resilient ecosystem.
      • +
    +
    4. +
  4. Incentives for Development and Collaboration: +
      +
    • Creating a Strong Incentive to Implement the Disbursement Mechanism: Allocating 50% of the block reward to the lockbox indefinitely creates a powerful incentive for the community to work together to implement the disbursement mechanism without delay. Knowing that there is a substantial amount of funds available, stakeholders will be motivated to develop and agree on an effective, decentralized method for distributing these funds.
      • +
    • Incentivizing Continuous Improvements: The accumulation of a large stored fortune within the lockbox incentivizes continuous improvements to the Zcash protocol and ecosystem. Developers, contributors, and community members will be driven to propose and execute projects that enhance the network, knowing that successful initiatives have the potential to receive funding. This model fosters a culture of ongoing innovation and development, ensuring that Zcash remains at the forefront of blockchain technology.
      • +
    • Aligning Long-Term Interests: By tying a significant portion of the block reward to future decentralized grants funding, the model aligns the long-term interests of all stakeholders. Miners, developers, and community members alike have a vested interest in maintaining and improving the Zcash network, as the value and success of their efforts are directly linked to the availability and effective use of the lockbox funds. This alignment of incentives ensures that the collective efforts of the community are focused on the sustainable growth and advancement of the Zcash ecosystem.
      • +
    +
    5. +
+
+

Guidance on Future Requirements for Alternative 1

+

To support the motivations outlined, the following guidance is proposed for Alternative 1. Future ZIP(s) will define the disbursement mechanism. These are suggestions to achieve the outlined motivations and should be considered in those future ZIP(s). It is important to note that these are ideas and guidance, not hard, enforceable requirements:

+
    +
  1. Cap on Grants: Grants should be capped to promote more granular accountability and incremental goal-setting. This approach ensures that projects are required to define their work, goals, milestones, KPIs, and achievements in smaller, more manageable increments. Even if a single project is utilizing significant funds quickly, the cap ensures that progress is continuously evaluated and approved based on tangible results and alignment with community priorities.
    2. +
  2. Decentralized Disbursement Mechanism: The disbursement mechanism should be sufficiently decentralized to ensure the regulatory motivations are fulfilled. A decentralized mechanism could reduce the need for recipients to undergo KYC with a controlling party, preserving privacy and aligning with the ethos of the Zcash project.
    3. +
  3. Governance and Accountability: The governance structure for the disbursement mechanism should be open and accountable, with decisions made through community consensus or decentralized voting processes to maintain trust and accountability. This approach will help ensure that the allocation of funds is fair and aligned with the community's evolving priorities.
    4. +
  4. Periodic Review and Adjustment: There should be provisions for periodic review and adjustment of the funding mechanism to address any emerging issues or inefficiencies and to adapt to the evolving needs of the Zcash ecosystem. This could include the ability to add or remove participants as necessary. Regular assessments will help keep the funding model responsive and effective, ensuring it continues to meet the community's goals.
    5. +
+

By addressing these motivations and providing this guidance, Alternative 1 aims to provide a robust, sustainable, and decentralized funding model that aligns with the principles and long-term goals of the Zcash community.

+
+
+

Alternative 2: Hybrid Deferred Dev Fund: Transitioning to a Non-Direct Funding Model

+

Proposed by Jason McGee, Peacemonger, GGuy

+
    +
  • 12% of the block subsidy is to be distributed to the lockbox.
    • +
  • 8% of the block subsidy is to be distributed to the Financial Privacy Foundation (FPF), for the express use of the Zcash Community Grants Committee (ZCG) to fund independent teams in the Zcash ecosystem.
    • +
+

As of block height 2726400, and continuing for one year, the complete set of funding streams will be:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_DEFERRED1210027264003146400
FS_FPF_ZCG810027264003146400
+

Motivations for Alternative 2

+
    +
  • Limited Runway: ZCG does not have the financial runway that ECC/BP and ZF have. As such, allocating ongoing funding to ZCG will help ensure the Zcash ecosystem has an active grants program.
    • +
  • Promoting Decentralization: Allocating a portion of the Dev Fund to Zcash Community Grants ensures small teams continue to receive funding to contribute to Zcash. Allowing the Dev Fund to expire, or putting 100% into a lockbox, would disproportionally impact grant recipients. This hybrid approach promotes decentralization and the growth of independent development teams.
    • +
  • Mitigating Regulatory Risks: The Financial Privacy Foundation (FPF) is a non-profit organization incorporated and based in the Cayman Islands. By minimizing direct funding of US-based organizations, this proposal helps to reduce potential regulatory scrutiny and legal risks.
    • +
+
+
+

Alternative 3: Lockbox For Decentralized Grants Allocation (20% option)

+

Proposed by Kris Nuttycombe

+
    +
  • 20% of the block subsidy is to be distributed to the lockbox.
    • +
+

As of block height 2726400, and continuing for two years, the complete set of funding streams will be:

+ + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_DEFERRED2010027264003566400
+

Motivations for Alternative 3

+

This alternative is presented as the simplest allocation of block rewards to a lockbox for future disbursement that is consistent with results of community polling.

+
+
+

Alternative 4: Masters Of The Universe?

+

Proposed by NoamChom (Zcash forum)

+
    +
  • 17% of the block subsidy is to be distributed to the lockbox.
    • +
  • 8% of the block subsidy is to be distributed to the Financial Privacy Foundation (FPF), for the express use of the Zcash Community Grants Committee (ZCG) to fund independent teams in the Zcash ecosystem.
    • +
+

As of block height 2726400, and continuing for four years, the complete set of funding streams will be:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_DEFERRED1710027264004406400
FS_FPF_ZCG810027264004406400
+

Motivations for Alternative 4

+

This alternative proposes a slightly larger slice of the block subsidy than is currently allocated for development funding, in order to better provide for the needs of the Zcash community.

+
+

Revisitation Requirement for Alternative 4

+

The terms for this Alternative should be revisited by the Zcash ecosystem upon creation/ activation of a "non-direct funding model" (NDFM). At that completion of an NDFM which accessess the lockbox funds, this ZIP should be reconsidered (potentially terminated) by the Zcash ecosystem, to determine if its ongoing direct block subsidies are preferred for continuation. Discussions / solications / sentiment gathering from the Zcash ecosystem should be initiated ~6 months in advance of the presumed activation of a "non-direct funding model", such that the Zcash ecosystem preference can be expediently realized.

+
+
+
+ +

References

+ + + + + + + +
1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
+ + + + + + + +
2The Open Source Definition
+ + + + + + + +
3ZIP 1014: Dev Fund Proposal and Governance
+ + + + + + + +
4ZIP 2001: Lockbox Funding Streams
+
+
+ + \ No newline at end of file diff --git a/rendered/draft-nuttycom-lockbox-streams.html b/rendered/draft-nuttycom-lockbox-streams.html new file mode 100644 index 000000000..17c801d92 --- /dev/null +++ b/rendered/draft-nuttycom-lockbox-streams.html @@ -0,0 +1,10 @@ + + + + ZIP 2001: Lockbox Funding Streams (redirect) + + + +

This draft was assigned ZIP number 2001.

+ + \ No newline at end of file diff --git a/rendered/draft-zf-community-dev-fund-2-proposal.html b/rendered/draft-zf-community-dev-fund-2-proposal.html new file mode 100644 index 000000000..4fdd60eab --- /dev/null +++ b/rendered/draft-zf-community-dev-fund-2-proposal.html @@ -0,0 +1,280 @@ + + + + Draft zf-community-dev-fund-2-proposal: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve + + + +
+ 
ZIP: Unassigned
+Title: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
+Owners: Jack Gavigan <jack@zfnd.org>
+Credits: The ZIP 1014 Authors
+Status: Draft
+Category: Consensus Process
+Created: 2024-07-01
+License: MIT
+Discussions-To:
+Pull-Request:
+

Terminology

+

The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

+

The term "network upgrade" in this document is to be interpreted as described in ZIP 200 6 and the Zcash Trademark Donation and License Agreement (4 or successor agreement).

+

The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. 2

+

"Electric Coin Company", also called "ECC", refers to the US-incorporated Zerocoin Electric Coin Company, LLC.

+

"Bootstrap Project", also called "BP", refers to the US-incorporated 501(c)(3) nonprofit corporation of that name.

+

"Zcash Foundation", also called "ZF", refers to the US-incorporated 501(c)(3) nonprofit corporation of that name.

+

"Financial Privacy Foundation", also called "FPF", refers to the Cayman Islands-incorporated non-profit foundation company limited by guarantee of that name.

+

"Autonomous Entities" refers to committees, DAOs, teams or other groups to which FPF provides operations, administrative, and financial management support.

+

"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). 14

+

"Zcash Community Advisory Panel", also called "ZCAP", refers to the panel of community members assembled by the Zcash Foundation and described at 13.

+

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.

+

“Lockbox” refers to a deferred funding pool of issued Zcash value as described in ZIP 2001 12.

+

“Dev Fund Reserve”, also called “DFR”, refers to the funds that are to be stored in the Lockbox as a result of the changes described in this ZIP.

+
+

Abstract

+

This proposal describes a structure for a new Zcash Development Fund (“Dev Fund”), to be enacted in Network Upgrade 6 and last for 2 years. This Dev Fund shall consist of 20% of the block subsidies.

+

The Dev Fund shall be split into 3 slices:

+
    +
  • 32% for Zcash Foundation;
    • +
  • 40% for "Zcash Community Grants", intended to fund large-scale long-term Projects (administered by the Financial Privacy Foundation, with extra community input and scrutiny).
    • +
  • 28% for a Dev Fund Reserve, to be stored in a Lockbox.
    • +
+

The Lockbox will securely store funds until a disbursement mechanism is established in a future ZIP.

+

Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged.

+
+

Motivation

+

Starting at Zcash's second halving in November 2024, the first Dev Fund will expire, meaning that by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, no substantial new funding may be available to existing teams dedicated to furthering charitable, educational, or scientific purposes, such as research, development, and outreach: the Electric Coin Company (ECC), the Zcash Foundation (ZF), and the many entities funded by the ZF grants and Zcash Community Grants programs.

+

There is a need to continue to strike a balance between incentivizing the security of the consensus protocol (i.e., mining) versus crucial charitable, educational, and/or scientific aspects, such as research, development and outreach.

+

Furthermore, there is a need to balance the sustenance of ongoing work by the current teams dedicated to Zcash, with encouraging decentralization and growth of independent development teams.

+

For these reasons, the Zcash Community desires to allocate and contribute a slice of the block subsidies otherwise allocated to miners as a donation to support charitable, educational, and scientific activities within the meaning of Section 501(c)(3) of Title 26 of the United States Code, and the Cayman Islands’ Foundation Companies Law, 2017.

+

The Zcash Community also supports the concept of a non-direct funding model, and desires to allocate a slice of the block subsidies otherwise allocated to miners to a Lockbox, with the expectation that those funds will be distributed under a non-direct funding model, which may be implemented in a future network upgrade.

+

For these reasons, the Zcash Community wishes to establish a Hybrid Development Fund after the second halving in November 2024, and apportion it among ZF, ZCG, and a Dev Fund Reserve to be held in a Lockbox.

+
+

Requirements

+

The Dev Fund should encourage decentralization of the Zcash ecosystem, by supporting new teams dedicated to Zcash.

+

The Dev Fund should maintain the existing teams and capabilities in the Zcash ecosystem, unless and until concrete opportunities arise to create even greater value for the Zcash ecosystem.

+

There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.

+

Major funding decisions should be based, to the extent feasible, on inputs from domain experts and pertinent stakeholders.

+

The Dev Fund mechanism itself should not modify the monetary emission curve (and in particular, should not irrevocably burn coins).

+

In case the value of ZEC jumps, the Dev Fund recipients should not wastefully use excessive amounts of funds. Conversely, given market volatility and eventual halvings, it is desirable to create rainy-day reserves.

+

The Dev Fund mechanism should not reduce users' financial privacy or security. In particular, it should not cause them to expose their coin holdings, nor cause them to maintain access to secret keys for much longer than they would otherwise. (This rules out some forms of voting, and of disbursing coins to past/future miners.)

+

The new Dev Fund system should be simple to understand and realistic to implement. In particular, it should not assume the creation of new mechanisms (e.g., election systems) or entities (for governance or development) for its execution; but it should strive to support and use these once they are built.

+

The Dev Fund should comply with legal, regulatory, and taxation constraints in pertinent jurisdictions.

+

The Lockbox must be prepared to allocate resources efficiently once the disbursement mechanism is defined. This includes ensuring that funds are readily available for future projects and not tied up in organizational overhead.

+

The Lockbox must implement robust security measures to protect against unauthorized access or misuse of funds. It must not be possible to disburse funds from the Lockbox until the Zcash Community reaches consensus on the design of a disbursement mechanism that is defined in a ZIP and implemented as part of a future Network Upgrade.

+
+

Non-requirements

+

General on-chain governance is outside the scope of this proposal.

+

Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or one-person-one-vote) are outside the scope of this proposal, though there is prescribed room for integrating them once available.

+

The mechanism by which funds held in the Dev Fund Reserve Lockbox are to be distributed is outside the scope of this proposal.

+
+

Specification

+

Consensus changes implied by this specification are applicable to the Zcash Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be applied to the Zcash Testnet for testing purposes.

+

Dev Fund allocation

+

Starting at the second Zcash halving in 2024, until block height 3566400 (which is expected to occur approximately two years after the second Zcash halving), 20% of the block subsidy of each block SHALL be allocated to a Dev Fund that consists of the following three slices:

+
    +
  • 32% for the Zcash Foundation (denoted ZF slice);
    • +
  • 40% for the Financial Privacy Foundation, for "Zcash Community Grants" for large-scale long-term projects (denoted ZCG slice);
    • +
  • 28% for the Dev Fund Reserve (denoted DFR slice).
    • +
+

The slices are described in more detail below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address(es) for each block. This Dev Fund will end at block height 3566400 (unless extended/modified by a future ZIP).

+

ZF slice (Zcash Foundation)

+

This slice of the Dev Fund will flow as charitable contributions from the Zcash Community to ZF, to be used at its discretion for any purpose within its mandate to support financial privacy and the Zcash platform, including: development, education, supporting community communication online and via events, gathering community sentiment, and awarding external grants for all of the above, subject to the requirements of Section 501(c)(3). The ZF slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.

+
+

ZCG slice (Zcash Community Grants)

+

This slice of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem, to the extent that such teams are available and effective.

+

The funds SHALL be received and administered by FPF. FPF MUST disburse them for "Zcash Community Grants" and expenses reasonably related to the administration of Zcash Community Grants, but subject to the following additional constraints:

+
    +
  1. These funds MUST only be used to issue Zcash Community Grants to external parties that are independent of FPF or to Autonomous Entities that operate under the FPF umbrella, and to pay for expenses reasonably related to the administration of Zcash Community Grants. They MUST NOT be used by FPF for its internal operations and direct expenses not related to administration of Zcash Community Grants. Additionally, ZF is ineligible to receive Zcash Community Grants while ZF is receiving a slice of the Dev Fund.
    2. +
  2. Zcash Community Grants SHOULD support well-specified work proposed by the grantee, at reasonable market-rate costs. They can be of any duration or ongoing without a duration limit. Grants of indefinite duration SHOULD be reviewed periodically (on a schedule that the Zcash Community Grants Committee considers appropriate for the value and complexity of the grant) for continuation of funding.
    3. +
  3. Priority SHOULD be given to Zcash Community Grants that bolster teams with substantial (current or prospective) continual existence, and set them up for long-term success, subject to the usual grant award considerations (impact, ability, risks, team, cost-effectiveness, etc.). Priority SHOULD Be given to grants that support ecosystem growth, for example through mentorship, coaching, technical resources, creating entrepreneurial opportunities, etc. If one proposal substantially duplicates another's plans, priority SHOULD be given to the originator of the plans.
    4. +
  4. Zcash Community Grants SHOULD be restricted to furthering the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general).
    5. +
  5. Zcash Community Grants awards are subject to approval by a five-seat Zcash Community Grants Committee. The Zcash Community Grants Committee SHALL be selected by the ZF's Zcash Community Advisory Panel (ZCAP) or successor process.
    6. +
  6. The Zcash Community Grants Committee's funding decisions will be final, requiring no approval from the FPF Board, but are subject to veto if FPF judges them to violate Cayman law or the FPF's reporting requirements and other (current or future) obligations under the Cayman Islands’ Companies Act (2023 Revision) and Foundation Companies Law, 2017.
    7. +
  7. Zcash Community Grants Committee members SHALL have a one-year term and MAY sit for reelection. The Zcash Community Grants Committee is subject to the same conflict of interest policy that governs the FPF Board of Directors (i.e. they MUST recuse themselves when voting on proposals where they have a financial interest). At most one person with association with the BP/ECC, at most one person with association with the ZF and at most one person with association with the FPF, are allowed to sit on the Zcash Community Grants Committee. "Association" here means: having a financial interest, full-time employment, being an officer, being a director, or having an immediate family relationship with any of the above.
    8. +
  8. A portion of the ZCG Slice shall be allocated to a Discretionary Budget, which may be disbursed for expenses reasonably related to the administration of Zcash Community Grants. The amount of funds allocated to the Discretionary Budget SHALL be decided by the ZF's Zcash Community Advisory Panel or successor process. Any disbursement of funds from the Discretionary Budget MUST be approved by the Zcash Community Grants Committee. Expenses related to the administration of Zcash Community Grants include, without limitation the following: +
      +
    • Paying for operational management and administration services that support the purpose of the Zcash Community Grants program, including administration services provided by FPF.
      • +
    • Paying third party vendors for services related to domain name registration, or the design, website hosting and administration of websites for the Zcash Community Grants Committee.
      • +
    • Paying independent consultants to develop requests for proposals that align with the Zcash Community Grants program.
      • +
    • Paying independent consultants for expert review of grant applications.
      • +
    • Paying for sales and marketing services to promote the Zcash Community Grants program.
      • +
    • Paying third party consultants to undertake activities that support the purpose of the Zcash Community Grants program.
      • +
    • Reimbursement to members of the Zcash Community Grants Committee for reasonable travel expenses, including transportation, hotel and meals allowance.
      • +
    +

    The Zcash Community Grants Committee's decisions relating to the allocation and disbursement of funds from the Discretionary Budget will be final, requiring no approval from the FPF Board, but are subject to veto if FPF judges them to violate Cayman law or the FPF's reporting requirements and other (current or future) obligations under Cayman Islands law.

    +
    9. +
  9. A portion of the Discretionary Budget MAY be allocated to provide reasonable compensation to members of the Zcash Community Grants Committee. The time for which each Committee member is compensated SHALL be limited to the hours needed to successfully perform their positions, up to a maximum of 15 hours in each month, and MUST align with the scope and responsibilities of that member's role. The compensation rate for each Committee member SHALL be $115 per hour (and therefore the maximum compensation for a Committee member is $1725 per month). The allocation and distribution of compensation to committee members SHALL be administered by FPF. Changes to the hours or rate SHALL be determined by the ZF’s Zcash Community Advisory Panel or successor process.
    10. +
+

As part of the contractual commitment specified under the Enforcement section below, FPF SHALL be contractually required to recognize the ZCG slice of the Dev Fund as a Restricted Fund donation under the above constraints (suitably formalized), and keep separate accounting of its balance and usage under its Transparency and Accountability obligations defined below.

+
+

DFR slice (Dev Fund Reserve)

+

This slice of the Dev Fund is to be stored in a Lockbox until such time as the Zcash Community reaches consensus on the design of a disbursement mechanism that is defined in a ZIP and implemented as part of a future Network Upgrade.

+
+
+

Transparency and Accountability

+

Obligations

+

ZF, FPF and Zcash Community Grant recipients (during and leading to their award period) SHALL all accept the obligations in this section.

+

Ongoing public reporting requirements:

+
    +
  • Quarterly reports, detailing future plans, execution on previous plans, and finances (balances, and spending broken down by major categories).
    • +
  • Monthly developer calls, or a brief report, on recent and forthcoming tasks. (Developer calls may be shared.)
    • +
  • Annual detailed review of the organization performance and future plans.
    • +
  • Annual financial report (IRS Form 990, or substantially similar information).
    • +
+

These reports may be either organization-wide, or restricted to the income, expenses, and work associated with the receipt of Dev Fund.

+

It is expected that ZF, FPF and Zcash Community Grant recipients will be focused primarily (in their attention and resources) on Zcash. Thus, they MUST promptly disclose:

+
    +
  • Any major activity they perform (even if not supported by the Dev Fund) that is not in the interest of the general Zcash ecosystem.
    • +
  • Any conflict of interest with the general success of the Zcash ecosystem.
    • +
+

BP, ECC, ZF, FPF and grant recipients MUST promptly disclose any security or privacy risks that may affect users of Zcash (by responsible disclosure under confidence to the pertinent developers, where applicable).

+

ZF's and FPF's annual reports on its non-grant operations, SHOULD be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.

+

All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative 5), preferably the MIT license.

+

The ZF SHALL continue to operate the Zcash Community Advisory Panel and SHOULD work toward making it more representative and independent (more on that below).

+
+

Enforcement

+

For grant recipients, these conditions SHOULD be included in their contract with FPF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to FPF.

+

ZF and FPF MUST contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other parties to issue a modified version of Zcash node software that removes the violating party's Dev Fund slice, and use the Zcash trademark for this modified version. The slice's funds will be reassigned to ZCG (whose integrity is legally protected by the Restricted Fund treatment).

+
+
+

Amendments and Replacement of the Dev Fund

+

Nothing in this ZIP is intended to preclude any amendments to the Dev Fund (including but not limited to, changes to the Dev Fund allocation and/or the addition of new Dev Fund recipients), if such amendments enjoy the consensus support of the Zcash community.

+

Nothing in this ZIP is intended to preclude replacement of the Dev Fund with a different mechanism for ecosystem development funding.

+

ZF and FPF SHOULD facilitate the amendment or replacement of the Dev Fund if there is sufficient community support for doing so.

+

This ZIP recognizes there is strong community support for a non-direct funding model. As such, ZF MUST collaborate with the Zcash community to research and explore the establishment of a non-direct funding model. The research should consider potential designs as well as possible legal and regulatory risks.

+
+

Future Community Governance

+

Decentralized community governance is used in this proposal via the Zcash Community Advisory Panel as input into the Zcash Community Grants Committee which governs the ZCG slice (Zcash Community Grants).

+

It is highly desirable to develop robust means of decentralized community voting and governance, either by expanding the Zcash Community Advisory Panel or a successor mechanism. ZF, FPF and ZCG SHOULD place high priority on such development and its deployment, in their activities and grant selection.

+
+

ZF Board Composition

+

Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC or BP.

+

The Zcash Foundation SHOULD endeavor to use the Zcash Community Advisory Panel (or successor mechanism) as advisory input for future board elections.

+
+

FPF Board Composition

+

Members of FPF's Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC or BP.

+
+
+

Acknowledgements

+

This proposal is a modification of ZIP 1014 11 by the Zcash Foundation based on feedback and suggestions from the community, and incorporating elements of draft ZIPs by community members Jason McGee and Skylar.

+

ZIP 1014 is a limited modification of Eran Tromer's ZIP 1012 10 by the Zcash Foundation and ECC, further modified by feedback from the community.

+

Eran's proposal is most closely based on the Matt Luongo 'Decentralize the Dev Fee' proposal (ZIP 1011) 9. Relative to ZIP 1011 there are substantial changes and mixing in of elements from @aristarchus's '20% Split Evenly Between the ECC and the Zcash Foundation' (ZIP 1003) 7, Josh Cincinnati's 'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) 8, and extensive discussions in the Zcash Community Forum, including valuable comments from forum users @aristarchus and @dontbeevil.

+
+

References

+ + + + + + + +
1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
+ + + + + + + +
2Zcash Protocol Specification, Version 2021.2.16 or later
+ + + + + + + +
3Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet
+ + + + + + + +
4Zcash Trademark Donation and License Agreement
+ + + + + + + +
5The Open Source Definition
+ + + + + + + +
6ZIP 200: Network Upgrade Mechanism
+ + + + + + + +
7ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
+ + + + + + + +
8ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams
+ + + + + + + +
9ZIP 1011: Decentralize the Dev Fee
+ + + + + + + +
10ZIP 1012: Dev Fund to ECC + ZF + Major Grants
+ + + + + + + +
11ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
+ + + + + + + +
12ZIP 2001: Lockbox Funding Streams
+ + + + + + + +
13Zcash Community Advisory Panel
+ + + + + + + +
14U.S. Code, Title 26, Section 501(c)(3)
+
+
+ + \ No newline at end of file diff --git a/rendered/index.html b/rendered/index.html new file mode 100644 index 000000000..8ee5e0a9c --- /dev/null +++ b/rendered/index.html @@ -0,0 +1,257 @@ + + + + README: Specifications and Zcash Improvement Proposals + + + +
+ +

What are ZIPs?

+

Zcash Improvement Proposals (ZIPs) are the way to:

+
    +
  • propose new features for the Zcash cryptocurrency and their rationale,
    • +
  • specify the implementation details of the feature,
    • +
  • collect community input on the proposal, and
    • +
  • document design decisions.
    • +
+
+

Contributing

+

The authors of a ZIP are responsible for building consensus within the community and documenting / addressing dissenting opinions.

+

Anyone can write a ZIP! We encourage community contributions and decentralization of work on the Zcash protocol. If you’d like to bounce ideas off people before formally writing a ZIP, we encourage it! Visit the ZcashCommunity Discord chat to talk about your idea.

+

Participation in the Zcash project is subject to a Code of Conduct.

+

The Zcash protocol is documented in its Protocol Specification.

+

To start contributing, first read ZIP 0 which documents the ZIP process. Then clone this repo from GitHub, and start adding your draft ZIP, formatted either as reStructuredText or as Markdown, into the zips/ directory.

+

For example, if using reStructuredText, use a filename matching zips/draft-*.rst. Use make to check that you are using correct reStructuredText or Markdown syntax, and double-check the generated rendered/draft-*.html file before filing a Pull Request. See here for the project dependencies.

+
+

License

+

Unless otherwise stated in this repository’s individual files, the contents of this repository are released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT .

+
+

Released ZIPs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZIP Title Status
0 ZIP Process Active
32 Shielded Hierarchical Deterministic Wallets Final
143 Transaction Signature Validation for Overwinter Final
155 addrv2 message Proposed
173 Bech32 Format Final
200 Network Upgrade Mechanism Final
201 Network Peer Management for Overwinter Final
202 Version 3 Transaction Format for Overwinter Final
203 Transaction Expiry Final
205 Deployment of the Sapling Network Upgrade Final
206 Deployment of the Blossom Network Upgrade Final
207 Funding Streams Final
208 Shorter Block Target Spacing Final
209 Prohibit Negative Shielded Chain Value Pool Balances Final
211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
213 Shielded Coinbase Final
214 Consensus rules for a Zcash Development Fund Final
215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
216 Require Canonical Jubjub Point Encodings Final
221 FlyClient - Consensus-Layer Changes Final
224 Orchard Shielded Protocol Final
225 Version 5 Transaction Format Final
239 Relay of Version 5 Transactions Final
243 Transaction Signature Validation for Sapling Final
244 Transaction Identifier Non-Malleability Final
250 Deployment of the Heartwood Network Upgrade Final
251 Deployment of the Canopy Network Upgrade Final
252 Deployment of the NU5 Network Upgrade Final
300 Cross-chain Atomic Transactions Proposed
301 Zcash Stratum Protocol Final
308 Sprout to Sapling Migration Final
316 Unified Addresses and Unified Viewing Keys Revision 0: Final, Revision 1: Proposed
317 Proportional Transfer Fee Mechanism Active
320 Defining an Address Type to which funds can only be sent from Transparent Addresses Proposed
321 Payment Request URIs Proposed
401 Addressing Mempool Denial-of-Service Active
1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
+

Draft ZIPs

+

These are works-in-progress that have been assigned ZIP numbers. These will eventually become either Proposed (and thus Released), or one of Withdrawn, Rejected, or Obsolete.

+

In some cases a ZIP number is reserved by the ZIP Editors before a draft is written.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZIP Title Status
1 Network Upgrade Policy and Scheduling Reserved
2 Design Considerations for Network Upgrades Reserved
68 Relative lock-time using consensus-enforced sequence numbers Draft
76 Transaction Signature Validation before Overwinter Reserved
112 CHECKSEQUENCEVERIFY Draft
113 Median Time Past as endpoint for lock-time calculations Draft
204 Zcash P2P Network Protocol Reserved
217 Aggregate Signatures Reserved
219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
222 Transparent Zcash Extensions Draft
226 Transfer and Burn of Zcash Shielded Assets Draft
227 Issuance of Zcash Shielded Assets Draft
228 Asset Swaps for Zcash Shielded Assets Reserved
230 Version 6 Transaction Format Draft
231 Decouple Memos from Transaction Outputs Reserved
236 Blocks should balance exactly Draft
245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
253 Deployment of the NU6 Network Upgrade Draft
302 Standardized Memo Field Format Draft
303 Sprout Payment Disclosure Reserved
304 Sapling Address Signatures Draft
305 Best Practices for Hardware Wallets supporting Sapling Reserved
306 Security Considerations for Anchor Selection Reserved
307 Light Client Protocol for Payment Detection Draft
309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
310 Security Properties of Sapling Viewing Keys Draft
311 Zcash Payment Disclosures Draft
312 FROST for Spend Authorization Multisignatures Draft
314 Privacy upgrades to the Zcash light client protocol Reserved
315 Best Practices for Wallet Implementations Draft
318 Associated Payload Encryption Reserved
319 Options for Shielded Pool Retirement Reserved
322 Generic Signed Message Format Reserved
323 Specification of getblocktemplate for Zcash Reserved
324 URI-Encapsulated Payments Draft
332 Wallet Recovery from zcashd HD Seeds Reserved
339 Wallet Recovery Words Reserved
400 Wallet.dat format Draft
402 New Wallet Database Format Reserved
403 Verification Behaviour of zcashd Reserved
416 Support for Unified Addresses in zcashd Reserved
2001 Lockbox Funding Streams Draft
guide-markdown {Something Short and To the Point} Draft
guide {Something Short and To the Point} Draft
+

Drafts without assigned ZIP numbers

+

These are works-in-progress, and may never be assigned ZIP numbers if their ideas become obsoleted or abandoned. Do not assume that these drafts will exist in perpetuity; instead assume that they will either move to a numbered ZIP, or be deleted.

+ + + + + +
Title
Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
Block Reward Allocation for Non-Direct Development Funding
Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
+

Withdrawn, Rejected, or Obsolete ZIPs

+
+Click to show/hide + + + + + + + + + + + + + + + + + + +
ZIP Title Status
210 Sapling Anchor Deduplication within Transactions Withdrawn
220 Zcash Shielded Assets Withdrawn
313 Reduce Conventional Transaction Fee to 1000 zatoshis Obsolete
1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
1002 Opt-in Donation Feature Obsolete
1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
1004 Miner-Directed Dev Fund Obsolete
1005 Zcash Community Funding System Obsolete
1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
1008 Fund ECC for Two More Years Obsolete
1009 Five-Entity Strategic Council Obsolete
1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
1011 Decentralize the Dev Fee Obsolete
1012 Dev Fund to ECC + ZF + Major Grants Obsolete
1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
+
+

Index of ZIPs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZIP Title Status
0 ZIP Process Active
1 Network Upgrade Policy and Scheduling Reserved
2 Design Considerations for Network Upgrades Reserved
32 Shielded Hierarchical Deterministic Wallets Final
68 Relative lock-time using consensus-enforced sequence numbers Draft
76 Transaction Signature Validation before Overwinter Reserved
112 CHECKSEQUENCEVERIFY Draft
113 Median Time Past as endpoint for lock-time calculations Draft
143 Transaction Signature Validation for Overwinter Final
155 addrv2 message Proposed
173 Bech32 Format Final
200 Network Upgrade Mechanism Final
201 Network Peer Management for Overwinter Final
202 Version 3 Transaction Format for Overwinter Final
203 Transaction Expiry Final
204 Zcash P2P Network Protocol Reserved
205 Deployment of the Sapling Network Upgrade Final
206 Deployment of the Blossom Network Upgrade Final
207 Funding Streams Final
208 Shorter Block Target Spacing Final
209 Prohibit Negative Shielded Chain Value Pool Balances Final
210 Sapling Anchor Deduplication within Transactions Withdrawn
211 Disabling Addition of New Value to the Sprout Chain Value Pool Final
212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final
213 Shielded Coinbase Final
214 Consensus rules for a Zcash Development Fund Final
215 Explicitly Defining and Modifying Ed25519 Validation Rules Final
216 Require Canonical Jubjub Point Encodings Final
217 Aggregate Signatures Reserved
219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved
220 Zcash Shielded Assets Withdrawn
221 FlyClient - Consensus-Layer Changes Final
222 Transparent Zcash Extensions Draft
224 Orchard Shielded Protocol Final
225 Version 5 Transaction Format Final
226 Transfer and Burn of Zcash Shielded Assets Draft
227 Issuance of Zcash Shielded Assets Draft
228 Asset Swaps for Zcash Shielded Assets Reserved
230 Version 6 Transaction Format Draft
231 Decouple Memos from Transaction Outputs Reserved
236 Blocks should balance exactly Draft
239 Relay of Version 5 Transactions Final
243 Transaction Signature Validation for Sapling Final
244 Transaction Identifier Non-Malleability Final
245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft
250 Deployment of the Heartwood Network Upgrade Final
251 Deployment of the Canopy Network Upgrade Final
252 Deployment of the NU5 Network Upgrade Final
253 Deployment of the NU6 Network Upgrade Draft
300 Cross-chain Atomic Transactions Proposed
301 Zcash Stratum Protocol Final
302 Standardized Memo Field Format Draft
303 Sprout Payment Disclosure Reserved
304 Sapling Address Signatures Draft
305 Best Practices for Hardware Wallets supporting Sapling Reserved
306 Security Considerations for Anchor Selection Reserved
307 Light Client Protocol for Payment Detection Draft
308 Sprout to Sapling Migration Final
309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
310 Security Properties of Sapling Viewing Keys Draft
311 Zcash Payment Disclosures Draft
312 FROST for Spend Authorization Multisignatures Draft
313 Reduce Conventional Transaction Fee to 1000 zatoshis Obsolete
314 Privacy upgrades to the Zcash light client protocol Reserved
315 Best Practices for Wallet Implementations Draft
316 Unified Addresses and Unified Viewing Keys Revision 0: Final, Revision 1: Proposed
317 Proportional Transfer Fee Mechanism Active
318 Associated Payload Encryption Reserved
319 Options for Shielded Pool Retirement Reserved
320 Defining an Address Type to which funds can only be sent from Transparent Addresses Proposed
321 Payment Request URIs Proposed
322 Generic Signed Message Format Reserved
323 Specification of getblocktemplate for Zcash Reserved
324 URI-Encapsulated Payments Draft
332 Wallet Recovery from zcashd HD Seeds Reserved
339 Wallet Recovery Words Reserved
400 Wallet.dat format Draft
401 Addressing Mempool Denial-of-Service Active
402 New Wallet Database Format Reserved
403 Verification Behaviour of zcashd Reserved
416 Support for Unified Addresses in zcashd Reserved
1001 Keep the Block Distribution as Initially Defined — 90% to Miners Obsolete
1002 Opt-in Donation Feature Obsolete
1003 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate Obsolete
1004 Miner-Directed Dev Fund Obsolete
1005 Zcash Community Funding System Obsolete
1006 Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity Obsolete
1007 Enforce Development Fund Commitments with a Legal Charter Obsolete
1008 Fund ECC for Two More Years Obsolete
1009 Five-Entity Strategic Council Obsolete
1010 Compromise Dev Fund Proposal With Diverse Funding Streams Obsolete
1011 Decentralize the Dev Fee Obsolete
1012 Dev Fund to ECC + ZF + Major Grants Obsolete
1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete
1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
2001 Lockbox Funding Streams Draft
guide-markdown {Something Short and To the Point} Draft
guide {Something Short and To the Point} Draft
+
+ + \ No newline at end of file diff --git a/protocol/heartwood.pdf b/rendered/protocol/blossom.pdf similarity index 59% rename from protocol/heartwood.pdf rename to rendered/protocol/blossom.pdf index dc9e17ea2..6ebbbe543 100644 Binary files a/protocol/heartwood.pdf and b/rendered/protocol/blossom.pdf differ diff --git a/protocol/canopy.pdf b/rendered/protocol/canopy.pdf similarity index 58% rename from protocol/canopy.pdf rename to rendered/protocol/canopy.pdf index 72a1f8536..bd1cb8897 100644 Binary files a/protocol/canopy.pdf and b/rendered/protocol/canopy.pdf differ diff --git a/protocol/blossom.pdf b/rendered/protocol/heartwood.pdf similarity index 58% rename from protocol/blossom.pdf rename to rendered/protocol/heartwood.pdf index 6b0e06bde..ba7423ba5 100644 Binary files a/protocol/blossom.pdf and b/rendered/protocol/heartwood.pdf differ diff --git a/protocol/nu5.pdf b/rendered/protocol/nu5.pdf similarity index 58% rename from protocol/nu5.pdf rename to rendered/protocol/nu5.pdf index ea2dd38d2..6091c70e2 100644 Binary files a/protocol/nu5.pdf and b/rendered/protocol/nu5.pdf differ diff --git a/protocol/protocol.pdf b/rendered/protocol/protocol.pdf similarity index 58% rename from protocol/protocol.pdf rename to rendered/protocol/protocol.pdf index ea2dd38d2..6091c70e2 100644 Binary files a/protocol/protocol.pdf and b/rendered/protocol/protocol.pdf differ diff --git a/protocol/sapling.pdf b/rendered/protocol/sapling.pdf similarity index 59% rename from protocol/sapling.pdf rename to rendered/protocol/sapling.pdf index e13be5306..8304c988d 100644 Binary files a/protocol/sapling.pdf and b/rendered/protocol/sapling.pdf differ diff --git a/protocol/sprout.pdf b/rendered/protocol/sprout.pdf similarity index 100% rename from protocol/sprout.pdf rename to rendered/protocol/sprout.pdf diff --git a/zip-0000.html b/rendered/zip-0000.html similarity index 97% rename from zip-0000.html rename to rendered/zip-0000.html index abb04049d..83e34a33f 100644 --- a/zip-0000.html +++ b/rendered/zip-0000.html @@ -8,16 +8,15 @@ 
ZIP: 0
 Title: ZIP Process
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
-        teor <teor@zfnd.org>
-        Jack Grigg <str4d@electriccoin.co>
-        Conrado Gouvea <conrado@zfnd.org>
-        Aditya Bharadwaj <nighthawk24@gmail.com>
+Owners: Jack Grigg <str4d@electriccoin.co>
+        Conrado Gouvêa <conrado@zfnd.org>
         Arya <arya@zfnd.org>
-Original-Authors: Daira Emma Hopwood
+Original-Authors: Daira-Emma Hopwood
                   Josh Cincinnati
                   George Tankersley
                   Deirdre Connolly
+                  teor
+                  Aditya Bharadwaj
 Credits: Luke Dashjr
 Status: Active
 Category: Process
@@ -61,13 +60,12 @@
             
ZIP Editors 

                 
The current ZIP Editors are:

                 
    
-                    
  • Daira Emma Hopwood and Jack Grigg, associated with the Electric Coin Company;
    • 
-                    
  • teor, Conrado Gouvea, and Arya, associated with the Zcash Foundation.
    • 
-                    
  • Aditya Bharadwaj, associated with Nighthawk Apps.
    • 
+                    
  • Jack Grigg, associated with the Electric Coin Company;
    • 
+                    
  • Conrado Gouvêa and Arya, associated with the Zcash Foundation.
    • 
                 

                 
All can be reached at zips@z.cash. The current design of the ZIP Process dictates that there are always at least two ZIP Editors: at least one from the Electric Coin Company and at least one from the Zcash Foundation.

                 
ZIP Editors MUST declare any potential or perceived conflict of interest they have relating to their responsibilities as ZIP Editors.

-                
ZIP Editors MUST be publicly transparent about any external influence or constraints that have been placed or attempted to be placed on their actions as ZIP Editors (including from the Electric Coin Company, Zcash Foundation, or Nighthawk Apps), whether or not it affects those actions. This should not be interpreted as requiring ZIP Editors to reveal knowledge of undisclosed security vulnerabilities or mitigations.

+                
ZIP Editors MUST be publicly transparent about any external influence or constraints that have been placed or attempted to be placed on their actions as ZIP Editors (including from the Electric Coin Company, Zcash Foundation, or other organizations with which the Editors are associated), whether or not it affects those actions. This should not be interpreted as requiring ZIP Editors to reveal knowledge of undisclosed security vulnerabilities or mitigations.

                 
Additional Editors may be selected, with their consent, by consensus among the current Editors.

                 
An Editor may be removed or replaced by consensus among the current Editors. However, if the other ZIP Editors have consensus, an Editor can not prevent their own removal.

                 
Any Editor can resign by informing the other Editors in writing.

@@ -358,6 +356,9 @@
                 
  • Zcash Network Upgrade Pipeline
    • 
             
         
    
+        
    Acknowledgements 
    
+            
    We thank George Tankersley, Deirdre Connolly, Daira-Emma Hopwood, teor, and Aditya Bharadwaj for their past contributions as ZIP Editors.
    
+        
    
         
    References 
    
             
diff --git a/zip-0001.html b/rendered/zip-0001.html
similarity index 100%
rename from zip-0001.html
rename to rendered/zip-0001.html
diff --git a/zip-0002.html b/rendered/zip-0002.html
similarity index 100%
rename from zip-0002.html
rename to rendered/zip-0002.html
diff --git a/zip-0022.html b/rendered/zip-0022.html
similarity index 100%
rename from zip-0022.html
rename to rendered/zip-0022.html
diff --git a/zip-0032.html b/rendered/zip-0032.html
similarity index 99%
rename from zip-0032.html
rename to rendered/zip-0032.html
index c73284614..4622c88d0 100644
--- a/zip-0032.html
+++ b/rendered/zip-0032.html
@@ -10,7 +10,7 @@
         
    ZIP: 32
 Title: Shielded Hierarchical Deterministic Wallets
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Sean Bowe
          Kris Nuttycombe
          Ying Tong Lai
@@ -534,7 +534,7 @@
                         \(R\)
                      are the same between deriving a full viewing key, and deriving the corresponding spending key. Both of these derivations are shown in the following diagram:
    
                     
    
-                        
+                        
                         
    Diagram of Sapling internal key derivation
    
                     
    
                     
    (For simplicity, the proof authorizing key is not shown.)
    
@@ -693,7 +693,7 @@
                     \(\mathsf{ovk_{internal}}\)
                  fields being derived, as specified in 12 and shown in the following diagram:
    
                 
    
-                    
+                    
                     
    Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key
    
                 
    
                 
    This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 8.
    
diff --git a/rendered/zip-0068.html b/rendered/zip-0068.html
new file mode 100644
index 000000000..1971b9626
--- /dev/null
+++ b/rendered/zip-0068.html
@@ -0,0 +1,246 @@
+
+
+
+    ZIP 68: Relative lock-time using consensus-enforced sequence numbers
+    
+
+
+    
    
+        
    ZIP: 68
+Title: Relative lock-time using consensus-enforced sequence numbers
+Credits: Mark Friedenbach <mark@friedenbach.org>
+         BtcDrak <btcdrak@gmail.com>
+         Nicolas Dorier <nicolas.dorier@gmail.com>
+         kinoshitajona <kinoshitajona@gmail.com>
+Category: Consensus
+Status: Draft
+Created: 2016-06-06
    
+        
    Terminology 
    
+            
    The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. 1
    
+            
    The "Median Time Past" of a block in this document is to be interpreted as described in 4.
    
+        
    
+        
    Abstract 
    
+            
    This ZIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field, to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
    
+        
    
+        
    Motivation 
    
+            
    Zcash transactions have a sequence number field for each input, inherited from Bitcoin. The original idea in Bitcoin appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this ZIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases.
    
+            
    The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in 5 and 3.
    
+        
    
+        
    Specification 
    
+            
    This specification defines the meaning of sequence numbers for transactions in blocks after this proposal has activated.
    
+            
    If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances.
    
+            
    If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
    
+            
    The sequence number encoding MUST be interpreted as follows:
    
+            
    Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 32 seconds granularity. The timespan starts from the Median Time Past of the output’s previous block, and ends at the Median Time Past of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
    
+            
    Note: the 64-second time unit differs from Bitcoin's BIP 68, which uses a 512-second time unit.
    
+            
    The flag (1 << 22) is the highest order bit in a 3-byte signed integer for use in Zcash scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY 3.
    
+            
    This specification only interprets 22 bits of the sequence number as relative lock-time, so a mask of 0x003FFFFF MUST be applied to the sequence field to extract the relative lock-time. The 22-bit specification allows for over 8.5 years of relative lock-time.
    
+            
    
+                
+                
    A 32-bit field with 'Disable Flag' at bit (1 << 31), 'Type Flag' at bit (1 << 22), and 'Value' in the low 22 bits.
    
+            
    
+            
    For time-based relative lock-time, 64-second granularity was chosen because the block target spacing for Zcash, after activation of the Blossom network upgrade, is 75 seconds. So when using block-based or time-based, roughly the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 64.
    
+            
    When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 64 * n seconds after the mining date of the output it is spending, or any block thereafter. The mining date of the output is equal to the Median Time Past of the previous block that mined it.
    
+            
    The block produced time is equal to the Median Time Past of its previous block.
    
+            
    When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input that can be included in any block. More generally, a relative block lock-time n MAY be included n blocks after the mining date of the output it is spending, or any block thereafter.
    
+            
    The new rules are not applied to the nSequence field of the input of the coinbase transaction.
    
+        
    
+        
    Reference Implementation 
    
+            
+        
    
+        
    Acknowledgments 
    
+            
    This ZIP is based on BIP 68, authored by Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona.
    
+            
    Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of the BIP text.
    
+        
    
+        
    Deployment 
    
+            
    At the time of writing it has not been decided which network upgrade (if any) will implement this proposal.
    
+            
    This ZIP is designed to be deployed simultaneously with 3 and 4.
    
+        
    
+        
    Compatibility 
    
+            
    The only use of sequence numbers by the zcashd reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this ZIP.
    
+            
    As can be seen from the specification section, a number of bits are undefined by this ZIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this ZIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset.
    
+            
    Unlike BIP 68 in Bitcoin, all of the low 22 bits are used for the value. This reflects the fact that blocks are more frequent (75 seconds instead of 600 seconds), and so more bits are needed to obtain approximately the same range of time.
    
+            
    The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:
    
+            
+        
    
+        
    References 
    
+            
    
                 
    
+                
+                    
+                        
+                        
+                    
+                
+            
    1Key words for use in RFCs to Indicate Requirement Levels
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    2Bitcoin mailing list discussion
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    3ZIP 112: CHECKSEQUENCEVERIFY
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    4ZIP 113: Median Time Past as endpoint for lock-time calculations
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    5Reaching The Ground With Lightning (draft 0.2)
    
+        
    
+
    + + \ No newline at end of file diff --git a/zip-0076.html b/rendered/zip-0076.html similarity index 90% rename from zip-0076.html rename to rendered/zip-0076.html index f983a889b..627643358 100644 --- a/zip-0076.html +++ b/rendered/zip-0076.html @@ -9,7 +9,7 @@ 
    ZIP: 76
 Title: Transaction Signature Validation before Overwinter
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Consensus
 Discussions-To: <https://github.com/zcash/zips/issues/130>
    diff --git a/rendered/zip-0112.html b/rendered/zip-0112.html new file mode 100644 index 000000000..9203b6ff1 --- /dev/null +++ b/rendered/zip-0112.html @@ -0,0 +1,309 @@ + + + + ZIP 112: CHECKSEQUENCEVERIFY + + + +
    + 
    ZIP: 112
+Title: CHECKSEQUENCEVERIFY
+Author: Daira Hopwood <daira@electriccoin.co>
+Credits: BtcDrak <btcdrak@gmail.com>
+         Mark Friedenbach <mark@friedenbach.org>
+         Eric Lombrozo <elombrozo@gmail.com>
+Category: Consensus
+Status: Draft
+Created: 2019-06-06
+License: MIT
    +

    Terminology

    +

    The key word "MUST" in this document is to be interpreted as described in RFC 2119. 1

    +
    +

    Abstract

    +

    This ZIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Zcash scripting system, that in combination with ZIP 68 allows execution pathways of a script to be restricted based on the age of the output being spent.

    +
    +

    Motivation

    +

    ZIP 68 repurposes the transaction nSequence field meaning by giving sequence numbers new consensus-enforced semantics as a relative lock-time. However, there is no way to build Zcash scripts to make decisions based on this field.

    +

    By making the nSequence field accessible to script, it becomes possible to construct code pathways that only become accessible some minimum time after proof-of-publication. This enables a wide variety of applications in phased protocols such as escrow, payment channels, or bidirectional pegs.

    +
    +

    Specification

    +

    CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed, if any of the following conditions are true, the script interpreter MUST terminate with an error:

    +
      +
    • the stack is empty; or
      • +
    • the top item on the stack is less than 0; or
      • +
    • the top item on the stack has the disable flag (1 << 31) unset; and any of the following hold: +
        +
      • the transaction version is less than 2; or
        • +
      • the transaction input sequence number disable flag (1 << 31) is set; or
        • +
      • the relative lock-time type is not the same; or
        • +
      • the top stack item is greater than the transaction input sequence (when masked according to 4;
        • +
      +
      • +
    +

    Otherwise, script execution MUST continue as if a NOP had been executed.

    +

    ZIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the the output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block.

    +
    +

    Use cases

    +

    Contracts With Expiration Deadlines

    +

    Escrow with Timeout

    +

    An escrow that times out automatically 30 days after being funded can be established in the following way. Alice, Bob and Escrow create a 2-of-3 address with the following redeem script:

    + 
    IF
+    2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG
+ELSE
+    "30d" CHECKSEQUENCEVERIFY DROP
+    <Alice's pubkey> CHECKSIG
+ENDIF
    +

    At any time funds can be spent using signatures from any two of Alice, Bob or the Escrow.

    +

    After 30 days Alice can sign alone.

    +

    The clock does not start ticking until the payment to the escrow address confirms.

    +
    +
    +

    Retroactive Invalidation

    +

    In many instances, we would like to create contracts that can be revoked in case of some future event. However, given the immutable nature of the block chain, it is practically impossible to retroactively invalidate a previous commitment that has already confirmed. The only mechanism we really have for retroactive invalidation is block chain reorganization which, for fundamental security reasons, is designed to be very hard and very expensive to do.

    +

    Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of execution where one or more of the branches are delayed we provide a time window in which someone can supply an invalidation condition that allows the output to be spent, effectively invalidating the would-be delayed branch and potentially discouraging another party from broadcasting the transaction in the first place. If the invalidation condition does not occur before the timeout, the delayed branch becomes spendable, honoring the original contract.

    +

    Some more specific applications of this idea:

    +

    Hash Time-Locked Contracts

    +

    Hash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead.

    +
    +

    Bidirectional Payment Channels

    +

    Scriptable relative locktime provides a predictable amount of time to respond in the event a counterparty broadcasts a revoked transaction: Absolute locktime necessitates closing the channel and reopening it when getting close to the timeout, whereas with relative locktime, the clock starts ticking the moment the transaction confirms in a block. It also provides a means to know exactly how long to wait (in number of blocks) before funds can be pulled out of the channel in the event of a noncooperative counterparty.

    +
    +

    Lightning Network

    +

    The lightning network protocol 6 extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops.

    +

    These channels are based on an anchor transaction that requires a 2-of-2 multisig from Alice and Bob, and a series of revocable commitment transactions that spend the anchor transaction. The commitment transaction splits the funds from the anchor between Alice and Bob and the latest commitment transaction may be published by either party at any time, finalising the channel.

    +

    Ideally then, a revoked commitment transaction would never be able to be successfully spent; and the latest commitment transaction would be able to be spent very quickly.

    +

    To allow a commitment transaction to be effectively revoked, Alice and Bob have slightly different versions of the latest commitment transaction. In Alice's version, any outputs in the commitment transaction that pay Alice also include a forced delay, and an alternative branch that allows Bob to spend the output if he knows that transaction's revocation code. In Bob's version, payments to Bob are similarly encumbered. When Alice and Bob negotiate new balances and new commitment transactions, they also reveal the old revocation code, thus committing to not relaying the old transaction.

    +

    A simple output, paying to Alice might then look like:

    + 
    HASH160 <revokehash> EQUAL
+IF
+    <Bob's pubkey>
+ELSE
+    "24h" CHECKSEQUENCEVERIFY DROP
+    <Alice's pubkey>
+ENDIF
+CHECKSIG
    +

    This allows Alice to publish the latest commitment transaction at any time and spend the funds after 24 hours, but also ensures that if Alice relays a revoked transaction, that Bob has 24 hours to claim the funds.

    +

    With CHECKLOCKTIMEVERIFY, this would look like:

    + 
    HASH160 <revokehash> EQUAL
+IF
+    <Bob's pubkey>
+ELSE
+    "2015/12/15" CHECKLOCKTIMEVERIFY DROP
+    <Alice's pubkey>
+ENDIF
+CHECKSIG
    +

    This form of transaction would mean that if the anchor is unspent on 2015/12/16, Alice can use this commitment even if it has been revoked, simply by spending it immediately, giving no time for Bob to claim it.

    +

    This means that the channel has a deadline that cannot be pushed back without hitting the blockchain; and also that funds may not be available until the deadline is hit. CHECKSEQUENCEVERIFY allows you to avoid making such a tradeoff.

    +

    Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated, since in principle they may pay either Alice or Bob, depending on whether Alice discovers a secret R, or a timeout is reached, but the same principle applies -- the branch paying Alice in Alice's commitment transaction gets a delay, and the entire output can be claimed by the other party if the revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to Alice might look like the following in Alice's commitment transaction:

    + 
    HASH160 DUP <R-HASH> EQUAL
+IF
+    "24h" CHECKSEQUENCEVERIFY
+    2DROP
+    <Alice's pubkey>
+ELSE
+    <Commit-Revocation-Hash> EQUAL
+    NOTIF
+        "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
+    ENDIF
+    <Bob's pubkey>
+ENDIF
+CHECKSIG
    +

    and correspondingly in Bob's commitment transaction:

    + 
    HASH160 DUP <R-HASH> EQUAL
+SWAP <Commit-Revocation-Hash> EQUAL ADD
+IF
+    <Alice's pubkey>
+ELSE
+    "2015/10/20 10:33" CHECKLOCKTIMEVERIFY
+    "24h" CHECKSEQUENCEVERIFY
+    2DROP
+    <Bob's pubkey>
+ENDIF
+CHECKSIG
    +

    Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the final branch above to ensure Bob cannot spend the output until after both the timeout is complete and Alice has had time to reveal the revocation secret.

    +

    See also the 'Deployable Lightning' paper 5.

    +
    +
    +

    2-Way Pegged Sidechains

    +

    The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics of which are outside the scope of this ZIP. CHECKSEQUENCEVERIFY is used to make sure that sufficient time has passed since the return peg was posted to publish a reorg proof:

    + 
    IF
+    lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> REORGPROOFVERIFY
+ELSE
+    withdrawLockTime CHECKSEQUENCEVERIFY DROP HASH160 p2shWithdrawDest EQUAL
+ENDIF
    +
    +
    +

    Reference Implementation

    + +
    +

    Deployment

    +

    At the time of writing it has not been decided which network upgrade (if any) will implement this proposal.

    +

    This ZIP must be deployed simultaneously with ZIP 68 4.

    +
    +

    Acknowledgements

    +

    This ZIP is closely based on BIP 112, authored by BtcDrak.

    +

    Mark Friedenbach invented the application of sequence numbers to achieve relative lock-time, and wrote the reference implementation of CHECKSEQUENCEVERIFY for Bitcoin.

    +

    The Bitcoin reference implementation and BIP 112 was based heavily on work done by Peter Todd for the closely related BIP 65. Eric Lombrozo and Anthony Towns contributed example use cases.

    +
    +

    References

    + + + + + + + +
    1Key words for use in RFCs to Indicate Requirement Levels
    + + + + + + + +
    2Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling]
    + + + + + + + +
    3BIP 65: OP_CHECKLOCKTIMEVERIFY
    + + + + + + + +
    4ZIP 68: Relative lock-time through consensus-enforced sequence numbers
    + + + + + + + +
    5Deployable Lightning
    + + + + + + + +
    6Lightning Network paper
    + + + + + + + +
    7HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes
    + + + + + + + +
    8Scaling Bitcoin to Billions of Transactions Per Day
    + + + + + + + +
    9Jeremy Spilman, Micropayment Channels
    +
    +
    + + \ No newline at end of file diff --git a/rendered/zip-0113.html b/rendered/zip-0113.html new file mode 100644 index 000000000..5a6b70156 --- /dev/null +++ b/rendered/zip-0113.html @@ -0,0 +1,97 @@ + + + + ZIP 113: Median Time Past as endpoint for lock-time calculations + + + +
    + 
    ZIP: 113
+Title: Median Time Past as endpoint for lock-time calculations
+Author: Daira Hopwood <daira@electriccoin.co>
+Credits: Thomas Kerin <me@thomaskerin.io>
+         Mark Friedenbach <mark@friedenbach.org>
+         Gregory Maxwell
+Category: Consensus
+Status: Draft
+Created: 2019-06-07
+License: MIT
    +

    Terminology

    +

    The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. 1

    +
    +

    Abstract

    +

    This ZIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block. The median of the last PoWMedianBlockSpan (11) blocks is used instead of the block's timestamp, ensuring that it increases monotonically with each block.

    +
    +

    Motivation

    +

    At present, transactions are excluded from inclusion in a block if the present time or block height is less than or equal to that specified in the locktime. Since the consensus rules do not mandate strict ordering of block timestamps, this has the unfortunate outcome of creating a perverse incentive for miners to lie about the time of their blocks in order to collect more fees by including transactions that by wall clock determination have not yet matured.

    +

    This ZIP proposes comparing the locktime against the median of the past PoWMedianBlockSpan blocks' timestamps, rather than the timestamp of the block including the transaction. Existing consensus rules guarantee this value to monotonically advance, thereby removing the capability for miners to claim more transaction fees by lying about the timestamps of their block.

    +

    This proposal seeks to ensure reliable behaviour in locktime calculations as required by 3 (CHECKLOCKTIMEVERIFY) and matching the behavior of 5 (CHECKSEQUENCEVERIFY). This also matches the use of Median Time Past in difficulty adjustment as specified in section 7.6.3 of 2.

    +
    +

    Specification

    +

    Let PoWMedianBlockSpan be as defined in 2 section 5.3, and let the median function be as defined in 2 section 7.6.3.

    +

    The Median Time Past of a block is specified as the median of the timestamps of the prior PoWMedianBlockSpan blocks, as calculated by MedianTime(height) in 2 section 7.6.3.

    +

    The values for transaction locktime remain unchanged. The difference is only in the calculation determining whether a transaction can be included. After activation of this ZIP, lock-time constraints of a transaction MUST be checked according to the Median Time Past of the transaction's block.

    +

    [FIXME make this a proper specification, independent of the zcashd implementation.]

    +

    Lock-time constraints are checked by the consensus method IsFinalTx(). This method takes the block time as one parameter. This ZIP proposes that after activation calls to IsFinalTx() within consensus code use the return value of GetMedianTimePast(pindexPrev) instead.

    +

    The new rule applies to all transactions, including the coinbase transaction.

    +
    +

    Reference Implementation

    +

    This will be based on Bitcoin PR 6566.

    +
    +

    Acknowledgements

    +

    This ZIP is based on BIP 113, authored by Thomas Kerin and Mark Friedenbach.

    +

    Mark Friedenbach designed and authored the reference implementation for Bitcoin.

    +

    Gregory Maxwell came up with the original idea, in #bitcoin-wizards on 2013-07-16 and 2013-07-17.

    +
    +

    Deployment

    +

    At the time of writing it has not been decided which network upgrade (if any) will implement this proposal.

    +

    This ZIP is designed to be deployed simultaneously with 4 and 5.

    +
    +

    Compatibility

    +

    At the post-Blossom block target spacing of 75 seconds, transactions generated using time-based lock-time will take approximately 7.5 minutes longer to confirm than would be expected under the old rules. This is not known to introduce any compatibility concerns with existing protocols. This delay is less than in Bitcoin due to the faster block target spacing in Zcash.

    +
    +

    References

    + + + + + + + +
    1Key words for use in RFCs to Indicate Requirement Levels
    + + + + + + + +
    2Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]
    + + + + + + + +
    3BIP 65: OP_CHECKLOCKTIMEVERIFY
    + + + + + + + +
    4ZIP 68: Consensus-enforced transaction replacement signaled via sequence numbers
    + + + + + + + +
    5ZIP 112: CHECKSEQUENCEVERIFY
    +
    +
    + + \ No newline at end of file diff --git a/zip-0143.html b/rendered/zip-0143.html similarity index 99% rename from zip-0143.html rename to rendered/zip-0143.html index f162e9503..5adb479d7 100644 --- a/zip-0143.html +++ b/rendered/zip-0143.html @@ -9,7 +9,7 @@ 
    ZIP: 143
 Title: Transaction Signature Validation for Overwinter
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Johnson Lau
          Pieter Wuille
          Bitcoin-ABC
diff --git a/zip-0155.html b/rendered/zip-0155.html
similarity index 99%
rename from zip-0155.html
rename to rendered/zip-0155.html
index bde364823..a28ada2c4 100644
--- a/zip-0155.html
+++ b/rendered/zip-0155.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 155
 Title: addrv2 message
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Wladimir J. van der Laan
          Zancas Wilcox
 Status: Proposed
diff --git a/zip-0173.html b/rendered/zip-0173.html
similarity index 98%
rename from zip-0173.html
rename to rendered/zip-0173.html
index d9fa29694..52e120c7a 100644
--- a/zip-0173.html
+++ b/rendered/zip-0173.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 173
 Title: Bech32 Format
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Pieter Wuille <pieter.wuille@gmail.com>
          Greg Maxwell <greg@xiph.org>
          Rusty Russell
@@ -193,6 +193,11 @@
                         
  • In C++
    • 
                     
                 
+                
  • Encoders and decoders written specifically for Zcash:
+                    
      
+                        
    • For C# (Bech32 and Bech32m)
      • 
+                    
    
+                
    • 
                 
  • Encoders and decoders written for Bitcoin:
                     
      
                         
    • For C
      • 
diff --git a/zip-0200.html b/rendered/zip-0200.html
similarity index 100%
rename from zip-0200.html
rename to rendered/zip-0200.html
diff --git a/zip-0201.html b/rendered/zip-0201.html
similarity index 99%
rename from zip-0201.html
rename to rendered/zip-0201.html
index 70d0e6877..d7a384f7a 100644
--- a/zip-0201.html
+++ b/rendered/zip-0201.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 201
 Title: Network Peer Management for Overwinter
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: Simon Liu
 Status: Final
 Category: Network
diff --git a/zip-0202.html b/rendered/zip-0202.html
similarity index 99%
rename from zip-0202.html
rename to rendered/zip-0202.html
index a6d148ba8..43a4a2cf3 100644
--- a/zip-0202.html
+++ b/rendered/zip-0202.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 202
 Title: Version 3 Transaction Format for Overwinter
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: Simon Liu
 Status: Final
 Category: Consensus
diff --git a/zip-0203.html b/rendered/zip-0203.html
similarity index 99%
rename from zip-0203.html
rename to rendered/zip-0203.html
index 38d826a0a..074d62c7d 100644
--- a/zip-0203.html
+++ b/rendered/zip-0203.html
@@ -9,7 +9,7 @@
     
      
         
      ZIP: 203
 Title: Transaction Expiry
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: Jay Graber
 Status: Final
 Category: Consensus
diff --git a/zip-0204.html b/rendered/zip-0204.html
similarity index 89%
rename from zip-0204.html
rename to rendered/zip-0204.html
index 54a743a65..150f8bfe4 100644
--- a/zip-0204.html
+++ b/rendered/zip-0204.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 204
 Title: Zcash P2P Network Protocol
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Network
 Discussions-To: <https://github.com/zcash/zips/issues/352>
      
diff --git a/zip-0205.html b/rendered/zip-0205.html
similarity index 99%
rename from zip-0205.html
rename to rendered/zip-0205.html
index 92b534ca0..73bc1a994 100644
--- a/zip-0205.html
+++ b/rendered/zip-0205.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 205
 Title: Deployment of the Sapling Network Upgrade
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Simon Liu
 Status: Final
 Category: Consensus / Network
diff --git a/zip-0206.html b/rendered/zip-0206.html
similarity index 99%
rename from zip-0206.html
rename to rendered/zip-0206.html
index de5170f5f..bf74ecadb 100644
--- a/zip-0206.html
+++ b/rendered/zip-0206.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 206
 Title: Deployment of the Blossom Network Upgrade
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Simon Liu
 Status: Final
 Category: Consensus / Network
diff --git a/zip-0207.html b/rendered/zip-0207.html
similarity index 99%
rename from zip-0207.html
rename to rendered/zip-0207.html
index 1fa6890e8..10de04631 100644
--- a/zip-0207.html
+++ b/rendered/zip-0207.html
@@ -10,7 +10,7 @@
         
      ZIP: 207
 Title: Funding Streams
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus
 Created: 2019-01-04
diff --git a/zip-0208.html b/rendered/zip-0208.html
similarity index 99%
rename from zip-0208.html
rename to rendered/zip-0208.html
index d406ec647..4d4a014bc 100644
--- a/zip-0208.html
+++ b/rendered/zip-0208.html
@@ -8,8 +8,8 @@
     
      
         
      ZIP: 208
 Title: Shorter Block Target Spacing
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
-Original-Authors: Daira Emma Hopwood
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Original-Authors: Daira-Emma Hopwood
                   Simon Liu
 Status: Final
 Category: Consensus
diff --git a/zip-0209.html b/rendered/zip-0209.html
similarity index 99%
rename from zip-0209.html
rename to rendered/zip-0209.html
index ba8a2191c..83e0a7eed 100644
--- a/zip-0209.html
+++ b/rendered/zip-0209.html
@@ -9,7 +9,7 @@
         
      ZIP: 209
 Title: Prohibit Negative Shielded Chain Value Pool Balances
 Owners: Sean Bowe <sean@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus
 Created: 2019-02-25
diff --git a/zip-0210.html b/rendered/zip-0210.html
similarity index 100%
rename from zip-0210.html
rename to rendered/zip-0210.html
diff --git a/zip-0211.html b/rendered/zip-0211.html
similarity index 99%
rename from zip-0211.html
rename to rendered/zip-0211.html
index dbf97a696..ea75db48d 100644
--- a/zip-0211.html
+++ b/rendered/zip-0211.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 211
 Title: Disabling Addition of New Value to the Sprout Chain Value Pool
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Sean Bowe
 Status: Final
 Category: Consensus
diff --git a/zip-0212.html b/rendered/zip-0212.html
similarity index 100%
rename from zip-0212.html
rename to rendered/zip-0212.html
diff --git a/zip-0213.html b/rendered/zip-0213.html
similarity index 100%
rename from zip-0213.html
rename to rendered/zip-0213.html
diff --git a/zip-0214.html b/rendered/zip-0214.html
similarity index 99%
rename from zip-0214.html
rename to rendered/zip-0214.html
index 4c52384ac..1e49cae61 100644
--- a/zip-0214.html
+++ b/rendered/zip-0214.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 214
 Title: Consensus rules for a Zcash Development Fund
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus
 Created: 2020-02-28
diff --git a/zip-0215.html b/rendered/zip-0215.html
similarity index 100%
rename from zip-0215.html
rename to rendered/zip-0215.html
diff --git a/zip-0216.html b/rendered/zip-0216.html
similarity index 95%
rename from zip-0216.html
rename to rendered/zip-0216.html
index 482288d30..52bc7adab 100644
--- a/zip-0216.html
+++ b/rendered/zip-0216.html
@@ -10,7 +10,7 @@
         
      ZIP: 216
 Title: Require Canonical Jubjub Point Encodings
 Owners: Jack Grigg <jack@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus
 Created: 2021-02-11
@@ -29,9 +29,9 @@
                 \(u\!\)
             -coordinate is zero, there are two encodings that will be accepted:
      
             
      // Fix the sign of `u` if necessary
-let flip_sign = Choice::from((u.to_bytes()[0] ^ sign) & 1);
+let flip_sign = Choice::from((u.to_bytes()[0] ^ sign) & 1);
 let u_negated = -u;
-let final_u = Fq::conditional_select(&u, &u_negated, flip_sign);
      
+let final_u = Fq::conditional_select(&u, &u_negated, flip_sign);
      
             
      This code accepts either sign bit, because u_negated == u.
      
             
      There are two points on the Jubjub curve with
                 \(u\!\)
diff --git a/zip-0217.html b/rendered/zip-0217.html
similarity index 88%
rename from zip-0217.html
rename to rendered/zip-0217.html
index 854b61089..822e1fb60 100644
--- a/zip-0217.html
+++ b/rendered/zip-0217.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 217
 Title: Aggregate Signatures
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Consensus
 Discussions-To: <https://github.com/zcash/zcash/issues/2914>
      
diff --git a/zip-0219.html b/rendered/zip-0219.html
similarity index 90%
rename from zip-0219.html
rename to rendered/zip-0219.html
index 135cb6ba3..296aa847b 100644
--- a/zip-0219.html
+++ b/rendered/zip-0219.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 219
 Title: Disabling Addition of New Value to the Sapling Chain Value Pool
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Consensus
 Discussions-To: <https://github.com/zcash/zips/issues/428>
      
diff --git a/zip-0220.html b/rendered/zip-0220.html
similarity index 91%
rename from zip-0220.html
rename to rendered/zip-0220.html
index 17eba3f3d..a557d39a1 100644
--- a/zip-0220.html
+++ b/rendered/zip-0220.html
@@ -9,7 +9,7 @@
         
      ZIP: 220
 Title: Zcash Shielded Assets
 Owners: Jack Grigg <jack@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Withdrawn
 Category: Consensus
 Discussions-To: <https://github.com/zcash/zcash/issues/830>
diff --git a/zip-0221.html b/rendered/zip-0221.html
similarity index 100%
rename from zip-0221.html
rename to rendered/zip-0221.html
diff --git a/zip-0222.html b/rendered/zip-0222.html
similarity index 99%
rename from zip-0222.html
rename to rendered/zip-0222.html
index 33e2237b0..8bac39fa6 100644
--- a/zip-0222.html
+++ b/rendered/zip-0222.html
@@ -11,7 +11,7 @@
 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 @@
             
    
         
    • 
         
    Acknowledgements 
    
-            
    The handler semantics of tze_verify 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.
    
+            
    The handler semantics of tze_verify 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.
    
             
    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.
    
         
    
         
    References 
    
diff --git a/zip-0224.html b/rendered/zip-0224.html
similarity index 99%
rename from zip-0224.html
rename to rendered/zip-0224.html
index dfde043b6..211d87e21 100644
--- a/zip-0224.html
+++ b/rendered/zip-0224.html
@@ -9,11 +9,11 @@
     
    
         
    ZIP: 224
 Title: Orchard Shielded Protocol
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
-        Ying Tong Lai <yingtong@electriccoin.co>
+Original-Authors: Ying Tong Lai
 Status: Final
 Category: Consensus
 Created: 2021-02-27
diff --git a/zip-0225.html b/rendered/zip-0225.html
similarity index 99%
rename from zip-0225.html
rename to rendered/zip-0225.html
index 2830d955d..1ab6b9415 100644
--- a/zip-0225.html
+++ b/rendered/zip-0225.html
@@ -9,11 +9,11 @@
     
    
         
    ZIP: 225
 Title: Version 5 Transaction Format
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
-        Ying Tong Lai <yingtong@electriccoin.co>
+Original-Authors: Ying Tong Lai
 Status: Final
 Category: Consensus
 Created: 2021-02-28
diff --git a/zip-0226.html b/rendered/zip-0226.html
similarity index 99%
rename from zip-0226.html
rename to rendered/zip-0226.html
index df2f822d8..c54818e33 100644
--- a/zip-0226.html
+++ b/rendered/zip-0226.html
@@ -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@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <str4d@electriccoin.co>
 Credits: Daniel Benarroch
          Aurelien Nicolas
diff --git a/zip-0227.html b/rendered/zip-0227.html
similarity index 99%
rename from zip-0227.html
rename to rendered/zip-0227.html
index bcd47cb5a..3b313b876 100644
--- a/zip-0227.html
+++ b/rendered/zip-0227.html
@@ -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@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <str4d@electriccoin.co>
 Credits: Daniel Benarroch
          Aurelien Nicolas
@@ -84,7 +84,7 @@
             
             
    The relations between these keys are shown in the following diagram:
    
             
    
-                
+                
                 
    Diagram of Issuance Key Components for the Orchard-ZSA Protocol
    
             
    
             
    Issuance Authorization Signature Scheme 
    
@@ -294,7 +294,7 @@
              is defined as in 20.
    
             
    The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:
    
             
    
-                
+                
                 
    Diagram relating the Asset Identifier, Asset Digest, and Asset Base in the ZSA Protocol
    
             
    
             
    Note: To keep notations light and concise, we may omit
diff --git a/zip-0228.html b/rendered/zip-0228.html
similarity index 92%
rename from zip-0228.html
rename to rendered/zip-0228.html
index 1917f4e63..e43bedfe8 100644
--- a/zip-0228.html
+++ b/rendered/zip-0228.html
@@ -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@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <str4d@electriccoin.co>
 Credits: Daniel Benarroch
          Aurelien Nicolas
diff --git a/zip-0230.html b/rendered/zip-0230.html
similarity index 99%
rename from zip-0230.html
rename to rendered/zip-0230.html
index 4b7648efd..1857d1e9a 100644
--- a/zip-0230.html
+++ b/rendered/zip-0230.html
@@ -9,7 +9,7 @@
     
    
         
    ZIP: 230
 Title: Version 6 Transaction Format
-Owners: Daira-Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
diff --git a/zip-0231.html b/rendered/zip-0231.html
similarity index 91%
rename from zip-0231.html
rename to rendered/zip-0231.html
index cac8d4d1b..877430c9b 100644
--- a/zip-0231.html
+++ b/rendered/zip-0231.html
@@ -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@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Sean Bowe
          Nate Wilcox
 Status: Reserved
diff --git a/rendered/zip-0236.html b/rendered/zip-0236.html
new file mode 100644
index 000000000..7af767d39
--- /dev/null
+++ b/rendered/zip-0236.html
@@ -0,0 +1,129 @@
+
+
+
+    ZIP 236: Blocks should balance exactly
+    
+
+
+    
    
+        
    ZIP: 236
+Title: Blocks should balance exactly
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Credits: Jack Grigg
+         Kris Nuttycombe
+Status: Draft
+Category: Consensus
+Created: 2024-07-02
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/864>
    
+        
    Terminology 
    
+            
    The key word "MUST" in this document is to be interpreted as described in BCP 14 1 when, and only when, it appears in all capitals.
    
+            
    The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 5
    
+            
    The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification. 4
    
+            
    The character § is used when referring to sections of the Zcash Protocol Specification 2.
    
+        
    
+        
    Abstract 
    
+            
    In the current Zcash protocol, the miner of a coinbase transaction is permitted to claim up to and including the total amount of miner subsidy plus fees from other transactions in the block, but is not required to claim the full amount.
    
+            
    This proposal would require the full amount of miner subsidy and fees to be collected in coinbase transactions.
    
+        
    
+        
    Motivation 
    
+            
    The current semantics of coinbase transactions creates a potential for miners to miscalculate the total amount of miner subsidy plus fees in a block. If they claim a higher amount than the actual miner subsidy plus total fees, the block will be invalid, but if they claim a lower amount, the excess is effectively burnt. As a consequence, the effective ZEC issuance can fall short of the amount calculated from the intended issuance curve.
    
+            
    This unnecessarily complicates the question of how much ZEC has been issued: if it is defined as not including the amounts that were left unclaimed by miners, then it is difficult to calculate, and cannot be predicted exactly in advance for any given block height. Alternatively if it is defined to include those amounts, then that introduces potentially confusing discrepancies between different definitions of issuance or total supply.
    
+        
    
+        
    Requirements 
    
+            
    The consensus rule change specified in this ZIP must:
    
+            
      
+                
    • allow issuance to be predicted exactly in advance, starting from the point at which it activates;
      • 
+                
    • preclude errors by miners in computing the total miner subsidy plus fees for transactions in the mined block;
      • 
+                
    • be deployable in the NU6 network upgrade, which is not expected to define a new transaction version.
      • 
+            
    
+        
    
+        
    Non-requirements 
    
+            
    Since this ZIP is intended to activate in a network upgrade that is not expected to support a new transaction version, it cannot resolve the issue that the amounts of fees are implicit in non-coinbase transactions. That issue results in various potential security difficulties and the potential for users' wallets to inadvertently overpay the fee, but solving that would require an explicit "fee" field.
    
+            
    (It would technically be possible to encode the fee as a transparent output, but that would be a more disruptive change than is desirable, since other consensus rules would have to change in order to prevent this output from being spent, and since existing consumers of the transaction format could misinterpret such outputs.)
    
+            
    This consensus change is not intended to prevent other methods of provably removing ZEC from the circulating supply, such as sending it to an address for which it would be demonstrably infeasible to find the spending key.
    
+        
    
+        
    Specification 
    
+            
    From the activation block of this ZIP onward, coinbase transactions MUST claim all of the available miner subsidy plus fees in their block. More specifically, the following paragraph and consensus rule in § 3.4 "Transactions and Treestates" of the Zcash Protocol Specification 3:
    
+            
    
+                
    Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction, and transparent outputs remove value from this pool. As in Bitcoin, the remaining value in the transparent transaction value pool of a non-coinbase transaction is available to miners as a fee. The remaining value in the transparent transaction value pool of a coinbase transaction is destroyed.
    
+                
    Consensus rule: The remaining value in the transparent transaction value pool MUST be nonnegative.
    
+            
    
+            
    is modified to become:
    
+            
    
+                
    Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction, and transparent outputs remove value from this pool. The effect of Sapling Spends and Outputs, and of Orchard Actions on the transaction value pool are specified in § 4.13 and § 4.14 respectively.
    
+                
    As in Bitcoin, the remaining value in the transparent transaction value pool of a non-coinbase transaction is available to miners as a fee. That is, the sum of those values for non-coinbase transactions in each block is treated as an implicit input to the transaction value balance of the block's coinbase transaction (in addition to the implicit input created by issuance).
    
+                
    The remaining value in the transparent transaction value pool of coinbase transactions in blocks prior to NU-X is destroyed. From activation of NU-X, this remaining value is required to be zero; that is, all of the available balance MUST be consumed by outputs of the coinbase transaction.
    
+                
    Consensus rules:
    
+                
      
+                    
    • The remaining value in the transparent transaction value pool of a non-coinbase transaction MUST be nonnegative.
      • 
+                    
    • [Pre-NU-X] The remaining value in the transparent transaction value pool of a coinbase transaction MUST be nonnegative.
      • 
+                    
    • [NU-X onward] The remaining value in the transparent transaction value pool of a coinbase transaction MUST be zero.
      • 
+                
    
+            
    
+            
    where "NU-X" is to be replaced by the designation of the network upgrade in which this ZIP will be activated.
    
+            
    Note that the differences in the first two paragraphs of the above replacement text are clarifications of the protocol, rather than consensus changes. Those could be made independently of this ZIP.
    
+            
    This change applies identically to Mainnet and Testnet.
    
+        
    
+        
    Deployment 
    
+            
    Subject to community agreement, this ZIP is proposed to be deployed with NU6. 6
    
+        
    
+        
    Reference implementation 
    
+            
    TODO
    
+        
    
+        
    Acknowledgements 
    
+            
    The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading to the submission of this ZIP.
    
+        
    
+        
    References 
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    2Zcash Protocol Specification, Version 2023.4.0 or later
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    3Zcash Protocol Specification, Version 2023.4.0. Section 3.4: Transactions and Treestates
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    4Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    5ZIP 200: Network Upgrade Mechanism
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    6ZIP 253: Deployment of the NU6 Network Upgrade
    
+        
    
+    
    
+
+
\ No newline at end of file
diff --git a/zip-0239.html b/rendered/zip-0239.html
similarity index 99%
rename from zip-0239.html
rename to rendered/zip-0239.html
index 4d09ee36a..f4d1626e2 100644
--- a/zip-0239.html
+++ b/rendered/zip-0239.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 239
 Title: Relay of Version 5 Transactions
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
 Status: Final
 Category: Network
diff --git a/zip-0243.html b/rendered/zip-0243.html
similarity index 99%
rename from zip-0243.html
rename to rendered/zip-0243.html
index 2e497df51..e0fa280a3 100644
--- a/zip-0243.html
+++ b/rendered/zip-0243.html
@@ -9,7 +9,7 @@
         
    ZIP: 243
 Title: Transaction Signature Validation for Sapling
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Simon Liu
 Status: Final
 Category: Consensus
diff --git a/zip-0244.html b/rendered/zip-0244.html
similarity index 99%
rename from zip-0244.html
rename to rendered/zip-0244.html
index 8cc9b2165..8f73e4511 100644
--- a/zip-0244.html
+++ b/rendered/zip-0244.html
@@ -10,7 +10,7 @@
         
    ZIP: 244
 Title: Transaction Identifier Non-Malleability
 Owners: Kris Nuttycombe <kris@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <str4d@electriccoin.co>
 Status: Final
 Category: Consensus
diff --git a/zip-0245.html b/rendered/zip-0245.html
similarity index 99%
rename from zip-0245.html
rename to rendered/zip-0245.html
index 63ad4c9b2..0a44da2f6 100644
--- a/zip-0245.html
+++ b/rendered/zip-0245.html
@@ -9,6 +9,7 @@
         
    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
diff --git a/zip-0250.html b/rendered/zip-0250.html
similarity index 99%
rename from zip-0250.html
rename to rendered/zip-0250.html
index aac84c5c1..0c942d7e7 100644
--- a/zip-0250.html
+++ b/rendered/zip-0250.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 250
 Title: Deployment of the Heartwood Network Upgrade
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus / Network
 Created: 2020-02-28
diff --git a/zip-0251.html b/rendered/zip-0251.html
similarity index 99%
rename from zip-0251.html
rename to rendered/zip-0251.html
index 8cbbc6120..be3a7505b 100644
--- a/zip-0251.html
+++ b/rendered/zip-0251.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 251
 Title: Deployment of the Canopy Network Upgrade
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus / Network
 Created: 2020-02-28
diff --git a/zip-0252.html b/rendered/zip-0252.html
similarity index 99%
rename from zip-0252.html
rename to rendered/zip-0252.html
index 326ce0773..92f931d3a 100644
--- a/zip-0252.html
+++ b/rendered/zip-0252.html
@@ -9,7 +9,7 @@
         
    ZIP: 252
 Title: Deployment of the NU5 Network Upgrade
 Owners: teor <teor@zfnd.org>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus / Network
 Created: 2021-02-23
diff --git a/rendered/zip-0253.html b/rendered/zip-0253.html
new file mode 100644
index 000000000..a8764a8de
--- /dev/null
+++ b/rendered/zip-0253.html
@@ -0,0 +1,81 @@
+
+
+
+    ZIP 253: Deployment of the NU6 Network Upgrade
+    
+    
+    
+
+
+
    ZIP: 253
+Title: Deployment of the NU6 Network Upgrade
+Owners: Arya <arya@zfnd.org>
+Status: Draft
+Category: Consensus / Network
+Created: 2024-07-17
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/806>
    
+
    Terminology
    
+
    The key word “MUST” in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
+
    The term “network upgrade” in this document is to be interpreted as described in ZIP 200 2.
    
+
    The terms “Testnet” and “Mainnet” are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.
    
+
    Abstract
    
+
    This proposal defines the deployment of the NU6 network upgrade.
    
+
    Specification
    
+
    NU6 deployment
    
+
+
    The primary sources of information about NU6 consensus protocol changes are:
    
+
      
+
    • The Zcash Protocol Specification 4.
      • 
+
    • Network Upgrade Mechanism 5.
      • 
+
    • Lockbox Funding Streams 6.
      • 
+
    • Block Reward Allocation for Non-Direct Development Funding 7.
      • 
+
    • Blocks should balance exactly 8.
      • 
+
    
+
    The network handshake and peer management mechanisms defined in ZIP 201 9 also apply to this upgrade.
    
+
    The following ZIPs have been updated in varying degrees to take into account NU6:
    
+
      
+
    • ZIP 207: Funding Streams 10.
      • 
+
    • ZIP 214: Consensus rules for a Zcash Development Fund 11.
      • 
+
    
+
    The following network upgrade constants 12 are defined for the NU6 upgrade:
    
+
    
+
    CONSENSUS_BRANCH_ID
    
+
    0xC8E71055
+
    
+
    ACTIVATION_HEIGHT (NU6)
    
+
    Testnet: TBD
+
    
+
    Mainnet: TBD
+
    
+
    MIN_NETWORK_PROTOCOL_VERSION (NU6)
    
+
    Testnet: 170110
+
    
+
    Mainnet: 170120
+
    
+
    
+
    For each network (Testnet and Mainnet), nodes compatible with NU6 activation on that network MUST advertise a network protocol version that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU6) for that activation.
    
+
    Backward compatibility
    
+
    Prior to the network upgrade activating on each network, NU6 and pre-NU6 nodes are compatible and can connect to each other. However, NU6 nodes will have a preference for connecting to other NU6 nodes, so pre-NU6 nodes will gradually be disconnected in the run up to activation.
    
+
    Once the network upgrades, even though pre-NU6 nodes can still accept the numerically larger protocol version used by NU6 as being valid, NU6 nodes will always disconnect peers using lower protocol versions.
    
+
    NU6 does not define a new transaction version or impose a new minimum transaction version. NU6 transactions are therefore in the same v4 or v5 formats as NU5 transactions. This does not imply that transactions are valid across the NU6 activation, since signatures MUST use the appropriate consensus branch ID.
    
+
    References
    
+
    
+
    
+
      
+
    1. Information on BCP 14 — “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels” and “RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”↩︎
      2. 
+
    2. ZIP 200: Network Upgrade Mechanism↩︎
      3. 
+
    3. Zcash Protocol Specification, Version v2023.4.0 or later. Section 3.12: Mainnet and Testnet↩︎
      4. 
+
    4. Zcash Protocol Specification, Version v2023.4.0 or later↩︎
      5. 
+
    5. ZIP 200: Network Upgrade Mechanism↩︎
      6. 
+
    6. ZIP 2001 Lockbox Funding Streams↩︎
      7. 
+
    7. ZIP ???: Block Reward Allocation for Non-Direct Development Funding↩︎
      8. 
+
    8. ZIP 236: Blocks should balance exactly↩︎
      9. 
+
    9. ZIP 201: Network Peer Management for Overwinter↩︎
      10. 
+
    10. ZIP 207: Funding Streams↩︎
      11. 
+
    11. ZIP 214: Consensus rules for a Zcash Development Fund↩︎
      12. 
+
    12. ZIP 200: Network Upgrade Mechanism↩︎
      13. 
+
    
+
    
+
+
diff --git a/zip-0300.html b/rendered/zip-0300.html
similarity index 99%
rename from zip-0300.html
rename to rendered/zip-0300.html
index 3e95321e9..b8ec28883 100644
--- a/zip-0300.html
+++ b/rendered/zip-0300.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 300
 Title: Cross-chain Atomic Transactions
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: Jay Graber
 Status: Proposed
 Category: Informational
diff --git a/zip-0301.html b/rendered/zip-0301.html
similarity index 99%
rename from zip-0301.html
rename to rendered/zip-0301.html
index d575f6474..e84119136 100644
--- a/zip-0301.html
+++ b/rendered/zip-0301.html
@@ -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 @@
             
    Thanks to:
    
             
      
                 
    • 5a1t for the initial brainstorming session.
      • 
-                
    • Daira Emma Hopwood for their input on API selection and design.
      • 
+                
    • Daira-Emma Hopwood for hir input on API selection and design.
      • 
                 
    • Marek Palatinus (slush) and his colleagues for their refinements, suggestions, and robust discussion.
      • 
                 
    • Jelle Bourdeaud'hui (razakal) and ocminer for their help with testing and finding implementation bugs in the specification.
      • 
             
    
diff --git a/zip-0302.html b/rendered/zip-0302.html
similarity index 80%
rename from zip-0302.html
rename to rendered/zip-0302.html
index 13bd7501c..a404fc92b 100644
--- a/zip-0302.html
+++ b/rendered/zip-0302.html
@@ -31,21 +31,21 @@
             
    This ZIP refines the specification of the third case.
    
             
    The following specification constrains a party, called the "reader", that interprets the contents of a memo. It does not define consensus requirements.
    
             
      
-                
    • If the first byte (byte 0) has a value of 0xF4 or smaller, then the reader MUST:
+                
    • If the first byte (byte 0) has a value of 0xF4 or smaller, then the reader MUST:
                     
        
                         
      • strip any trailing zero bytes
        • 
                         
      • decode it as a UTF-8 string (if decoding fails then report an error).
        • 
                     
      
                 
      • 
-                
    • If the first byte has a value of 0xF6, and the remaining 511 bytes are 0x00, then the user supplied no memo, and the encrypted memo field is to be treated as empty.
      • 
+                
    • If the first byte has a value of 0xF6, and the remaining 511 bytes are 0x00, then the user supplied no memo, and the encrypted memo field is to be treated as empty.
      • 
                 
    • If the memo matches any of these patterns, then this memo is from the future, because these ranges are reserved for future updates to this specification:
                     
        
-                        
      • The first byte has a value of 0xF5.
        • 
-                        
      • The first byte has a value of 0xF6, and the remaining 511 bytes are not all 0x00.
        • 
-                        
      • The first byte has a value between 0xF7 and 0xFE inclusive.
        • 
+                        
      • The first byte has a value of 0xF6, and the remaining 511 bytes are not all 0x00.
        • 
+                        
      • The first byte has a value between 0xF7 and 0xFE inclusive.
        • 
                     
      
                 
      • 
-                
    • If the first byte has a value of 0xFF then the reader should not make any other assumption about the memo. In order to put arbitrary data into a memo field (that might have some private non-standard structure), the value of the first byte SHOULD be set to 0xFF; the remaining 511 bytes are then unconstrained.
      • 
+                
    • If the first byte has a value of 0xFF then the reader should not make any other assumption about the memo. In order to put arbitrary data into a memo field (that might have some private non-standard structure), the value of the first byte SHOULD be set to 0xFF; the remaining 511 bytes are then unconstrained.
      • 
+                
    • If the first byte has a value of 0xF5, then the reader should not make any other assumption about the memo. This value was used ambiguously in the past by private agreement; applications SHOULD prefer 0xFF which is unambiguously for this purpose.
      • 
             
    
         
    
         
    Rationale 
    
@@ -54,10 +54,10 @@
                 
    The usage of the memo field is by agreement between the sender and recipient of the note. The memo field SHOULD be encoded either as:
    
                 
      
                     
    • a UTF-8 human-readable string [Unicode], padded by appending zero bytes; or
      • 
-                    
    • an arbitrary sequence of 512 bytes starting with a byte value of 0xF5 or greater, which is therefore not a valid UTF-8 string.
      • 
+                    
    • an arbitrary sequence of 512 bytes starting with a byte value of 0xF5 or greater, which is therefore not a valid UTF-8 string.
      • 
                 
    
-                
    In the former case, wallet software is expected to strip any trailing zero bytes and then display the resulting UTF-8 string to the recipient user, where applicable. Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters (U+FFFD).
    
-                
    In the latter case, the contents of the memo field SHOULD NOT be displayed. A start byte of 0xF5 is reserved for use by automated software by private agreement. A start byte of 0xF6 or greater is reserved for use in future Zcash protocol extensions.
    
+                
    In the former case, wallet software is expected to strip any trailing zero bytes and then display the resulting UTF-8 string to the recipient user, where applicable. Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters (U+FFFD).
    
+                
    In the latter case, the contents of the memo field SHOULD NOT be displayed. A start byte of 0xF5 is reserved for use by automated software by private agreement. A start byte of 0xF6 or greater is reserved for use in future Zcash protocol extensions.
    
             
             
    See issue #1849 for further discussion.
    
         
    
diff --git a/zip-0303.html b/rendered/zip-0303.html
similarity index 100%
rename from zip-0303.html
rename to rendered/zip-0303.html
diff --git a/zip-0304.html b/rendered/zip-0304.html
similarity index 99%
rename from zip-0304.html
rename to rendered/zip-0304.html
index df9d5d806..453038ad0 100644
--- a/zip-0304.html
+++ b/rendered/zip-0304.html
@@ -10,7 +10,7 @@
         
    ZIP: 304
 Title: Sapling Address Signatures
 Owners: Jack Grigg <jack@electriccoin.co>
-Credits: Daira Emma Hopwood <daira@electriccoin.co>
+Credits: Daira-Emma Hopwood <daira-emma@electriccoin.co>
          Sean Bowe <sean@electriccoin.co>
 Status: Draft
 Category: Standards / RPC / Wallet
diff --git a/zip-0305.html b/rendered/zip-0305.html
similarity index 89%
rename from zip-0305.html
rename to rendered/zip-0305.html
index fc1e5e11a..e430de062 100644
--- a/zip-0305.html
+++ b/rendered/zip-0305.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 305
 Title: Best Practices for Hardware Wallets supporting Sapling
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/346>
    
diff --git a/zip-0306.html b/rendered/zip-0306.html
similarity index 89%
rename from zip-0306.html
rename to rendered/zip-0306.html
index f535f3aef..6847e02c6 100644
--- a/zip-0306.html
+++ b/rendered/zip-0306.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 306
 Title: Security Considerations for Anchor Selection
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Informational
 Discussions-To: <https://github.com/zcash/zips/issues/351>
    
diff --git a/zip-0307.html b/rendered/zip-0307.html
similarity index 99%
rename from zip-0307.html
rename to rendered/zip-0307.html
index ed49efa17..07a72407c 100644
--- a/zip-0307.html
+++ b/rendered/zip-0307.html
@@ -10,7 +10,7 @@
         
    ZIP: 307
 Title: Light Client Protocol for Payment Detection
 Owners: Jack Grigg <jack@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: George Tankersley
 Credits: Matthew Green
 Category: Standards / Ecosystem
@@ -39,7 +39,7 @@
                 
  • Light client that subscribes to the stream from a proxy server and uses that data to update its own view of the chain state. The light client MAY be attached to a wallet backend that will track particular Sapling notes.
    • 
             
             
    
-                
+                
                 
    Outline of the light wallet architecture
    
             
    
         
    
diff --git a/zip-0308.html b/rendered/zip-0308.html
similarity index 99%
rename from zip-0308.html
rename to rendered/zip-0308.html
index 169ea6445..6afcc473a 100644
--- a/zip-0308.html
+++ b/rendered/zip-0308.html
@@ -8,8 +8,8 @@
     
    
         
    ZIP: 308
 Title: Sprout to Sapling Migration
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
-Original-Authors: Daira Emma Hopwood
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Original-Authors: Daira-Emma Hopwood
                   Eirik Ogilvie-Wigley
 Status: Final
 Category: Standards / RPC / Wallet
diff --git a/zip-0309.html b/rendered/zip-0309.html
similarity index 100%
rename from zip-0309.html
rename to rendered/zip-0309.html
diff --git a/zip-0310.html b/rendered/zip-0310.html
similarity index 99%
rename from zip-0310.html
rename to rendered/zip-0310.html
index 17962bfac..0c9c2b30e 100644
--- a/zip-0310.html
+++ b/rendered/zip-0310.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 310
 Title: Security Properties of Sapling Viewing Keys
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
 Status: Draft
 Category: Informational
diff --git a/rendered/zip-0311.html b/rendered/zip-0311.html
new file mode 100644
index 000000000..cfec0a94b
--- /dev/null
+++ b/rendered/zip-0311.html
@@ -0,0 +1,637 @@
+
+
+
+    ZIP 311: Zcash Payment Disclosures
+    
+    
+
+
+    
    
+        
    ZIP: 311
+Title: Zcash Payment Disclosures
+Owners: Jack Grigg <jack@electriccoin.co>
+Status: Draft
+Category: Standards / RPC / Wallet
+Discussions-To: <https://github.com/zcash/zips/issues/387>
    
+        
    Abstract 
    
+            
    This ZIP describes a mechanism and format for disclosing information about shielded spends and outputs within a transaction. In the typical case, this means enabling a sender to present a proof that they transferred funds to a recipient's shielded address.
    
+        
    
+        
    Motivation 
    
+            
    There are various situations where a proof-of-payment may be desired. For example:
    
+            
      
+                
    • A sender may need to prove that their payment was sent to a recipient, and available to be received (following the Zcash protocol in-band).
      • 
+                
    • A third party may need to verify that a payment between a given sender and recipient was executed successfully.
      • 
+            
    
+            
    When a transaction involves only transparent addresses, proof-of-payment is simple: The sender provides the transaction ID, and the recipient examines the blockchain to confirm that the transaction was mined. A third party can also perform this verification if they know the transparent addresses of the involved parties.
    
+            
    However, if the transaction involves shielded addresses, the blockchain by itself does not contain enough information to allow a record of the payment to be reconstructed and verified:
    
+            
+                
+                    
+                        
+                        
+                        
+                        
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                        
+                        
+                        
+                        
+                    
+                    
+                        
+                        
+                        
+                        
+                        
+                        
+                    
+                    
+                        
+                        
+                        
+                        
+                        
+                        
+                    
+                    
+                        
+                        
+                        
+                        
+                        
+                        
+                    
+                
+            
    SourceDestinationSenderRecipientAmountPayment dislosure?
    TransparentTransparent🔍🔍🔍Not required
    TransparentShielded🔍🔐🔐*Required
    ShieldedTransparent🔒🔍🔍Required
    ShieldedShielded🔒🔐🔐Required
    
+            
      
+                
    • 🔍 = Visible on the block chain.
      • 
+                
    • 🔐 = Cannot be confirmed without information that is not visible on the block chain.
      • 
+                
    • 🔐* = Information is revealed, but not enough to confirm the amount paid (due to change).
      • 
+                
    • 🔒 = Requires either an interactive payment disclosure, or a non-interactive payment disclosure that reveals the sender's address.
      • 
+            
    
+            
    Enabling proof-of-payment for all of these transaction variants (where it is possible to do so) is the subject of this ZIP.
    
+        
    
+        
    Use cases 
    
+            
    Managing contributions for an event 
    
+                
    Alice runs an event on behalf of Bob and Carol, who both agree to split the cost equally. Alice receives a single payment for half the amount, and wants proof of who it came from (so she knows which person to follow up with for the remaining amount). Carol can provide a payment disclosure that reveals to Alice:
    
+                
      
+                    
    • The correct amount was sent to the Alice's recipient address in the given transaction.
      • 
+                    
    • Carol was the sender of that transaction (more precisely, Carol controls the spend authority used in that transaction).
      • 
+                
    
+                
    and does not reveal:
    
+                
      
+                    
    • Carol's payment address.
      • 
+                    
    • Any of Carol's other diversified payment addresses.
      • 
+                    
    • Any of Carol's other transactions.
      • 
+                
    
+                
    For this use case, it is not necessary (and not necessarily intended) that the payment disclosure be publically verifiable.
    
+            
    
+            
    Donation drive 
    
+                
    Diana is a well-known individual with a public shielded payment address (for receiving donations). She runs a matching donation drive to the non-profit Totally Legit Bunnies, and wants to prove to her followers that she correctly matched their donations. Diana can create a payment disclosure, and post it to her social media account, that reveals:
    
+                
      
+                    
    • The correct amount was sent to the Totally Legit Bunnies' recipient address in the given transaction.
      • 
+                    
    • The sender of the transaction is the payment address that is associated with Diana.
      • 
+                
    
+                
    and does not reveal:
    
+                
      
+                    
    • Any of Diana's other diversified payment addresses.
      • 
+                    
    • Any of Diana's other transactions.
      • 
+                
    
+            
    
+            
    Merchant dispute 
    
+                
    Edward goes to CarsRFast to buy a Lamborghini, and sends funds from his shielded address to CarsRFast's transparent address. They can see a payment has been made, but claim that they have not received a payment from Edward. He can create a payment disclosure that reveals:
    
+                
      
+                    
    • Edward was the sender of the given transaction.
      • 
+                
    
+                
    and does not reveal:
    
+                
      
+                    
    • Edward's payment address.
      • 
+                    
    • Any of Edward's other diversified payment addresses.
      • 
+                    
    • Any of Edward's other transactions.
      • 
+                
    
+            
    
+            
    Shielded withdrawals from an exchange 
    
+                
    CorpBux is an exchange with a transparent hot wallet, and enables customers to withdraw their funds to shielded addresses. They can create a payment disclosure, that they can give to their customers, that reveals:
    
+                
      
+                    
    • The correct amount was sent to the customer's shielded recipient address in the given transaction.
      • 
+                    
    • CorpBux was the sender of the given transaction.
      • 
+                
    
+            
    
+        
    
+        
    Requirements 
    
+            
      
+                
    • The payment disclosure may disclose the contents of zero or more shielded outputs within a single transaction. (Zero outputs is useful for z2t transactions.)
      • 
+                
    • Payment disclosures can only be created by a sender of the transaction, and are non-malleable (that is, no-one else can take one or more payment disclosures and construct a new one that they would not have been able to make independently).
      • 
+                
    • A payment disclosure may be tied to a challenge, creating an interactive proof.
      • 
+                
    • Senders with a shielded address may choose to provably reveal that address as part of the payment disclosure.
      • 
+                
    • Senders are not required to remember any ephemeral data from the creation of a transaction in order to produce a payment disclosure for that transaction. (Performance may be improved if they do cache witness data for spent notes.)
      • 
+                
    • The payment disclosure can be created without requiring another trusted setup.
      • 
+            
    
+        
    
+        
    Conventions 
    
+            
    The following functions used in this ZIP are defined in the Zcash protocol specification: 3
    
+            
      
+                
    • 
+                    \(\mathsf{DiversifyHash}(\mathsf{d})\)
+                 7
      • 
+                
    • 
+                    \(\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})\)
+                ,
+                    \(\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)\)
+                , and
+                    \(\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)\)
+                 8
      • 
+            
    
+            
    We reproduce some notation and functions from 3 here for convenience:
    
+            
      
+                
    • 
+                    \([k] P\)
+                 means scalar multiplication of the elliptic curve point
+                    \(P\)
+                 by the scalar
+                    \(k\)
+                .
      • 
+                
    • 
+                    \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)
+                 refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string
+                    \(p\)
+                , and input
+                    \(x\)
+                .
      • 
+            
    
+            
    We also define the following notation here:
    
+            
      
+                
    • 
+                    \([a..b]\)
+                 means the sequence of values inclusive of
+                    \(a\)
+                 and exclusive of
+                    \(b\)
+                .
      • 
+                
    • 
+                    \(\mathsf{length}(a)\)
+                 means the length of the sequence
+                    \(a\)
+                .
      • 
+            
    
+        
    
+        
    Specification 
    
+            
    Payment disclosure data structure 
    
+                
    A payment disclosure has the following fields:
    
+                
      
+                    
    • txid: Transaction id for the transaction tx being disclosed.
      • 
+                    
    • msg: A message field, which could contain a challenge value from the party to whom the payment disclosure is directed.
      • 
+                    
    • 
+                        \(\mathsf{transparentInputs}\)
+                    : A sequence of the transparent inputs for which we are proving spend authority
+                        \([0..\mathsf{length}(\mathsf{tx.vin})]\)
+                        
        
+                            
      • 
+                                \(\mathsf{index}\)
+                            : An index into
+                                \(\mathsf{tx.vin}\)
+                            .
        • 
+                            
      • 
+                                \(\mathsf{sig}\)
+                            : A BIP 322 signature. 9
+                                
          
+                                    
        • TODO: zcashd currently only supports the legacy format defined in BIP 322. We may want to backport full BIP 322 support before having transparent input support in this ZIP, to ensure it does what we need.
          • 
+                                    
        • TODO: BIP 322 specifies consensus rule checks as part of the signature verification process. We will likely need to migrate it over to an equivalent ZIP that specifies these for Zcash (which has a different set of script validation consensus rules).
          • 
+                                
        
+                            
        • 
+                        
      
+                    
      • 
+                    
    • 
+                        \(\mathsf{saplingSpends}\)
+                    : A sequence of the Sapling Spends for which we are proving spend authority
+                        \([0..\mathsf{length}(\mathsf{tx.shieldedSpends})]\)
+                        
        
+                            
      • 
+                                \(\mathsf{index}\)
+                            : An index into
+                                \(\mathsf{tx.shieldedSpends}\)
+                            .
        • 
+                            
      • 
+                                \(\mathsf{cv}\)
+                            : A value commitment to the spent note.
        • 
+                            
      • 
+                                \(\mathsf{rk}\)
+                            : A randomized public key linked to the spent note.
        • 
+                            
      • 
+                                \(\mathsf{zkproof_{spend}}\)
+                            : A Sapling spend proof.
        • 
+                            
      • [Optional] A payment address proof addr_proof:
+                                
          
+                                    
        • Any
+                                        \((\mathsf{d, pk_d})\)
+                                     such that
+                                        \(\mathsf{pk_d} = [\mathsf{ivk}] \mathsf{DiversifyHash}(\mathsf{d})\)
+                                    
          • 
+                                    
        • 
+                                        \(\mathsf{nullifier_{addr}}\)
+                                    : A nullifier for a ZIP 304 fake note. 11
          • 
+                                    
        • 
+                                        \(\mathsf{zkproof_{addr}}\)
+                                    : A Sapling spend proof.
          • 
+                                
        
+                            
        • 
+                            
      • 
+                                \(\mathsf{spendAuthSig}\)
+                            
        • 
+                        
      
+                    
      • 
+                    
    • 
+                        \(\mathsf{saplingOutputs}\)
+                    : A sequence of the Sapling Outputs that we are disclosing
+                        \([0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]\)
+                        
        
+                            
      • 
+                                \(\mathsf{index}\)
+                            : An index into
+                                \(\mathsf{tx.shieldedOutputs}\)
+                            .
        • 
+                            
      • 
+                                \(\mathsf{ock}\)
+                            : The outgoing cipher key that allows this output to be recovered. 5
        • 
+                        
      
+                    
      • 
+                
    
+                
    TODO: Add support for Orchard.
    
+                
    TODO: Decide on payment disclosure versioning.
    
+                
    TODO: Define encodings for unsigned and signed payment disclosures.
    
+            
    
+            
    Creating a payment disclosure 
    
+                
    The inputs to a payment disclosure are:
    
+                
      
+                    
    • The transaction.
      • 
+                    
    • The SLIP-44 10 coin type.
      • 
+                    
    • The message
+                        \(msg\)
+                     to be included (which may be empty).
      • 
+                    
    • A sequence of
+                        \((\mathsf{outputIndex}, \mathsf{ock})\)
+                     tuples (which may be empty).
      • 
+                    
    • A sequence of Sapling spend tuples (which may be empty) containing:
+                        
        
+                            
      • A Sapling spend index.
        • 
+                            
      • Its corresponding expanded spending key
+                                \((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})\)
+                            .
        • 
+                            
      • [Optional] An associated payment address
+                                \((\mathsf{d}, \mathsf{pk_d})\)
+                            .
        • 
+                        
      
+                    
      • 
+                    
    • A sequence of transparent input tuples (which may be empty) containing:
+                        
        
+                            
      • 
+                                \(\mathsf{index}\)
+                            : An index into
+                                \(\mathsf{tx.vin}\)
+                            .
        • 
+                            
      • The inputs to a BIP 322 signature (excluding message_data).
        • 
+                        
      
+                    
      • 
+                
    
+                
    The caller MUST provide at least one input tuple of any type (either a Sapling spend tuple or a transparent input tuple).
    
+                
    The payment disclosure is created as follows:
    
+                
      
+                    
    • For each Sapling spend index:
+                        
        
+                            
      • Create a Sapling spend proof for the note that was spent in
+                                \(\mathsf{tx.shieldedSpends[index]}\)
+                            , using the same anchor, to obtain
+                                \((\mathsf{cv}, \mathsf{rk}, \mathsf{zkproof_{spend}})\)
+                             as well as the random
+                                \(\alpha\)
+                             that was generated internally.
        • 
+                            
      • [Optional] If an associated payment address was provided for this spend index, create a ZIP 304 signature proof for that payment address, 11 using
+                                \(\alpha\)
+                             and
+                                \(\mathsf{rk}\)
+                             from the previous step. We obtain
+                                \((\mathsf{nullifier_{addr}}, \mathsf{zkproof_{addr}})\)
+                             from this step.
        • 
+                        
      
+                    
      • 
+                    
    • For each transparent input index:
+                        
        
+                            
      • TODO: Prepare BIP 322 signature inputs using msg as the message_data.
        • 
+                        
      
+                    
      • 
+                    
    • Construct an unsigned payment disclosure from the disclosed Sapling outputs, and the above data for the Sapling spends and transparent inputs. Define the encoding of this as
+                        \(unsignedPaymentDisclosure\)
+                    .
      • 
+                    
    • For each Sapling spend index:
+                        
        
+                            
      • Let
+                                \(\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(\alpha, \mathsf{ask})\)
+                            .
        • 
+                            
      • Let
+                                \(coinType\)
+                             be the 4-byte little-endian encoding of the SLIP 44 coin type in its index form, not its hardened form (i.e. 133 for mainnet Zcash).
        • 
+                            
      • Let
+                                \(digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, unsignedPaymentDisclosure)\)
+                            .
        • 
+                            
      • Let
+                                \(spendAuthSig = \mathsf{SpendAuthSig.Sign}(\mathsf{rsk}, digest)\)
+                            .
        • 
+                        
      
+                    
      • 
+                    
    • For each transparent input index:
+                        
        
+                            
      • TODO: Create a BIP 322 signature using msg as the message_data.
        • 
+                        
      
+                    
      • 
+                    
    • Return the payment disclosure as the combination of the unsigned payment disclosure and the set of spendAuthSig and transparent signature values.
      • 
+                
    
+            
    
+            
    Verifying a payment disclosure 
    
+                
    Given a payment disclosure
+                    \(\mathsf{pd}\)
+                , a transaction
+                    \(\mathsf{tx}\)
+                , and the height of the block in which
+                    \(\mathsf{tx}\)
+                 was mined (which we assume was verified by the caller), the verifier proceeds as follows:
    
+                
      
+                    
    • Perform the following structural correctness checks, returning false if any check fails:
+                        
        
+                            
      • 
+                                \(\mathsf{pd.txid} = \mathsf{tx.txid}()\)
+                            
        • 
+                            
      • Sequence length correctness:
+                                
          
+                                    
        • 
+                                        \(\mathsf{length}(\mathsf{pd.saplingOutputs}) \leq \mathsf{length}(\mathsf{tx.shieldedOutputs})\)
+                                    
          • 
+                                    
        • 
+                                        \(\mathsf{length}(\mathsf{pd.saplingSpends}) \leq \mathsf{length}(\mathsf{tx.shieldedSpends})\)
+                                    
          • 
+                                    
        • 
+                                        \(\mathsf{length}(\mathsf{pd.transparentInputs}) \leq \mathsf{length}(\mathsf{tx.vin})\)
+                                    
          • 
+                                
        
+                            
        • 
+                            
      • Index uniqueness:
+                                
          
+                                    
        • For every
+                                        \(\mathsf{output}\)
+                                     in
+                                        \(\mathsf{pd.saplingOutputs}\)
+                                    ,
+                                        \(\mathsf{output.index}\)
+                                     only occurs once.
          • 
+                                    
        • For every
+                                        \(\mathsf{spend}\)
+                                     in
+                                        \(\mathsf{pd.saplingSpends}\)
+                                    ,
+                                        \(\mathsf{spend.index}\)
+                                     only occurs once.
          • 
+                                    
        • For every
+                                        \(\mathsf{input}\)
+                                     in
+                                        \(\mathsf{pd.transparentInputs}\)
+                                    ,
+                                        \(\mathsf{input.index}\)
+                                     only occurs once.
          • 
+                                
        
+                            
        • 
+                            
      • Index correctness:
+                                
          
+                                    
        • For every
+                                        \(\mathsf{output}\)
+                                     in
+                                        \(\mathsf{pd.saplingOutputs}\)
+                                    ,
+                                        \(\mathsf{output.index} < \mathsf{length}(\mathsf{tx.shieldedOutputs})\)
+                                    
          • 
+                                    
        • For every
+                                        \(\mathsf{spend}\)
+                                     in
+                                        \(\mathsf{pd.saplingSpends}\)
+                                    ,
+                                        \(\mathsf{spend.index} < \mathsf{length}(\mathsf{tx.shieldedSpends})\)
+                                    
          • 
+                                    
        • For every
+                                        \(\mathsf{input}\)
+                                     in
+                                        \(\mathsf{pd.transparentInputs}\)
+                                    ,
+                                        \(\mathsf{input.index} < \mathsf{length}(\mathsf{tx.vin})\)
+                                    
          • 
+                                
        
+                            
        • 
+                            
      • 
+                                \(\mathsf{length}(\mathsf{pd.saplingSpends}) + \mathsf{length}(\mathsf{pd.transparentInputs}) > 0\)
+                            
        • 
+                        
      
+                    
      • 
+                    
    • Let
+                        \(unsignedPaymentDisclosure\)
+                     be the encoding of the payment disclosure without signatures.
      • 
+                    
    • Let
+                        \(coinType\)
+                     be the 4-byte little-endian encoding of the coin type in its index form, not its hardened form (i.e. 133 for mainnet Zcash).
      • 
+                    
    • Let
+                        \(digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, unsignedPaymentDisclosure)\)
+                    .
      • 
+                    
    • For every
+                        \(\mathsf{spend}\)
+                     in
+                        \(\mathsf{pd.saplingSpends}\)
+                    :
+                        
        
+                            
      • If
+                                \(\mathsf{SpendAuthSig.Verify}(\mathsf{spend.rk}, digest, \mathsf{spend.spendAuthSig}) = 0\)
+                            , return false.
        • 
+                            
      • [Optional] If a payment address proof
+                                \(\mathsf{addrProof}\)
+                             is present in
+                                \(\mathsf{spend}\)
+                            , verify
+                                \((\mathsf{addrProof.nullifier_{addr}}, \mathsf{spend.rk}, \mathsf{addrProof.zkproof_{addr}})\)
+                             as a ZIP 304 proof for
+                                \((\mathsf{addrProof.d}, \mathsf{addrProof.pk_d})\)
+                             11. If verification fails, return false.
        • 
+                            
      • Decode and verify
+                                \(\mathsf{zkproof_{spend}}\)
+                             as a Sapling spend proof 4 with primary input:
+                                
          
+                                    
        • 
+                                        \(\mathsf{tx.shieldedSpends[spend.index].rt}\)
+                                    
          • 
+                                    
        • 
+                                        \(\mathsf{spend.cv}\)
+                                    
          • 
+                                    
        • 
+                                        \(\mathsf{tx.shieldedSpends[spend.index].nf}\)
+                                    
          • 
+                                    
        • 
+                                        \(\mathsf{spend.rk}\)
+                                    
          • 
+                                
        
+                                
        If verification fails, return false.
        
+                            
        • 
+                        
      
+                    
      • 
+                    
    • For every
+                        \(\mathsf{input}\)
+                     in
+                        \(\mathsf{pd.transparentInputs}\)
+                    :
+                        
        
+                            
      • TODO: BIP 322 verification.
        • 
+                        
      
+                    
      • 
+                    
    • For every
+                        \(\mathsf{output}\)
+                     in
+                        \(\mathsf{pd.saplingOutputs}\)
+                    :
+                        
        
+                            
      • Recover the Sapling note in
+                                \(\mathsf{tx.shieldedOutputs}[\mathsf{output.index}]\)
+                             via the process specified in 6 with inputs
+                                \((height, \mathsf{output.ock})\)
+                            . If recovery returns
+                                \(\bot\)
+                            , return false.
        • 
+                        
      
+                    
      • 
+                    
    • Return true.
      • 
+                
    
+            
    
+            
    Payment disclosure validity in UIs 
    
+                
    TODO: Set some standards for how UIs should display payment disclosures, and how they should convey the various kinds of validity information:
    
+                
      
+                    
    • One, but not all, of the spenders proved spend authority.
      • 
+                    
    • All spenders of a specific type proved spend authority.
      • 
+                    
    • All spenders proved spend authority.
      • 
+                    
    • These, but also including optional payment address proofs.
      • 
+                
    
+            
    
+        
    
+        
    Rationale 
    
+            
    If a sender elects, at transaction creation time, to use an
+                \(\mathsf{ovk}\)
+             of
+                \(\bot\)
+             for a specific Sapling output, then they are unable to subsequently create a payment disclosure that discloses that output. This maintains the semantics of
+                \(\mathsf{ovk}\)
+            , in that the sender explicitly chose to lose the capability to recover that output.
    
+            
    Payment disclosures that prove Sapling spend authority are not required to reveal a sender address. This is because it is impossible: we can "prove" the transaction came from any of the diversified addresses linked to the spending key. Fundamentally, the "sender" of a transaction is anyone who has access to the corresponding spend authority; in the case of Sapling, a spend authority corresponds to multiple diversified addresses. In situations where a sender address is already known to the verifier of the payment disclosure (or publically), it may still be useful to have the option of linking the payment disclosure to that address.
    
+        
    
+        
    Security and Privacy Considerations 
    
+            
    When spending Sapling notes normally in transactions, wallets select a recent anchor to make the anonymity set of the spent note as large as possible. By contrast, Sapling spend authority in a payment disclosure is proven using the same anchor that was used in the transaction itself, instead of a recent anchor. We do this for efficency reasons:
    
+            
      
+                
    • The anchor is already encoded in the transaction, so can be omitted from the payment disclosure encoding.
      • 
+                
    • It is necessary to have a witness for each spent note that is being included in the payment disclosure. Using the same anchor means that the same witness can be used for the transaction spend and the payment disclosure, which in turn means that wallets that support payment disclosures only need to remember that witness, and do not need to continually update witnesses for spent notes in the off-chance that they might be used in a payment disclosure.
      • 
+            
    
+            
    There is no privacy benefit to selecting a more recent anchor; the anonymity set of the note was "fixed" by the original spend (which revealed that the note existed as of that anchor's height).
    
+            
    We require all payment disclosures to prove spend authority for at least one input, in order to simplify the verification UX. In particular, if payment disclosures without spends were considered valid, an invalid payment disclosure with invalid signatures (that would be shown as invalid by UIs) could be mutated into a payment disclosure that would be shown as valid by UIs, by stripping off the signatures. We do not believe that this prevents any useful use cases; meanwhile if someone is intent on obtaining Sapling output disclosures regardless of the validity of their source, they will do so without a common standard.
    
+        
    
+        
    Reference implementation 
    
+            
    TBD
    
+        
    
+        
    References 
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    2RFC 4648: The Base16, Base32, and Base64 Data Encodings
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    3Zcash Protocol Specification, Version 2020.1.15 or later
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    4Zcash Protocol Specification, Version 2020.1.15. Section 4.15.2: Spend Statement (Sapling)
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    5Zcash Protocol Specification, Version 2020.1.15. 4.17.1: Encryption (Sapling)
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    6Zcash Protocol Specification, Version 2020.1.15. 4.17.3: Decryption using a Full Viewing Key (Sapling)
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    7Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    8Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    9BIP 322: Generic Signed Message Format
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    10SLIP-0044 : Registered coin types for BIP-0044
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    11ZIP 304: Sapling Address Signatures
    
+        
    
+    
    
+
+
\ No newline at end of file
diff --git a/rendered/zip-0312.html b/rendered/zip-0312.html
new file mode 100644
index 000000000..f69ad06eb
--- /dev/null
+++ b/rendered/zip-0312.html
@@ -0,0 +1,425 @@
+
+
+
+    ZIP 312: FROST for Spend Authorization Multisignatures
+    
+    
+
+
+    
    
+        
    ZIP: 312
+Title: FROST for Spend Authorization Multisignatures
+Owners: Conrado Gouvea <conrado@zfnd.org>
+        Chelsea Komlo <ckomlo@uwaterloo.ca>
+        Deirdre Connolly <deirdre@zfnd.org>
+Status: Draft
+Category: Wallet
+Created: 2022-08-dd
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/382>
+Pull-Request: <https://github.com/zcash/zips/pull/662>
    
+        
    Terminology 
    
+            
    {Edit this to reflect the key words that are actually used.} The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 2
    
+            
    The terms below are to be interpreted as follows:
    
+            
    
+                
    Unlinkability
    
+                
    The property of statistical independence of signatures from the signers' long-term keys, ensuring that (for perfectly uniform generation of Randomizers and no leakage of metadata) it is impossible to determine whether two transactions were generated by the same party.
    
+            
    
+        
    
+        
    Abstract 
    
+            
    This proposal adapts FROST 3, a threshold signature scheme, to make it unlinkable, which is a requirement for its use in the Zcash protocol. The adapted scheme generates signatures compatible with spend authorization signatures in the Sapling and Orchard shielded protocols as deployed in Zcash.
    
+        
    
+        
    Motivation 
    
+            
    In the Zcash protocol, Spend Authorization Signatures are employed to authorize a transaction. The ability to generate these signatures with the user's private key is what effectively allows the user to spend funds.
    
+            
    This is a security-critical step, since anyone who obtains access to the private key will be able to spend the user's funds. For this reason, one interesting possibility is to require multiple parties to allow the transaction to go through. This can be accomplished with threshold signatures, where the private key is split between parties (or generated already split using a distributed protocol) in a way that a threshold (e.g. 2 out of 3) of them must sign the transaction in order to create the final signature. This enables scenarios such as users and third-party services sharing custody of a wallet, or a group of people managing shared funds, for example.
    
+            
    FROST is one of such threshold signature protocols. However, it can't be used as-is since the Zcash protocol also requires re-randomizing public and private keys to ensure unlinkability between transactions. This ZIP specifies a variant of FROST with re-randomization support. This variant is named "Re-Randomized FROST" and has been described in 4.
    
+        
    
+        
    Requirements 
    
+            
      
+                
    • All signatures generated by following this ZIP must be verified successfully as Sapling or Orchard spend authorization signatures using the appropriate validating key.
      • 
+                
    • The signatures generated by following this ZIP should meet the security criteria for Signature with Re-Randomizable Keys as specified in the Zcash protocol 12.
      • 
+                
    • The threat model described below must be taken into account.
      • 
+            
    
+            
    Threat Model 
    
+                
    In normal usage, a Zcash user follows multiple steps in order to generate a shielded transaction:
    
+                
      
+                    
    • The transaction is created.
      • 
+                    
    • The transaction is signed with a re-randomized version of the user's spend authorization private key.
      • 
+                    
    • The zero-knowledge proof for the transaction is created with the randomizer as an auxiliary (secret) input, among others.
      • 
+                
    
+                
    When employing re-randomizable FROST as specified in this ZIP, the goal is to split the spend authorization private key
+                    \(\mathsf{ask}\)
+                 among multiple possible signers. This means that the proof generation will still be performed by a single participant, likely the one that created the transaction in the first place. Note that this user already controls the privacy of the transaction since they are responsible for creating the proof.
    
+                
    This fits well into the "Coordinator" role from the FROST specification 5. The Coordinator is responsible for sending the message to be signed to all participants, and to aggregate the signature shares.
    
+                
    With those considerations in mind, the threat model considered in this ZIP is:
    
+                
      
+                    
    • The Coordinator is trusted with the privacy of the transaction (which includes the unlinkability property). A rogue Coordinator will be able to break unlinkability and privacy, but should not be able to create signed transactions without the approval of MIN_PARTICIPANTS participants, as specified in FROST.
      • 
+                    
    • All key share holders are also trusted with the privacy of the transaction, thus a rogue key share holder will be able to break its privacy and unlinkability.
      • 
+                
    
+            
    
+        
    
+        
    Non-requirements 
    
+            
      
+                
    • This ZIP does not support removing the Coordinator role, as described in 6.
      • 
+                
    • This ZIP does not prevent key share holders from linking the signing operation to a transaction in the blockchain.
      • 
+                
    • Like the FROST specification 3, this ZIP does not specify a key generation procedure; but refer to that specification for guidelines.
      • 
+                
    • Network privacy is not in scope for this ZIP, and must be obtained with other tools if desired.
      • 
+            
    
+        
    
+        
    Specification 
    
+            
    Algorithms in this section are specified using Python pseudo-code, in the same fashion as the FROST specification 3.
    
+            
    The types Scalar, Element, and G are defined in 7, as well as the notation for elliptic-curve arithmetic, which uses the additive notation. Note that this notation differs from that used in the Zcash Protocol Specification. For example, G.ScalarMult(P, k) is used for scalar multiplication, where the protocol spec would use
+                \([k] P\)
+             with the group implied by
+                \(P\)
+            .
    
+            
    An additional per-ciphersuite hash function is used, denote HR(m), which receives an arbitrary-sized byte string and returns a Scalar. It is defined concretely in the Ciphersuites section.
    
+            
    Key Generation 
    
+                
    While key generation is out of scope for this ZIP and the FROST spec 3, it needs to be consistent with FROST, see 9 for guidance. The spend authorization private key
+                    \(\mathsf{ask}\)
+                 14 is the particular key that must be used in the context of this ZIP. Note that the
+                    \(\mathsf{ask}\)
+                 is usually derived from the spending key
+                    \(\mathsf{sk}\)
+                , though that is not required. Not doing so allows using distributed key generation, since the key it generates is unpredictable. Note however that not deriving
+                    \(\mathsf{ask}\)
+                 from
+                    \(\mathsf{sk}\)
+                 prevents using seed phrases to recover the original secret (which may be something desirable in the context of FROST).
    
+            
    
+            
    Re-randomizable FROST 
    
+                
    To add re-randomization to FROST, follow the specification 3 with the following modifications.
    
+                
    Randomizer Generation 
    
+                    
    A new helper function is defined, which generates a randomizer. The encode_signing_package is defined as the byte serialization of the msg, commitment_list values as described in 11. Implementations MAY choose another encoding as long as all values (the message, and the identifier, binding nonce and hiding nonce for each participant) are unambiguously encoded.
    
+                    
    The function random_bytes(n) is defined in 3 and it returns a buffer with n bytes sampled uniformly at random. The constant Ns is also specified in 3 and is the size of a serialized scalar.
    
+                    
    randomizer_generate():
+
+Inputs:
+- msg, the message being signed in the current FROST signing run
+- commitment_list = [(i, hiding_nonce_commitment_i,
+  binding_nonce_commitment_i), ...], a list of commitments issued by
+  each participant, where each element in the list indicates a
+  NonZeroScalar identifier i and two commitment Element values
+  (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list
+  MUST be sorted in ascending order by identifier.
+
+Outputs: randomizer, a Scalar
+
+def randomizer_generate(msg, commitment_list):
+  # Generate a random byte buffer with the size of a serialized scalar
+  rng_randomizer = random_bytes(Ns)
+  signing_package_enc = encode_signing_package(commitment_list, msg)
+  randomizer_input = rng_randomizer || signing_package_enc
+  return HR(randomizer_input)
    
+                
    
+                
    Round One - Commitment 
    
+                    
    Roune One is exactly the same as specified 3. But for context, it involves these steps:
    
+                    
      
+                        
    • Each signer generates nonces and their corresponding public commitments. A nonce is a pair of Scalar values, and a commitment is a pair of Element values.
      • 
+                        
    • The nonces are stored locally by the signer and kept private for use in the second round.
      • 
+                        
    • The commitments are sent to the Coordinator.
      • 
+                    
    
+                
    
+                
    Round Two - Signature Share Generation 
    
+                    
    In Round Two, the Coordinator generates a random scalar randomizer by calling randomizer_generate and sends it to each signer, over a confidential and authenticated channel, along with the message and the set of signing commitments. (Note that this differs from regular FROST which just requires an authenticated channel.)
    
+                    
    In Zcash, the message that needs to be signed is actually the SIGHASH transaction hash, which does not convey enough information for the signers to decide if they want to authorize the transaction or not. Therefore, in practice, more data is needed to be sent (over the same encrypted, authenticated channel) from the Coordinator to the signers, possibly the transaction itself, openings of value commitments, decryption of note ciphertexts, etc.; and the signers MUST check that the given SIGHASH matches the data sent from the Coordinator, or compute the SIGHASH themselves from that data. However, the specific mechanism for that process is outside the scope of this ZIP.
    
+                    
    The randomized sign function is defined as the regular FROST sign function, but with its inputs modified relative to the randomizer as following:
    
+                    
      
+                        
    • sk_i = sk_i + randomizer
      • 
+                        
    • group_public_key = group_public_key + G.ScalarBaseMult(randomizer)
      • 
+                    
    
+                
    
+                
    Signature Share Verification and Aggregation 
    
+                    
    The randomized aggregate function is defined as the regular FROST aggregate function, but with its inputs modified relative to the randomizer as following:
    
+                    
      
+                        
    • group_public_key = group_public_key + G.ScalarBaseMult(randomizer)
      • 
+                    
    
+                    
    The randomized verify_signature_share function is defined as the regular FROST verify_signature_share function, but with its inputs modified relative to the randomizer as following:
    
+                    
      
+                        
    • PK_i = PK_i + G.ScalarBaseMult(randomizer)
      • 
+                        
    • group_public_key = group_public_key + G.ScalarBaseMult(randomizer)
      • 
+                    
    
+                
    
+            
    
+            
    Ciphersuites 
    
+                
    FROST(Jubjub, BLAKE2b-512) 
    
+                    
    This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function H meant to produce signatures indistinguishable from RedJubjub Sapling Spend Authorization Signatures as specified in 13.
    
+                    
      
+                        
    • Group: Jubjub 15 with base point
+                            \(\mathcal{G}^{\mathsf{Sapling}}\)
+                         as defined in 13.
+                            
        
+                                
      • Order:
+                                    \(r_\mathbb{J}\)
+                                 as defined in 15.
        • 
+                                
      • Identity: as defined in 15.
        • 
+                                
      • RandomScalar(): Implemented by returning a uniformly random Scalar in the range [0, G.Order() - 1]. Refer to {{frost-randomscalar}} for implementation guidance.
        • 
+                                
      • SerializeElement(P): Implemented as
+                                    \(\mathsf{repr}_\mathbb{J}(P)\)
+                                 as defined in 15
        • 
+                                
      • DeserializeElement(P): Implemented as
+                                    \(\mathsf{abst}_\mathbb{J}(P)\)
+                                 as defined in 15, returning an error if
+                                    \(\bot\)
+                                 is returned. Additionally, this function validates that the resulting element is not the group identity element, returning an error if the check fails.
        • 
+                                
      • SerializeScalar: Implemented by outputting the little-endian 32-byte encoding of the Scalar value.
        • 
+                                
      • DeserializeScalar: Implemented by attempting to deserialize a Scalar from a little-endian 32-byte string. This function can fail if the input does not represent a Scalar in the range [0, G.Order() - 1].
        • 
+                            
      
+                        
      • 
+                        
    • Hash (H): BLAKE2b-512 1 (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64.
+                            
        
+                                
      • H1(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubR", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order().
        • 
+                                
      • H2(m): Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order(). (This is equivalent to
+                                    \(\mathsf{H}^\circledast(m)\)
+                                , as defined by the
+                                    \(\mathsf{RedJubjub}\)
+                                 scheme instantiated in 12.)
        • 
+                                
      • H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order().
        • 
+                                
      • H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubM", m).
        • 
+                                
      • H5(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubC", m).
        • 
+                                
      • HR(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubA", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order().
        • 
+                            
      
+                        
      • 
+                    
    
+                    
    Signature verification is as specified in 13 for RedJubjub.
    
+                
    
+                
    FROST(Pallas, BLAKE2b-512) 
    
+                    
    This ciphersuite uses Pallas for the Group and BLAKE2b-512 for the Hash function H meant to produce signatures indistinguishable from RedPallas Orchard Spend Authorization Signatures as specified in 13.
    
+                    
      
+                        
    • Group: Pallas 16 with base point
+                            \(\mathcal{G}^{\mathsf{Orchard}}\)
+                         as defined in 13.
+                            
        
+                                
      • Order:
+                                    \(r_\mathbb{P}\)
+                                 as defined in 16.
        • 
+                                
      • Identity: as defined in 16.
        • 
+                                
      • RandomScalar(): Implemented by returning a uniformly random Scalar in the range [0, G.Order() - 1]. Refer to {{frost-randomscalar}} for implementation guidance.
        • 
+                                
      • SerializeElement(P): Implemented as
+                                    \(\mathsf{repr}_\mathbb{P}(P)\)
+                                 as defined in 16.
        • 
+                                
      • DeserializeElement(P): Implemented as
+                                    \(\mathsf{abst}_\mathbb{P}(P)\)
+                                 as defined in 16, failing if
+                                    \(\bot\)
+                                 is returned. Additionally, this function validates that the resulting element is not the group identity element, returning an error if the check fails.
        • 
+                                
      • SerializeScalar: Implemented by outputting the little-endian 32-byte encoding of the Scalar value.
        • 
+                                
      • DeserializeScalar: Implemented by attempting to deserialize a Scalar from a little-endian 32-byte string. This function can fail if the input does not represent a Scalar in the range [0, G.Order() - 1].
        • 
+                            
      
+                        
      • 
+                        
    • Hash (H): BLAKE2b-512 1 (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64.
+                            
        
+                                
      • H1(m): Implemented by computing BLAKE2b-512("FROST_RedPallasR", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order().
        • 
+                                
      • H2(m): Implemented by computing BLAKE2b-512("Zcash_RedPallasH", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order(). (This is equivalent to
+                                    \(\mathsf{H}^\circledast(m)\)
+                                , as defined by the
+                                    \(\mathsf{RedPallas}\)
+                                 scheme instantiated in 12.)
        • 
+                                
      • H3(m): Implemented by computing BLAKE2b-512("FROST_RedPallasN", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order().
        • 
+                                
      • H4(m): Implemented by computing BLAKE2b-512("FROST_RedPallasM", m).
        • 
+                                
      • H5(m): Implemented by computing BLAKE2b-512("FROST_RedPallasC", m).
        • 
+                                
      • HR(m): Implemented by computing BLAKE2b-512("FROST_RedPallasA", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo G.Order().
        • 
+                            
      
+                        
      • 
+                    
    
+                    
    Signature verification is as specified in 13 for RedPallas.
    
+                
    
+            
    
+        
    
+        
    Rationale 
    
+            
    FROST is a threshold Schnorr signature scheme, and Zcash Spend Authorization are also Schnorr signatures, which allows the usage of FROST with Zcash. However, since there is no widespread standard for Schnorr signatures, it must be ensured that the signatures generated by the FROST variant specified in this ZIP can be verified successfully by a Zcash implementation following its specification. In practice this entails making sure that the generated signature can be verified by the
+                \(\mathsf{RedDSA.Validate}\)
+             function specified in 12:
    
+            
      
+                
    • The FROST signature, when split into R and S in the first step of
+                    \(\mathsf{RedDSA.Validate}\)
+                , must yield the values expected by the function. This is ensured by defining SerializeElement and SerializeScalar in each ciphersuite to yield those values.
      • 
+                
    • The challenge c used during FROST signing must be equal to the challenge c computed during
+                    \(\mathsf{RedDSA.Validate}\)
+                . This requires defining the ciphersuite H2 function as the
+                    \(\mathsf{H}^\circledast(m)\)
+                 Zcash function in the ciphersuites, and making sure its input will be the same. Fortunately FROST and Zcash use the same input order (R, public key, message) so we just need to make sure that SerializeElement (used to compute the encoded public key before passing to the hash function) matches what
+                    \(\mathsf{RedDSA.Validate}\)
+                 expects; which is possible since both R and vk (the public key) are encoded in the same way as in Zcash.
      • 
+                
    • Note that r (and thus R) will not be generated as specified in RedDSA.Sign. This is not an issue however, since with Schnorr signatures it does not matter for the verifier how the r value was chosen, it just needs to be generated uniformly at random, which is true for FROST.
      • 
+                
    • The above will ensure that the verification equation in
+                    \(\mathsf{RedDSA.Validate}\)
+                 will pass, since FROST ensures the exact same equation will be valid as described in 8.
      • 
+            
    
+            
    The second step is adding the re-randomization functionality so that each FROST signing generates a re-randomized signature:
    
+            
      
+                
    • Anywhere the public key is used, the randomized public key must be used instead. This is exactly what is done in the functions defined above.
      • 
+                
    • The re-randomization must be done in each signature share generation, such that the aggregated signature must be valid under verification with the randomized public key. The R value from the signature is not influenced by the randomizer so we just need to focus on the z value (using FROST notation). Recall that z must equal to r + (c * sk), and that each signature share is z_i = (hiding_nonce + (binding_nonce * binding_factor)) +
+(lambda_i * c * sk_i). The first terms are not influenced by the randomizer so we can only look into the second term of each top-level addition, i.e. c
+* sk must be equal to sum(lambda_i * c * sk_i) for each participant i. Under re-randomization these become c * (sk + randomizer) (see
+                    \(\mathsf{RedDSA.RandomizedPrivate}\)
+                , which refers to the randomizer as
+                    \(\alpha\)
+                ) and sum(lambda_i * c * (sk_i + randomizer)). The latter can be rewritten as c * (sum(lambda_i * sk_i) + randomizer *
+sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Shamir secret sharing mechanism used by FROST, and since sum(lambda_i) == 1 18, we arrive at c * (sk + randomizer) as required.
      • 
+                
    • The re-randomization procedure must be exactly the same as in 12 to ensure that re-randomized keys are uniformly distributed and signatures are unlinkable. This is also true; observe that randomizer_generate generates randomizer uniformly at random as required by
+                    \(\mathsf{RedDSA.GenRandom}\)
+                ; and signature generation is compatible with
+                    \(\mathsf{RedDSA.RandomizedPrivate}\)
+                ,
+                    \(\mathsf{RedDSA.RandomizedPublic}\)
+                ,
+                    \(\mathsf{RedDSA.Sign}\)
+                 and
+                    \(\mathsf{RedDSA.Validate}\)
+                 as explained in the previous item.
      • 
+            
    
+            
    The security of Re-Randomized FROST with respect to the security assumptions of regular FROST is shown in 4.
    
+        
    
+        
    Reference implementation 
    
+            
    The reddsa crate 17 contains a re-randomized FROST implementation of both ciphersuites.
    
+        
    
+        
    References 
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    1BLAKE2: simpler, smaller, fast as MD5
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    2RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    3RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    4Re-Randomized FROST
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    5RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 5: Two-Round FROST Signing Protocol
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    6RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 7.3: Removing the Coordinator Role
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    7RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 3.1: Prime-Order Group
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    8RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix B: Schnorr Signature Generation and Verification for Prime-Order Groups
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    9RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix B: Trusted Dealer Key Generation
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    10RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix C: Random Scalar Generation
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    11The ZF FROST Book, Serialization Format
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    12Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    13Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard)
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    14Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.15: Spend Authorization Signature (Sapling and Orchard)
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    15Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.3: Jubjub
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    16Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    17reddsa
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    18Prove that the sum of the Lagrange (interpolation) coefficients is equal to 1
    
+        
    
+    
    
+
+
\ No newline at end of file
diff --git a/zip-0313.html b/rendered/zip-0313.html
similarity index 99%
rename from zip-0313.html
rename to rendered/zip-0313.html
index f992628cc..d5aead657 100644
--- a/zip-0313.html
+++ b/rendered/zip-0313.html
@@ -9,7 +9,7 @@
         
    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 @@
             
    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 z_* RPC APIs. It is planned to extend this to all transactions in a future version 7.
    
         
    
         
    Acknowledgements 
    
-            
    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.
    
+            
    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.
    
         
    
         
    References 
    
             
diff --git a/zip-0314.html b/rendered/zip-0314.html
similarity index 100%
rename from zip-0314.html
rename to rendered/zip-0314.html
diff --git a/rendered/zip-0315.html b/rendered/zip-0315.html
new file mode 100644
index 000000000..9ae30b3d9
--- /dev/null
+++ b/rendered/zip-0315.html
@@ -0,0 +1,396 @@
+
+
+
+    ZIP 315: Best Practices for Wallet Implementations
+    
+
+
+    
    
+        
    ZIP: 315
+Title: Best Practices for Wallet Implementations
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+        Jack Grigg <jack@electriccoin.co>
+        Kris Nuttycombe <kris@electriccoin.co>
+Credits: Francisco Gindre
+Status: Draft
+Category: Wallet
+Discussions-To: <https://github.com/zcash/zips/issues/447>
+Pull-Request: <https://github.com/zcash/zips/pull/607>
    
+        
    Terminology 
    
+            
    The key words "MUST", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
+            
    The terms below are to be interpreted as follows:
    
+            
    
+                
    Auto-shielding
    
+                
    The process of automatically transferring transparent funds to the most recent shielded pool on receipt.
    
+                
    Auto-migration
    
+                
    The process of automatically transferring shielded funds from older pools to the most preferred (usually the most recent) pool on receipt.
    
+                
    Opportunistic migration
    
+                
    The process of transferring previously received shielded funds from older pools to the most preferred (usually the most recent) pool as part of a user-initiated transaction.
    
+                
    Transaction output (TXO)
    
+                
    An output (transparent coin or shielded note) of a transaction on the consensus block chain or in the mempool visible to a wallet.
    
+            
    
+            
    TODO: Add informal definitions of: * known-spendable and confirmed-spendable TXOs; * trusted and untrusted TXOs.
    
+            
    These should forward-reference the specification section with the formal definitions.
    
+        
    
+        
    Motivation 
    
+            
    Zcash wallets have to serve two purposes as a user agent:
    
+            
      
+                
    • to manage the economic actions dictated by the user;
      • 
+                
    • to manage the privacy implications of these actions.
      • 
+            
    
+            
    The goal of this ZIP is to document security and privacy best practices when handling funds and transactions as the user's agent. These best practices are intended to provide as much privacy as is feasible by default, while still enabling the user's desired transactions to occur, and exposing any privacy implications to the user so that they have enough information to assess the consequences of their economic actions.
    
+            
    This ZIP covers best practices for:
    
+            
      
+                
    • what information to display to the user about transactions and balances;
      • 
+                
    • how to handle interactions between the ZIP 32 2 key tree and Unified Addresses 4;
      • 
+                
    • when to use external or internal keys/addresses;
      • 
+                
    • sharing addresses and viewing keys;
      • 
+                
    • sending and receiving funds (including fee selection);
      • 
+                
    • migrating funds between pools.
      • 
+            
    
+        
    
+        
    Requirements 
    
+            
+            
    Prompt accessibility of funds 
    
+                
    Wallets need to take account of two main concerns with respect to accessibility of funds:
    
+                
      
+                    
    • enabling funds to be spent as quickly as possible to reduce latency;
      • 
+                    
    • ensuring that the confirmed-spendable balance is not overestimated, and so can be trusted by the user.
      • 
+                
    
+                
    These concerns affect the way that balances should be computed, which notes are selected for spending, and how the wallet should ensure that sufficient notes are available to cover multiple spends within a short period.
    
+                
    To support this we define two kinds of TXOs:
    
+                
      
+                    
    • A trusted TXO is a TXO received from a party where the wallet trusts that it will remain mined in its original transaction, such as TXOs created by the wallet's internal TXO handling.
      • 
+                    
    • An untrusted TXO is a TXO received by the wallet that is not trusted.
      • 
+                
    
+                
    Wallets can then require that untrusted TXOs need more confirmations before they become confirmed-spendable than trusted TXOs. This provides an improved trade-off between latency on the one hand, and reliability and safety on the other.
    
+            
    
+        
    
+        
    Specification 
    
+            
    Long-term storage of funds 
    
+                
    It is RECOMMENDED that wallets only hold funds as shielded in the long term; that is, if a wallet supports receiving transparent funds (or supports importing a seed from another wallet that might have done so), then it SHOULD auto-shield such funds by default.
    
+                
    A shielding transaction is always linked to the transparent addresses it spends from. This can cause undesirable information leaks:
    
+                
      
+                    
    1. if there are multiple transparent addresses, they will be linked to each other;
      2. 
+                    
    2. a link between the input transparent address(es) and the payment will be visible to the recipient(s), or to any other holder of an Incoming Viewing Key for the destination address(es).
      3. 
+                
    
+                
    Despite the fact that it is not possible to achieve strong privacy guarantees from any use of transparent addresses, it is undesirable to reveal this additional information. In particular, issue b) motivates ruling out the use of "opportunistic shielding", i.e. shielding previously received transparent funds as part of a user-initiated transaction.
    
+                
    Wallets SHOULD NOT auto-shield from multiple transparent addresses in the same transaction, and SHOULD NOT use opportunistic shielding.
    
+                
    Following all of the recommendations in this section improves both collective privacy and the user's individual privacy, by maximizing the size of the note anonymity set over time and minimizing the potential linkage of shielding transactions to other transactions.
    
+                
    The remainder of this specification assumes a wallet that follows all of these recommendations, except where explicitly noted.
    
+                
    A wallet MAY allow users to disable auto-shielding, auto-migration, and/or opportunistic migration. If it does so, this need not be via three independent settings.
    
+                
    Automatic shielding and automatic/opportunistic migration SHOULD NOT be applied to inputs where the cost of shielding or migrating them will exceed their economic value. If these transactions are paying the ZIP 317 conventional fee 5, that will be the case if the amount of the UTXO to be shielded/migrated exceeds the marginal fee, and cannot be accommodated by an input that would be present in any case due to padding of the number of inputs from a given shielded pool.
    
+            
    
+            
    Trusted and untrusted TXOs 
    
+                
    A wallet SHOULD treat received TXOs that are outputs of transactions created by the same wallet, as trusted TXOs. Wallets MAY enable users to mark specific external transactions as trusted, allowing their received TXOs also to be classified as trusted TXOs.
    
+                
    A wallet SHOULD have a policy that is clearly communicated to the user for the number of confirmations needed to spend untrusted and trusted TXOs respectively. The following confirmation policy is RECOMMENDED:
    
+                
      
+                    
    • 10 confirmations, for untrusted TXOs;
      • 
+                    
    • 3 confirmations, for trusted TXOs.
      • 
+                
    
+                
    Rationale for the given numbers of confirmations 
    
+                    
    The rationale for choosing three confirmations for trusted TXOs is that anecdotally, reorgs are usually less than three blocks.
    
+                    
    The consequences of attempting to spend a trusted TXO may be less severe in the case of a rollback than the consequences of attempting to spend an untrusted TXO. The value received from a trusted TXO should always be recoverable, whereas recovering value received from an untrusted TXO may require the user to request that funds are re-sent.
    
+                
    
+            
    
+            
    Categories of TXOs according to spendability 
    
+                
    A TXO is known-spendable, relative to a given block chain and wallet state, if and only if all of the following are true in that state:
    
+                
      
+                    
    • the TXO is unspent at the wallet's view of the chain tip, and that view is reasonably up-to-date;
+                        
      TODO: consider undoing the up-to-date part, as when combined with the definition of balance below, it causes wallet balance to drop to zero in the short window between opening and updating the wallet's chain tip view.
      
+                    
      • 
+                    
    • the TXO is not committed to be spent in another transaction created by this wallet; and
      • 
+                    
    • the wallet has the TXO's spending key (for whatever protocol the TXO uses).
      • 
+                
    
+                
    A TXO is confirmed-spendable, relative to a given block chain and wallet state, if and only if all of the following are true in that state:
    
+                
      
+                    
    • the wallet is synchronized; and
      • 
+                    
    • the TXO is known-spendable; and
      • 
+                    
    • either auto-shielding is not active or the TXO is shielded; and
      • 
+                    
    • auto-migration from whatever protocol the TXO uses is not active; and
      • 
+                    
    • the TXO is trusted and has at least the required confirmations for trusted TXOs, or it is untrusted and has at least the required confirmations for untrusted TXOs.
      • 
+                
    
+                
    A TXO is unconfirmed-spendable, relative to a given block chain and wallet state, if and only if the TXO is known-spendable but is not confirmed-spendable in that state.
    
+                
    A TXO is watch-only if and only if the wallet has its full viewing key (or address in the case of a transparent TXO) but not its spending key.
    
+                
    A wallet MUST NOT attempt to spend a TXO in a user-initiated transaction that is not confirmed-spendable.
    
+                
    Open question: what should be specified about which TXOs can be spent in non-user-initiated transactions?
    
+                
    Note: the definition of a TXO includes outputs in mempool transactions that are unconflicted from the perspective of the wallet.
    
+            
    
+            
    Reporting of balances 
    
+                
    Wallets SHOULD report:
    
+                
      
+                    
    • Confirmed-spendable balance.
      • 
+                    
    • Pending balance, or total balance.
      • 
+                
    
+                
    These are calculated as follows:
    
+                
      
+                    
    • The confirmed-spendable balance is the sum of values of confirmed-spendable TXOs.
      • 
+                    
    • The pending balance is the sum of values of unconfirmed-spendable TXOs.
      • 
+                    
    • The total balance is the confirmed-spendable balance plus the pending balance.
      • 
+                
    
+                
    Note: the definition of "confirmed-spendable" above ensures that:
    
+                
      
+                    
    • if auto-shielding is enabled, transparent funds will be reported in the pending or total balance, but not in the confirmed-spendable balance;
      • 
+                    
    • if the wallet has not synchronized at least the nullifier set to the chain tip, the confirmed-spendable balance will be zero.
      • 
+                
    
+                
    If auto-shielding is disabled, the wallet MAY report shielded and transparent balances separately. If it does so, it MUST make clear whether each reported balance corresponds to a confirmed-spendable, pending, or total subset of funds.
    
+                
    Rationale for reporting of balances 
    
+                    
    If auto-shielding is disabled, then separate shielded and transparent balances can constitute useful information. If auto-shielding is enabled then the wallet can and will automatically spend transparent TXOs in order to shield them, and so transparent TXOs need to be presented as pending, not as part of the balance spendable by the user.
    
+                    
    Potentially, for expert users, separate shielded balances per pool could also be useful.
    
+                    
    Open question: Does the specification of balance reporting give the user sufficient visibility into the operation of auto-shielding and pool migration/usage?
    
+                
    
+            
    
+            
    Reporting of transactions 
    
+                
    If a transaction includes watch-only received TXOs, its watch-only incoming balance MUST be reported separately to any potentially known-spendable balance.
    
+                
    Incoming transactions 
    
+                    
    A transaction is incoming if it contains unconfirmed-spendable TXOs. Incoming transactions SHOULD be reported with their number of confirmations and their balances as described in Reporting of balances.
    
+                
    
+                
    Sent transactions 
    
+                    
    A transaction is sent if it was either:
    
+                    
      
+                        
    • created by the wallet, or
      • 
+                        
    • detected by using the wallet's outgoing viewing keys to decrypt Sapling or Orchard outputs, or
      • 
+                        
    • detected as spending a note that was at some time held by the wallet by recognizing that note's nullifier, or
      • 
+                        
    • detected as spending a transparent TXO associated with one of the wallet's addresses (including watch-only addresses).
      • 
+                    
    
+                    
    Sent transactions SHOULD be reported with their number of confirmations, an estimate of how long until they expire (if they are unmined and have an expiry height), and their balances as described in Reporting of balances.
    
+                
    
+            
    
+            
    Transaction creation 
    
+                
+                
    Linkability of transactions or addresses 
    
+                    
    Motivation for choices reducing linkability 
    
+                        
    We want to support creating unlinkable addresses, in order that a user can give different addresses to different counterparties, in such a way that the counterparties (even if they collude) cannot tell that the addresses were provided by the same or distinct users.
    
+                        
    If multiple UTXOs are received at the same transparent address, it is safe to shield them all in the same transaction, because that is not leaking additional information.
    
+                        
    UTXOs received on different transparent receivers SHOULD NOT be shielded in the same transaction. Ideally, when they are shielded in separate transactions, this should be done in such a way that the timing of those transactions is not linkable.
    
+                        
    TODO: move this. Daira-Emma thinks that if we only document leakage rather than explicitly say in the specification of how to construct transactions how to mitigate it, then implementors will ignore it.
    
+                        
    When spending transparent UTXOs, they SHOULD only be sent to an internal shielded receiver belonging to the wallet, except when they are generated and spent ephemerally as part of a ZIP 320 transfer 6.
    
+                        
    A wallet MUST NOT send funds to a transparent address unless all of the source funds come from shielded pools, and this SHOULD be a single shielded pool.
    
+                        
    We want to minimize pool crossing.
    
+                    
    
+                
    
+                
    Anchor selection 
    
+                    
    A wallet SHOULD choose an anchor a number of blocks back from the head of the chain equal to the trusted confirmation depth. That is, if the current block is at height H, the anchor SHOULD reflect the final treestate of the block at height H-3.
    
+                    
    TODO: Define a parameter for this depth, and then RECOMMEND a value of 3.
    
+                
    
+                
    Rationale for anchor selection 
    
+                    
      
+                        
    • If the chain rolls back past the block at which the anchor is chosen, then the anchor and the transaction will be invalidated. This is undesirable both for reliability, and because the nullifiers of spent shielded notes will have been revealed, linking this transaction to any future transactions that spend those notes.
+                            
      TODO: Reword this given the proposed note management mitigation below.
      
+                        
      • 
+                        
    • On the other hand, it is undesirable to choose an anchor too many blocks back, because that prevents more recently received shielded notes from being spent.
      • 
+                        
    • Using a fixed anchor depth (as opposed to a different depth depending on whether or not we are spending trusted shielded notes) avoids leaking information about whether or not the shielded notes we spent were trusted.
      • 
+                    
    
+                
    
+                
    Note selection 
    
+                    
    TODO: recommend that when nullifiers are revealed in a transaction that is then invalidated (or revealed in some other detectable way), they SHOULD be used in a note management tx to avoid linking the invalidated tx with some arbitrary future tx. Provided that there are no transparent outputs leaving this wallet's control, the same arities and transparent outputs SHOULD be preserved, which also avoids revealing whether the user changed their mind about whether to send the original semantic transaction.
    
+                
    
+                
    Expiration height 
    
+                    
    A wallet SHOULD create transactions using the default expiration height of 40 blocks from the current height, as specified in 3.
    
+                
    
+                
    Open question 
    
+                    
    How should wallet developers time transactions to avoid linkability?
    
+                    
      
+                        
    • when we roll addresses with transparent components, we have to consider how that could allow linking of shielded components
      • 
+                    
    
+                    
    TODO: dusting attack mitigation
    
+                
    
+            
    
+            
    Network-layer privacy 
    
+            
    
+            
    Viewing keys 
    
+                
    What they are supposed to reveal; see ZIP 310 for Sapling (needs updating for Orchard). https://github.com/zcash/zips/issues/606
    
+            
    
+            
    Allowed transfers 
    
+                
      
+                    
    • Sprout -> transparent or Sapling
      • 
+                    
    • Sapling -> transparent or Sapling or Orchard
      • 
+                    
    • Orchard -> transparent or Sapling or Orchard
      • 
+                    
    • if auto-shielding is off: * transparent -> transparent or Sapling or Orchard
      • 
+                    
    • if auto-shielding is on: * transparent -> internal Orchard or Sapling
      • 
+                
    
+                
    Note: wallets MAY further restrict the set of transfers they perform.
    
+            
    
+            
    Auto-shielding 
    
+                
    Wallets SHOULD NOT spend funds from a transparent address to an external address, unless the user gives explicit consent for this on a per-transaction basis.
    
+                
    TODO: Reword this to define the source transparent address as any transparent address (external, internal, or ephemeral), except in the case of ephemeral as allowed for implementing ZIP 320.
    
+                
    In order to support this policy, wallets SHOULD implement a system of auto-shielding with the following characteristics:
    
+                
    If auto-shielding functionality is available in a wallet, then users MUST be able to explicitly consent to one of the following possibilities:
    
+                
      
+                    
    • auto-shielding is always on;
      • 
+                    
    • auto-shielding is always off;
      • 
+                    
    • the user specifies a policy...
      • 
+                
    
+                
    Auto-shielding MUST be one of:
    
+                
      
+                    
    • "must opt in or out" (zcashd will do this -- i.e. refuse to start unless the option is configured), or
      • 
+                    
    • always on.
      • 
+                
    
+            
    
+            
    Auto-migration 
    
+            
    
+            
    Information leakage for transfers between pools 
    
+                
    If no auto-migration, if you can satisfy a transfer request to Sapling from your Sapling funds, do so.
    
+                
    The user's consent is needed to reveal amounts publically (as opposed to revealing them to the holder of a viewing key authorized to see that amount). Therefore, there should be per-transaction opt-in for any transfer that publically reveals amounts on chain.
    
+                
      
+                    
    • there may be a compatibility issue for amount-revealing cross-pool txns that were previously allowed without opt-in
      • 
+                
    
+                
    Wallets MUST NOT automatically combine funds across pools to satisfy a transfer (since that could reveal the total funds the user holds in some pool).
    
+                
    In order to maintain the integrity of IVK guarantees, wallets should not generate unified addresses that contain internal receivers, nor expose internal receivers (such as those used for auto-shielding and change outputs) in any way.
    
+                
    Open questions:
    
+                
      
+                    
    • should there be an auto-migration option from Sapling to Orchard?
      • 
+                
    
+                
    str4d notes 
    
+                    
    If we want to have both automatic and opportunistic shielding, and keep the two indistinguishable, then we can't auto-shield when the transparent balance reaches some threshold (otherwise opportunistic would either never be used, or would be identifiable when it uses the balance below the threshold).
    
+                    
    Instead, a proposition: we define a distribution of "time since last payment to the address" from which we sample the time at which the auto-shielding transaction will be created. This distribution is weighted by the balance in the address, so as more funds accrue, the auto-shielding transaction is more likely to be created.
    
+                    
      
+                        
    • It ensures that all funds will eventually be auto-shielded, while preventing fee-dusting attacks (where dust is sent in order to repeatedly consume fees from the wallet), as the auto-shielding transaction is not directly triggered by payment receipt.
      • 
+                        
    • If the user makes a shielding transaction in the meantime, we opportunistically shield, without it being clearly not an auto-shielding transaction.
      • 
+                        
    • If a wallet is offline for a long time, then it would likely auto-shield as soon as it finishes syncing. This maybe isn't enough to reveal that the wallet came online, except that it _might_ result in auto-shielding transactions for multiple transparent addresses being created at the same time. So we might want to special-case this?
      • 
+                    
    
+                    
    Properties we want from auto-shielding:
    
+                    
      
+                        
    • Auto-shielding transactions MUST NOT shield from multiple transparent receivers in the same transaction. - Doing so would trivially link diversified UAs containing transparent receivers.
      • 
+                    
    
+                    
    Properties we want from auto-migration:
    
+                    
      
+                        
    • Receipt of a shielded payment MUST NOT trigger any on-chain behaviour (as that reveals transaction linkability).
      • 
+                    
    
+                    
    Both auto-shielding and auto-migration are time-triggered actions, not receipt-triggered actions. An auto-shielding or auto-migration transaction MUST NOT be created as a direct result of a payment being received.
    
+                    
    Both of these are opportunistic: if the user's wallet is making a transaction in which one of these actions would occur anyway, then the wallet takes the opportunity to migrate as much as it would do if it were generating an autoshielding transaction. This both saves on a transaction, and removes the need for any kind of transparent change address within UAs.
    
+                    
    TODO: what pool should change go to?
    
+                    
      
+                        
    • Proposal: the most recent pool already involved in the transaction.
      • 
+                    
    
+                
    
+            
    
+            
    Wallet Recovery 
    
+                
    In the case where we are recovering a wallet from a backed-up mnemonic phrase, and not from a wallet.dat, we don't have enough information to figure out what receiver types the user originally used when deriving each UA under an account. We have a similar issue if someone exports a UFVK, derives an address from it, and has a payment sent to the address: zcashd will detect the payment, but has no way to figure out what address it should display in the UI. A wallet could store this information in the memo field of change outputs, but that adds a bunch of coordination to the problem, and assumes ongoing on-chain state storage.
    
+                
      
+                    
    • If the receiver matches an address that the wallet knows was derived via z_getaddressforaccount, show that UA as expected (matching the receiver types the user selected).
      • 
+                    
    • If the receiver matches a UFVK in the wallet, and we are looking it up because we detected a received note in some block, show the UA with the default receiver types that zcashd was using as of that block height (ideally the earliest block height we detect), and cache this for future usage.
      • 
+                    
    • For zcashd's current policy of "best and second-best shielded pools, plus transparent pool", that would mean Orchard, Sapling, and transparent for current block heights.
      • 
+                    
    • For each release of a wallet, the wallet should specify a set of receiver types and an associated range of block heights during which the wallet will, by default, generate unified addresses using that set of receiver types.
      • 
+                    
    • For zcashd we know how the policy evolves because each zcashd release has an approximate release height and End-of-Service height that defines the window.
      • 
+                    
    • Subsequent releases of a wallet SHOULD NOT retroactively change their policies for previously defined block height ranges.
      • 
+                    
    • If the receiver type for a note received at a given time is not a member of the set of receiver types expected for the range of block heights, the policy corresponding to the nearest block height range that includes that receiver type SHOULD be used.
      • 
+                    
    • If the receiver matches a UFVK in the wallet, and we have no information about when this receiver may have been first used, show the UA corresponding to the most recent receiver types policy that includes the receiver's type.
      • 
+                    
    • As part of this, we're also going to change the "Sapling receiver to UfvkId" logic to trial-decrypt after trying internal map, so that we will detect all receivers linked to UFVKs in the wallet, not just receivers in addresses generated via z_getaddressforaccount. The internal map lookup is then just an optimisation (and a future refactor to have Orchard do the same is possible, but for now we will only trial-decrypt so we don't need to refactor to access the Rust wallet). TODO: express this in a less zcashd-specific way.
      • 
+                
    
+                
    TODO: Mention recommendations (not requirements) of receiver types based on settled ('accepted') network upgrades, as defined in §3.3 of the Zcash Protocol Specification, at the time of the release of the wallet.
    
+                
    TODO: Rationale subsection explaining why earliest block height at detection and the rules/recommendations in place at that block height are preferred over showing different UAs at different heights
    
+            
    
+        
    
+        
    References 
    
+            
    
+                
+                    
+                        
+                        
+                    
+                
+            
    1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    2ZIP 32: Shielded Hierarchical Deterministic Wallets
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    3ZIP 203: Transaction Expiry
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    4ZIP 316: Unified Addresses and Unified Viewing Keys
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    5ZIP 317: Proportional Transfer Fee Mechanism
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    6ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses
    
+        
    
+    
    
+
+
\ No newline at end of file
diff --git a/zip-0316.html b/rendered/zip-0316.html
similarity index 75%
rename from zip-0316.html
rename to rendered/zip-0316.html
index 6cc68afa1..7dae95159 100644
--- a/zip-0316.html
+++ b/rendered/zip-0316.html
@@ -9,22 +9,22 @@
     
    
         
    ZIP: 316
 Title: Unified Addresses and Unified Viewing Keys
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Nathan Wilcox <nathan@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
-        Greg Pfeil <greg@electriccoin.co>
+Original-Authors: Greg Pfeil
+                  Ying Tong Lai
 Credits: Taylor Hornby
-         Ying Tong Lai
          Stephen Smith
-Status: Final
+Status: Revision 0: Final, Revision 1: Proposed
 Category: Standards / RPC / Wallet
 Created: 2021-04-07
 License: MIT
 Discussions-To: <https://github.com/zcash/zips/issues/482>
    
         
    Terminology 
    
-            
    The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
+            
    The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
             
    The terms below are to be interpreted as follows:
    
             
    
                 
    Recipient
    
@@ -34,7 +34,7 @@
                 
    Consumer
    
                 
    A wallet or other software that can make use of an Address or Viewing Key that it is given.
    
                 
    Sender
    
-                
    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.
    
+                
    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.
    
                 
    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
    
@@ -67,6 +67,8 @@
                 
    An encoding of a UA/UVK as a QR code, intended for display and transfer by Zcash end-users in situations where usability advantages of a 2D bar code may be relevant.
    
                 
    Address Encoding
    
                 
    The externally visible encoding of an Address (e.g. as a string of characters or a QR code).
    
+                
    Unix Epoch Time
    
+                
    An integer representing a UTC time in seconds relative to the Unix Epoch of 1970-01-01T00:00:00Z.
    
             
    
             
    Notation for sequences, conversions, and arithmetic operations follows the Zcash protocol specification 3.
    
         
    
@@ -80,8 +82,8 @@
                 
  • Sprout Addresses
    • 
                 
  • Sapling Addresses
    • 
             
-            
    Each of these has its own Address Encodings, as a string and as a QR code. (Since the QR code is derivable from the string encoding as described in 8, for many purposes it suffices to consider the string encoding.)
    
-            
    The Orchard proposal 24 adds a new Address type, Orchard Addresses.
    
+            
    Each of these has its own Address Encodings, as a string and as a QR code. (Since the QR code is derivable from the string encoding as described in 9, for many purposes it suffices to consider the string encoding.)
    
+            
    The Orchard proposal 26 adds a new Address type, Orchard Addresses.
    
             
    The difficulty with defining new Address Encodings for each Address type, is that end-users are forced to be aware of the various types, and in particular which types are supported by a given Consumer or Recipient. In order to make sure that transfers are completed successfully, users may be forced to explicitly generate Addresses of different types and re-distribute encodings of them, which adds significant friction and cognitive overhead to understanding and using Zcash.
    
             
    The goals for a Unified Address standard are as follows:
    
             
      
@@ -101,7 +103,7 @@
             
      Overview 
      
                 
      Unified Addresses specify multiple methods for payment to a Recipient's wallet. The Sender's wallet can then non-interactively select the method of payment.
      
                 
      Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending.
      
-                
      Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs 26 and similar schemes. Since Payment Requests encode addresses as alphanumeric strings, no change to ZIP 321 is required in order to use Unified Addresses in Payment Requests.
      
+                
      Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs 29 and similar schemes. Since Payment Requests encode addresses as alphanumeric strings, no change to ZIP 321 is required in order to use Unified Addresses in Payment Requests.
      
             
      
             
      Concepts 
      
                 
      Wallets follow a model Interaction Flow as follows:
      
@@ -121,21 +123,21 @@
                 
      When new Transport Protocols are introduced to the Zcash protocol after Unified Addresses are standardized, those should introduce new Receiver Types but not different Address types outside of the UA standard. There needs to be a compelling reason to deviate from the standard, since the benefits of UA come precisely from their applicability across all new protocol upgrades.
      
             
      
             
      Receivers 
      
-                
      Every wallet must properly parse encodings of a Unified Address or Unified Viewing Key containing unrecognized Items.
      
-                
      A wallet may process unrecognized Items by indicating to the user their presence or similar information for usability or diagnostic purposes.
      
+                
      Every wallet must properly parse encodings of a Unified Address or Unified Viewing Key containing unrecognised Items.
      
+                
      A wallet may process unrecognised Items by indicating to the user their presence or similar information for usability or diagnostic purposes.
      
             
      
             
      Transport Encoding 
      
                 
      The Unified String Encoding is “opaque” to human readers: it does not allow visual identification of which Receivers or Receiver Types are present.
      
                 
      The Unified String Encoding is resilient against typos, transcription errors, cut-and-paste errors, truncation, or other likely UX hazards.
      
                 
      There is a well-defined Unified QR 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 Unified QR Encoding and Unified String Encoding of a given UA/UVK in either direction.
      
-                
      The Unified String Encoding fits into ZIP-321 Payment URIs 26 and general URIs without introducing parse ambiguities.
      
+                
      The Unified String Encoding fits into ZIP-321 Payment URIs 29 and general URIs without introducing parse ambiguities.
      
                 
      The encoding must support sufficiently many Recipient Types to allow for reasonable future expansion.
      
-                
      The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them.
      
+                
      The encoding must allow all wallets to safely and correctly parse out unrecognised Receiver Types well enough to ignore them.
      
             
      
             
      Transfers 
      
                 
      When executing a Transfer the Sender selects a Receiver via a Selection process.
      
-                
      Given a valid UA, Selection must treat any unrecognized Item as though it were absent.
      
+                
      Given a valid UA, Selection must treat any unrecognised Item as though it were absent.
      
                 
        
                     
      • This property is crucial for forward compatibility to ensure users who upgrade to newer protocols / UAs don't lose the ability to smoothly interact with older wallets.
        • 
                     
      • This property is crucial for allowing Transparent-Only UA-Conformant wallets to interact with newer shielded wallets, removing a disincentive for adopting newer shielded wallets.
        • 
@@ -146,8 +148,8 @@
                 
        Unified Addresses and Unified Viewing Keys must be able to include Receivers and Viewing Keys of experimental types, possibly alongside non-experimental ones. These experimental Receivers or Viewing Keys must be used only by wallets whose users have explicitly opted into the corresponding experiment.
        
             
      
             
      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 2.
      
-                
      For a Transparent P2PKH Address that is derived according to BIP 32 27 and BIP 44 30, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.
      
+                
      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 2.
      
+                
      For a Transparent P2PKH Address that is derived according to BIP 32 30 and BIP 44 33, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.
      
                 
      A wallet should support deriving a UIVK from a UFVK, and a Unified Address from a UIVK.
      
             
      
             
      Open Issues and Known Concerns 
      
@@ -155,16 +157,43 @@
             
      
         
    
         
    Specification 
    
+            
    Revisions 
    
+                
      
+                    
    • Revision 0: The initial version of this specification.
      • 
+                
    
+                
+                
    A Revision 0 UA/UVK is distinguished from a Revision 1 UA/UVK by its Human-Readable Part, as follows.
    
+                
    Let prefix be:
    
+                
      
+                    
    • “u”, if this is a UA/UVK prior to Revision 1;
      • 
+                    
    • “ur”, if this is a UA/UVK from Revision 1 onward.
      • 
+                
    
+                
    The Human-Readable Parts (as defined in 36) of Unified Addresses are defined as:
    
+                
      
+                    
    • prefix, for Unified Addresses on Mainnet;
      • 
+                    
    • prefix || “test”, for Unified Addresses on Testnet.
      • 
+                
    
+                
    The Human-Readable Parts of Unified Viewing Keys are defined as:
    
+                
      
+                    
    • prefix || “ivk” for Unified Incoming Viewing Keys on Mainnet;
      • 
+                    
    • prefix || “ivktest” for Unified Incoming Viewing Keys on Testnet;
      • 
+                    
    • prefix || “view” for Unified Full Viewing Keys on Mainnet;
      • 
+                    
    • prefix || “viewtest” for Unified Full Viewing Keys on Testnet.
      • 
+                
    
+                
    While support for Revision 1 UAs/UVKs is still being rolled out across the Zcash ecosystem, a Producer can maximize interoperability by generating a Revision 0 UA/UVK in cases where the conditions on its use are met (i.e. there are no MUST-understand Metadata Items, and at least one shielded item). At some point when Revision 1 UA/UVKs are widely supported, this will be unnecessary and it will be sufficient to always produce Revision 1 UA/UVKs.
    
+            
    
             
    Encoding of Unified Addresses 
    
                 
    Rather than defining a Bech32 string encoding of Orchard Shielded Payment Addresses, we instead define a Unified Address format that is able to encode a set of Receivers of different types. This enables the Consumer of a Unified Address 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 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
                         \(\mathtt{0x03}\)
-                     — an Orchard raw address as defined in 10;
      • 
+                     — an Orchard raw address as defined in 11;
                     
    • Typecode
                         \(\mathtt{0x02}\)
-                     — a Sapling raw address as defined in 9;
      • 
+                     — a Sapling raw address as defined in 10;
                     
    • Typecode
                         \(\mathtt{0x01}\)
                      — a Transparent P2SH address, or Typecode
@@ -177,7 +206,7 @@
                 
      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.
      
                 
      The raw encoding of a Unified Address is a concatenation of
                     \((\mathtt{typecode}, \mathtt{length}, \mathtt{addr})\)
-                 encodings of the consituent Receivers, in ascending order of Typecode:
      
+                 encodings of the constituent Receivers, in ascending order of Typecode:
      
                 
        
                     
      • 
                         \(\mathtt{typecode} : \mathtt{compactSize}\)
@@ -202,9 +231,9 @@
                  in practice.)
        
                 
        A Receiver Encoding is the raw encoding of a Shielded Payment Address, or the
                     \(160\!\)
-                -bit script hash of a P2SH address 35, or the
+                -bit script hash of a P2SH address 38, or the
                     \(160\!\)
-                -bit validating key hash of a P2PKH address 34.
        
+                -bit validating key hash of a P2PKH address 37.
        
                 
        Let padding be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append padding to the concatenated encodings, and then apply the
                     \(\mathsf{F4Jumble}\)
                  algorithm as described in Jumbling. (In order for the limitation on the
@@ -213,7 +242,7 @@
                     \(\ell^\mathsf{MAX}_M - 16\)
                  bytes, where
                     \(\ell^\mathsf{MAX}_M\)
-                 is defined in Jumbling.) The output is then encoded with Bech32m 33, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.
        
+                 is defined in Jumbling.) The output is then encoded with Bech32m 36, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.
        
                 
        To decode a Unified Address Encoding, a Consumer MUST use the following procedure:
        
                 
          
                     
        • Decode using Bech32m, rejecting any address with an incorrect checksum.
          • 
@@ -223,7 +252,7 @@
                     
        • Let padding be the Human-Readable Part, padded to 16 bytes as for encoding. If the result ends in padding, remove these 16 bytes; otherwise reject.
          • 
                     
        • Parse the result as a raw encoding as described above, rejecting the entire Unified Address if it does not parse correctly.
          • 
                 
        
-                
        For Unified Addresses on Mainnet, the Human-Readable Part (as defined in 33) is “u”. For Unified Addresses on Testnet, the Human-Readable Part is “utest”.
        
+                
        The Human-Readable Part is as specified for a Unified Address in Revisions.
        
                 
        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, except by opting into experiments.
        
             
    
             
    Encoding of Unified Full/Incoming Viewing Keys 
    
@@ -235,7 +264,7 @@
                 
      
                     
    • An Orchard FVK or IVK Encoding, with Typecode
                         \(\mathtt{0x03},\)
-                     is is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively.
      • 
+                     is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively.
                     
    • A Sapling FVK Encoding, with Typecode
                         \(\mathtt{0x02},\)
                      is the encoding of
@@ -244,7 +273,7 @@
                         \(\mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)
                     , where
                         \(\mathsf{EncodeExtFVKParts}\)
-                     is defined in 14. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.
      • 
+                     is defined in 15. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.
                     
    • A Sapling IVK Encoding, also with Typecode
                         \(\mathtt{0x02},\)
                      is an encoding of
@@ -254,26 +283,20 @@
                     
      • 
                     
    • There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be diversified in an unlinkable way). The Typecode
                         \(\mathtt{0x01}\)
-                     MUST NOT be included in a UFVK or UIVK by Producers, and MUST be treated as unrecognized by Consumers.
      • 
-                    
    • For Transparent P2PKH Addresses that are derived according to BIP 32 27 and BIP 44 30, the FVK and IVK Encodings have Typecode
+                     MUST NOT be included in a UFVK or UIVK by Producers, and MUST be treated as unrecognised by Consumers.
      • 
+                    
    • For Transparent P2PKH Addresses that are derived according to BIP 32 30 and BIP 44 33, the FVK and IVK Encodings have Typecode
                         \(\mathtt{0x00}.\)
                      Both of these are encodings of the chain code and public key
                         \((\mathsf{c}, \mathsf{pk})\)
                      given by
                         \(\mathsf{c}\,||\,\mathsf{ser_P}(\mathsf{pk})\)
-                    . (This is the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 28.) However, the FVK uses the key at the Account level, i.e. at path
+                    . (This is the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 31.) However, the FVK uses the key at the Account level, i.e. at path
                         \(m / 44' / coin\_type' / account'\)
                     , while the IVK uses the external (non-change) child key at the Change level, i.e. at path
                         \(m / 44' / coin\_type' / account' / 0\)
                     .
      • 
                 
    
-                
    The Human-Readable Parts (as defined in 33) of Unified Viewing Keys are defined as follows:
    
-                
      
-                    
    • “uivk” for Unified Incoming Viewing Keys on Mainnet;
      • 
-                    
    • “uivktest” for Unified Incoming Viewing Keys on Testnet;
      • 
-                    
    • “uview” for Unified Full Viewing Keys on Mainnet;
      • 
-                    
    • “uviewtest” for Unified Full Viewing Keys on Testnet.
      • 
-                
    
+                
    The Human-Readable Part is as specified for a Unified Viewing Key in Revisions.
    
                 
    Rationale for address derivation 
    
                 
    
 Click to show/hide
@@ -283,32 +306,38 @@
             
    
             
    Requirements for both Unified Addresses and Unified Viewing Keys 
    
                 
      
-                    
    • A Unified Address or Unified Viewing Key MUST contain at least one shielded Item (Typecodes
+                    
    • A Revision 0 Unified Address or Unified Viewing Key MUST contain at least one shielded Item (Typecodes
                         \(\mathtt{0x02}\)
                      and
                         \(\mathtt{0x03}\)
-                    ). The rationale is that the existing P2SH and P2PKH transparent-only address formats, and the existing P2PKH extended public key format, suffice for representing transparent Items and are already supported by the existing ecosystem.
      • 
+                    ). This requirement is dropped for Revision 1 UA/UVKs.
                     
    • The
                         \(\mathtt{typecode}\)
                      and
                         \(\mathtt{length}\)
                      fields are encoded as
                         \(\mathtt{compactSize}.\)
-                     36 (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.)
      • 
+                     39 (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.)
                     
    • Within a single UA or UVK, all HD-derived Receivers, FVKs, and IVKs SHOULD represent an Address or Viewing Key for the same account (as used in the ZIP 32 or BIP 44 Account level).
      • 
                     
    • 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 or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade 23) to send funds into the Sprout chain value pool, this would not be generally useful.
      • 
-                    
    • Consumers MUST ignore constituent Items with Typecodes they do not recognize.
      • 
+                    
    • There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade 25) to send funds into the Sprout chain value pool, this would not be generally useful.
      • 
+                    
    • With the exception of MUST-understand Metadata Items, Consumers MUST ignore constituent Items with Typecodes they do not recognise.
      • 
                     
    • Consumers MUST reject Unified Addresses/Viewing Keys 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.
      • 
-                    
    • Consumers MUST reject Unified Addresses/Viewing Keys in which any constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification 2.
      • 
+                    
    • Consumers MUST reject Unified Addresses/Viewing Keys in which any constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification 2.
      • 
                     
    • Consumers MUST reject Unified Addresses/Viewing Keys in which the constituent Items are not ordered in ascending Typecode order. Note that this is different to priority order, and does not affect which Receiver in a Unified 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.
      • 
                     
    • If the encoding of a Unified Address/Viewing Key is shown to a user in an abridged form due to lack of space, at least the first 20 characters MUST be included.
      • 
                 
    
+                
    Rationale for dropping the "at least one shielded Item" restriction 
    
+                
    
+Click to show/hide
+                    
    The original rationale for this restriction was that the existing P2SH and P2PKH transparent-only address formats, and the existing P2PKH extended public key format, sufficed for representing transparent Items and were already supported by the existing ecosystem.
    
+                    
    However, as of Revision 1 there are uses for transparent-only UAs and UVKs that are not covered by the existing formats. In particular, they can use Metadata Items to represent expiration heights/dates as described in Address Expiration Metadata, or source restrictions as proposed in ZIP 320 28.
    
+                
    
                 
    Rationale for Item ordering 
    
                 
    
 Click to show/hide
-                    
    The rationale for requiring Items to be canonically ordered by Typecode is that it enables implementations to use an in-memory representation that discards ordering, while retaining the same round-trip serialization of a UA / UVK (provided that unrecognized Items are retained).
    
+                    
    The rationale for requiring Items to be canonically ordered by Typecode is that it enables implementations to use an in-memory representation that discards ordering, while retaining the same round-trip serialization of a UA/UVK (provided that unrecognised Items are retained).
    
                 
    
                 
    Rationale for showing at least the first 20 characters 
    
                 
    
@@ -317,7 +346,7 @@
                 
    
             
    
             
    Adding new types 
    
-                
    It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process 13.
    
+                
    It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process 14.
    
                 
    For experimentation prior to proposing a ZIP, experimental types MAY be added using the reserved Typecodes
                     \(\mathtt{0xFFFA}\)
                  to
@@ -327,12 +356,69 @@
             
    
             
    Metadata Items 
    
                 
    Typecodes
+                    \(\mathtt{0xC0}\)
+                 to
+                    \(\mathtt{0xFC}\)
+                 inclusive are reserved to indicate Metadata Items other than Receivers or Viewing Keys. These Items MAY affect the overall interpretation of the UA/UVK (for example, by specifying an expiration date).
    
+                
    As of Revision 1 of this ZIP, the subset of Metadata Typecodes in the range
                     \(\mathtt{0xE0}\)
                  to
                     \(\mathtt{0xFC}\)
-                 inclusive are reserved to indicate Metadata Items other than Receivers or Viewing Keys. These Items MAY affect the overall interpretation of the UA / UVK (for example, by specifying an expiration date).
    
+                 inclusive are designated as "MUST-understand": if a Consumer is unable to recognise the meaning of a Metadata Item with a Typecode in this range, then it MUST regard the entire UA/UVK as unsupported and not process it further.
    
+                
    A Revision 0 UA/UVK (determined by its HRP as specified in Revisions) MUST NOT include any Metadata Items with a MUST-understand Typecode; a Consumer MUST reject as invalid any UA/UVK that violates this requirement.
    
                 
    Since Metadata Items are not Receivers, they MUST NOT be selected by a Sender when choosing a Receiver to send to, and since they are not Viewing Keys, they MUST NOT provide additional authority to view information about transactions.
    
-                
    Currently no Metadata Types are defined. New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process 13.
    
+                
    New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process 14.
    
+                
    Rationale for making Revision 0 UA/UVKs with MUST-understand Typecodes invalid 
    
+                
    
+Click to show/hide
+                    
    A Consumer implementing this ZIP prior to Revision 1 will not recognise the Human-Readable Parts beginning with “ur” that mark a Revision 1 UA/UVK. So if a UA/UVK that includes MUST-understand Typecodes is required to use these Revision 1 HRPs, this will ensure that the MUST-understand specification is correctly enforced even for such implementations.
    
+                
    
+            
    
+            
    Address Expiration Metadata 
    
+                
    As of Revision 1, Typecodes
+                    \(\mathtt{0xE0}\)
+                 and
+                    \(\mathtt{0xE1}\)
+                 are reserved for optional address expiry metadata. A producer MAY choose to generate Unified Addresses containing either or both of the following Metadata Item Types, or none.
    
+                
    The value of a
+                    \(\mathtt{0xE0}\)
+                 item MUST be an unsigned 32-bit integer in little-endian order specifying the Address Expiry Height, a block height of the Zcash chain associated with the UA/UVK. A Unified Address containing metadata Typecode
+                    \(\mathtt{0xE0}\)
+                 MUST be considered expired when the height of the Zcash chain is greater than this value.
    
+                
    The value of a
+                    \(\mathtt{0xE1}\)
+                 item MUST be an unsigned 64-bit integer in little-endian order specifying a Unix Epoch Time, hereafter referred to as the Address Expiry Time. A Unified Address containing Metadata Typecode
+                    \(\mathtt{0xE1}\)
+                 MUST be considered expired when the current time is after the Address Expiry Time.
    
+                
    A Sender that supports Revision 1 of this specification MUST set a non-zero nExpiryHeight field in transactions it creates that are sent to a Unified Address that defines an Address Expiry Height. If the nExpiryHeight normally constructed by the Sender would be greater than the Address Expiry Height, then the transaction MUST NOT be sent. If only an Address Expiry Time is specified, then the Sender SHOULD choose a value for nExpiryHeight such that the transaction will expire no more than 24 hours after the current time. If both
+                    \(\mathtt{0xE0}\)
+                 and
+                    \(\mathtt{0xE1}\)
+                 Metadata Items are present, then both restrictions apply.
    
+                
    If a Sender sends to multiple Unified Addresses in the same transaction, then all of the Address Expiry constraints imposed by the individual addresses apply.
    
+                
    If a wallet user attempts to send to an expired address, the error presented to the user by the wallet SHOULD include a suggestion that the user should attempt to obtain a currently-valid address for the intended recipient. A wallet MUST NOT send to an address that it knows to have expired.
    
+                
    Address expiration imposes no constraints on the Producer of an address. A Producer MAY generate multiple Unified Addresses with the same Receivers but different expiration metadata and/or any number of distinct Diversified Unified Addresses with the same or different expiry metadata, in any combination. Note that although changes to metadata will result in a visually distinct address, such updated addresses will be directly linkable to the original addresses because they share the same Receivers.
    
+                
    When deriving a UIVK from a UFVK containing Typecodes
+                    \(\mathtt{0xE0}\)
+                 and/or
+                    \(\mathtt{0xE1}\)
+                , these Metadata Items MUST be retained unmodified in the derived UIVK.
    
+                
    When deriving a Unified Address from a UFVK or UIVK containing a Metadata Item having Typecode
+                    \(\mathtt{0xE0}\)
+                , the derived Unified Address MUST contain a Metadata Item having Typecode
+                    \(\mathtt{0xE0}\)
+                 such that the Address Expiry Height of the resulting address is less than or equal to the Expiry Height of the viewing key.
    
+                
    When deriving a Unified Address from a UFVK or UIVK containing a Metadata Item having Typecode
+                    \(\mathtt{0xE1}\)
+                , the derived Unified Address MUST contain a Metadata Item having Typecode
+                    \(\mathtt{0xE1}\)
+                 such that the Address Expiry Time of the resulting address is less than or equal to the Expiry Time of the viewing key.
    
+                
    Producers of Diversified Unified Addresses should be aware that the expiration metadata could potentially be used to link addresses from the same source. Normally, if Diversified Unified Addresses derived from the same UIVK contain only Sapling and/or Orchard Receivers and no Metadata Items, they will be unlinkable as described in 8; this property does not hold when Metadata Items are present. It is RECOMMENDED that when deriving Unified Addresses from a UFVK or UIVK containing expiry metadata that the Expiry Height and Expiry Time of each distinct address vary from one another, so as to reduce the likelihood that addresses may be linked via their expiry metadata.
    
+                
    Rationale 
    
+                    
    The intent of this specification is that Consumers of Unified Addresses must not send to expired addresses. If only an Address Expiry Time is specified, a transaction to the associated address could be mined after the Address Expiry Time within a 24-hour window.
    
+                    
    The reason that the transaction MUST NOT be sent when its nExpiryHeight as normally constructed is greater than the Address Expiry Height is to avoid unnecessary information leakage in that field about which address was used as the destination. If a sender were to instead use the expiry height to directly set the nExpiryHeight field, this would leak the expiry information of the destination address, which may then be identifiable.
    
+                    
    When honoring an Address Expiry Time, the reason that a sender SHOULD choose a nExpiryHeight that is expected to occur within 24 hours of the time of transaction construction is to, when possible, ensure that the expiry time is respected to within a day. Address Expiry Times are advisory and do not represent hard bounds because computer clocks often disagree, but every effort should be made to ensure that transactions expire instead of being mined more than 24 hours after a recipient address's expiry time. When chain height information is available to the Sender, it is both permissible and advisable to set this bound more tightly; a common expiry delta used by many wallets is 40 blocks from the current chain tip, as suggested in ZIP 203 24.
    
+                
    
             
    
             
    Deriving Internal Keys 
    
                 
    In addition to external addresses suitable for giving out to Senders, a wallet typically requires addresses for internal operations such as change and auto-shielding.
    
@@ -356,7 +442,7 @@
                     \(\mathsf{CRH^{ivk}}\)
                  or
                     \(\mathsf{Commit^{ivk}}\)
-                 (for Sapling and Orchard respectively). Derivation of an internal shielded FVK from an external shielded FVK is specified in the "Sapling internal key derivation" 17 and "Orchard internal key derivation" 19 sections of ZIP 32.
    
+                 (for Sapling and Orchard respectively). Derivation of an internal shielded FVK from an external shielded FVK is specified in the "Sapling internal key derivation" 18 and "Orchard internal key derivation" 20 sections of ZIP 32.
    
                 
    To satisfy the above properties for transparent (P2PKH) keys, we derive the external and internal
                     \(\mathsf{ovk}\)
                  components from the transparent FVK
@@ -369,7 +455,7 @@
                         \(\mathsf{ser_P}(pk)\)
                      is
                         \(33\)
-                     bytes, as specified in 28.
+                     bytes, as specified in 31.
                     
  • Let
                         \(\mathsf{ovk_{external}}\)
                      be the first
@@ -384,24 +470,30 @@
                         \(I_\mathsf{ovk}\)
                     .
    • 
                 
-                
    Since an external P2PKH FVK encodes the chain code and public key at the Account level, we can derive both external and internal child keys from it, as described in BIP 44 31. It is possible to derive an internal P2PKH FVK from the external P2PKH FVK (i.e. its parent) without having the external spending key, because child derivation at the Change level is non-hardened.
    
+                
    Since an external P2PKH FVK encodes the chain code and public key at the Account level, we can derive both external and internal child keys from it, as described in BIP 44 34. It is possible to derive an internal P2PKH FVK from the external P2PKH FVK (i.e. its parent) without having the external spending key, because child derivation at the Change level is non-hardened.
    
             
    
             
    Deriving a UIVK from a UFVK 
    
+                
    As a consequence of the specification in MUST-understand Typecodes, as of Revision 1 a Consumer of a UFVK MUST understand the meaning of all "MUST-understand" Metadata Item Typecodes present in the UFVK in order to derive a UIVK from it.
    
+                
    If the source UFVK is Revision 1 then the derived UIVK SHOULD be Revision 1; if the source UFVK includes any Metadata Items then the derived UIVK MUST be Revision 1.
    
+                
    For Metadata Items recognised by the Consumer, the processing of the Item when deriving a UIVK is specified in the section or ZIP describing that Item.
    
                 
    The following derivations are applied to each component FVK:
    
                 
      
-                    
    • For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in 4.
      • 
-                    
    • For an Orchard FVK, the corresponding Orchard IVK is obtained as specified in 5.
      • 
+                    
    • For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in 4.
      • 
+                    
    • For an Orchard FVK, the corresponding Orchard IVK is obtained as specified in 5.
      • 
                     
    • For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK is obtained by deriving the child key with non-hardened index
                         \(0\)
-                     as described in 29.
      • 
+                     as described in 32.
                 
    
                 
    In each case, the Typecode remains the same as in the FVK.
    
-                
    Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see Experimental Usage), MUST be dropped when deriving a UIVK from a UFVK.
    
+                
    Items (including Metadata Items that are not "MUST-understand") that are unrecognised by a given Consumer, or that are specified in experiments that the user has not opted into (see Experimental Usage), MUST be dropped when the Consumer derives a UIVK from a UFVK.
    
             
    
             
    Deriving a Unified Address from a UIVK 
    
+                
    As a consequence of the specification in MUST-understand Typecodes, as of Revision 1 a Consumer of a UIVK MUST understand the meaning of all "MUST-understand" Metadata Item Typecodes present in the UIVK in order to derive a Unified Address from it.
    
+                
    If the source UIVK is Revision 1 then the derived Unified Address SHOULD be Revision 1; if the source UIVK includes any Metadata Items then the derived Unified Address MUST be Revision 1.
    
+                
    For Metadata Items recognised by the Consumer, the processing of the Item when deriving a Unified Address is specified in the section or ZIP describing that Item.
    
                 
    To derive a Unified Address from a UIVK we need to choose a diversifier index, which MUST be valid for all of the Viewing Key Types in the UIVK. That is,
    
                 
      
-                    
    • A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” 16.
      • 
+                    
    • A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” 17.
      • 
                     
    • A Transparent diversifier index MUST be in the range
                         \(0\)
                      to
@@ -411,18 +503,19 @@
                 
    
                 
    The following derivations are applied to each component IVK using the diversifier index:
    
                 
      
-                    
    • For a Sapling IVK, the corresponding Sapling Receiver is obtained as specified in 4.
      • 
-                    
    • For an Orchard IVK, the corresponding Orchard Receiver is obtained as specified in 5.
      • 
-                    
    • For a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level 32 to derive the corresponding Transparent P2PKH Receiver. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation 29 MUST be used. The IVK is assumed to correspond to the extended public key for the external (non-change) element of the path. That is, if the UIVK was constructed correctly then the BIP 44 path of the Transparent P2PKH Receiver will be
+                    
    • For a Sapling IVK, the corresponding Sapling Receiver is obtained as specified in 4.
      • 
+                    
    • For an Orchard IVK, the corresponding Orchard Receiver is obtained as specified in 5.
      • 
+                    
    • For a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level 35 to derive the corresponding Transparent P2PKH Receiver. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation 32 MUST be used. The IVK is assumed to correspond to the extended public key for the external (non-change) element of the path. That is, if the UIVK was constructed correctly then the BIP 44 path of the Transparent P2PKH Receiver will be
                         \(m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.\)
                     
      • 
                 
    
                 
    In each case, the Typecode remains the same as in the IVK.
    
-                
    Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see Experimental Usage), MUST be dropped when deriving a Receiver from a UIVK.
    
+                
    Items (including Metadata Items that are not "MUST-understand") that are unrecognised by a given Consumer, or that are specified in experiments that the user has not opted into (see Experimental Usage), MUST be dropped when the Consumer derives a Unified Address from a UIVK.
    
+                
    See Address Expiration Metadata for discussion of potential linking of Diversified Unified Addresses via their metadata.
    
             
    
             
    Usage of Outgoing Viewing Keys 
    
-                
    When a Sender constructs a transaction that creates Sapling or Orchard notes, it uses an outgoing viewing key, as described in 6 and 7, to encrypt an outgoing ciphertext. Decryption with the outgoing viewing key allows recovering the sent note plaintext, including destination address, amount, and memo. The intention is that this outgoing viewing key should be associated with the source of the funds.
    
-                
    However, the specification of which outgoing viewing key should be used is left somewhat open in 6 and 7; in particular, it was unclear whether transfers should be considered as being sent from an address, or from a ZIP 32 account 20. The adoption of multiple shielded protocols that support outgoing viewing keys (i.e. Sapling and Orchard) further complicates this question, since from NU5 activation, nothing at the consensus level prevents a wallet from spending both Sapling and Orchard notes in the same transaction. (Recommendations about wallet usage of multiple pools will be given in ZIP 315 25.)
    
+                
    When a Sender constructs a transaction that creates Sapling or Orchard notes, it uses an outgoing viewing key, as described in 6 and 7, to encrypt an outgoing ciphertext. Decryption with the outgoing viewing key allows recovering the sent note plaintext, including destination address, amount, and memo. The intention is that this outgoing viewing key should be associated with the source of the funds.
    
+                
    However, the specification of which outgoing viewing key should be used is left somewhat open in 6 and 7; in particular, it was unclear whether transfers should be considered as being sent from an address, or from a ZIP 32 account 21. The adoption of multiple shielded protocols that support outgoing viewing keys (i.e. Sapling and Orchard) further complicates this question, since from NU5 activation, nothing at the consensus level prevents a wallet from spending both Sapling and Orchard notes in the same transaction. (Recommendations about wallet usage of multiple pools will be given in ZIP 315 27.)
    
                 
    Here we refine the protocol specification in order to allow more precise determination of viewing authority for UFVKs.
    
                 
    A Sender will attempt to determine a "sending Account" for each transfer. The preferred approach is for the API used to perform a transfer to directly specify a sending Account. Otherwise, if the Sender can ascertain that all funds used in the transfer are from addresses associated with some Account, then it SHOULD treat that as the sending Account. If not, then the sending Account is undetermined.
    
                 
    The Sender also determines a "preferred sending protocol" —one of "transparent", "Sapling", or "Orchard"— corresponding to the most preferred Receiver Type (as given in Encoding of Unified Addresses) of any funds sent in the transaction.
    
@@ -462,13 +555,13 @@
                      targets. It may be possible to improve on this attack by making use of properties of checksums, etc.
    
                     
    The generic attack puts an upper bound on the achievable security: if it takes work
                         \(w\)
-                     to produce and verify a UA / UVK, and the size of the character set is
+                     to produce and verify a UA/UVK, and the size of the character set is
                         \(c,\)
                      then the generic attack costs
                         \(\sim \frac{w \cdot
 c^{n+m}}{q}.\)
                     
    
-                    
    There is also a generic brute force attack against nonmalleability. The adversary modifies the target UA / UVK 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
+                    
    There is also a generic brute force attack against nonmalleability. The adversary modifies the target UA/UVK 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
                         \(w\)
                      defined as above, the cost is
                         \(w/p\)
@@ -565,7 +658,7 @@
                         \(0 \text{ up to } \mathsf{ceiling}(\ell_R/\ell_H)-1].\)
                     
    
                     
    
-                        
+                        
                         
    Diagram of 4-round unkeyed Feistel construction
    
                     
    
                     
    (In practice the lengths
@@ -582,21 +675,41 @@
                     
    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, UFVK, or UIVK appends the HRP, padded to 16 bytes with zero bytes, to the raw encoding, then applies
                         \(\mathsf{F4Jumble}\)
                      before encoding the result with Bech32m.
    
-                    
    The Consumer rejects any Bech32m-decoded byte sequence that is less than 48 bytes or greater than
+                    
    The Consumer rejects any Bech32m-decoded byte sequence that is less than 38 bytes or greater than
                         \(\ell^\mathsf{MAX}_M\)
                      bytes; otherwise it applies
                         \(\mathsf{F4Jumble}^{-1}.\)
                      It rejects any result that does not end in the expected 16-byte padding, before stripping these 16 bytes and parsing the result.
    
-                    
    (48 bytes allows for the minimum size of a shielded UA, UFVK, or UIVK Item encoding to be 32 bytes, taking into account 16 bytes of padding. Although there is currently no shielded Item encoding that short, it is plausible that one might be added in future.
+                
    
+                
    Rationale for length restrictions 
    
+                
    
+Click to show/hide
+                    
    A minimum input length to
+                        \(\mathsf{F4Jumble}^{-1}\)
+                     of 38 bytes allows for the minimum size of a UA/UVK Item encoding to be 22 bytes including the typecode and length, taking into account 16 bytes of padding. This allows for a UA containing only a Transparent P2PKH Receiver:
    
+                    
      
+                        
    • Transparent P2PKH Receiver Item:
+                            
        
+                                
      • 1-byte typecode
        • 
+                                
      • 1-byte encoding of length
        • 
+                                
      • 20-byte transparent address hash
        • 
+                            
      
+                        
      • 
+                    
    
+                    
    
                         \(\ell^\mathsf{MAX}_M\)
                      bytes is the largest input/output size supported by
                         \(\mathsf{F4Jumble}.\)
-                    )
    
-                
    
+                    
    
+                    
    Allowing only a Transparent P2PKH Receiver is consistent with dropping the requirement to have at least one shielded Item in Revision 1 UA/UVKs (see rationale).
    
+                    
    Note that Revision 0 of this ZIP specified a minimum input length to
+                        \(\mathsf{F4Jumble}^{-1}\)
+                     of 48 bytes. Since there were no sets of UA/UVK Item Encodings valid in Revision 0 to which a byte sequence (after removal of the 16-byte padding) of length between 22 and 31 bytes inclusive could be parsed, the difference between the 38 and 48-byte restrictions is not observable, other than potentially affecting which error is reported. A Consumer supporting Revision 1 of this specification MAY therefore apply either the 48-byte or 38-byte minimum to Revision 0 UA/UVKs.
    
+                
    
                 
    Heuristic analysis 
    
                     
    A 3-round unkeyed Feistel, as shown, is not sufficient:
    
                     
    
-                        
+                        
                         
    Diagram of 3-round unkeyed Feistel construction
    
                     
    
                     
    Suppose that an adversary has a target input/output pair
@@ -667,7 +780,7 @@
                             \(y' \neq y,\)
                          all four pieces are randomized.
                     
-                    
    Note that the size of each piece is at least 24 bytes.
    
+                    
    Note that the size of each piece is at least 19 bytes.
    
                     
    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 Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.
    
                     
    The padding contains the HRP so that the HRP has the same protection against malleation as the rest of the address. This may help against cross-network attacks, or attacks that confuse addresses with viewing keys.
    
                 
    
@@ -723,10 +836,8 @@
             
    
         
    
         
    Reference implementation 
    
-            
+            
    Revision 0: * https://github.com/zcash/librustzcash/pull/352 * https://github.com/zcash/librustzcash/pull/416
    
+            
    Revision 1: * https://github.com/zcash/librustzcash/pull/1135
    
         
    
         
    Acknowledgements 
    
             
    The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre, Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, Teor, Eran Tromer, Conrado Gouvêa, and Marek Bielik for discussions on the subject of Unified Addresses and Unified Viewing Keys.
    
@@ -740,11 +851,11 @@
                     
                 
             
-            
+            
    
-                        
+                        
    
                 
                     
    
                         2Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal]Zcash Protocol Specification, Version 2023.4.0 or later
                     
    
                     
             
    
@@ -752,7 +863,7 @@
                 
                     
                         3
-                        Zcash Protocol Specification, Version 2022.2.19. Section 2: Notation
+                        Zcash Protocol Specification, Version 2023.4.0. Section 2: Notation
                     
                 
             
@@ -760,7 +871,7 @@
                 
                     
                         4
-                        Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components
+                        Zcash Protocol Specification, Version 2023.4.0. Section 4.2.2: Sapling Key Components
                     
                 
             
@@ -768,7 +879,7 @@
                 
                     
                         5
-                        Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components
+                        Zcash Protocol Specification, Version 2023.4.0. Section 4.2.3: Orchard Key Components
                     
                 
             
@@ -776,7 +887,7 @@
                 
                     
                         6
-                        Zcash Protocol Specification, Version 2022.2.19. Section 4.7.2: Sending Notes (Sapling)
+                        Zcash Protocol Specification, Version 2023.4.0. Section 4.7.2: Sending Notes (Sapling)
                     
                 
             
@@ -784,54 +895,62 @@
                 
                     
                         7
-                        Zcash Protocol Specification, Version 2022.2.19. Section 4.7.3: Sending Notes (Orchard)
+                        Zcash Protocol Specification, Version 2023.4.0. Section 4.7.3: Sending Notes (Orchard)
                     
                 
             
-            
+            
    
-                        
+                        
    
                 
                     
    
                         8Zcash Protocol Specification, Version 2022.2.19. Section 5.6: Encodings of Addresses and KeysZcash Protocol Specification, Version 2023.4.0. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions
                     
    
                     
             
    
-            
+            
    
-                        
+                        
    
                 
                     
    
                         9Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.1: Sapling Payment AddressesZcash Protocol Specification, Version 2023.4.0. Section 5.6: Encodings of Addresses and Keys
                     
    
                     
             
    
-            
+            
    
-                        
+                        
    
                 
                     
    
                         10Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.2: Orchard Raw Payment AddressesZcash Protocol Specification, Version 2023.4.0. Section 5.6.3.1: Sapling Payment Addresses
                     
    
                     
             
    
-            
+            
    
-                        
+                        
    
                 
                     
    
                         11Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.3: Orchard Raw Incoming Viewing KeysZcash Protocol Specification, Version 2023.4.0. Section 5.6.4.2: Orchard Raw Payment Addresses
                     
    
                     
             
    
-            
+            
    
-                        
+                        
    
                 
                     
    
                         12Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing KeysZcash Protocol Specification, Version 2023.4.0. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys
                     
    
                     
             
    
-            
+            
    
+                        
+                    
+                
+            
    
                 
                     
    
                         13Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.4: Orchard Raw Full Viewing Keys
    
+            
+                
+                    
+                        
@@ -839,7 +958,7 @@
             
    14
                         ZIP 0: ZIP Process
                     
    
                 
    
-                        
+                        
@@ -847,7 +966,7 @@
             
    
                 
                     
    1415
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions
                     
    
                 
    
-                        
+                        
@@ -855,7 +974,7 @@
             
    
                 
                     
    1516
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys
                     
    
                 
    
-                        
+                        
@@ -863,7 +982,7 @@
             
    
                 
                     
    1617
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation
                     
    
                 
    
-                        
+                        
@@ -871,7 +990,7 @@
             
    
                 
                     
    1718
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling internal key derivation
                     
    
                 
    
-                        
+                        
@@ -879,7 +998,7 @@
             
    
                 
                     
    1819
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation
                     
    
                 
    
-                        
+                        
@@ -887,7 +1006,7 @@
             
    
                 
                     
    1920
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard internal key derivation
                     
    
                 
    
-                        
+                        
@@ -895,7 +1014,7 @@
             
    
                 
                     
    2021
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Specification: Wallet usage
                     
    
                 
    
-                        
+                        
@@ -903,15 +1022,23 @@
             
    
                 
                     
    2122
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path
                     
    
                 
    
-                        
+                        
    
                 
                     
    2223
                         ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path
                     
    
                     
             
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    24ZIP 203: Transaction Expiry — Changes for Blossom
    
             
-                        
+                        
@@ -919,7 +1046,7 @@
             
    
                 
                     
    2325
                         ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool
                     
    
                 
    
-                        
+                        
@@ -927,15 +1054,23 @@
             
    
                 
                     
    2426
                         ZIP 224: Orchard Shielded Protocol
                     
    
                 
    
-                        
+                        
    
                 
                     
    2527
                         ZIP 315: Best Practices for Wallet Handling of Multiple Pools
                     
    
                     
             
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    28ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses
    
             
-                        
+                        
@@ -943,7 +1078,7 @@
             
    
                 
                     
    2629
                         ZIP 321: Payment Request URIs
                     
    
                 
    
-                        
+                        
@@ -951,7 +1086,7 @@
             
    
                 
                     
    2730
                         BIP 32: Hierarchical Deterministic Wallets
                     
    
                 
    
-                        
+                        
@@ -959,7 +1094,7 @@
             
    
                 
                     
    2831
                         BIP 32: Hierarchical Deterministic Wallets — Serialization Format
                     
    
                 
    
-                        
+                        
@@ -967,7 +1102,7 @@
             
    
                 
                     
    2932
                         BIP 32: Hierarchical Deterministic Wallets — Child key derivation (CKD) functions: Public parent key → public child key
                     
    
                 
    
-                        
+                        
@@ -975,7 +1110,7 @@
             
    
                 
                     
    3033
                         BIP 44: Multi-Account Hierarchy for Deterministic Wallets
                     
    
                 
    
-                        
+                        
@@ -983,7 +1118,7 @@
             
    
                 
                     
    3134
                         BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Change
                     
    
                 
    
-                        
+                        
@@ -991,7 +1126,7 @@
             
    
                 
                     
    3235
                         BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Index
                     
    
                 
    
-                        
+                        
@@ -999,7 +1134,7 @@
             
    
                 
                     
    3336
                         BIP 350: Bech32m format for v1+ witness addresses
                     
    
                 
    
-                        
+                        
@@ -1007,7 +1142,7 @@
             
    
                 
                     
    3437
                         Transactions: P2PKH Script Validation — Bitcoin Developer Guide
                     
    
                 
    
-                        
+                        
@@ -1015,7 +1150,7 @@
             
    
                 
                     
    3538
                         Transactions: P2SH Scripts — Bitcoin Developer Guide
                     
    
                 
    
-                        
+                        
diff --git a/zip-0317.html b/rendered/zip-0317.html
similarity index 99%
rename from zip-0317.html
rename to rendered/zip-0317.html
index edd511c0a..1ada72c08 100644
--- a/zip-0317.html
+++ b/rendered/zip-0317.html
@@ -10,7 +10,7 @@
         
    ZIP: 317
 Title: Proportional Transfer Fee Mechanism
 Owners: Aditya Bharadwaj <nighthawk24@gmail.com>
-        Daira Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Madars Virza
          Kris Nuttycombe
          Jack Grigg
@@ -25,7 +25,7 @@
         
    Terminology 
    
             
    The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
             
    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.
    
-            
    The terms "Mainnet, "Testnet", and "zatoshi" in this document are defined as in 2.
    
+            
    The terms "Mainnet", "Testnet", and "zatoshi" in this document are defined as in 2.
    
         
    
         
    Abstract 
    
             
    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.
    
diff --git a/zip-0318.html b/rendered/zip-0318.html
similarity index 90%
rename from zip-0318.html
rename to rendered/zip-0318.html
index f60a9b25a..1bf2b988a 100644
--- a/zip-0318.html
+++ b/rendered/zip-0318.html
@@ -9,7 +9,7 @@
         
    ZIP: 318
 Title: Associated Payload Encryption
 Owners: Kris Nuttycombe <kris@electriccoin.co>
-        Daira Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Standards Track
 Created: 2022-09-19
diff --git a/zip-0319.html b/rendered/zip-0319.html
similarity index 90%
rename from zip-0319.html
rename to rendered/zip-0319.html
index 12088159b..6d801d6b0 100644
--- a/zip-0319.html
+++ b/rendered/zip-0319.html
@@ -9,7 +9,7 @@
         
    ZIP: 319
 Title: Options for Shielded Pool Retirement
 Owners: Nathan Wilcox <nathan@electriccoin.co>
-        Daira Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Informational
 Created: 2022-09-20
diff --git a/rendered/zip-0320.html b/rendered/zip-0320.html
new file mode 100644
index 000000000..0094e0110
--- /dev/null
+++ b/rendered/zip-0320.html
@@ -0,0 +1,236 @@
+
+
+
+    ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses
+    
+    
+
+
+    
    
+        
    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>
+        Kris Nuttycombe <kris@nutty.land>
+Credits: Hanh
+Status: Proposed
+Category: Standards / Wallet
+Created: 2024-01-12
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/757>
+                <https://github.com/zcash/zips/issues/795>
+Pull-Request: <https://github.com/zcash/zips/pull/760>
+              <https://github.com/zcash/zips/pull/766>
+              <https://github.com/zcash/zips/pull/798>
    
+        
    Terminology 
    
+            
    The key words "MUST", "SHOULD", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
+            
    The terms "Recipient", "Producer", "Consumer", "Sender", "Receiver", "Address", and "Unified Address" are to be interpreted as described in ZIP 316 7.
    
+            
    The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 10.
    
+        
    
+        
    Abstract 
    
+            
    This ZIP defines a new encoding for transparent Zcash addresses. Wallets must ensure that no shielded notes are spent in transactions that send to a transparent address encoded in the specified fashion.
    
+        
    
+        
    Background 
    
+            
    In November 2023, the Zcash community received notice from the Binance cryptocurrency exchange that Zcash was at risk of being delisted from the exchange unless the community could provide a mechanism by which Binance could refuse deposits from shielded addresses and return them to the depositor. This issue was raised and discussed at length in the Zcash Community forum 2.
    
+            
    In the course of that discussion thread, wallet developer and community member @hanh 3 suggested a wallet-oriented approach 4 that involved defining a new encoding for Zcash transparent P2PKH addresses. A Consumer of such an address, whether it be a wallet or an exchange, could recognize this encoding as a directive that the wallet should only spend transparent funds when creating an output to that address. This ZIP formalizes that proposal.
    
+        
    
+        
    Motivation 
    
+            
    The Binance cryptocurrency exchange requires that funds sent to their deposit addresses come from source addresses that are readily identifiable using on-chain information, such that if necessary funds may be rejected by sending them back to one of the source addresses. This ZIP is intended to standardize a transparent address encoding that is not yet understood by preexisting Consumers, in order to prevent inadvertent shielded spends when sending to such addresses. Then, Consumers that upgrade to support the new encoding will do so with the understanding that they must respect the restrictions on sources of funds described in this ZIP.
    
+            
    It is not expected that other exchanges or Producers of Zcash addresses will generate Transparent-Source-Only Addresses unless they have a specific need to be able to identify the address or addresses from which a payment was funded. However, all Consumers of Zcash addresses should implement this specification, in order to promote interoperability across the Zcash ecosystem.
    
+        
    
+        
    Requirements 
    
+            
      
+                
    1. A Recipient wishing to receive funds from exclusively transparent sources must be able to generate a receiving address such that only transparent funds will be spent in transactions with an output to this address. The purpose of this is to ensure that it is reliably possible for the Recipient to send back funds received from a Sender that conforms to this ZIP.
      2. 
+                
    2. Wallets and other Consumers that have not been upgraded to recognize the new address format cannot mistake the address for another address type or inadvertently send shielded funds to the address.
      3. 
+                
    3. No changes to Recipient infrastructure beyond changes to address encoding and decoding should be required as a consequence of this ZIP. In particular, conversion between a Transparent-Source-Only Address and the corresponding unrestricted transparent address should be possible using only dependencies that are available to Binance's front-end code.
      4. 
+            
    
+        
    
+        
    Non-requirements 
    
+            
      
+                
    1. It is only required to support a Transparent-Source-Only form of P2PKH addresses; P2SH address support is not necessary.
      2. 
+                
    2. It is not required to limit the source of transparent funds sent to a Transparent-Source-Only Address to a single source address. This implies that if the Recipient chooses to send back the funds, it is acceptable for it to send them back to any of the source addresses if there is more than one.
      3. 
+                
    3. It is not necessary for the restriction on the source of funds to be enforced as a consensus rule. If a Sender fails to adhere to the restriction, it risks loss of funds, which is acceptable in the case of a non-conforming Sender implementation.
      4. 
+            
    
+        
    
+        
    Specification 
    
+            
    A TEX Address, also called a Transparent-Source-Only Address, is a Bech32m 15 reencoding of a transparent Zcash P2PKH address 11.
    
+            
    Wallets and other Senders sending to a TEX address (as any output) MUST ensure that only transparent (P2SH or P2PKH) UTXOs are spent in the creation of the transaction. For simplicity of parsing and interpreting such transactions, they also SHOULD only send to transparent outputs.
    
+            
    A TEX address can be produced from a Mainnet Zcash P2PKH Address by executing the following steps:
    
+            
      
+                
    1. Decode the address to a byte sequence using the Base58Check decoding algorithm 13.
      2. 
+                
    2. If the length of the resulting byte sequence is not 22 bytes or if its two-byte address prefix is not
+                    \([\mathtt{0x1C}, \mathtt{0xB8}]\)
+                , return an error. Otherwise, let the validating key hash be the remaining 20 bytes of the sequence after removing the two-byte address prefix.
      3. 
+                
    3. Reencode the 20-byte validating key hash using the Bech32m encoding defined in 15 with the human-readable prefix (HRP) "tex".
      4. 
+            
    
+            
    For Testnet addresses, the required lead bytes of a P2PKH address in step 2 are
+                \([\mathtt{0x1D}, \mathtt{0x25}]\)
+            , and the "textest" HRP is used when reencoding in step 3.
    
+            
    A TEX address can be parsed by reversing this encoding, i.e.:
    
+            
      
+                
    1. Decode the address to a byte sequence using Bech32m 15, checking that the HRP is "tex" for a Mainnet TEX Address and "textest" for a Testnet TEX Address.
      2. 
+                
    2. If the length of the resulting byte sequence is not 20 bytes, return an error. Otherwise, the validating key hash is this byte sequence.
      3. 
+            
    
+            
    Design considerations for Senders 
    
+                
    For a transaction that spends only from transparent funds to a TEX Address, this specification imposes no additional requirements.
    
+                
    If, on the other hand, a user desires to spend shielded funds to a TEX Address, a Sender supporting this ZIP MUST create two transactions: one that unshields the funds to an ephemeral transparent address, and one that spends from that ephemeral address to the destination TEX Address. This does not defeat the intent of the ZIP, because it is still possible for a Recipient to return the funds to the Sender by sending them back to the ephemeral address.
    
+                
    Wallets MUST be able to recognize funds that have been returned in this way and spend them if desired. In order for this to be possible without use of TEX Addresses increasing the risk of loss of funds, wallets based on ZIP 32 5 SHOULD choose ephemeral addresses in a way that allows the corresponding private keys to be recovered from a ZIP 32 master seed.
    
+                
    However, ephemeral addresses SHOULD NOT be chosen in a way that allows them to be linked between transactions, without knowledge of the wallet seed or the relevant transparent viewing keys. This also implies that they SHOULD be chosen in a way that avoids collisions with addresses for previously generated outputs (including change outputs), such as might have been created by a transparent-only wallet using Bitcoin-derived code based on BIP 44 14.
    
+                
    In order to show accurate transaction history to a user, wallets SHOULD remember when a particular transaction output was sent to a TEX Address, so that they can show that form rather than its P2PKH form. It is acceptable that this information may be lost on recovery from seed.
    
+            
    
+        
    
+        
    Reference Implementation 
    
+            
    Javascript:
    
+            
    import bs58check from 'bs58check'
+import {bech32m} from 'bech32'
+
+// From t1 to tex
+var b58decoded = bs58check.decode('t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC')
+console.assert(b58decoded.length == 22, 'Invalid length');
+console.assert(b58decoded[0] == 0x1C && b58decoded[1] == 0xB8, 'Invalid address prefix');
+var pkh = b58decoded.slice(2)
+var tex = bech32m.encode('tex', bech32m.toWords(pkh))
+console.log(tex)
+
+// From tex to t1
+var bech32decoded = bech32m.decode('tex1s2rt77ggv6q989lr49rkgzmh5slsksa9khdgte')
+console.assert(bech32decoded.prefix == 'tex', 'Invalid address prefix')
+var pkh2 = Uint8Array.from(bech32m.fromWords(bech32decoded.words))
+console.assert(pkh2.length == 20, 'Invalid length');
+var t1 = bs58check.encode(Buffer.concat([Uint8Array.from([0x1C, 0xB8]), pkh2]))
+console.log(t1)
    
+        
    
+        
    Rationale 
    
+            
    TEX addresses are the simplest possible approach to creating a new address type that indicates that only transparent sources of funds should be used.
    
+            
    As required by Binance, it will be possible to convert between a TEX address and an unrestricted transparent P2PKH address using extremely straightforward code that depends only on Base58Check and Bech32m encoding/decoding, as shown in the above Reference Implementation.
    
+            
    An earlier version of this ZIP also described another alternative using metadata in Unified Addresses, as specified in ZIP 316 6. That alternative was designed to enable better integration with the Zcash Unified Address ecosystem, and had the advantage of being able to combine different types of metadata along with the Transparent-Source-Only indicator, such as an expiration block height or time 9 12.
    
+            
    However, ultimately the Unified Address-based approach did not meet all of the requirements, since it would in practice have required dependencies on address handling libraries that Binance did not want to depend on in their front-end code.
    
+            
    Some design elements of that approach that apply to metadata in general have been incorporated into ZIP 316 Revision 1 8. A more general form of Source Restriction Metadata is also under consideration.
    
+            
    Disadvantages 
    
+                
    A disadvantage of TEX Addresses (and also of the alternative approach using Unified Addresses) is that the information that a TEX Address was used does not appear on-chain, i.e. a transaction sending to a TEX Address is indistinguishable from one sending to the underlying P2PKH address. This is inevitable given the desire not to change the underlying consensus protocol to support this functionality.
    
+            
    
+        
    
+        
    References 
    
+            
    
                 
                     
    3639
                         Variable length integer. Bitcoin Wiki
                     
    
                 
    
+                
+                    
+                        
+                        
+                    
+                
+            
    1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    2Zcash Community Forum thread "Important: Potential Binance Delisting"
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    3Zcash Community Forum user @hanh
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    4Ywallet developer @hanh's proposal
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    5ZIP 32: Shielded Hierarchical Deterministic Wallets
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    6ZIP 316: Unified Addresses and Unified Viewing Keys
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    7ZIP 316: Unified Addresses and Unified Viewing Keys — Terminology
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    8ZIP 316: Unified Addresses and Unified Viewing Keys — Revision 1
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    9ZIP 316: Unified Addresses and Unified Viewing Keys — Address Expiration Metadata
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    10Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    11Zcash Protocol Specification, Version 2023.4.0. Section 5.6.1.1 Transparent Addresses
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    12Zcash Community Forum post describing motivations for address expiry
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    13Base58Check encoding — Bitcoin Wiki
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    14BIP 44: Multi-Account Hierarchy for Deterministic Wallets
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    15BIP 350: Bech32m format for v1+ witness addresses
    
+        
    
+    
    
+
+
\ No newline at end of file
diff --git a/zip-0321.html b/rendered/zip-0321.html
similarity index 99%
rename from zip-0321.html
rename to rendered/zip-0321.html
index 66f254109..447bcf50e 100644
--- a/zip-0321.html
+++ b/rendered/zip-0321.html
@@ -8,8 +8,8 @@
     
    
         
    ZIP: 321
 Title: Payment Request URIs
-Owners: Kris Nuttycombe (kris@electriccoin.co)
-        Daira Emma Hopwood (daira@electriccoin.co)
+Owners: Kris Nuttycombe <kris@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Francisco Gindre
 Status: Proposed
 Category: Standards / Wallet
diff --git a/zip-0322.html b/rendered/zip-0322.html
similarity index 90%
rename from zip-0322.html
rename to rendered/zip-0322.html
index f40d997cd..9ad8f3dc0 100644
--- a/zip-0322.html
+++ b/rendered/zip-0322.html
@@ -9,7 +9,7 @@
         
    ZIP: 322
 Title: Generic Signed Message Format
 Owners: Jack Grigg <jack@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Standards / RPC / Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/429>
    
diff --git a/zip-0323.html b/rendered/zip-0323.html
similarity index 90%
rename from zip-0323.html
rename to rendered/zip-0323.html
index d8bff5417..0fa4f5385 100644
--- a/zip-0323.html
+++ b/rendered/zip-0323.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 323
 Title: Specification of getblocktemplate for Zcash
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
 Status: Reserved
 Category: RPC / Mining
diff --git a/rendered/zip-0324.html b/rendered/zip-0324.html
new file mode 100644
index 000000000..2816bce7c
--- /dev/null
+++ b/rendered/zip-0324.html
@@ -0,0 +1,386 @@
+
+
+
+    ZIP 324: URI-Encapsulated Payments
+    
+    
+
+
+    
    
+        
    ZIP: 324
+Title: URI-Encapsulated Payments
+Owners: Jack Grigg <jack@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
+        Kris Nuttycombe <kris@electriccoin.co>
+Original-Authors: Ian Miers
+                  Eran Tromer
+                  Jack Grigg
+                  Kevin Gorham
+                  Daira-Emma Hopwood
+Credits: Sean Bowe
+         Deirdre Connolly
+         Linda Naeun Lee
+         George Tankersley
+         Henry de Valence
+Status: Draft
+Category: Standards / Wallet
+Created: 2019-07-17
+License: MIT
    
+        
    Terminology 
    
+            
    The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
+            
    Zcash protocol terms are as defined in the Zcash Protocol Specification. 3
    
+            
+        
    
+        
    Abstract 
    
+            
    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.
    
+            
    The proposal specifies the syntax and semantics of URI-Encapsulated Payments, the workflow of generating and handling them, and requisite infrastructure.
    
+            
    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.
    
+            
    Usage Story 
    
+                
    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.
    
+                
    Bob receives the message, which looks as follows:
    
+                
    
+                    
    This message contains a Zcash payment. Click the following link to view it and receive the funds using your Zcash wallet app:
    
+                    
    https://pay.withzcash.com:65536/v1#amount=1.23&desc=Payment+for+foo&key=...
    
+                    
    If you do not yet have a Zcash wallet app, see: https://z.cash/wallets
    
+                
    
+                
    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.
    
+            
    
+        
    
+        
    Motivation 
    
+            
    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.
    
+            
    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.
    
+            
    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.
    
+            
    Additionally, the proposal greatly improves the scalability of Zcash. If a recipient only receives URI payments, they need not scan the blockchain or delegate their view keys to a third party to do so.
    
+            
    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.
    
+            
    The proposal is complementary to ZIP 321 4, which will standardize Payment Request URIs using which the payment recipient can convey their persistent payment address to the sender, for subsequent fund transfers (to be done using the normal on-chain mechanism rather than the encapsulated payments described in the current proposal).
    
+        
    
+        
    Requirements 
    
+            
    This proposal's specification of URI-Encapsulated Payments, and the intended protocols for using them, is meant to fulfill the following requirements:
    
+            
      
+                
    • The protocol must not require the sender of a payment to stay online until the recipient receives the URI (let alone finalizes the payment).
      • 
+                
    • For convenient rendering, URIs should be short; this also maximizes compatibility with length-limited messaging platforms.
      • 
+                
    • It must not be feasible for someone who has not seen the URI (or has compromised a party who has) to collect the funds.
      • 
+                
    • The URIs and protocol should minimize the likelihood of inadvertent misuse, and in particular the risks discussed in “Security Considerations” below.
      • 
+                
    • The protocol must not leak any information (sender identity, recipient identity, amount, description) to third parties, other than inevitable metadata about the existence of a transaction, the inevitable network communication around sending/receipt of transactions, whatever leakage is induced by the communication channel used to transmit the URI, and whatever is voluntarily shared by the parties.
      • 
+                
    • The URIs should allow for future modifications and expansion of the format, without risk of ambiguous parsing.
      • 
+                
    • The on-chain footprint of payments that use this mechanism should be indistinguishable from normal fully-shielded transactions (except, possibly, for the statistics of the number of shielded inputs and outputs).
      • 
+                
    • Don't lose funds, even if wallets crash, or everything but the sending wallet master secret is lost.
      • 
+            
    
+        
    
+        
    Non-requirements 
    
+            
      
+                
    • 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.
      • 
+                
    • 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).
      • 
+            
    
+        
    
+        
    Specification 
    
+            
    A Payment-Encapsulating URI represents the capability to claim the Zcash funds from specific on-chain transactions, as long as they're unspent. See Usage Story for an example.
    
+            
    Syntax 
    
+                
    A Payment-Encapsulating URI is a Universal Resource Locator (URL), as defined in RFC 3986 2, of the following form.
    
+                
    Scheme: https
    
+                
    Host: pay.withzcash.com
    
+                
    Port: 65536 (this is intentionally not a valid TCP/IP port number)
    
+                
    Path: payment/v1
    
+                
    Fragment parameters: these attribute-value pairs, in this order, separated by &, and with all values percent-encoded where necessary:
    
+                
      
+                    
    • amount=... where the attribute is a decimal number representing the amount of ZEC included in the payment. MUST be present. If a decimal fraction is present then a period (.) MUST be used as the separating character to separate the whole number from the decimal fraction, and both the whole number and the decimal fraction MUST be nonempty. No other separators (such as commas for grouping or thousands) are permitted. Leading zeros in the whole number or trailing zeros in the decimal fraction are ignored. There MUST NOT be more than 8 digits in the decimal fraction.
      • 
+                    
    • desc=... where the attribute is a human-readable string associated with the payment. MAY be present. If present, it MUST be encoded as “textual data consisting of characters from the Universal Character Set” as specified in RFC 3986 section 2.5.
      • 
+                    
    • key= is a 256-bit random number encoded with Bech32 as specified in Section 5.6.9 of the Zcash Protocol Specification 3). MUST be present.
      • 
+                
    
+            
    
+            
    Semantics 
    
+                
    The values of key and amount deterministically imply a unique payment note 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 key. The derivation of this note is done by the following procedure:
    
+                
    DerivePaymentNote(key,amount):
    
+                
      
+                    
    • Derive pk_d from key via the process defined in 3 Section 4.2.2 (setting sk = key).
      • 
+                    
    • Fix the diversified d = DefaultDiversifier(key).
      • 
+                    
    • Derive rseed = PRF^expand(sk_m || [0xFIXME]) as specified in 3 Section 5.4.2.
      • 
+                    
    • Define the corresponding payment note as n = (d, pk_d, amount, rseed) (see 3 Section 3.2 (https://zips.z.cash/protocol/protocol.pdf#notes)).
      • 
+                
    
+                
    TODO: Possible alternate way to derive pk_d and rseed from key:
    
+                
      
+                    
    • Use PRF^expand on key with to-be-defined domain separation to obtain 64 bytes. Split this into two 32-byte values.
+                        
        
+                            
      • First 32-byte value is sk; derive pk_d from this as in the spec.
        • 
+                            
      • Second 32-byte value is rseed.
        • 
+                        
      
+                    
      • 
+                    
    • Could also mix in other parts of the URI (amount, desc) to bind them here, without interfering with the existing key derivation process in the spec.
      • 
+                
    
+                
    Construct a shielded zcash transaction containing that note as an output.
    
+                
    The payment note SHOULD be unspent at the time it is intended to be received by the recipient.
    
+                
    Clients MAY generate and send the URI before the transaction is built, sent, or confirmed.
    
+                
    The amount parameter MUST match the total amount of ZEC in the payment note plus the standard transaction fee for fully-shielded transactions (currently 0.00001 ZEC).
    
+                
    There MUST NOT exist any other notes on the blockchain, or broadcast to the node network, beyond the payment note derived from the Payment URI, that are addressed to any payment address derived from key (with any diversifier). Such notes MAY be generated within an implementation (e.g., as speculative pre-generation with various note values) but MUST NOT be broadcast for mining.
    
+                
    Wallet software MUST NOT expose the ephemeral payment address corresponding to a payment URI (which helps to ensure the prior paragraph).
    
+                
    The desc parameter MAY convey a human-readable description of the payment, entered manually by the user or generated by the application in any reasonable manner.
    
+                
    The encrypted memo fields in the output description containing the payment note commitment SHOULD be either empty (all-zero), or identical to the desc parameter (padded with zeros).
    
+                
    The payment associated with an URI is not deemed “received” by the recipient until they execute a “finalization” process (see section Finalization).
    
+                
    When conveying payment to users, the sender's and recipient's wallet software MAY convey the description encoded in the desc parameter.
    
+                
    The recipient's wallet software SHOULD convey to the user that the desc value is merely a claim made by the party who sent the URI, and may be tentative, inaccurate or malicious.
    
+                
    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 amount parameter, and may change (possibly to zero), until the finalization process has been completed.
    
+            
    
+            
    Centralized Deployment 
    
+                
    The owner of the withzcash.com domain name MUST NOT create a DNS record for the pay.withzcash.com 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 withzcash.com domain name. (See Rationale for URI Format and Security Considerations below for discussion.)
    
+                
    Applink 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 withzcash.com domain effectively controls the whitelist of apps that may be launched by users' platform to handle URI-Encapsulated Payments (see Security Considerations). This whitelist should protect users from installing rogue apps that intercept incoming payments. Thus, the domain owner MUST do the following:
    
+                
      
+                    
    • Maintain such a whitelist and serve it as needed for the applink mechanisms of major platforms.
      • 
+                    
    • Publish a policy for inclusion of apps in this whitelist.
      • 
+                    
    • Use all feasible means to whitelist only apps that comply with the published policy.
      • 
+                    
    • Publish the whitelist's content in human-readable form.
      • 
+                    
    • Provide clear and effective means for rapid removal of apps from the whitelist when required as security response.
      • 
+                    
    • Use all feasible means to protect the whitelist's integrity (in particular, this includes protecting the web server that serves the whitelist, the domain's TLS certificate, and the means by which the whitelist is modified).
      • 
+                    
    • Use effective means for keeping a precise, irrevocable and public history of the whitelist (e.g., using a timestamped Git repository, or an accountability mechanism akin to Certificate Transparency).
      • 
+                
    
+                
    They also SHOULD:
    
+                
      
+                    
    • 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.
      • 
+                
    
+            
    
+            
    Testing 
    
+                
    For testing purposes, all of the above specification is duplicated for the Zcash testnet network, substituting TAZ (Zcash testnet coins) for ZEC and testzcash.com for withzcash.com.
    
+                
    A separate “testnet whitelist” MUST be maintained by the owner of the testzcash.com 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.
    
+                
    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.
    
+            
    
+        
    
+        
    Lifecycle Specification 
    
+            
    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:
    
+            
    Generating the notes and URI 
    
+                
    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.
    
+                
    Ephemeral key derivation 
    
+                    
    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.
    
+                    
    The derivation mechanism is as follows:
    
+                    
      
+                        
    • Use a ZIP 32 derivation pathway to obtain a child extended spending key from path m_Sapling/324'/coin_type'/payment_index'
+                            
        
+                                
      • Implementations need to remember which payment_index values they have used (in range 0..2^31), and not reuse them.
        • 
+                            
      
+                        
      • 
+                        
    • Compute key = BLAKE2b-256(extended spending key, personal='Zcash_PaymentURI')
      • 
+                    
    
+                
    
+            
    
+            
    URI Transmission 
    
+                
    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).
    
+                
    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).
    
+                
    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).
    
+                
    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.
    
+            
    
+            
    Message Rendering 
    
+                
    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.
    
+                
    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.
    
+            
    
+            
    Payment Rendering and Blockchain Lookup 
    
+                
    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.
    
+                
    In parallel, the wallet app SHOULD retrieve the relevant transactions from the Zcash blockchain, by looking up the transaction given by the cmu parameter (this MAY use an efficient index, perhaps assisted by a server), and check whether:
    
+                
      
+                    
    • such transactions are indeed present on the blockchain
      • 
+                    
    • the notes are unspent
      • 
+                    
    • the notes can be spent using an ephemeral spending keys given by the key parameter.
      • 
+                
    
+                
    The wallet conveys to the user one of the following states:
    
+                
      
+                    
    • Ready-to-finalize: The tests all verify, and the payment is ready to be finalized. The wallet SHOULD present the user with an option to finalize the payment (e.g., a “Finalize” button).
      • 
+                    
    • Invalid: The tests fail irreversibly (e.g., some of the notes are already spent, or the amounts to not add up). The wallet MAY convey the reason to the user, but in any case MUST convey that the funds cannot be received.
      • 
+                    
    • Pending: The tests fail in a way that may be remedied in the future, namely, some of the notes are not yet present on the blockchain (and no other tests are violated).
      • 
+                
    
+                
    Within the Pending 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 Ready-to-finalize state (since unmined notes cannot be immediately spent.)
    
+                
    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.
    
+            
    
+            
    Finalization 
    
+                
    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).
    
+                
    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.
    
+                
    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.
    
+                
    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.
    
+                
    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.
    
+            
    
+            
    Payment Cancellation 
    
+                
    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.
    
+                
    Cancellation requires the sender to know the ephemeral spending key. If the sender has lost this state, it can be recovered deterministically (see Recovery From Wallet Crash, below).
    
+            
    
+            
    Status View 
    
+                
    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 Pending inbound payment, and MAY offer the ability to cancel any outbound payment.
    
+                
    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.
    
+            
    
+            
    Recovery From Wallet Crash 
    
+                
    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.
    
+                
    We define a “gap limit” N, similar to the “address gap limit” in BIP 44. If a wallet implementation observes N 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.
    
+                
    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 ivks, and the likelihood of missing on-chain funds due to out-of-order payment URI generation, we specify a standard gap limit of N = 3.
    
+                
    The process for determining the position of this gap during wallet recovery is as follows:
    
+                
      
+                    
    • Derive the first N payment URI keys.
      • 
+                    
    • Derive the N ivks corresponding to these keys via the process defined in 3 Section 4.2.2 (setting sk = key).
      • 
+                    
    • Scan the chain for spent nullifiers (for the wallet's own notes, or any payment URI notes it currently knows about). This is part of the normal chain-scanning process for wallets.
      • 
+                    
    • When a nullifier is detected as spent, trial-decrypt every output of the corresponding transaction with the current set of payment URI ivks. If a note is detected:
+                        
        
+                            
      • Store the note details along with the corresponding payment URI (which can be derived from the note).
        • 
+                            
      • Add the note's nullifier to the set of wallet nullifiers (to enable discovery of funded payment URIs that the sender has recalled).
        • 
+                            
      • Drop the ivk from the set of current payment URI ivks.
        • 
+                            
      • Derive the next ivk in line, and add it to the set.
        • 
+                        
      
+                    
      • 
+                
    
+                
    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 ivks within the set of ivks 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 N = 3, and a wallet with one Sapling account).
    
+            
    
+        
    
+        
    Security Considerations 
    
+            
      
+                
    • 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.
+                    
        
+                        
      • The Payment-Encapsulating URI is like a magic spell that will teleport the money to the first person that clicks it and then does "finalize".
        • 
+                    
      
+                
      • 
+                
    • URI-Encapsulated Payments may be captured by malicious local apps on the sender or receiver's platform, e.g., by screen capturing or clipboard eavesdropping. Wallet apps should use the platform's interaction and communication facilities in a way that minimizes these risks (e.g., use the “Share” API rather than a clipboard that is visible to all apps).
      • 
+                
    • Likewise, if the URI is transferred by presenting and optically scanning a QR code, anyone who observes this QR code may be able to finalize the payment and thus take ownership of the funds before the intended recipient. For example, an attacker may use a telephoto lens aimed at a point-of-sale terminal to steal QR-encoded payments sent to that terminal.
      • 
+                
    • Users may have casually-established communication channels (e.g., they have entered the phone number of a new contact without bothering to double-check it), but may later mistakenly consider these to be adequately-authenticated secure channels for the purpose of sending Payment-Encapsulating URI. Wallet apps should mitigate this where feasible, e.g., by indicating that the chosen messaging channel is previously-unused and thus should be more carefully checked.
      • 
+                
    • Users may incorrectly believe that the payment has been irrevocably received even though they have not invoked the finalization procedure, or even though the finalization procedure has failed. Wallet software should correctly convey the status and set expectations, as discussed above.
      • 
+                
    • Payment recipients may not notice the incoming payment notification and act on it (i.e., invoke finalization) in a timely fashion. By the time they see it, the payment may have been cancelled by the sender.
      • 
+                
    • Users may not understand that URI-Encapsulated Payments are for one-time use, and attempt to use the same URI for multiple people or payments, resulting in race conditions on who receives the funds.
      • 
+                
    • Users may confuse URI-Encapsulated Payments (as specified in the current ZIP) with Payment Request URIs of the form zcash:payment-address?amount=... as specified in ZIP 321 4. Normally these serve different workflows, and work in opposing directions (send vs. receive of funds), and thus ought to not arise in ambiguous context. Wallet apps should take care to not create or send a Payment-Encapsulating URI (which is for sending funds) in a context where the user may be intending to receive funds.
      • 
+                
    • Users may attempt to use a Payment-Encapsulating URI as a “cold wallet”, e.g., by writing the URI on paper and putting it in a safe. This is dangerous. The spending key is known to the sending wallet at the time when the URI is produced, and possibly also at other times (e.g., if there are storage remnants, or if deterministic derivation is used; see “Ephemeral key derivation” below). Thus, an adversary who compromises the sending wallet may drain the cold wallet.
      • 
+                
    • The act and timing of finalizing a payment is visible to the sender, which may be a privacy leak. Likewise, if the on-chain transactions are sent in advance, their timing can be linked to the later payment, which may be a privacy leak.
      • 
+                
    • The payment amount is readily visible to anyone who observes the Payment-Encapsulating URI, even in retrospect after payment has already been finalized (e.g., if their device or chat log backups are later compromised). This may be a privacy concern, and in particular may put recipients of large payments at risk of undesired attention.
      • 
+                
    • Users attempting to follow URI-Encapsulated Payments as a regular HTTPS hyperlink may inadvertently leak the payment information to a remote attacker, if all layers of defense listed in Rationale for URI Format are somehow breached.
      • 
+                
    • The owner of the withzcash.com domain effectively controls the whitelist of apps that may be launched by users' platform to handle URI-Encapsulated Payments using the applink mechanism. If the whitelist is too permissive and includes a malicious or vulnerable app, and a user installs that app (which itself may be subject to the platform vendor's app review mechanism), then the user is placed at risk of having their payments intercepted by an attacker. Conversely, if the whitelist is too restrictive, or altogether unavailable, then users would not be able to trigger desirable wallet apps by simply following links, and would need to instead ”share” the message containing the URI into their wallet app (note that, as discussed above, clipboard copy-and-paste is insecure).
      • 
+                
    • 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.
      • 
+            
    
+        
    
+        
    Design Decisions and Rationale 
    
+            
    Rationale for URI Format 
    
+                
    The URI format https://pay.withzcash.com:65536/v1#... was chosen to allow automatic triggering of wallet software on mobile devices, using the platform's applink 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:
    
+                
      
+                    
    • The pay.withzcash.com domain should not resolve.
      • 
+                    
    • A valid TLS certificate for pay.withzcash.com should not exist..
      • 
+                    
    • The port number 65536 is not valid for the TCPv4, TCPv6 or UDP protocols. Empirically, the common behavior in browsers and messaging apps, when following HTTPS links with port number port number 65536, is to render an empty or about:blank page rather than a DNS error; a network fetch is not triggered. (This may change if a network proxy protocol is used, but SOCKS5 also cannot represent port 65536.)
      • 
+                    
    • The contents of the fragment identifier are specified by HTTP as being resolved locally, rather than sent over the network (but see the caveat about active JavaScript attacks below).
      • 
+                
    
+                
    The downside is that if the user follows the link prior to installing a suitable wallet app, they get a weird-looking DNS error or a blank page. Also, the URL looks weird due to the port number.
    
+                
    Several alternatives were considered, but found to have inferior usability and/or security ramifications:
    
+                
      
+                    
    1. https://pay.withzcash.com/v1#...: similar to above, but without the port number, and backed by a DNS record, TLS certificate and web server for pay.withzcash.com that serves an informative HTML page (e.g., “Please install a wallet to receive this payment”). This still allows handling by wallet apps using an applink mechanism, and provides a friendlier fallback in case the user follows the link prior to installing a suitable app. However, it creates a security risk. If the web server serving that web page is compromised, or impersonated using an DNS+TLS attack, then the attacker can capture they payment parameters and steal the funds. (Note that the sensitive information is in the fragment following the #, which is not sent in an HTTP GET request; but the malicious server can serve JavaScript code which retrieves the fragment.)
      2. 
+                    
    2. zcash-data:payment/v1?amount=1.23&desc=Payment+for+foo&key=...: a custom URI scheme, such as zcash-data. This still allows for triggering application action (e.g., using Mobile Deep Links). However, on most platorms, any app installed on the device is able to register to handle links from (almost) any custom URI scheme. If the request is received by a rogue party, then the funds could be stolen. Even if received by an honest operator, funds could be stolen if they are compromised. Also, custom URI schemes are not linkified when displayed in some messaging apps.
+                        
      Note the use of the zcash-data URI scheme, rather than the more elegant zcash, because URIs of the form zcash:address?... are already used to specify Zcash addresses and payment requests in ZIP 321 4, by analogy to the bitcoin URIs of BIP 21. An alternative is to use zcash:v1/payment?...; legacy software may parse this as a payment request to the address v1, which is invalid. Another alternative is to use zcash-payment:v1?..., which is appealing in terms of length and readability, but may be gratuitous pollution of the URI scheme namespace.
      
+                    
      3. 
+                
    
+                
    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.
    
+            
    
+            
    Identifying Notes 
    
+                
    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.
    
+                
    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.
    
+                
    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).
    
+                
    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:
    
+                
    
+                    \(\hspace{0.9em}\)
+                0. Explicitly list the note commitments within the URI.
    
+                
      
+                    
    1. 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.
      2. 
+                    
    2. 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).
      3. 
+                    
    3. 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).
      4. 
+                    
    4. 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.
      5. 
+                
    
+            
    
+            
    Additional rationale 
    
+                
      
+                    
    1. 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.
      2. 
+                    
    2. 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.
      3. 
+                    
    3. We do not include the sender or receiver's identity in the URI, because the sending wallet many not know the name of who it is sending to (or even from). Moreover there is the risk that fraudulent sender/recipient information could be used. If necessitated by circumstances (e.g., the FinCEN "Travel Rule" 8), claimed sender and recipient identity can be included in desc parameter.
      4. 
+                
    
+            
    
+        
    
+        
    Open Questions 
    
+            
    URI Usability 
    
+                
    The URI could be changed in several ways due to usability concerns:
    
+                
      
+                    
    1. It may be desirable to prevent the amount and desc 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).
      2. 
+                    
    2. Perhaps the URI should be contain the phrase “password” early on (e.g., zcash-data:/payment/v1/password=, as a cue that this string must be kept secret. (Note that technically nothing here is a password in the usual sense of the term.)
      3. 
+                    
    3. Perhaps we should actually use BIP 39 words as an actual password. So you could memorize it or read it over the phone. The BIP 39 words can be embedded in the URI itself (which is highly unusual):
+                        
      zcash-data:payment/v1/password=witch+collapse+practice+feed+shame+open+despair+creek+road+again+ice+least
      
+                        
      or
      
+                        
      zcash-data:payment/v1/password=WitchCollapsePracticeFeedShameOpenDespairCreekRoadAgainIceLeast
      
+                        
      This provides an additional cue that the URI contains a sensitive password (for users who are accustomed to BIP 39 style word lists; to others the Base 64 encoding may be more evocative of a password). Moreover, users may discover the fact that they can manually send these words to recipients, in writing or verbally, as a way to send money without a textual messaging service. Alternatively, the BIP 39 words can be used as an alternative syntax for the encapsulation, without the confusing-to-humans URI syntax (but generating this alternative syntax this may complicate the UI).
      
+                    
      4. 
+                
    
+            
    
+            
    Note retrieval 
    
+                
    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.
    
+            
    
+            
    Other Questions 
    
+                
    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)?
    
+                
    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?
    
+            
    
+        
    
+        
    References 
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    2Uniform Resource Identifier (URI): Generic Syntax
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    3Zcash Protocol Specification, Version 2023.4.0 or later
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    4ZIP 321: Payment Request URIs
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
+            
+                
+                    
+                        
+                        
+                    
+                
+            
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    7Microsoft Universal Windows Platform Documentation: Enable apps for websites using app URI handlers
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    8FinCEN Guidance FIN-2019-G001. May 9, 2019. Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies
    
+        
    
+        
    Publication Blockers 
    
+            
      
+                
    • Clean up semantics.
      • 
+                
    • Clean up rationale.
      • 
+            
    
+        
    
+    
    
+
+
\ No newline at end of file
diff --git a/zip-0332.html b/rendered/zip-0332.html
similarity index 90%
rename from zip-0332.html
rename to rendered/zip-0332.html
index d016de120..60c742bdd 100644
--- a/zip-0332.html
+++ b/rendered/zip-0332.html
@@ -9,7 +9,7 @@
         
    ZIP: 332
 Title: Wallet Recovery from zcashd HD Seeds
 Owners: Kris Nuttycombe <kris@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/675>
    
diff --git a/zip-0339.html b/rendered/zip-0339.html
similarity index 88%
rename from zip-0339.html
rename to rendered/zip-0339.html
index 598685051..ff4297622 100644
--- a/zip-0339.html
+++ b/rendered/zip-0339.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 339
 Title: Wallet Recovery Words
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/364>
    
diff --git a/zip-0400.html b/rendered/zip-0400.html
similarity index 100%
rename from zip-0400.html
rename to rendered/zip-0400.html
diff --git a/zip-0401.html b/rendered/zip-0401.html
similarity index 99%
rename from zip-0401.html
rename to rendered/zip-0401.html
index 9061762f3..aaec293e4 100644
--- a/zip-0401.html
+++ b/rendered/zip-0401.html
@@ -9,7 +9,7 @@
     
    
         
    ZIP: 401
 Title: Addressing Mempool Denial-of-Service
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Active
 Category: Network
 Created: 2019-09-09
diff --git a/zip-0402.html b/rendered/zip-0402.html
similarity index 100%
rename from zip-0402.html
rename to rendered/zip-0402.html
diff --git a/zip-0403.html b/rendered/zip-0403.html
similarity index 100%
rename from zip-0403.html
rename to rendered/zip-0403.html
diff --git a/zip-0416.html b/rendered/zip-0416.html
similarity index 92%
rename from zip-0416.html
rename to rendered/zip-0416.html
index afc4201bb..00519ad24 100644
--- a/zip-0416.html
+++ b/rendered/zip-0416.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 416
 Title: Support for Unified Addresses in zcashd
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
diff --git a/zip-1001.html b/rendered/zip-1001.html
similarity index 100%
rename from zip-1001.html
rename to rendered/zip-1001.html
diff --git a/zip-1002.html b/rendered/zip-1002.html
similarity index 100%
rename from zip-1002.html
rename to rendered/zip-1002.html
diff --git a/zip-1003.html b/rendered/zip-1003.html
similarity index 100%
rename from zip-1003.html
rename to rendered/zip-1003.html
diff --git a/zip-1004.html b/rendered/zip-1004.html
similarity index 100%
rename from zip-1004.html
rename to rendered/zip-1004.html
diff --git a/zip-1005.html b/rendered/zip-1005.html
similarity index 100%
rename from zip-1005.html
rename to rendered/zip-1005.html
diff --git a/zip-1006.html b/rendered/zip-1006.html
similarity index 100%
rename from zip-1006.html
rename to rendered/zip-1006.html
diff --git a/zip-1007.html b/rendered/zip-1007.html
similarity index 100%
rename from zip-1007.html
rename to rendered/zip-1007.html
diff --git a/zip-1008.html b/rendered/zip-1008.html
similarity index 100%
rename from zip-1008.html
rename to rendered/zip-1008.html
diff --git a/zip-1009.html b/rendered/zip-1009.html
similarity index 100%
rename from zip-1009.html
rename to rendered/zip-1009.html
diff --git a/zip-1010.html b/rendered/zip-1010.html
similarity index 99%
rename from zip-1010.html
rename to rendered/zip-1010.html
index 707f57cf4..222d6b127 100644
--- a/zip-1010.html
+++ b/rendered/zip-1010.html
@@ -167,7 +167,7 @@
                 
                     
                         6
-                        ZF Grants — Funding for Zcash ecosystem projects
+                        ZF Grants — Funding for Zcash ecosystem projects
                     
                 
             
diff --git a/zip-1011.html b/rendered/zip-1011.html
similarity index 100%
rename from zip-1011.html
rename to rendered/zip-1011.html
diff --git a/zip-1012.html b/rendered/zip-1012.html
similarity index 100%
rename from zip-1012.html
rename to rendered/zip-1012.html
diff --git a/zip-1013.html b/rendered/zip-1013.html
similarity index 100%
rename from zip-1013.html
rename to rendered/zip-1013.html
diff --git a/zip-1014.html b/rendered/zip-1014.html
similarity index 99%
rename from zip-1014.html
rename to rendered/zip-1014.html
index bd2dcbf1f..570b3d49b 100644
--- a/zip-1014.html
+++ b/rendered/zip-1014.html
@@ -14,7 +14,7 @@
 Credits: Matt Luongo
          @aristarchus
          @dontbeevil
-         Daira Emma Hopwood
+         Daira-Emma Hopwood
          George Tankersley
          Josh Cincinnati
          Andrew Miller
diff --git a/rendered/zip-2001.html b/rendered/zip-2001.html
new file mode 100644
index 000000000..4677832e3
--- /dev/null
+++ b/rendered/zip-2001.html
@@ -0,0 +1,113 @@
+
+
+
+    ZIP 2001: Lockbox Funding Streams
+    
+    
+
+
+    
    
+        
    ZIP: 2001
+Title: Lockbox Funding Streams
+Owners: Kris Nuttycombe <kris@nutty.land>
+Credits: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+         Jack Grigg <jack@electriccoin.co>
+Status: Draft
+Category: Consensus
+Created: 2024-07-02
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/>
    
+        
    Terminology 
    
+            
    The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
+        
    
+        
    Abstract 
    
+            
    This ZIP specifies a change to the Zcash consensus protocol to define a pool of issued Zcash value to be used to fund future development efforts within the Zcash ecosystem.
    
+            
    This ZIP builds upon the funding stream mechanism defined in ZIP 207 3. It defines a new "DEFERRED_POOL" funding stream type such that portions of the block reward sent to a stream of this type are deposited directly into the deferred funding pool instead of being sent to a recipient address. Other ways of adding to the pool, such as allowing for direct deposits or fee value currently allocated to miners may be defined in the future.
    
+        
    
+        
    Motivation 
    
+            
    In accordance with ZIP 1014, 2 the Zcash block reward is allocated with 80% going to miners, and the remaining 20% distributed among the Major Grants Fund (8%), Electric Coin Company (ECC) (7%), and the Zcash Foundation (ZF) (5%). This funding structure supports various essential activities such as protocol development, security, marketing, and legal expenses. However, this model will expire in November 2024, leading to the entire block reward being allocated to miners if no changes are made.
    
+            
    Several draft ZIPs under consideration for replacing the existing direct allocation of block rewards suggest that part of the block reward be directed to a reserve, the distribution of which is to be determined via a future ZIP. This ZIP is intended to provide a common mechanism that can be used to implement these various proposals.
    
+        
    
+        
    Requirements 
    
+            
    The Zcash protocol will maintain a new Deferred chain pool value balance
+                \(\mathsf{PoolValue}_{Deferred}\)
+             for the deferred funding pool, in much the same fashion as it maintains chain pool value balances for the transparent, Sprout, Sapling, and Orchard pools.
    
+            
    The funding stream mechanism defined in ZIP 207 3 is modified such that a funding stream may deposit funds into the deferred pool.
    
+        
    
+        
    Specification 
    
+            
    Deferred Development Fund Chain Value Pool Balance 
    
+                
    Full node implementations MUST track an additional
+                    \(\mathsf{PoolValue}_{Deferred}\)
+                 chain value pool balance, in addition to the Sprout, Sapling, and Orchard chain value pool balances. This balance is set to zero prior to the activation of Network Upgrade 6.
    
+                
    ZIP 207 3 is modified as follows:
    
+                
    In the section Funding streams 4, instead of:
    
+                
    
+                    
    Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.
    
+                
    
+                
    it will be modified to read:
    
+                
    
+                    
    Each funding stream has an associated sequence of recipients, each of which MUST be either a transparent P2SH address, a Sapling address, or the identifier DEFERRED_POOL.
    
+                
    
+                
    In the section Consensus rules 5, the following will be added:
    
+                
    
+                    
    The "prescribed way" to pay to the DEFERRED_POOL is to add
+                        \(\mathsf{FundingStream[FUND].Value}(\mathsf{height})\)
+                     to
+                        \(\mathsf{PoolValue}_{Deferred}\)
+                    .
    
+                
    
+                
    The protocol specification is modified to define the "total issued supply" such that the total issued supply as of a given height is given by the function:
    
+                
    \(\begin{array}{ll}
+\mathsf{IssuedSupply}(\mathsf{height}) := &\!\!\!\!\mathsf{PoolValue}_{Transparent}(\mathsf{height}) \\
+&+\;\; \mathsf{PoolValue}_{Sprout}(\mathsf{height}) \\
+&+\,\; \mathsf{PoolValue}_{Sapling}(\mathsf{height}) \\
+&+\,\; \mathsf{PoolValue}_{Orchard}(\mathsf{height}) \\
+&+\,\; \mathsf{PoolValue}_{Deferred}(\mathsf{height})
+\end{array}\)
    
+            
    
+        
    
+        
    References 
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    2ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    3ZIP 207: Funding Streams
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    4ZIP 207: Funding Streams. Section: Funding streams
    
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    5ZIP 207: Funding Streams. Section: Consensus rules
    
+        
    
+    
    
+
+
\ No newline at end of file
diff --git a/rendered/zip-guide-markdown.html b/rendered/zip-guide-markdown.html
new file mode 100644
index 000000000..b9121a6d1
--- /dev/null
+++ b/rendered/zip-guide-markdown.html
@@ -0,0 +1,125 @@
+
+
+
+    ZIP guide-markdown: {Something Short and To the Point}
+    
+    
+    
+
+
+
    ZIP: Unassigned {numbers are assigned by ZIP editors}
+Title: {Something Short and To the Point}
+Owners: First Owner <email>
+        ...
+Credits: First Credited
+         ...
+Status: Draft
+Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational | Process}
+Created: yyyy-mm-dd
+License: {usually MIT}
+Pull-Request: <https://github.com/zcash/zips/pull/???>
    
+
    Don’t Panic
    
+
    If this is your first time writing a ZIP, the structure and format may look intimidating. But really, it’s just meant to reflect common-sense practice and some technical conventions. Feel free to start with a simple initial draft that gets ideas across, even if it doesn’t quite follow this format. The community and ZIP editors will help you figure things out and get it into shape later.
    
+
    {Delete this section.}
    
+
    Terminology
    
+
    {Edit this to reflect the key words that are actually used.} The key words “MUST”, “REQUIRED”, “MUST NOT”, “SHOULD”, and “MAY” in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
+
    {Avoid duplicating definitions from other ZIPs. Instead use wording like this:}
    
+
    The terms “Mainnet” and “Testnet” in this document are to be interpreted as defined in the Zcash protocol specification 2.
    
+
    The term “full validator” in this document is to be interpreted as defined in the Zcash protocol specification 3.
    
+
    The terms below are to be interpreted as follows:
    
+
    
+
    {Term to be defined}
    
+
    {Definition.}
    
+
    
+
    {Another term}
    
+
    {Definition.}
    
+
    
+
    
+
    Abstract
    
+
    {Describe what this proposal does, typically in a few paragraphs.
    
+
    The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.
    
+
    Use links where applicable, e.g. 4 5.}
    
+
    Motivation
    
+
    {Why is this proposal needed?
    
+
    This is one of the most important sections of the ZIP, and should be detailed and comprehensive. It shouldn’t include any of the actual specification – don’t put conformance requirements in this section.
    
+
    Explain the status quo, why the status quo is in need of improvement, and if applicable, the history of how this area has changed. Then describe at a high level why this proposed solution addresses the perceived issues. It is ok if this is somewhat redundant with the abstract, but here you can go into a lot more detail.}
    
+
    Requirements
    
+
    {Describe design constraints on, or goals for the solution – typically one paragraph for each constraint or goal. Again, don’t actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements.}
    
+
    Non-requirements
    
+
    {This section is entirely optional. If it is present, it describes issues that the proposal is not attempting to address, that someone might otherwise think it does or should.}
    
+
    Specification
    
+
    {Replace this entire section.}
    
+
    The Specification section describes what should change, using precise language and conformance key words. Anything that is required in order to implement the ZIP (or follow its process, in the case of a Process ZIP) should be in this section.
    
+
    Avoid overspecification! Also avoid underspecification. Specification is hard. Don’t be afraid to ask for help.
    
+
    Feel free to copy from other ZIPs doing similar things, e.g. defining RPC calls, consensus rules, etc.
    
+
    ZIPs MUST take into account differences between the Zcash Mainnet and Testnet 6 where applicable. A consensus ZIP MUST be able to be deployed on both Mainnet and Testnet.
    
+
    Unless the specification is particularly simple, you will need to organise it under subheadings.
    
+
    Example subheading
    
+
    At least while the ZIP is in Draft, we encourage writing open questions and TODOs.
    
+
    Open questions
    
+
      
+
    • What happens if a full validator can’t parse the fandangle as a doohicky?
      • 
+
    
+
    TODO: define byte encoding for the Jabberwock.
    
+
    Comparison of ZIPs to RFCs
    
+
    Like RFCs, ZIPs are precise technical documents that SHOULD give enough implementation information to implement part of a Zcash-related protocol or follow a Zcash-related process 7.
    
+
    ZIPs are different from RFCs in the following ways:
    
+
      
+
    • Many (but not all) ZIPs are “living documents”; they are updated in-place as the relevant areas of the protocol or process change. Unlike in the RFC process, making a change in an area described by a published ZIP does not necessarily require creating a new ZIP, although that is an option if the change is extensive enough to warrant it.
      • 
+
    • The expected structure of a ZIP is more constrained than an RFC. For example, the Specification section is REQUIRED, and all of the conformance requirements MUST go in that section. The ZIP editors will help you to ensure that things go in the right sections.
      • 
+
    • Security considerations SHOULD be spread throughout the text, in the places where they are most relevant.
      • 
+
    
+
    Using mathematical notation
    
+
    Embedded LaTeX x + y is allowed and encouraged in ZIPs. The syntax for inline math is “:math:latex code`" in reStructuredText or "latexcode`” in Markdown. The rendered HTML will use KaTeX 8, which only supports a subset of LaTeX, so you will need to double-check that the rendering is as intended.
    
+
    In general the conventions in the Zcash protocol specification SHOULD be followed. If you find this difficult, don’t worry too much about it in initial drafts; the ZIP editors will catch any inconsistencies in review.
    
+
    Notes and warnings
    
+
    
+
    “.. note::” in reStructuredText, or “:::info” (terminated by “:::”) in Markdown, can be used for an aside from the main text.
    
+
    The rendering of notes is colourful and may be distracting, so they should only be used for important points.
    
+
    
+
    
+
    “.. warning::” in reStructuredText, or “:::warning” (terminated by “:::”) in Markdown, can be used for warnings.
    
+
    Warnings should be used very sparingly — for example to signal that a entire specification, or part of it, may be inapplicable or could cause significant interoperability or security problems. In most cases, a “MUST” or “SHOULD” conformance requirement is more appropriate.
    
+
    
+
    Valid markup
    
+
    This is optional before publishing a PR, but to check whether a document is valid reStructuredText or Markdown, first install rst2html5 and pandoc. E.g. on Debian-based distros::
    
+
    sudo apt install python3-pip pandoc perl sed
+pip3 install docutils==0.19 rst2html5
    
+
    Then, with draft-myzip.rst or draft-myzip.md in the root directory of a clone of this repo, run::
    
+
    make draft-myzip.html
    
+
    (or just “make”) and view draft-myzip.html in a web browser.
    
+
    Citations and references
    
+
    Each reference should be given a short name, e.g. “snark” 9. The syntax to cite that reference is “[#snark]_” in reStructuredText, or “[^snark]” in Markdown.
    
+
    The corresponding entry in the References section should look like this in reStructuredText:
    
+
    .. [#snark] `The Hunting of the Snark <https://www.gutenberg.org/files/29888/29888-h/29888-h.htm>_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
    
+
    or like this in Markdown::
    
+
    [^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
    
+
    Note that each entry must be on a single line regardless of how long that makes the line. In Markdown there must be a blank line between entries.
    
+
    The current rendering of a Markdown ZIP reorders the references according to their first use; the rendering of a reStructuredText ZIP keeps them in the same order as in the References section.
    
+
    To link to another section of the same ZIP, use
    
+
    `Section title`_
    
+
    in reStructuredText, or
    
+
    [Section title]
    
+
    in Markdown.
    
+
    Citing the Zcash protocol specification
    
+
    For references to the Zcash protocol specification, prefer to link to a section anchor, and name the reference as [^protocol-<anchor>]. This makes it more likely that the link will remain valid if sections are renumbered or if content is moved. The anchors in the protocol specification can be displayed by clicking on a section heading in most PDF viewers. References to particular sections should be versioned, even though the link will point to the most recent stable version.
    
+
    Do not include the “https://zips.z.cash/” part of URLs to ZIPs or the protocol spec.
    
+
    Reference implementation
    
+
    {This section is entirely optional; if present, it usually gives links to zcashd or zebrad PRs.}
    
+
    References
    
+
    
+
    
+
      
+
    1. Information on BCP 14 — “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels” and “RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”↩︎
      2. 
+
    2. Zcash Protocol Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet↩︎
      3. 
+
    3. Zcash Protocol Specification, Version 2022.3.8. Section 3.3: The Block Chain↩︎
      4. 
+
    4. Zcash Protocol Specification, Version 2022.3.8 or later↩︎
      5. 
+
    5. Zcash Protocol Specification, Version 2022.3.8. Section 1: Introduction↩︎
      6. 
+
    6. Zcash Protocol Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet↩︎
      7. 
+
    7. ZIP 0: ZIP Process↩︎
      8. 
+
    8. KaTeX - The fastest math typesetting library for the web↩︎
      9. 
+
    9. The Hunting of the Snark. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.↩︎
      10. 
+
    
+
    
+
+
diff --git a/zip-guide.html b/rendered/zip-guide.html
similarity index 81%
rename from zip-guide.html
rename to rendered/zip-guide.html
index b2bcdcff9..ccc02ec80 100644
--- a/zip-guide.html
+++ b/rendered/zip-guide.html
@@ -68,7 +68,7 @@
                 
    
             
    
             
    Comparison of ZIPs to RFCs 
    
-                
    Like RFCs, ZIPs are precise technical documents that SHOULD give enough implementation information to implement part of a Zcash-related protocol or follow a Zcash-related process.
    
+                
    Like RFCs, ZIPs are precise technical documents that SHOULD give enough implementation information to implement part of a Zcash-related protocol or follow a Zcash-related process 7.
    
                 
    ZIPs are different from RFCs in the following ways:
    
                 
      
                     
    • Many (but not all) ZIPs are "living documents"; they are updated in-place as the relevant areas of the protocol or process change. Unlike in the RFC process, making a change in an area described by a published ZIP does not necessarily require creating a new ZIP, although that is an option if the change is extensive enough to warrant it.
      • 
@@ -79,7 +79,7 @@
             
      Using mathematical notation 
      
                 
      Embedded
                     \(\LaTeX\)
-                 is allowed and encouraged in ZIPs. The syntax for inline math is ":math:`latex code`" in reStructuredText or "$latex code$" in Markdown. The rendered HTML will use KaTeX 6, which only supports a subset of
+                 is allowed and encouraged in ZIPs. The syntax for inline math is ":math:`latex code`" in reStructuredText or "$latex code$" in Markdown. The rendered HTML will use KaTeX 6, which only supports a subset of
                     \(\LaTeX\!\)
                 , so you will need to double-check that the rendering is as intended.
      
                 
      In general the conventions in the Zcash protocol specification SHOULD be followed. If you find this difficult, don't worry too much about it in initial drafts; the ZIP editors will catch any inconsistencies in review.
      
@@ -94,15 +94,25 @@
                     
      Warnings should be used very sparingly — for example to signal that a entire specification, or part of it, may be inapplicable or could cause significant interoperability or security problems. In most cases, a "MUST" or "SHOULD" conformance requirement is more appropriate.
      
                 
             
      
-            
      Valid reStructuredText 
      
-                
      This is optional before publishing a PR, but to check whether a document is valid reStructuredText, first install rst2html5. E.g. on Debian-based distros:
      
+            
      Valid markup 
      
+                
      This is optional before publishing a PR, but to check whether a document is valid reStructuredText or Markdown, first install rst2html5 and pandoc. E.g. on Debian-based distros:
      
                 
      sudo apt install python3-pip pandoc perl sed
 pip3 install docutils==0.19 rst2html5
      
-                
      Then, with zip-xxxx.rst in the root directory of a clone of this repo, run:
      
-                
      make zip-xxxx.html
      
-                
      (or just make) and view zip-xxxx.html in a web browser.
      
+                
      Then, with draft-myzip.rst or draft-myzip.md in the root directory of a clone of this repo, run:
      
+                
      make draft-myzip.html
      
+                
      (or just "make") and view draft-myzip.html in a web browser.
      
             
      
-            
      Conventions for references 
      
+            
      Citations and references 
      
+                
      Each reference should be given a short name, e.g. "snark" 8. The syntax to cite that reference is "[#snark]_" in reStructuredText, or "[^snark]" in Markdown.
      
+                
      The corresponding entry in the References section should look like this in reStructuredText:
      
+                
      .. [#snark] `The Hunting of the Snark <https://www.gutenberg.org/files/29888/29888-h/29888-h.htm>`_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
      
+                
      or like this in Markdown:
      
+                
      [^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
      
+                
      Note that each entry must be on a single line regardless of how long that makes the line. In Markdown there must be a blank line between entries.
      
+                
      The current rendering of a Markdown ZIP reorders the references according to their first use; the rendering of a reStructuredText ZIP keeps them in the same order as in the References section.
      
+                
      To link to another section of the same ZIP, use "`Section title`_" in reStructuredText, or "[Section title]" in Markdown.
      
+            
      
+            
      Citing the Zcash protocol specification 
      
                 
      For references to the Zcash protocol specification, prefer to link to a section anchor, and name the reference as [#protocol-<anchor>]. This makes it more likely that the link will remain valid if sections are renumbered or if content is moved. The anchors in the protocol specification can be displayed by clicking on a section heading in most PDF viewers. References to particular sections should be versioned, even though the link will point to the most recent stable version.
      
                 
      Do not include the "https://zips.z.cash/" part of URLs to ZIPs or the protocol spec.
      
             
      
@@ -167,6 +177,14 @@
                     
                 
             
+            
+                
+                    
+                        
+                        
+                    
+                
+            
      8The Hunting of the Snark. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
      
         
      
     
      
 
diff --git a/zip-0311.html b/zip-0311.html
deleted file mode 100644
index 9d6a86e98..000000000
--- a/zip-0311.html
+++ /dev/null
@@ -1,17 +0,0 @@
-
-
-
-    ZIP 311: Sapling Payment Disclosure
-    
-
-
-    
      
-        
      ZIP: 311
-Title: Sapling Payment Disclosure
-Owners: Deirdre Connolly <deirdre@zfnd.org>
-Status: Reserved
-Category: Standards / RPC / Wallet
-Discussions-To: <https://github.com/zcash/zips/issues/387>
      
-    
      
-
-
\ No newline at end of file
diff --git a/zip-0311.rst b/zip-0311.rst
deleted file mode 100644
index 94b7b0e88..000000000
--- a/zip-0311.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-::
-
-  ZIP: 311
-  Title: Sapling Payment Disclosure
-  Owners: Deirdre Connolly 
-  Status: Reserved
-  Category: Standards / RPC / Wallet
-  Discussions-To: 
diff --git a/zip-0312.html b/zip-0312.html
deleted file mode 100644
index c5d670b15..000000000
--- a/zip-0312.html
+++ /dev/null
@@ -1,16 +0,0 @@
-
-
-
-    ZIP 312: Shielded Multisignatures using FROST
-    
-
-
-    
      
-        
      ZIP: 312
-Title: Shielded Multisignatures using FROST
-Status: Reserved
-Category: Standards / RPC / Wallet
-Discussions-To: <https://github.com/zcash/zips/issues/382>
      
-    
      
-
-
\ No newline at end of file
diff --git a/zip-0312.rst b/zip-0312.rst
deleted file mode 100644
index 8f9c3c400..000000000
--- a/zip-0312.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-::
-
-  ZIP: 312
-  Title: Shielded Multisignatures using FROST
-  Status: Reserved
-  Category: Standards / RPC / Wallet
-  Discussions-To: 
diff --git a/zip-0315.html b/zip-0315.html
deleted file mode 100644
index 77fa48678..000000000
--- a/zip-0315.html
+++ /dev/null
@@ -1,18 +0,0 @@
-
-
-
-    ZIP 315: Best Practices for Wallet Handling of Multiple Pools
-    
-
-
-    
      
-        
      ZIP: 315
-Title: Best Practices for Wallet Handling of Multiple Pools
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
-        Jack Grigg <jack@electriccoin.co>
-Status: Reserved
-Category: Wallet
-Discussions-To: <https://github.com/zcash/zips/issues/447>
      
-    
      
-
-
\ No newline at end of file
diff --git a/zip-0315.rst b/zip-0315.rst
deleted file mode 100644
index 141cac408..000000000
--- a/zip-0315.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-::
-
-  ZIP: 315
-  Title: Best Practices for Wallet Handling of Multiple Pools
-  Owners: Daira Emma Hopwood 
-          Jack Grigg 
-  Status: Reserved
-  Category: Wallet
-  Discussions-To: 
diff --git a/zip-0320.html b/zip-0320.html
deleted file mode 100644
index 5cd39958f..000000000
--- a/zip-0320.html
+++ /dev/null
@@ -1,369 +0,0 @@
-
-
-
-    ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses
-    
-    
-
-
-    
      
-        
      ZIP: 320
-Title: Defining an Address Type to which funds can only be sent from Transparent Addresses
-Owners: Daira-Emma Hopwood <daira@electriccoin.co>
-        Kris Nuttycombe <kris@nutty.land>
-Credits: Hanh
-Status: Draft
-Category: Standards / Wallet
-Created: 2024-01-12
-License: MIT
-Discussions-To: <https://github.com/zcash/zips/issues/757>
-Pull-Request: <https://github.com/zcash/zips/pull/760>
-              <https://github.com/zcash/zips/pull/766>
      
-        
      Terminology 
      
-            
      The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
      
-            
      The terms "Recipient", "Producer", "Consumer", "Sender", "Receiver", "Item", "Metadata Item", "Typecode", "Address", "Unified Address" (UA), "Unified Viewing Key" (UVK), "Unified Full Viewing Key" (UFVK), and "Unified Incoming Viewing Key" (UIVK) are to be interpreted as described in ZIP 316 5.
      
-            
      The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 11.
      
-        
      
-        
      Abstract 
      
-            
      This ZIP defines a new encoding for transparent Zcash addresses. Wallets must ensure that no shielded notes are spent in transactions that send to a transparent address encoded in the specified fashion.
      
-            
      This ZIP is presently in Draft status, and defines two alternate encodings for consideration. Analysis of the benefits and drawbacks of each of the proposed alternatives is presented at the end of this document.
      
-        
      
-        
      Background 
      
-            
      In November of 2023, the Zcash community received notice from the Binance cryptocurrency exchange that Zcash was at risk of being delisted from the exchange unless the community could provide a mechanism by which Binance could refuse deposits from shielded addresses and return them to the depositor. This issue was raised and discussed at length in the Zcash Community forum 2.
      
-            
      In the course of that discussion thread, wallet developer and community member @hanh 3 suggested a wallet-oriented approach 4 that involved defining a new encoding for Zcash transparent P2PKH addresses. A Consumer of such an address, whether it be a wallet or an exchange, could recognize this encoding as a directive that the wallet should only spend transparent funds when creating an output to that address.
      
-        
      
-        
      Motivation 
      
-            
      The Binance cryptocurrency exchange requires that funds sent to their deposit addresses come from source addresses that are readily identifiable using on-chain information, such that if necessary funds may be rejected by sending them back to the source address(es). This ZIP is intended to standardize a transparent address encoding that is not yet understood by preexisting Consumers, in order to prevent inadvertent shielded spends when sending to such addresses. Then, Consumers that upgrade to support the new encoding will do so with the understanding that they must respect the restrictions on sources of funds described in this ZIP.
      
-        
      
-        
      Requirements 
      
-            
        
-                
      1. A Recipient wishing to receive funds from exclusively transparent sources must be able to generate a receiving address such that only transparent funds will be spent in transactions with an output to this address.
        2. 
-                
      2. Wallets and other Consumers that have not been upgraded to recognize the new address format cannot mistake the address for another address type or inadvertently send shielded funds to the address.
        3. 
-                
      3. No changes to Recipient infrastructure beyond changes to address encoding and decoding should be required as a consequence of this ZIP.
        4. 
-            
      
-        
      
-        
      Alternative 1 
      
-            
      This alternative was suggested by @hanh in 4.
      
-            
      TEX Addresses 
      
-                
      A TEX Address is a Bech32m 16 reencoding of a transparent Zcash P2PKH address 12.
      
-            
      
-            
      Motivations for Alternative 1 
      
-                
      The TEX Address is the simplest possible approach to creating a new address type that indicates that only transparent sources of funds should be used.
      
-            
      
-            
      Specification (Alternative 1) 
      
-                
      A TEX address is produced from a Mainnet Zcash P2PKH Address by executing the following steps:
      
-                
        
-                    
      1. Decode the address to a byte sequence using the Base58Check decoding algorithm 14.
        2. 
-                    
      2. If the length of the resulting byte sequence is not 22 bytes or if its two-byte address prefix is not
-                        \([\mathtt{0x1C}, \mathtt{0xB8}]\)
-                    , return an error. Otherwise, let the validating key hash be the remaining 20 bytes of the sequence after removing the two-byte address prefix.
        3. 
-                    
      3. Reencode the 20-byte validating key hash using the Bech32m encoding defined in 16 with the human-readable prefix (HRP) "tex".
        4. 
-                
      
-                
      For Testnet addresses, the required lead bytes of a P2PKH address in step 2 are
-                    \([\mathtt{0x1D}, \mathtt{0x25}]\)
-                , and the "textest" HRP is used when reencoding in step 3.
      
-                
      Wallets and other Senders sending to a TEX address (as any output) MUST ensure that only transparent UTXOs are spent in the creation of a transaction.
      
-            
      
-            
      Reference Implementation (Alternative 1) 
      
-                
      Javascript:
      
-                
      import bs58check from 'bs58check'
-import {bech32m} from 'bech32'
-
-// From t1 to tex
-var b58decoded = bs58check.decode('t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC')
-console.assert(b58decoded.length == 22, 'Invalid length');
-console.assert(b58decoded[0] == 0x1C && b58decoded[1] == 0xB8, 'Invalid address prefix');
-var pkh = b58decoded.slice(2)
-var tex = bech32m.encode('tex', bech32m.toWords(pkh))
-console.log(tex)
-
-// From tex to t1
-var bech32decoded = bech32m.decode('tex1s2rt77ggv6q989lr49rkgzmh5slsksa9khdgte')
-console.assert(bech32decoded.prefix == 'tex', 'Invalid address prefix')
-var pkh2 = Uint8Array.from(bech32m.fromWords(bech32decoded.words))
-console.assert(pkh2.length == 20, 'Invalid length');
-var t1 = bs58check.encode(Buffer.concat([Uint8Array.from([0x1C, 0xB8]), pkh2]))
-console.log(t1)
      
-            
      
-        
      
-        
      Alternative 2 
      
-            
      Traceable Unified Addresses 
      
-                
      A Traceable Unified Address is a reencoding of a transparent Zcash P2PKH address into a Unified Address 6.
      
-            
      
-            
      Motivations for Alternative 2 
      
-                
      Traceable Unified Addresses fit into the Zcash Unified Address ecosystem defined by ZIP 316, Revision 1 7. Existing Consumers of Unified Addresses will not be able to send to these address unless they update their code to understand the new MUST-understand Metadata Typecode defined in this ZIP.
      
-                
      By integrating with the Unified Address framework, it becomes possible for the addresses being generated to include extra metadata; in particular, metadata items such as an Address Expiry Height or Address Expiry Date 9 may be included. For exchange use cases such as Binance's, it is useful to ensure that an address provided to a user has a limited utility life, such that after expiration the user must obtain a new address in order to be able to continue to send funds 13.
      
-            
      
-            
      Specification (Alternative 2) 
      
-                
      Upon activation of this ZIP, the section Metadata Items of ZIP 316 10 will be modified to define a new MUST-understand Metadata Item type: Source Restriction Metadata, having Typecode
-                    \(\mathtt{0xE2}\)
-                , the value of which MUST be a single byte:
      
-                
        
-                    
      • 
-                        \(\mathtt{0x00}\)
-                     - Transparent Source Only
        • 
-                
      
-                
      Additional Source Restriction Metadata values can be defined in the future, but a Consumer that does not recognise the value MUST reject the entire UA/UVK as invalid.
      
-                
      The "Requirements for both Unified Addresses and Unified Viewing Keys" section of ZIP 316 8 will be modified as follows — the text:
      
-                
      
-                    
      A Unified Address or Unified Viewing Key MUST contain at least one shielded Item (Typecodes
-                        \(\mathtt{0x02}\)
-                     and
-                        \(\mathtt{0x03}\)
-                    ). The rationale is that the existing P2SH and P2PKH transparent-only address formats, and the existing P2PKH extended public key format, suffice for representing transparent Items and are already supported by the existing ecosystem.
      
-                
      
-                
      will be replaced by:
      
-                
      
-                    
      A Unified Address or Unified Viewing Key MUST either:
      
-                    
        
-                        
      • contain at least one shielded Item (Typecodes
-                            \(\mathtt{0x02}\)
-                         and
-                            \(\mathtt{0x03}\)
-                        ), and no Source Restriction Metadata Item having value
-                            \(\mathtt{0x00}\)
-                        ; or
        • 
-                        
      • contain both a Transparent Item (Typecode
-                            \(\mathtt{0x00}\)
-                         or Typecode
-                            \(\mathtt{0x01}\)
-                        ) and a Source Restriction Metadata Item (Typecode
-                            \(\mathtt{0xE2}\)
-                        ) having value
-                            \(\mathtt{0x00}\)
-                        , and no other non-Metadata Items.
        • 
-                    
      
-                
      
-                
      In the following, the “u+” Human Readable Part of Revision 1 Unified Addresses is a placeholder value, pending the finalization of Revision 1 7.
      
-                
      A Traceable Unified Address is produced from a Mainnet Zcash P2PKH address by executing the following steps:
      
-                
        
-                    
      1. Decode the address to a byte sequence using the Base58Check decoding algorithm 14.
        2. 
-                    
      2. If the length of the resulting byte sequence is not 22 bytes or if its two-byte address prefix is not
-                        \([\mathtt{0x1C}, \mathtt{0xB8}]\)
-                    , return an error. Otherwise, let the validating key hash be the remaining 20 bytes of the array after removing the two-byte address prefix.
        3. 
-                    
      3. Construct a new Revision 1 Unified Address using a single P2PKH Receiver
-                        \(\mathtt{0x04}\)
-                     with the 20-byte validating key hash as its value, and a Source Restriction Metadata Item (Typecode
-                        \(\mathtt{0xE2}\)
-                    ) having value
-                        \(\mathtt{0x00}\)
-                     (Transparent Source Only). In addition, metadata items such as an Address Expiry Height or Address Expiry Date 9 MAY be included.
        4. 
-                    
      4. Encode the Unified Address using the “u+” Human Readable Part as specified for Revision 1 of ZIP 316 6.
        5. 
-                
      
-                
      For Testnet addresses, the required lead bytes of a P2PKH address in step 2 are
-                    \([\mathtt{0x1D}, \mathtt{0x25}]\)
-                .
      
-                
      The HRP of the resulting Unified Address is the same as for any other Revision 1 Unified Address on the relevant network as specified in 7, i.e. "u+" for Mainnet and "u+test" for Testnet.
      
-                
      Wallets and other Senders MUST ensure that only transparent UTXOs are spent in the creation of a transaction to any Unified Address containing a Source Restriction Metadata Item having value
-                    \(\mathtt{0x00}\)
-                .
      
-                
      Any Source Restriction Metadata Item MUST be preserved with the same value when deriving a UIVK from a UFVK, or a UA from a UIVK. It has no other effect on the meaning of the UFVK or UIVK.
      
-            
      
-            
      Reference Implementation (Alternative 2) 
      
-                
      Javascript using zcash_address_wasm 17:
      
-                
      import init, { to_traceable_address, traceable_to_p2pkh, addr_expiry_time } from 'zcash_address_wasm';
-init().then(() => {
-  var t_address = "t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC";
-  console.log("original P2PKH address: " + t_address);
-
-  var expiry_time = new Date();
-  // Add 30 days in UTC.
-  expiry_time.setUTCDate(expiry_time.getUTCDate() + 30);
-  // Date.getTime() returns UTC time since 1970-01-01T00:00:00Z in milliseconds.
-  var expiry_unix_seconds = BigInt(Math.floor(expiry_time.getTime() / 1000));
-
-  var traceable_address = to_traceable_address(t_address, expiry_unix_seconds);
-  console.log("Traceable Unified Address: " + traceable_address);
-
-  var p2pkh_addr = traceable_to_p2pkh(traceable_address);
-  console.log("decoded P2PKH address: " + p2pkh_addr);
-
-  var expiry = addr_expiry_time(traceable_address);
-  // Ignore far-future expiry times not representable as a Date.
-  if (expiry !== null && expiry <= 8_640_000_000_000n) {
-      console.log("expiry time: " + new Date(Number(expiry) * 1000).toUTCString());
-  }
-});
      
-                
      Example output:
      
-                
      original P2PKH address: t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC
-Traceable Unified Address: u1p3temdfuxr6vcfr2z3n5weh652rg0hv7q44c652y3su77d0pyktt47am3tng7uxxtk553hhka75r6cvfs5j
-decoded P2PKH address: t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC
-expiry time: Mon Feb 13 2024 01:14:18 GMT
      
-            
      
-        
      
-        
      Analysis of Alternative 1 
      
-            
      Pros to Alternative 1 
      
-                
        
-                    
      • The reencoding from Zcash P2PKH addresses is extremely straightforward and relies only upon widely available encoding libraries.
        • 
-                
      
-            
      
-            
      Cons to Alternative 1 
      
-                
        
-                    
      • Existing wallets and other Consumers will regard the new address type as entirely invalid, and will not automatically prompt their users that they need to upgrade in order to send to this type of address.
        • 
-                    
      • Creation of a new fully distinct address type further fragments the Zcash address ecosystem. Avoiding such fragmentation and providing smooth upgrade paths and good error messages to users is exactly the problem that Unified Addresses 6 were intended to avoid.
        • 
-                    
      • The TEX address type does not provide any mechanism for address expiration. One of the questions Binance has asked has been what to do about users who have stored their existing transparent deposit address in their wallets, or use them as a withdrawal address for other exchanges or services. This is a challenging problem to mitigate now because address expiration was not previously implemented. We should not further compound this problem by defining a new distinct address type that does not provide a mechanism for address expiry.
        • 
-                
      
-            
      
-        
      
-        
      Analysis of Alternative 2 
      
-            
      Pros To Alternative 2 
      
-                
        
-                    
      • By integrating with the Unified Address framework, Consumers of Revision 1 Unified Addresses that have not yet been upgraded to recognize these addresses can automatically be prompted to upgrade their wallets or services to understand the unrecognized MUST-understand Metadata Typecode.
        • 
-                    
      • It is possible to include address expiration metadata in a Traceable Unified Address, which can help to mitigate problems related to stored addresses in the future.
        • 
-                    
      • The Source Restriction Metadata feature can easily be extended to express other kinds of source restriction, such as "Shielded Source Only" or "Fully Shielded with No Pool Crossing".
        • 
-                    
      • Traceable Unified Addresses benefit from the robustness to errors and protection against malleation of Unified Addresses 15.
        • 
-                    
      • Regardless of which proposal is adopted, the Zcash Community will need to work with exchanges other than Binance to update their address parsing logic to understand the new address format. By encouraging Consumers such as exchanges to adopt parsing for Unified Addresses, this proposal furthers the original goal of Unified Addresses to reduce fragmentation in the address ecosystem.
-                        
        Whenever any new feature is added, wallets have a choice whether or not to support that new feature. The point of Unified Address parsing is that wallets don’t have to upgrade to recognize a different address format as a valid Zcash address. Instead of returning a “Not a valid Zcash address” error, which could be confusing for users, they can return an error more like “This is a valid Zcash address, but this wallet does not support sending to it.” This can be used as a prompt to upgrade the wallet to a version (or alternative) that does support that feature.
        
-                        
        For example: numerous wallets have already upgraded to being able to parse Unified Addresses. Those wallets, on seeing a Traceable Unified Address from Binance, will report to their users that the address is a valid Zcash address, but not yet supported by the wallet. Instead of a user thinking that Binance has made some error, they can contact the wallet’s developer and ask that the wallet be updated.
        
-                    
        • 
-                
      
-            
      
-            
      Cons to Alternative 2 
      
-                
        
-                    
      • Existing wallets and other Consumers of Revision 0 Unified Addresses will regard the new address type as entirely invalid, and will not automatically prompt their users that they need to upgrade in order to send to this type of address.
        • 
-                    
      • Unified Address encoding is slightly more complex than the proposed TEX address encoding, and requires use of the F4Jumble encoding algorithm 15. However, this can be readily mitigated by providing a purpose-built library for Traceable Unified Address encoding to Producers.
        • 
-                    
      • A Traceable Unified Address is somewhat longer than a TEX address, although not excessively so.
        • 
-                
      
-            
      
-        
      
-        
      References 
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      2Zcash Community Forum thread "Important: Potential Binance Delisting"
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      3Zcash Community Forum user @hanh
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      4Ywallet developer @hanh's proposal
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      5ZIP 316: Unified Addresses and Unified Viewing Keys — Terminology
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      6ZIP 316: Unified Addresses and Unified Viewing Keys — Encoding of Unified Addresses
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      7ZIP 316: Unified Addresses and Unified Viewing Keys — Revision 1
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      8ZIP 316: Unified Addresses and Unified Viewing Keys — Requirements for both Unified Addresses and Unified Viewing Keys
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      9ZIP 316: Unified Addresses and Unified Viewing Keys — Address Expiration Metadata
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      10ZIP 316: Unified Addresses and Unified Viewing Keys — Metadata Items
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      11Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      12Zcash Protocol Specification, Version 2023.4.0. Section 5.6.1.1 Transparent Addresses
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      13Zcash Community Forum post describing motivations for address expiry
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      14Base58Check encoding — Bitcoin Wiki
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      15ZIP 316: Unified Addresses and Unified Viewing Keys — Jumbling
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      16BIP 350: Bech32m format for v1+ witness addresses
      
-            
-                
-                    
-                        
-                        
-                    
-                
-            
      17zcash_address_wasm: Proof-of-concept library for Traceable Unified Address Encoding
      
-        
      
-    
      
-
-
\ No newline at end of file
diff --git a/zip-0320.rst b/zip-0320.rst
deleted file mode 100644
index 290ca479b..000000000
--- a/zip-0320.rst
+++ /dev/null
@@ -1,388 +0,0 @@
-::
-
-  ZIP: 320
-  Title: Defining an Address Type to which funds can only be sent from Transparent Addresses
-  Owners: Daira-Emma Hopwood 
-          Kris Nuttycombe 
-  Credits: Hanh
-  Status: Draft
-  Category: Standards / Wallet
-  Created: 2024-01-12
-  License: MIT
-  Discussions-To: 
-  Pull-Request: 
-                
-
-Terminology
-===========
-
-The key words "MUST", "SHOULD", and "MAY" in this document are to be
-interpreted as described in BCP 14 [#BCP14]_ when, and only when, they appear
-in all capitals.
-
-The terms "Recipient", "Producer", "Consumer", "Sender", "Receiver", "Item",
-"Metadata Item", "Typecode", "Address", "Unified Address" (UA), "Unified
-Viewing Key" (UVK), "Unified Full Viewing Key" (UFVK), and "Unified Incoming
-Viewing Key" (UIVK) are to be interpreted as described in ZIP 316
-[#zip-0316-terminology]_.
-
-The terms "Testnet" and "Mainnet" are to be interpreted as described in section
-3.12 of the Zcash Protocol Specification [#protocol-networks]_.
-  
-Abstract
-========
-
-This ZIP defines a new encoding for transparent Zcash addresses. Wallets must
-ensure that no shielded notes are spent in transactions that send to a
-transparent address encoded in the specified fashion.
-
-This ZIP is presently in Draft status, and defines two alternate encodings for
-consideration. Analysis of the benefits and drawbacks of each of the proposed
-alternatives is presented at the end of this document.
-
-Background
-==========
-
-In November of 2023, the Zcash community received notice from the Binance
-cryptocurrency exchange that Zcash was at risk of being delisted from the
-exchange unless the community could provide a mechanism by which Binance could
-refuse deposits from shielded addresses and return them to the depositor. This
-issue was raised and discussed at length in the Zcash Community forum
-[#binance-delisting]_.
-
-In the course of that discussion thread, wallet developer and community member
-@hanh [#hanh-profile]_ suggested a wallet-oriented approach [#hanh-suggestion]_
-that involved defining a new encoding for Zcash transparent P2PKH addresses. A
-Consumer of such an address, whether it be a wallet or an exchange, could
-recognize this encoding as a directive that the wallet should only spend
-transparent funds when creating an output to that address.
-
-Motivation
-==========
-
-The Binance cryptocurrency exchange requires that funds sent to their deposit
-addresses come from source addresses that are readily identifiable using
-on-chain information, such that if necessary funds may be rejected by sending
-them back to the source address(es). This ZIP is intended to standardize a
-transparent address encoding that is not yet understood by preexisting
-Consumers, in order to prevent inadvertent shielded spends when sending to such
-addresses. Then, Consumers that upgrade to support the new encoding will do so
-with the understanding that they must respect the restrictions on sources of
-funds described in this ZIP.
-
-Requirements
-============
-
-1. A Recipient wishing to receive funds from exclusively transparent sources
-   must be able to generate a receiving address such that only transparent
-   funds will be spent in transactions with an output to this address.
-2. Wallets and other Consumers that have not been upgraded to recognize the new
-   address format cannot mistake the address for another address type or
-   inadvertently send shielded funds to the address.
-3. No changes to Recipient infrastructure beyond changes to address encoding
-   and decoding should be required as a consequence of this ZIP.
-
-Alternative 1
-=============
-
-This alternative was suggested by @hanh in [#hanh-suggestion]_.
-
-TEX Addresses
--------------
-
-A TEX Address is a Bech32m [#bip-0350]_ reencoding of a transparent Zcash
-P2PKH address [#protocol-transparentaddrencoding]_.
-
-Motivations for Alternative 1
------------------------------
-
-The TEX Address is the simplest possible approach to creating a new address
-type that indicates that only transparent sources of funds should be used.
-
-Specification (Alternative 1)
------------------------------
-
-A TEX address is produced from a Mainnet Zcash P2PKH Address by executing the
-following steps:
-
-1. Decode the address to a byte sequence using the Base58Check decoding
-   algorithm [#Base58Check]_.
-2. If the length of the resulting byte sequence is not 22 bytes or if its two-byte
-   address prefix is not :math:`[\mathtt{0x1C}, \mathtt{0xB8}]`, return an error. Otherwise,
-   let the **validating key hash** be the remaining 20 bytes of the sequence after
-   removing the two-byte address prefix.
-3. Reencode the 20-byte **validating key hash** using the Bech32m encoding
-   defined in [#bip-0350]_ with the human-readable prefix (HRP) ``"tex"``.
-
-For Testnet addresses, the required lead bytes of a P2PKH address in step 2 are
-:math:`[\mathtt{0x1D}, \mathtt{0x25}]`, and the ``"textest"`` HRP is used when
-reencoding in step 3.
-
-Wallets and other Senders sending to a TEX address (as any output) MUST
-ensure that only transparent UTXOs are spent in the creation of a
-transaction.
-
-Reference Implementation (Alternative 1)
-----------------------------------------
-
-Javascript::
-
-   import bs58check from 'bs58check'
-   import {bech32m} from 'bech32'
-   
-   // From t1 to tex
-   var b58decoded = bs58check.decode('t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC')
-   console.assert(b58decoded.length == 22, 'Invalid length');
-   console.assert(b58decoded[0] == 0x1C && b58decoded[1] == 0xB8, 'Invalid address prefix');
-   var pkh = b58decoded.slice(2)
-   var tex = bech32m.encode('tex', bech32m.toWords(pkh))
-   console.log(tex)
-   
-   // From tex to t1
-   var bech32decoded = bech32m.decode('tex1s2rt77ggv6q989lr49rkgzmh5slsksa9khdgte')
-   console.assert(bech32decoded.prefix == 'tex', 'Invalid address prefix')
-   var pkh2 = Uint8Array.from(bech32m.fromWords(bech32decoded.words))
-   console.assert(pkh2.length == 20, 'Invalid length');
-   var t1 = bs58check.encode(Buffer.concat([Uint8Array.from([0x1C, 0xB8]), pkh2]))
-   console.log(t1)
-
-Alternative 2
-=============
-
-Traceable Unified Addresses
----------------------------
-
-A Traceable Unified Address is a reencoding of a transparent Zcash P2PKH
-address into a Unified Address [#zip-0316-unified-addresses]_. 
-
-Motivations for Alternative 2
------------------------------
-
-Traceable Unified Addresses fit into the Zcash Unified Address ecosystem
-defined by ZIP 316, Revision 1 [#zip-0316-revision-1]_. Existing Consumers of
-Unified Addresses will not be able to send to these address unless they update
-their code to understand the new MUST-understand Metadata Typecode defined in
-this ZIP. 
-
-By integrating with the Unified Address framework, it becomes possible for the
-addresses being generated to include extra metadata; in particular, metadata
-items such as an Address Expiry Height or Address Expiry Date
-[#zip-0316-address-expiry]_ may be included. For exchange use cases such as
-Binance's, it is useful to ensure that an address provided to a user has a
-limited utility life, such that after expiration the user must obtain a new
-address in order to be able to continue to send funds
-[#binance-address-expiry]_.
-
-Specification (Alternative 2)
------------------------------
-
-Upon activation of this ZIP, the section `Metadata Items` of ZIP 316
-[#zip-0316-metadata-items]_ will be modified to define a new MUST-understand
-Metadata Item type: Source Restriction Metadata, having Typecode
-:math:`\mathtt{0xE2}`, the value of which MUST be a single byte:
-
-* :math:`\mathtt{0x00}` - Transparent Source Only
-
-Additional Source Restriction Metadata values can be defined in the future,
-but a Consumer that does not recognise the value MUST reject the entire
-UA/UVK as invalid.
-
-The "Requirements for both Unified Addresses and Unified Viewing Keys" section
-of ZIP 316 [#zip-0316-unified-requirements]_ will be modified as follows — the
-text:
-
-  A Unified Address or Unified Viewing Key MUST contain at least one
-  shielded Item (Typecodes :math:`\mathtt{0x02}` and :math:`\mathtt{0x03}`).
-  The rationale is that the existing P2SH and P2PKH transparent-only
-  address formats, and the existing P2PKH extended public key format,
-  suffice for representing transparent Items and are already supported
-  by the existing ecosystem.
-
-will be replaced by:
-
-  A Unified Address or Unified Viewing Key MUST **either**:
-
-  * contain at least one shielded Item (Typecodes :math:`\mathtt{0x02}`
-    and :math:`\mathtt{0x03}`), and **no** Source Restriction Metadata Item
-    having value :math:`\mathtt{0x00}`; **or**
-  * contain **both** a Transparent Item (Typecode :math:`\mathtt{0x00}` or
-    Typecode :math:`\mathtt{0x01}`) **and** a Source Restriction Metadata Item
-    (Typecode :math:`\mathtt{0xE2}`) having value :math:`\mathtt{0x00}`, and
-    **no other** non-Metadata Items.
-
-In the following, the “``u+``” Human Readable Part of Revision 1 Unified
-Addresses is a placeholder value, pending the finalization of Revision 1 
-[#zip-0316-revision-1]_.
-
-A Traceable Unified Address is produced from a Mainnet Zcash P2PKH address by
-executing the following steps:
-
-1. Decode the address to a byte sequence using the Base58Check decoding
-   algorithm [#Base58Check]_.
-2. If the length of the resulting byte sequence is not 22 bytes or if its
-   two-byte address prefix is not :math:`[\mathtt{0x1C}, \mathtt{0xB8}]`,
-   return an error. Otherwise, let the **validating key hash** be the remaining
-   20 bytes of the array after removing the two-byte address prefix.
-3. Construct a new Revision 1 Unified Address using a single P2PKH Receiver
-   :math:`\mathtt{0x04}` with the 20-byte **validating key hash** as its value,
-   and a Source Restriction Metadata Item (Typecode :math:`\mathtt{0xE2}`)
-   having value :math:`\mathtt{0x00}` (Transparent Source Only). In addition,
-   metadata items such as an Address Expiry Height or Address Expiry Date
-   [#zip-0316-address-expiry]_ MAY be included.
-4. Encode the Unified Address using the “``u+``” Human Readable Part as
-   specified for Revision 1 of ZIP 316 [#zip-0316-unified-addresses]_.
-
-For Testnet addresses, the required lead bytes of a P2PKH address in step 2
-are :math:`[\mathtt{0x1D}, \mathtt{0x25}]`.
-
-The HRP of the resulting Unified Address is the same as for any other Revision 1
-Unified Address on the relevant network as specified in [#zip-0316-revision-1]_,
-i.e. ``"u+"`` for Mainnet and ``"u+test"`` for Testnet.
-
-Wallets and other Senders MUST ensure that only transparent UTXOs are spent in
-the creation of a transaction to any Unified Address containing a Source
-Restriction Metadata Item having value :math:`\mathtt{0x00}`.
-
-Any Source Restriction Metadata Item MUST be preserved with the same value
-when deriving a UIVK from a UFVK, or a UA from a UIVK. It has no other effect
-on the meaning of the UFVK or UIVK.
-
-Reference Implementation (Alternative 2)
-----------------------------------------
-
-Javascript using `zcash_address_wasm` [#zcash_address_wasm]_::
-
-    import init, { to_traceable_address, traceable_to_p2pkh, addr_expiry_time } from 'zcash_address_wasm';
-    init().then(() => {
-      var t_address = "t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC";
-      console.log("original P2PKH address: " + t_address);
-    
-      var expiry_time = new Date();
-      // Add 30 days in UTC.
-      expiry_time.setUTCDate(expiry_time.getUTCDate() + 30);
-      // Date.getTime() returns UTC time since 1970-01-01T00:00:00Z in milliseconds.
-      var expiry_unix_seconds = BigInt(Math.floor(expiry_time.getTime() / 1000));
-    
-      var traceable_address = to_traceable_address(t_address, expiry_unix_seconds);
-      console.log("Traceable Unified Address: " + traceable_address);
-    
-      var p2pkh_addr = traceable_to_p2pkh(traceable_address);
-      console.log("decoded P2PKH address: " + p2pkh_addr);
-    
-      var expiry = addr_expiry_time(traceable_address);
-      // Ignore far-future expiry times not representable as a Date.
-      if (expiry !== null && expiry <= 8_640_000_000_000n) {
-          console.log("expiry time: " + new Date(Number(expiry) * 1000).toUTCString());
-      }
-    });
-
-Example output::
-
-    original P2PKH address: t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC
-    Traceable Unified Address: u1p3temdfuxr6vcfr2z3n5weh652rg0hv7q44c652y3su77d0pyktt47am3tng7uxxtk553hhka75r6cvfs5j
-    decoded P2PKH address: t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC
-    expiry time: Mon Feb 13 2024 01:14:18 GMT
-
-Analysis of Alternative 1
-=========================
-
-Pros to Alternative 1
----------------------
-
-- The reencoding from Zcash P2PKH addresses is extremely straightforward and
-  relies only upon widely available encoding libraries.
-
-Cons to Alternative 1
----------------------
-
-- Existing wallets and other Consumers will regard the new address type as
-  entirely invalid, and will not automatically prompt their users that they
-  need to upgrade in order to send to this type of address.
-- Creation of a new fully distinct address type further fragments the Zcash
-  address ecosystem. Avoiding such fragmentation and providing smooth upgrade
-  paths and good error messages to users is exactly the problem that Unified
-  Addresses [#zip-0316-unified-addresses]_ were intended to avoid.
-- The TEX address type does not provide any mechanism for address expiration.
-  One of the questions Binance has asked has been what to do about users who
-  have stored their existing transparent deposit address in their wallets, or
-  use them as a withdrawal address for other exchanges or services. This is a
-  challenging problem to mitigate now because address expiration was not
-  previously implemented. We should not further compound this problem by
-  defining a new distinct address type that does not provide a mechanism for
-  address expiry.
-
-Analysis of Alternative 2
-=========================
-
-Pros To Alternative 2
----------------------
-
-- By integrating with the Unified Address framework, Consumers of Revision 1
-  Unified Addresses that have not yet been upgraded to recognize these
-  addresses can automatically be prompted to upgrade their wallets or services
-  to understand the unrecognized MUST-understand Metadata Typecode.
-- It is possible to include address expiration metadata in a Traceable Unified
-  Address, which can help to mitigate problems related to stored addresses in
-  the future.
-- The Source Restriction Metadata feature can easily be extended to express
-  other kinds of source restriction, such as "Shielded Source Only" or
-  "Fully Shielded with No Pool Crossing".
-- Traceable Unified Addresses benefit from the robustness to errors and
-  protection against malleation of Unified Addresses [#F4Jumble]_.
-- Regardless of which proposal is adopted, the Zcash Community will need to
-  work with exchanges other than Binance to update their address parsing logic
-  to understand the new address format. By encouraging Consumers such as
-  exchanges to adopt parsing for Unified Addresses, this proposal furthers the
-  original goal of Unified Addresses to reduce fragmentation in the address
-  ecosystem.
-
-  Whenever any new feature is added, wallets have a choice whether or not to
-  support that new feature. The point of Unified Address parsing is that
-  wallets don’t have to upgrade to recognize a different address format as a
-  valid Zcash address. Instead of returning a “Not a valid Zcash address”
-  error, which could be confusing for users, they can return an error more like
-  “This is a valid Zcash address, but this wallet does not support sending to
-  it.” This can be used as a prompt to upgrade the wallet to a version (or
-  alternative) that does support that feature.
-
-  For example: numerous wallets have already upgraded to being able to parse
-  Unified Addresses. Those wallets, on seeing a Traceable Unified Address from
-  Binance, will report to their users that the address is a valid Zcash
-  address, but not yet supported by the wallet. Instead of a user thinking that
-  Binance has made some error, they can contact the wallet’s developer and ask
-  that the wallet be updated.
-
-Cons to Alternative 2
----------------------
-
-- Existing wallets and other Consumers of Revision 0 Unified Addresses will
-  regard the new address type as entirely invalid, and will not automatically
-  prompt their users that they need to upgrade in order to send to this type of
-  address.
-- Unified Address encoding is slightly more complex than the proposed TEX
-  address encoding, and requires use of the F4Jumble encoding algorithm
-  [#F4Jumble]_. However, this can be readily mitigated by providing a
-  purpose-built library for Traceable Unified Address encoding to Producers.
-- A Traceable Unified Address is somewhat longer than a TEX address, although
-  not excessively so.
-
-References
-==========
-
-.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_
-.. [#binance-delisting] `Zcash Community Forum thread "Important: Potential Binance Delisting" `_
-.. [#hanh-profile] `Zcash Community Forum user @hanh `_
-.. [#hanh-suggestion] `Ywallet developer @hanh's proposal `_
-.. [#zip-0316-terminology] `ZIP 316: Unified Addresses and Unified Viewing Keys — Terminology `_
-.. [#zip-0316-unified-addresses] `ZIP 316: Unified Addresses and Unified Viewing Keys — Encoding of Unified Addresses `_
-.. [#zip-0316-revision-1] `ZIP 316: Unified Addresses and Unified Viewing Keys — Revision 1 `_
-.. [#zip-0316-unified-requirements] `ZIP 316: Unified Addresses and Unified Viewing Keys — Requirements for both Unified Addresses and Unified Viewing Keys `_
-.. [#zip-0316-address-expiry] `ZIP 316: Unified Addresses and Unified Viewing Keys — Address Expiration Metadata `_
-.. [#zip-0316-metadata-items] `ZIP 316: Unified Addresses and Unified Viewing Keys — Metadata Items `_
-.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet `_
-.. [#protocol-transparentaddrencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.1.1 Transparent Addresses `_
-.. [#binance-address-expiry] `Zcash Community Forum post describing motivations for address expiry `_
-.. [#Base58Check] `Base58Check encoding — Bitcoin Wiki `_
-.. [#F4Jumble] `ZIP 316: Unified Addresses and Unified Viewing Keys — Jumbling `_
-.. [#bip-0350] `BIP 350: Bech32m format for v1+ witness addresses `_
-.. [#zcash_address_wasm] `zcash_address_wasm: Proof-of-concept library for Traceable Unified Address Encoding `_
diff --git a/zips/draft-noamchom67-manufacturing-consent.rst b/zips/draft-noamchom67-manufacturing-consent.rst
new file mode 100644
index 000000000..1116732e4
--- /dev/null
+++ b/zips/draft-noamchom67-manufacturing-consent.rst
@@ -0,0 +1,497 @@
+::
+
+  ZIP: ####
+  Title: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
+  Owner: Noam Chom 
+  Credits: The ZIP-1014 Authors
+  Status: Active
+  Category: Consensus Process
+  Created: 2024-06-25
+  License: MIT
+  Discussions-To: 
+  Pull-Request: TBD
+
+
+Terminology
+===========
+
+The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY"
+in this document are to be interpreted as described in BCP 14 [#BCP14]_ when,
+and only when, they appear in all capitals.
+
+The term "network upgrade" in this document is to be interpreted as
+described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License
+Agreement ([#trademark]_ or successor agreement).
+
+The terms "block subsidy" and "halving" in this document are to be interpreted
+as described in sections 3.10 and 7.8 of the Zcash Protocol Specification.
+[#protocol]_
+
+"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric
+Coin Company, LLC.
+
+"Bootstrap Project", also called "BP", refers to the 501(c)(3) nonprofit
+corporation of that name.
+
+"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit
+corporation of that name.
+
+"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue
+Code (Title 26 of the U.S. Code). [#section501c3]_
+
+"Community Advisory Panel" refers to the panel of community members assembled
+by the Zcash Foundation and described at [#zf-community]_.
+
+"Zcash Community Grants", also called "ZCG", refers to grants program
+(formerly known as ZOMG) that funds independent teams entering the Zcash ecosystem, 
+to perform major ongoing development (or other work) 
+for the public good of the Zcash ecosystem.
+
+
+"Financial Privacy Foundation", also called "FPF" refers to the start-up non-profit
+organization incorporated and based in the Cayman Islands.
+
+
+"Qedit" refers to the company founded in 2016 by a world-class team of 
+accomplished tech entrepreneurs, researchers, and developers; 
+QEDIT has emerged as a global leader in the field of Zero-Knowledge Proofs.
+
+
+"ZecHub" refers to the team of content creators who have supported Zcash
+through a series of ZCG approved grants.
+
+
+The terms "Testnet" and "Mainnet" are to be interpreted as described in
+section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
+
+The term "ZSA" is to be interpreted as "Zcash Shielded Assets" the protocol
+feature enhancement (and subsequent application layer, legal, maintenance 
+efforts, et al) on-going by Qedit, et al.
+
+
+✳️ is used to denote elements of the process part of the ZIP that are still
+to-be-determined.
+
+
+Abstract
+========
+
+This proposal describes a structure for the Zcash Development Fund, to be
+enacted in Network Upgrade 6 and last for 4 years. This Dev Fund would consist
+of 15% of the block subsidies, as the following allocations:
+
+* 5% for the Zcash Foundation (for internal work and grants);
+* 4% for the Bootstrap Project (the parent of the Electric Coin Company) for the 1st year only;
+* 4% for Zcash Community Grants for continuation of their current activities as-is;
+* 2% for Qedit in support of their ZSA activities, and other Zcash protocol support;
+
+Following the first year, when ECC will no longer receive their 4% allocation, 
+those block subsidies will be distributed as 1% to ZCG, 1% to ZecHub, 1% to FPF,
+and 1% to ZF.
+
+Governance and accountability are based on existing entities and legal mechanisms,
+and increasingly decentralized governance is encouraged.  This proposal mandates 
+the ecosystem to design and deploy a "non-direct funding model" as generally
+recommended in Josh Swihart's proposal. [#draft-swihart]_
+
+Upon creation/ activation of a "non-direct funding model" this ZIP should be 
+reconsidered (potentially terminated) by the Zcash ecosystem, to determine 
+if its ongoing direct block subsidies are preferred for continuation.
+Discussions/ solications/ sentiment gathering from the Zcash
+ecosystem should be initiated ~6 months in advance of the presumed
+activation of a "non-direct funding model", such that the Zcash ecosystem
+preference can be expediently realized.
+
+Block subsidies will be administered through two organizations:
+
+1. Zcash Foundation  (✳️ for ECC, ZCG)
+2. Financial Privacy Foundation (✳️ for Qedit, ZecHub)
+
+✳️ **ZF and FPF adminstration of block subsidy details, costs, et al are currently under debate**
+[#zf-fpf-admin-details]_
+
+
+Motivation
+==========
+
+As of Zcash's second halving in November 2024, by default 100% of the block
+subsidies will be allocated to miners, and no further funds will be automatically
+allocated to any other entities. Consequently, no new funding
+may be available to existing teams dedicated to furthering charitable,
+educational, or scientific purposes, such as research, development, and outreach:
+the Electric Coin Company (ECC), the Zcash Foundation (ZF), the ZCG, and the many
+entities funded by the ZF and ZCG grant programs.
+
+There is a need to strike a balance between incentivizing the security of the
+consensus protocol (i.e., mining) versus crucial charitable, educational, and/or
+scientific aspects, such as research, development and outreach.
+
+Furthermore, there is a need to balance the sustenance of ongoing work by the
+current teams dedicated to Zcash, with encouraging decentralization and growth
+of independent development teams.
+
+For these reasons, the Zcash Community desires to allocate and
+contribute a portion of the block subsidies otherwise allocated to
+miners as a donation to support charitable, educational, and
+scientific activities within the meaning of Section 501(c)(3).
+
+This proposal also introduces the benefit of a non-USA based entity (FPF) as 
+the administrator for block subsidies to two organizations that are also 
+non-USA based (Qedit and ZecHub). USA based regulatory risk continues to
+(negatively) impact the Zcash project, which has been predominantly based in the USA.
+
+
+Requirements
+============
+
+The Dev Fund should encourage decentralization of the work and funding, by
+supporting new teams dedicated to Zcash.
+
+The Dev Fund should maintain the existing teams and capabilities in the Zcash
+ecosystem, unless and until concrete opportunities arise to create even greater
+value for the Zcash ecosystem.
+
+There should not be any single entity which is a single point of failure, i.e.,
+whose capture or failure will effectively prevent effective use of the funds.
+
+Major funding decisions should be based, to the extent feasible, on inputs from
+domain experts and pertinent stakeholders.
+
+The Dev Fund mechanism should not modify the monetary emission curve (and in
+particular, should not irrevocably burn coins).
+
+In case the value of ZEC jumps, the Dev Fund recipients should not wastefully
+use excessive amounts of funds. Conversely, given market volatility and eventual
+halvings, it is desirable to create rainy-day reserves.
+
+The Dev Fund mechanism should not reduce users' financial privacy or security.
+In particular, it should not cause them to expose their coin holdings, nor
+cause them to maintain access to secret keys for much longer than they would
+otherwise. (This rules out some forms of voting, and of disbursing coins to
+past/future miners.)
+
+The Dev Fund system should be simple to understand and realistic to
+implement. In particular, it should not assume the creation of new mechanisms
+(e.g., election systems) or entities (for governance or development) for its
+execution; but it should strive to support and use these once they are built.
+
+Dev Fund recipients should comply with legal, regulatory, and taxation
+constraints in their pertinent jurisdiction(s).
+
+
+Non-requirements
+================
+
+General on-chain governance is outside the scope of this proposal.
+
+Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or
+one-person-one-vote) are outside the scope of this proposal, however this 
+proposal does mandate the undertaking of the project to build a "non-direct
+funding model" as generally described in [#draft-swihart]_.
+
+Specification
+=============
+
+Consensus changes implied by this specification are applicable to the
+Zcash Mainnet. Similar (but not necessarily identical) consensus changes
+SHOULD be applied to the Zcash Testnet for testing purposes.
+
+
+Dev Fund allocation
+-------------------
+
+Starting at the second Zcash halving in 2024, until the third halving in 2028,
+15% of the block subsidy of each block SHALL be allocated to a "Dev Fund" that
+consists of the following allocations:
+
+* 5% for the Zcash Foundation (for internal work and grants);
+* 4% for the Bootstrap Project (the parent of the Electric Coin Company) for the 1st year only; 
+* 4% for Zcash Community Grants for continuation of their current activities as-is;
+* 2% for Qedit in support of their ZSA activities, and other Zcash protocol support;
+
+Following the first year, when ECC will no longer receive their 4% allocation, 
+those block subsidies will be distributed as 1% to ZCG, 1% to ZecHub, 1% to FPF,
+and 1% to ZF.
+
+This proposal mandates the ecosystem to design and deploy a "non-direct funding model"
+as generally recommended in Josh Swihart's proposal [#draft-swihart]_.
+
+"Dev Fund" block subsidies will be administered through two organizations:
+
+1. Zcash Foundation  (✳️ for ECC, ZCG)
+2. Financial Privacy Foundation (✳️ for Qedit, ZecHub)
+
+✳️ **ZF and FPF adminstration of block subsidy details, costs, et al are currently under debate**
+[#zf-fpf-admin-details]_
+
+The allocations are described in more detail below. The fund flow will be implemented
+at the consensus-rule layer, by sending the corresponding ZEC to the designated
+address(es) for each block. This Dev Fund will end at the third halving (unless
+extended/modified by a future ZIP).
+
+
+BP allocation (Bootstrap Project)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+✳️ These funds SHALL be received and administered by ZF.
+
+This allocation of the Dev Fund will flow as charitable contributions from
+the Zcash Community to the Bootstrap Project, the newly formed parent
+organization to the Electric Coin Company. The Bootstrap Project is organized
+for exempt educational, charitable, and scientific purposes in
+compliance with Section 501(c)(3), including but not
+limited to furthering education, information, resources, advocacy,
+support, community, and research relating to cryptocurrency and
+privacy, including Zcash. This allocation will be used at the discretion of
+the Bootstrap Project for any purpose within its mandate to support financial
+privacy and the Zcash platform as permitted under Section 501(c)(3). The
+BP allocation will be treated as a charitable contribution from the
+Community to support these educational, charitable, and scientific
+purposes.
+
+
+ZF allocation (Zcash Foundation's general use)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This allocation of the Dev Fund will flow as charitable contributions from
+the Zcash Community to ZF, to be used at its discretion for any
+purpose within its mandate to support financial privacy and the Zcash
+platform, including: development, education, supporting community
+communication online and via events, gathering community sentiment,
+and awarding external grants for all of the above, subject to the
+requirements of Section 501(c)(3). The ZF allocation will be
+treated as a charitable contribution from the Community to support
+these educational, charitable, and scientific purposes.
+
+
+Zcash Community Grants (ZCG)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This allocation of the Dev Fund is intended to fund independent teams entering the
+Zcash ecosystem, to perform major and minor ongoing development (or other work) for the
+public good of the Zcash ecosystem, to the extent that such teams are available
+and effective.
+
+✳️ These funds SHALL be received and administered by ZF (or FPF, pending TBD outcomes
+of FPF proposal: [#zf-fpf-admin-details]_).
+ZF MUST disburse them for "Major Grants" and expenses reasonably related to
+the administration of Major Grants, but subject to the following additional constraints:
+
+1. These funds MUST only be used to issue Major Grants to external parties
+   that are independent of ZF, and to pay for expenses reasonably related to 
+   the administration of Major Grants. They MUST NOT be used by ZF for its 
+   internal operations and direct expenses not related to administration of 
+   Major Grants. Additionally, BP, ECC, and ZF are ineligible to receive 
+   Major Grants.
+
+2. Major Grants SHOULD support well-specified work proposed by the grantee,
+   at reasonable market-rate costs. They can be of any duration or ongoing
+   without a duration limit. Grants of indefinite duration SHOULD have
+   semiannual review points for continuation of funding.
+
+3. Priority SHOULD be given to Major Grants that bolster teams with
+   substantial (current or prospective) continual existence, and set them up
+   for long-term success, subject to the usual grant award considerations
+   (impact, ability, risks, team, cost-effectiveness, etc.). Priority SHOULD be
+   given to Major Grants that support ecosystem growth, for example through
+   mentorship, coaching, technical resources, creating entrepreneurial
+   opportunities, etc. If one proposal substantially duplicates another's
+   plans, priority SHOULD be given to the originator of the plans.
+
+4. Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and
+   its ecosystem (which is more specific than furthering financial privacy in
+   general) as permitted under Section 501(c)(3).
+
+5. Major Grants awards are subject to approval by a five-seat Major Grant
+   Review Committee. The Major Grant Review Committee SHALL be selected by the
+   ZF's Community Advisory Panel or successor process.
+
+6. The Major Grant Review Committee's funding decisions will be final, requiring
+   no approval from the ZF Board, but are subject to veto if the Foundation
+   judges them to violate U.S. law or the ZF's reporting requirements and other
+   (current or future) obligations under U.S. IRS 501(c)(3).
+
+7. Major Grant Review Committee members SHALL have a one-year term and MAY sit
+   for reelection. The Major Grant Review Committee is subject to the same
+   conflict of interest policy that governs the ZF Board of Directors (i.e. they
+   MUST recuse themselves when voting on proposals where they have a financial
+   interest). At most one person with association with the BP/ECC, and at most
+   one person with association with the ZF, are allowed to sit on the Major
+   Grant Review Committee. "Association" here means: having a financial
+   interest, full-time employment, being an officer, being a director, or having
+   an immediate family relationship with any of the above. The ZF SHALL continue
+   to operate the Community Advisory Panel and SHOULD work toward making it more
+   representative and independent (more on that below).
+   
+8. From 1st January 2022, a portion of the MG allocation shall be allocated to a 
+   Discretionary Budget, which may be disbursed for expenses reasonably related 
+   to the administration of Major Grants. The amount of funds allocated to the 
+   Discretionary Budget SHALL be decided by the ZF's Community Advisory Panel or 
+   successor process. Any disbursement of funds from the Discretionary Budget 
+   MUST be approved by the Major Grant Review Committee. Expenses related to the 
+   administration of Major Grants include, without limitation the following:
+   
+   * Paying third party vendors for services related to domain name registration, or
+     the design, website hosting and administration of websites for the Major Grant 
+     Review Committee.
+   * Paying independent consultants to develop requests for proposals that align 
+     with the Major Grants program.
+   * Paying independent consultants for expert review of grant applications.
+   * Paying for sales and marketing services to promote the Major Grants 
+     program.
+   * Paying third party consultants to undertake activities that support the 
+     purpose of the Major Grants program. 
+   * Reimbursement to members of the Major Grant Review Committee for reasonable 
+     travel expenses, including transportation, hotel and meals allowance.
+     
+   The Major Grant Review Committee's decisions relating to the allocation and 
+   disbursement of funds from the Discretionary Budget will be final, requiring 
+   no approval from the ZF Board, but are subject to veto if the Foundation 
+   judges them to violate U.S. law or the ZF's reporting requirements and other 
+   (current or future) obligations under U.S. IRS 501(c)(3).
+
+ZF SHALL recognize the MG allocation of the Dev Fund as a Restricted Fund
+donation under the above constraints (suitably formalized), and keep separate
+accounting of its balance and usage under its `Transparency and Accountability`_
+obligations defined below.
+
+ZF SHALL strive to define target metrics and key performance indicators,
+and the Major Grant Review Committee SHOULD utilize these in its funding
+decisions.
+
+
+Qedit
+~~~~~
+
+✳️ These funds SHALL be received and administered by FPF.
+
+This allocation of the Dev Fund will flow as charitable contributions from
+the Zcash Community to Qedit, for the purposes of supporting their ongoing
+activities related to Zcash Shielded Assets, and related protocol/ application/ 
+legal/ and other efforts.
+
+ZecHub
+~~~~~~
+
+✳️ These funds SHALL be received and administered by FPF.
+
+This allocation of the Dev Fund will flow as charitable contributions from
+the Zcash Community to ZecHub, for the purposes of continuing their 
+ongoing content contributions, community organizing, et al within the
+Zcash ecosystem.
+
+
+Transparency and Accountability
+-------------------------------
+
+Obligations
+~~~~~~~~~~~
+
+BP, ECC, ZF, ZCG, Qedit, FPF and ZecHub are recommended to accept the obligations in this section.
+
+Ongoing public reporting requirements:
+
+* Quarterly reports, detailing future plans, execution on previous plans, and
+  finances (balances, and spending broken down by major categories).
+* Monthly developer calls, or a brief report, on recent and forthcoming tasks.
+  (Developer calls may be shared.)
+* Annual detailed review of the organization performance and future plans.
+* Annual financial report (IRS Form 990, or substantially similar information).
+
+These reports may be either organization-wide, or restricted to the income,
+expenses, and work associated with the receipt of Dev Fund.
+As BP is the parent organization of ECC it is expected they may publish
+joint reports.
+
+It is expected that ECC, ZF, and ZCG will be focused
+primarily (in their attention and resources) on Zcash. Thus, they MUST
+promptly disclose:
+
+* Any major activity they perform (even if not supported by the Dev Fund) that
+  is not in the interest of the general Zcash ecosystem.
+* Any conflict of interest with the general success of the Zcash ecosystem.
+
+BP, ECC, ZF, and grant recipients MUST promptly disclose any security or privacy
+risks that may affect users of Zcash (by responsible disclosure under
+confidence to the pertinent developers, where applicable).
+
+BP's reports, ECC's reports, and ZF's annual report on its non-grant operations,
+SHOULD be at least as detailed as grant proposals/reports submitted by other
+funded parties, and satisfy similar levels of public scrutiny.
+
+All substantial software whose development was funded by the Dev Fund SHOULD
+be released under an Open Source license (as defined by the Open Source
+Initiative [#osd]_), preferably the MIT license.
+
+
+Enforcement
+~~~~~~~~~~~
+
+For grant recipients, these conditions SHOULD be included in their contract
+with ZF, such that substantial violation, not promptly remedied, will cause
+forfeiture of their grant funds and their return to ZF.
+
+BP, ECC, and ZF MUST contractually commit to each other to fulfill these
+conditions, and the prescribed use of funds, such that substantial violation,
+not promptly remedied, will permit the other party to issue a modified version
+of Zcash node software that removes the violating party's Dev Fund allocation, and
+use the Zcash trademark for this modified version. The allocation's funds will be
+reassigned to MG (whose integrity is legally protected by the Restricted
+Fund treatment).
+
+
+Future Community Governance
+---------------------------
+
+It is highly desirable to develop robust means of decentralized community
+voting and governance –either by expanding the Zcash Community Advisory Panel or a
+successor mechanism– and to integrate them into this process by the end of
+2025. BP, ECC, ZCG, and ZF SHOULD place high priority on such development and its
+deployment, in their activities and grant selection.
+
+
+ZF Board Composition
+--------------------
+
+Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current
+business or employment relationships with ECC, except as provided for by the
+grace period described below.
+
+Grace period: members of the ZF board who hold ECC equity (but do not have other
+current relationships to ECC) may dispose of their equity, or quit the Board,
+by 21 November 2024. (The grace period is to allow for orderly replacement, and
+also to allow time for ECC corporate reorganization related to Dev Fund
+receipt, which may affect how disposition of equity would be executed.)
+
+The Zcash Foundation SHOULD endeavor to use the Community Advisory Panel (or
+successor mechanism) as advisory input for future board elections.
+
+
+Acknowledgements
+================
+
+This proposal is a modification of ZIP 1014 [#zip-1014]_
+and a modification from the original "Manufacturing Consent" proposal 
+as described in the Zcash Forum, in response to observable Zcash
+community sentiment.
+
+The author is grateful to everyone in the Zcash ecosystem.
+
+
+References
+==========
+
+.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_
+.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_
+.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_
+.. [#trademark] `Zcash Trademark Donation and License Agreement `_
+.. [#osd] `The Open Source Definition `_
+.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_
+.. [#zip-1003] `ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate `_
+.. [#zip-1010] `ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams `_
+.. [#zip-1011] `ZIP 1011: Decentralize the Dev Fee `_
+.. [#zip-1014] `ZIP 1012: Dev Fund to ECC + ZF + Major Grants `_
+.. [#zf-community] `ZF Community Advisory Panel `_
+.. [#section501c3] `U.S. Code, Title 26, Section 501(c)(3) `_
+.. [#draft-swihart] `Zcash Funding Bloc : A Dev Fund Proposal from Josh at ECC `_
+.. [#zf-fpf-admin-details] `Proposal: ZCG under FPF `_
diff --git a/zips/draft-nuttycom-funding-allocation.rst b/zips/draft-nuttycom-funding-allocation.rst
new file mode 100644
index 000000000..15b2bd51c
--- /dev/null
+++ b/zips/draft-nuttycom-funding-allocation.rst
@@ -0,0 +1,611 @@
+::
+
+  ZIP: Unassigned
+  Title: Block Reward Allocation for Non-Direct Development Funding
+  Owners: Kris Nuttycombe 
+          Jason McGee 
+  Original-Authors: Skylar Saveland 
+  Credits: Daira-Emma Hopwood
+           Jack Grigg
+           @Peacemonger (Zcash Forum)
+  Status: Draft
+  Category: Consensus
+  Created: 2024-07-03
+  License: MIT
+  Pull-Request: 
+
+Terminology
+===========
+
+The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this
+document are to be interpreted as described in BCP 14 [#BCP14]_ when, and only
+when, they appear in all capitals.
+
+Abstract
+========
+
+This ZIP proposes several options for the allocation of a percentage of the
+Zcash block subsidy, post-November 2024 halving, to an in-protocol "lockbox."
+The "lockbox" will be a separate pool of issued funds tracked by the protocol,
+as described in ZIP 2001: Lockbox Funding Streams
+[#zip-2001]_. No disbursement mechanism is currently defined
+for this "lockbox"; the Zcash community will need to decide upon and specify a
+suitable decentralized mechanism for permitting withdrawals from this lockbox
+in a future ZIP in order to make these funds available for funding grants to
+ecosystem participants.
+
+The proposed lockbox addresses significant issues observed with ZIP 1014
+[#zip-1014]_, such as regulatory risks, inefficiencies due to funding of organizations
+instead of projects, and centralization. While the exact disbursement mechanism
+for the lockbox funds is yet to be determined and will be addressed in a future
+ZIP, the goal is to employ a decentralized mechanism that ensures community
+involvement and efficient, project-specific funding. This approach is intended
+to potentially improve regulatory compliance, reduce inefficiencies, and
+enhance the decentralization of Zcash's funding structure.
+
+Motivation
+==========
+
+Starting at Zcash's second halving in November 2024, by default 100% of the
+block subsidies will be allocated to miners, and no further funds will be
+automatically allocated to any other entities. Consequently, unless the
+community takes action to approve new block-reward based funding, existing
+teams dedicated to development or outreach or furthering charitable,
+educational, or scientific purposes will likely need to seek other sources of
+funding; failure to obtain such funding would likely impair their ability to
+continue serving the Zcash ecosystem. Setting aside a portion of the block
+subsidy to fund development will help ensure that both existing teams and
+new contributors can obtain funding in the future.
+
+It is important to balance the incentives for securing the consensus protocol
+through mining with funding crucial charitable, educational, and scientific
+activities like research, development, and outreach. Additionally, there is a
+need to continue to promote decentralization and the growth of independent
+development teams.
+
+For these reasons, the Zcash Community wishes to establish a new Zcash
+Development Fund after the second halving in November 2024, with the intent to
+put in place a more decentralized mechanism for allocation of development
+funds. The alternatives presented here are intended to address the following:
+
+1. **Regulatory Risks**: The current model involves direct funding of US-based
+   organizations, which can potentially attract regulatory scrutiny from
+   entities such as the SEC, posing legal risks to the Zcash ecosystem.
+
+2. **Funding Inefficiencies**: The current model directly funds organizations
+   rather than specific projects, leading to a potential mismatch between those
+   organizations' development priorities and the priorities of the community.
+   Furthermore, if organizations are guaranteed funds regardless of
+   performance, there is little incentive to achieve key performance indicators
+   (KPIs) or align with community sentiment. A future system that allocates
+   resources directly to projects rather than organizations may help reduce
+   inefficiencies and better align development efforts with community
+   priorities.
+
+3. **Centralization Concerns**: The current model centralizes decision-making
+   power within a few organizations, contradicting the decentralized ethos of
+   blockchain technology. Traditional organizational structures with boards and
+   executives introduce single points of failure and limit community
+   involvement in funding decisions.
+
+4. **Community Involvement**: The current system provides minimal formal input
+   from the community regarding what projects should be funded, leading to a
+   misalignment between funded projects and community priorities.
+
+5. **Moving Towards a Non-Direct Funding Model**: There is strong community
+   support for a non-direct Dev Fund funding model. Allocating funds to a
+   Deferred Dev Fund Lockbox incentivizes the development of a decentralized
+   mechanism for the disbursement of the locked funds.
+
+By addressing these issues, this proposal aims to ensure sustainable,
+efficient, and decentralized funding for essential activities within the Zcash
+ecosystem.
+
+Requirements
+============
+
+1. **In-Protocol Lockbox**: The alternatives presented in this ZIP depend upon
+   the Lockbox Funding Streams proposal [#zip-2001]_.
+
+2. **Regulatory Considerations**: The allocation of funds should minimize
+   regulatory risks by avoiding direct funding of specific organizations. The
+   design should enable and encourage compliance with applicable laws and regulations to
+   support the long-term sustainability of the funding model.
+
+Non-requirements
+================
+
+The following considerations are explicitly deferred to future ZIPs and are not
+covered by this proposal:
+
+1. **Disbursement Mechanism**: The exact method for disbursing the accumulated
+   funds from the lockbox is not defined in this ZIP. The design,
+   implementation, and governance of the disbursement mechanism will be
+   addressed in a future ZIP. This includes specifics on how funds will be
+   allocated, the voting or decision-making process, and the structure of the
+   decentralized mechanism (such as a DAO).
+
+2. **Regulatory Compliance Details**: The proposal outlines the potential to
+   reduce regulatory risks by avoiding direct funding of US-based
+   organizations, but it does not detail specific regulatory compliance
+   strategies. Future ZIPs will need to address how the disbursement mechanism
+   complies with applicable laws and regulations.
+
+3. **Impact Assessment**: The long-term impact of reallocating a portion of the
+   block subsidy to the lockbox on the Zcash ecosystem, including its effect on
+   miners, developers, and the broader community, is not analyzed in this ZIP.
+   Subsequent proposals will need to evaluate the outcomes and make necessary
+   adjustments based on real-world feedback and data.
+
+Specification
+=============
+
+The following alternatives all depend upon the Lockbox Funding Streams proposal
+[#zip-2001]_ for storage of funds into a deferred value
+pool.
+
+Some of the alternatives described below do not specify a termination height
+for the funding streams they propose. In these cases, the termination height
+is set to `u32::MAX_VALUE`. A future network upgrade that alters the
+maximum possible block height MUST also alter these termination heights.
+
+Alternatives
+============
+
+Alternative 1: Lockbox For Decentralized Grants Allocation (perpetual 50% option)
+---------------------------------------------------------------------------------
+
+Proposed by Skylar Saveland
+
+* 50% of the block subsidy is to be distributed to the lockbox.
+
+As of block height 2726400, and continuing until modified by a future ZIP, the
+complete set of funding streams will be:
+
+================= =========== ============= ============== ============
+      Stream       Numerator   Denominator   Start height   End height
+================= =========== ============= ============== ============
+``FS_DEFERRED``       50           100          2726400      u32::MAX
+================= =========== ============= ============== ============
+
+Motivations for Alternative 1
+'''''''''''''''''''''''''''''
+
+This alternative proposes allocating a significantly larger portion of the block
+subsidy to development funding than is currently allocated, aiming to establish
+a long-term source of funding for protocol improvements. The disbursement of
+these funds will be governed by a mechanism to be determined by the community
+in the future, ensuring that the funds are released under agreed-upon constraints
+to maintain availability for years to come.
+
+The proposed lockbox funding model for Zcash's post-NU6 halving period allocates
+50% of the block reward to a deferred reserve, or "lockbox," designated for
+future decentralized grants funding. This approach is designed to address several
+critical motivations:
+
+.. Note: some of these are similar to the general motivations.
+
+1. **Regulatory Compliance**:
+
+   - **Reduction of Regulatory Risks**: Direct funding to legal entities poses
+     significant regulatory risks. Allocating funds to a decentralized lockbox
+     mitigates these risks by avoiding direct funding of any specific
+     organizations. This alternative represents the strongest regulatory
+     posture, as it reduces the likelihood of legal challenges associated with
+     funding centralized entities directly.
+
+   - **Potential Minimization of KYC Requirements**: The current funding
+     mechanism involves 100% KYC for recipients, which can be detrimental to
+     security, privacy, resilience, and participation. A sufficiently
+     decentralized disbursement mechanism could reduce the need for recipients
+     to undergo KYC with a controlling entity. This would preserve privacy and
+     encourage broader participation from developers and contributors who value
+     anonymity and privacy. By shifting from direct funding of specific legal
+     entities to a decentralized funding model, we create a more secure,
+     private, and resilient ecosystem. This potential future difference
+     enhances the robustness of the Zcash network by fostering a diverse and
+     engaged community without the constraints of centralized direct funding.
+
+2. **Ensuring Sustainable Development Funding**:
+
+   - **Need for Continuous Funding**: Zcash has numerous ongoing and future
+     projects essential for its ecosystem's growth and security. Without a
+     change, the expiration of the devfund will result in 100% of the block
+     reward going to miners, jeopardizing funding for development. The proposed
+     50% lockbox allocation ensures that funds are directed towards sustaining
+     and improving the Zcash ecosystem through a wide array of initiatives.
+     These include protocol development, new features, security audits, legal
+     support, marketing, ZSAs (Zcash Shielded Assets), stablecoins,
+     programmability, transitioning to a modern Rust codebase, wallets,
+     integrations with third-party services, improved node software, block
+     explorers, supporting ambassadors, and educational initiatives like
+     ZecHub.
+
+   - **Balanced Incentives for Network and Protocol Security**: While miners
+     have been essential in providing network security through hashpower,
+     allocating 100% of the block reward to mining alone overlooks the crucial
+     need for development, innovation, and protocol security. By investing in
+     these priorities, we enhance the long-term health and value of the
+     protocol, which ultimately benefits miners. A well-maintained and
+     innovative protocol increases the overall value of the network, making
+     miners' rewards more valuable. This balanced approach aligns the interests
+     of miners with the broader community, ensuring sustainable growth and
+     security for Zcash.
+
+3. **Efficiency, Accountability, and Decentralization**:
+
+   - **Reduction of Inefficiencies**: Traditional funding models often involve
+     significant corporate overhead and centralized decision-making, leading to
+     inefficiencies. The prior model provided two 501(c)(3) organizations with
+     constant funding for four years, which reduced accountability and allowed
+     for potential misalignment with the community's evolving priorities. By
+     funding projects directly rather than organizations, we can allocate
+     resources more efficiently, ensuring that funds are used for tangible
+     development rather than administrative costs. This approach minimizes the
+     influence of corporate executives, whose decisions have sometimes failed
+     to address critical issues promptly.
+
+   - **Increased Accountability**: A presumed grants-only mechanism, to be
+     defined in a future ZIP, would necessitate continuous accountability and
+     progress for continuous funding. Unlike the prior model, where
+     organizations received guaranteed funding regardless of performance, a
+     grants-based approach would require projects to demonstrate ongoing
+     success and alignment with community goals to secure funding. This
+     continuous evaluation fosters a more responsive and responsible allocation
+     of resources, ensuring that funds are directed towards initiatives that
+     provide the most value to the Zcash ecosystem. By increasing
+     accountability, this model promotes a culture of excellence and
+     innovation, driving sustained improvements and advancements in the
+     protocol.
+
+   - **Promotion of Decentralization**: The proposed non-direct funding model
+     stores deferred funds for future use, with the specifics of the
+     disbursement mechanism to be determined by a future ZIP. This could allow
+     the community to have a greater influence over funding decisions, aligning
+     more closely with the ethos of the Zcash project. By decentralizing the
+     allocation process, this approach has the potential to foster innovation
+     and community involvement, ensuring that development priorities are more
+     reflective of the community's needs and desires, promoting a more open,
+     transparent, and resilient ecosystem.
+
+4. **Incentives for Development and Collaboration**:
+
+   - **Creating a Strong Incentive to Implement the Disbursement Mechanism**:
+     Allocating 50% of the block reward to the lockbox indefinitely creates
+     a powerful incentive for the community to work together to implement the
+     disbursement mechanism without delay. Knowing that there is a substantial
+     amount of funds available, stakeholders will be motivated to develop and
+     agree on an effective, decentralized method for distributing these funds.
+
+   - **Incentivizing Continuous Improvements**: The accumulation of a large
+     stored fortune within the lockbox incentivizes continuous improvements
+     to the Zcash protocol and ecosystem. Developers, contributors, and
+     community members will be driven to propose and execute projects that
+     enhance the network, knowing that successful initiatives have the
+     potential to receive funding. This model fosters a culture of ongoing
+     innovation and development, ensuring that Zcash remains at the forefront
+     of blockchain technology.
+
+   - **Aligning Long-Term Interests**: By tying a significant portion of the
+     block reward to future decentralized grants funding, the model aligns
+     the long-term interests of all stakeholders. Miners, developers, and
+     community members alike have a vested interest in maintaining and
+     improving the Zcash network, as the value and success of their efforts
+     are directly linked to the availability and effective use of the lockbox
+     funds. This alignment of incentives ensures that the collective efforts
+     of the community are focused on the sustainable growth and advancement
+     of the Zcash ecosystem.
+
+Guidance on Future Requirements for Alternative 1
+'''''''''''''''''''''''''''''''''''''''''''''''''
+
+To support the motivations outlined, the following guidance is proposed for
+Alternative 1. Future ZIP(s) will define the disbursement mechanism. These are
+suggestions to achieve the outlined motivations and should be considered in
+those future ZIP(s). It is important to note that these are ideas and guidance,
+not hard, enforceable requirements:
+
+1. **Cap on Grants**: Grants should be capped to promote more granular
+   accountability and incremental goal-setting. This approach ensures that
+   projects are required to define their work, goals, milestones, KPIs, and
+   achievements in smaller, more manageable increments. Even if a single
+   project is utilizing significant funds quickly, the cap ensures that
+   progress is continuously evaluated and approved based on tangible results
+   and alignment with community priorities.
+
+2. **Decentralized Disbursement Mechanism**: The disbursement mechanism should
+   be sufficiently decentralized to ensure the regulatory motivations are
+   fulfilled. A decentralized mechanism could reduce the need for recipients to
+   undergo KYC with a controlling party, preserving privacy and aligning with
+   the ethos of the Zcash project.
+
+3. **Governance and Accountability**: The governance structure for the
+   disbursement mechanism should be open and accountable, with decisions made
+   through community consensus or decentralized voting processes to maintain
+   trust and accountability. This approach will help ensure that the allocation
+   of funds is fair and aligned with the community's evolving priorities.
+
+4. **Periodic Review and Adjustment**: There should be provisions for periodic
+   review and adjustment of the funding mechanism to address any emerging
+   issues or inefficiencies and to adapt to the evolving needs of the Zcash
+   ecosystem. This could include the ability to add or remove participants as
+   necessary. Regular assessments will help keep the funding model responsive
+   and effective, ensuring it continues to meet the community's goals.
+
+By addressing these motivations and providing this guidance, Alternative 1 aims
+to provide a robust, sustainable, and decentralized funding model that aligns
+with the principles and long-term goals of the Zcash community.
+
+Alternative 2: Hybrid Deferred Dev Fund: Transitioning to a Non-Direct Funding Model
+------------------------------------------------------------------------------------
+
+Proposed by Jason McGee, Peacemonger, GGuy
+
+* 12% of the block subsidy is to be distributed to the lockbox.
+* 8% of the block subsidy is to be distributed to the Financial Privacy
+  Foundation (FPF), for the express use of the Zcash Community Grants Committee
+  (ZCG) to fund independent teams in the Zcash ecosystem.
+
+As of block height 2726400, and continuing for one year, the complete set of
+funding streams will be:
+
+================= =========== ============= ============== ============
+      Stream       Numerator   Denominator   Start height   End height
+================= =========== ============= ============== ============
+``FS_DEFERRED``       12           100          2726400      3146400
+``FS_FPF_ZCG``         8           100          2726400      3146400
+================= =========== ============= ============== ============
+
+Motivations for Alternative 2
+'''''''''''''''''''''''''''''
+
+* **Limited Runway**: ZCG does not have the financial runway that ECC/BP and ZF
+  have. As such, allocating ongoing funding to ZCG will help ensure the Zcash
+  ecosystem has an active grants program.
+
+* **Promoting Decentralization**: Allocating a portion of the Dev Fund to Zcash
+  Community Grants ensures small teams continue to receive funding to
+  contribute to Zcash. Allowing the Dev Fund to expire, or putting 100% into a
+  lockbox, would disproportionally impact grant recipients. This hybrid
+  approach promotes decentralization and the growth of independent development
+  teams.
+
+* **Mitigating Regulatory Risks**: The Financial Privacy Foundation (FPF) is a
+  non-profit organization incorporated and based in the Cayman Islands. By
+  minimizing direct funding of US-based organizations, this proposal helps to
+  reduce potential regulatory scrutiny and legal risks.
+
+Alternative 3: Lockbox For Decentralized Grants Allocation (20% option)
+-----------------------------------------------------------------------
+
+Proposed by Kris Nuttycombe
+
+* 20% of the block subsidy is to be distributed to the lockbox.
+
+As of block height 2726400, and continuing for two years, the complete set of
+funding streams will be:
+
+================= =========== ============= ============== ============
+      Stream       Numerator   Denominator   Start height   End height
+================= =========== ============= ============== ============
+``FS_DEFERRED``       20           100          2726400      3566400
+================= =========== ============= ============== ============
+
+Motivations for Alternative 3
+'''''''''''''''''''''''''''''
+
+This alternative is presented as the simplest allocation of block rewards
+to a lockbox for future disbursement that is consistent with results of
+community polling.
+
+Alternative 4: Masters Of The Universe?
+---------------------------------------
+
+Proposed by NoamChom (Zcash forum)
+
+* 17% of the block subsidy is to be distributed to the lockbox.
+* 8% of the block subsidy is to be distributed to the Financial Privacy
+  Foundation (FPF), for the express use of the Zcash Community Grants Committee
+  (ZCG) to fund independent teams in the Zcash ecosystem.
+
+As of block height 2726400, and continuing for four years, the complete set of
+funding streams will be:
+
+================= =========== ============= ============== ============
+      Stream       Numerator   Denominator   Start height   End height
+================= =========== ============= ============== ============
+``FS_DEFERRED``       17           100          2726400      4406400
+``FS_FPF_ZCG``         8           100          2726400      4406400
+================= =========== ============= ============== ============
+
+Motivations for Alternative 4
+'''''''''''''''''''''''''''''
+
+This alternative proposes a slightly larger slice of the block subsidy than is
+currently allocated for development funding, in order to better provide for the
+needs of the Zcash community.
+
+
+Revisitation Requirement for Alternative 4
+''''''''''''''''''''''''''''''''''''''''''
+
+The terms for this Alternative should be revisited by the Zcash ecosystem upon
+creation/ activation of a "non-direct funding model" (NDFM). At that completion
+of an NDFM which accessess the lockbox funds, this ZIP should be reconsidered
+(potentially terminated) by the Zcash ecosystem, to determine if its ongoing
+direct block subsidies are preferred for continuation. Discussions / solications
+/ sentiment gathering from the Zcash ecosystem should be initiated ~6 months in
+advance of the presumed activation of a "non-direct funding model", such that
+the Zcash ecosystem preference can be expediently realized.
+
+
+Requirements related to direct streams for the Financial Privacy Foundation
+===========================================================================
+
+The following requirements apply to Alternative 2 and Alternative 4:
+
+The stream allocated to Zcash Community Grants (ZCG) is intended to fund
+independent teams entering the Zcash ecosystem, to perform major ongoing
+development (or other work) for the public good of the Zcash ecosystem, to the
+extent that such teams are available and effective. The ZCG Committee is given
+the discretion to allocate funds not only to major grants, but also to a
+diverse range of projects that advance the usability, security, privacy, and
+adoption of Zcash, including community programs, dedicated resources, and other
+projects of varying sizes.
+
+The funds SHALL be received and administered by the
+Financial Privacy Foundation (FPF). FPF MUST disburse them for grants and
+expenses reasonably related to the administration of the ZCG program, but
+subject to the following additional constraints:
+
+1. These funds MUST only be used to issue grants to external parties that are
+   independent of FPF, and to pay for expenses reasonably related to the
+   administration of the ZCG program. They MUST NOT be used by FPF for
+   its internal operations and direct expenses not related to the
+   administration of grants or the grants program.
+
+2. ZCG SHOULD support well-specified work proposed by the grantee, at
+   reasonable market-rate costs. They can be of any duration or ongoing without
+   a duration limit. Grants of indefinite duration SHOULD have semiannual
+   review points for continuation of funding.
+
+3. Priority SHOULD be given to major grants that bolster teams with substantial
+   (current or prospective) continual existence, and set them up for long-term
+   success, subject to the usual grant award considerations (impact, ability,
+   risks, team, cost-effectiveness, etc.). Priority SHOULD be given to major
+   grants that support ecosystem growth, for example through mentorship,
+   coaching, technical resources, creating entrepreneurial opportunities, etc.
+   If one proposal substantially duplicates another’s plans, priority SHOULD be
+   given to the originator of the plans.
+
+4. The ZCG committee SHOULD be restricted to funding projects that further the
+   Zcash cryptocurrency and its ecosystem (which is more specific than
+   furthering financial privacy in general) as permitted by FPF
+   and any relevant jurisdictional requirements.
+
+5. ZCG awards are subject to approval by a five-seat ZCG Committee. The ZCG
+   Committee SHALL be selected by the ZF’s Community Advisory Panel or a
+   successor process (e.g. as established by FPF). Elections SHALL be staggered
+   to ensure continuity within the Committee.
+
+6. The ZCG Committee’s funding decisions will be final, requiring no approval
+   from the FPF Board, but are subject to veto if the FPF judges them to
+   violate any relevant laws or other (current or future) obligations.
+
+7. ZCG Committee members SHALL have a one-year term and MAY sit for reelection.
+   The ZCG Committee is subject to the same conflict of interest policy that
+   governs the FPF Board of Directors (i.e. they MUST recuse themselves when
+   voting on proposals where they have a financial interest). At most one
+   person with association with the BP/ECC, at most one person with
+   association with the ZF, and at most one person with association with FPF
+   are allowed to sit on the ZCG Committee.
+   “Association” here means: having a financial interest, full-time employment,
+   being an officer, being a director, or having an immediate family
+   relationship with any of the above. The ZF SHALL continue to operate the
+   Community Advisory Panel and SHOULD work toward making it more
+   representative and independent (more on that below). Similarly, FPF should
+   also endeavor to establish its own means of collecting community sentiment
+   for the purpose of administering ZCG elections.
+
+8. A portion of the ZCG Slice shall be allocated to a Discretionary Budget,
+   which may be disbursed for expenses reasonably related to the administration
+   of the ZCG program. The amount of funds allocated to the Discretionary
+   Budget SHALL be decided by the ZF’s Community Advisory Panel or successor
+   process. Any disbursement of funds from the Discretionary Budget MUST be
+   approved by the ZCG Committee. Expenses related to the administration of the
+   ZCG program include, without limitation the following:
+
+    * Paying third party vendors for services related to domain name
+      registration, or the design, website hosting and administration of
+      websites for the ZCG Committee.
+    * Paying independent consultants to develop requests for proposals that
+      align with the ZCG program.
+    * Paying independent consultants for expert review of grant applications.
+    * Paying for sales and marketing services to promote the ZCG program.
+    * Paying third party consultants to undertake activities that support the
+      purpose of the ZCG program.
+    * Reimbursement to members of the ZCG Committee for reasonable travel
+      expenses, including transportation, hotel and meals allowance.
+
+9. A portion of the Discretionary Budget MAY be allocated to provide reasonable
+   compensation to members of the ZCG Committee. Committee member compensation
+   SHALL be limited to the hours needed to successfully perform their positions
+   and MUST align with the scope and responsibilities of their roles. The
+   allocation and distribution of compensation to committee members SHALL be
+   administered by the FPF. The compensation rate and hours for committee
+   members SHALL be determined by the ZF’s Community Advisory Panel or
+   successor process.
+
+10. The ZCG Committee’s decisions relating to the allocation and disbursement
+    of funds from the Discretionary Budget will be final, requiring no approval
+    from the FPF Board, but are subject to veto if the FPF judges
+    them to violate laws or FPF reporting requirements and other
+    (current or future) obligations.
+
+FPF SHALL recognize the ZCG slice of the Dev Fund as a Restricted Fund
+donation under the above constraints (suitably formalized), and keep separate
+accounting of its balance and usage under its Transparency and Accountability
+obligations defined below.
+
+FPF SHALL strive to define target metrics and key performance indicators,
+and the ZCG Committee SHOULD utilize these in its funding decisions.
+
+Furthering Decentralization
+---------------------------
+
+FPF SHALL conduct periodic reviews of the
+organizational structure, performance, and effectiveness of the ZCG program and
+committee, taking into consideration the input and recommendations of the ZCG
+Committee. As part of these periodic reviews, FPF MUST commit to
+exploring the possibility of transitioning ZCG into an independent organization
+if it is economically viable and it aligns with the interests of the Zcash
+ecosystem and prevailing community sentiment.
+
+In any transition toward independence, priority SHALL be given to maintaining
+or enhancing the decentralization of the Zcash ecosystem. The newly formed
+independent organization MUST ensure that decision-making processes remain
+community-driven, transparent, and responsive to the evolving needs of the
+Zcash community and ecosystem. In order to promote geographic decentralization,
+the new organization SHOULD establish its domicile outside of the United
+States.
+
+Transparency and Accountability
+-------------------------------
+
+FPF MUST accept the following obligations in this section on behalf of ZCG:
+
+* Publication of the ZCG Dashboard, providing a snapshot of ZCG’s current
+  financials and any disbursements made to grantees.
+* Bi-weekly meeting minutes documenting the decisions made by the ZCG committee
+  on grants.
+* Quarterly reports, detailing future plans, execution on previous plans, and
+  finances (balances, and spending broken down by major categories).
+* Annual detailed review of the organization performance and future plans.
+* Annual financial report (IRS Form 990, or substantially similar information).
+
+BP, ECC, ZF, FPF, ZCG and grant recipients MUST promptly disclose any security
+or privacy risks that may affect users of Zcash (by responsible disclosure
+under confidence to the pertinent developers, where applicable).
+
+All substantial software whose development was funded by the Dev Fund SHOULD be
+released under an Open Source license (as defined by the Open Source Initiative
+[#osd]_), preferably the MIT license.
+
+Enforcement
+-----------
+
+FPF MUST contractually commit to fulfill these obligations on behalf of
+ZCG, and the prescribed use of funds, such that substantial violation, not
+promptly remedied, will result in a modified version of Zcash node software
+that removes ZCG’s Dev Fund slice and allocates it to the Deferred Dev Fund
+lockbox.
+
+References
+==========
+
+.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to
+    Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs
+    Lowercase in RFC 2119 Key Words" `_
+.. [#osd] `The Open Source Definition `_
+.. [#zip-1014] `ZIP 1014: Dev Fund Proposal and Governance `_
+.. [#zip-2001] `ZIP 2001: Lockbox Funding Streams `_
diff --git a/zips/draft-zf-community-dev-fund-2-proposal.rst b/zips/draft-zf-community-dev-fund-2-proposal.rst
new file mode 100644
index 000000000..30182c7fe
--- /dev/null
+++ b/zips/draft-zf-community-dev-fund-2-proposal.rst
@@ -0,0 +1,499 @@
+::
+
+  ZIP: Unassigned
+  Title: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
+  Owners: Jack Gavigan 
+  Credits: The ZIP 1014 Authors
+  Status: Draft
+  Category: Consensus Process
+  Created: 2024-07-01
+  License: MIT
+  Discussions-To: 
+  Pull-Request: 
+
+
+Terminology
+===========
+
+The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" 
+in this document are to be interpreted as described in BCP 14 [#BCP14]_ when,
+and only when, they appear in all capitals.
+
+The term "network upgrade" in this document is to be interpreted as described 
+in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License Agreement
+([#trademark]_ or successor agreement).
+
+The terms "block subsidy" and "halving" in this document are to be interpreted 
+as described in sections 3.10 and 7.8 of the Zcash Protocol Specification.
+[#protocol]_
+
+"Electric Coin Company", also called "ECC", refers to the US-incorporated 
+Zerocoin Electric Coin Company, LLC.
+
+"Bootstrap Project", also called "BP", refers to the US-incorporated 501(c)(3) 
+nonprofit corporation of that name.
+
+"Zcash Foundation", also called "ZF", refers to the US-incorporated 501(c)(3) 
+nonprofit corporation of that name.
+
+"Financial Privacy Foundation", also called "FPF", refers to the Cayman 
+Islands-incorporated non-profit foundation company limited by guarantee of 
+that name.
+
+"Autonomous Entities" refers to committees, DAOs, teams or other groups to 
+which FPF provides operations, administrative, and financial management 
+support. 
+
+"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code 
+(Title 26 of the U.S. Code). [#section501c3]_
+
+"Zcash Community Advisory Panel", also called "ZCAP", refers to the panel of 
+community members assembled by the Zcash Foundation and described at [#zcap]_.
+
+The terms "Testnet" and "Mainnet" are to be interpreted as described in 
+section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
+
+“Lockbox” refers to a deferred funding pool of issued Zcash value as described 
+in ZIP 2001 [#zip-2001]_.
+
+“Dev Fund Reserve”, also called “DFR”, refers to the funds that are to be 
+stored in the Lockbox as a result of the changes described in this ZIP. 
+
+
+Abstract
+========
+
+This proposal describes a structure for a new Zcash Development Fund (“Dev 
+Fund”), to be enacted in Network Upgrade 6 and last for 2 years. This Dev 
+Fund shall consist of 20% of the block subsidies. 
+
+The Dev Fund shall be split into 3 slices:
+
+* 32% for Zcash Foundation;
+* 40% for "Zcash Community Grants", intended to fund large-scale long-term 
+  Projects (administered by the Financial Privacy Foundation, with extra
+  community input and scrutiny).
+* 28% for a Dev Fund Reserve, to be stored in a Lockbox. 
+
+The Lockbox will securely store funds until a disbursement mechanism is 
+established in a future ZIP.
+
+Governance and accountability are based on existing entities and legal 
+mechanisms, and increasingly decentralized governance is encouraged.
+
+
+Motivation
+==========
+
+Starting at Zcash's second halving in November 2024, the first Dev Fund will 
+expire, meaning that by default 100% of the block subsidies will be allocated 
+to miners, and no further funds will be automatically allocated to any other 
+entities. Consequently, no substantial new funding may be available to 
+existing teams dedicated to furthering charitable, educational, or scientific 
+purposes, such as research, development, and outreach: the Electric Coin 
+Company (ECC), the Zcash Foundation (ZF), and the many entities funded by the 
+ZF grants and Zcash Community Grants programs.
+
+There is a need to continue to strike a balance between incentivizing the 
+security of the consensus protocol (i.e., mining) versus crucial charitable, 
+educational, and/or scientific aspects, such as research, development and 
+outreach.
+
+Furthermore, there is a need to balance the sustenance of ongoing work by the 
+current teams dedicated to Zcash, with encouraging decentralization and growth 
+of independent development teams.
+
+For these reasons, the Zcash Community desires to allocate and contribute a 
+slice of the block subsidies otherwise allocated to miners as a donation to 
+support charitable, educational, and scientific activities within the meaning 
+of Section 501(c)(3) of Title 26 of the United States Code, and the Cayman 
+Islands’ Foundation Companies Law, 2017.
+
+The Zcash Community also supports the concept of a non-direct funding model, 
+and desires to allocate a slice of the block subsidies otherwise allocated 
+to miners to a Lockbox, with the expectation that those funds will be 
+distributed under a non-direct funding model, which may be implemented in a 
+future network upgrade. 
+
+For these reasons, the Zcash Community wishes to establish a Hybrid 
+Development Fund after the second halving in November 2024, and apportion it 
+among ZF, ZCG, and a Dev Fund Reserve to be held in a Lockbox.
+
+
+Requirements
+============
+
+The Dev Fund should encourage decentralization of the Zcash ecosystem, by 
+supporting new teams dedicated to Zcash.
+
+The Dev Fund should maintain the existing teams and capabilities in the Zcash 
+ecosystem, unless and until concrete opportunities arise to create even 
+greater value for the Zcash ecosystem.
+
+There should not be any single entity which is a single point of failure, 
+i.e., whose capture or failure will effectively prevent effective use of the 
+funds.
+
+Major funding decisions should be based, to the extent feasible, on inputs 
+from domain experts and pertinent stakeholders.
+
+The Dev Fund mechanism itself should not modify the monetary emission curve 
+(and in particular, should not irrevocably burn coins).
+
+In case the value of ZEC jumps, the Dev Fund recipients should not wastefully 
+use excessive amounts of funds. Conversely, given market volatility and 
+eventual halvings, it is desirable to create rainy-day reserves.
+
+The Dev Fund mechanism should not reduce users' financial privacy or security. 
+In particular, it should not cause them to expose their coin holdings, nor 
+cause them to maintain access to secret keys for much longer than they would 
+otherwise. (This rules out some forms of voting, and of disbursing coins to 
+past/future miners.)
+
+The new Dev Fund system should be simple to understand and realistic to 
+implement. In particular, it should not assume the creation of new mechanisms 
+(e.g., election systems) or entities (for governance or development) for its 
+execution; but it should strive to support and use these once they are built.
+
+The Dev Fund should comply with legal, regulatory, and taxation constraints in 
+pertinent jurisdictions.
+
+The Lockbox must be prepared to allocate resources efficiently once the 
+disbursement mechanism is defined. This includes ensuring that funds are 
+readily available for future projects and not tied up in organizational 
+overhead. 
+
+The Lockbox must implement robust security measures to protect against 
+unauthorized access or misuse of funds. It must not be possible to disburse 
+funds from the Lockbox until the Zcash Community reaches consensus on the 
+design of a disbursement mechanism that is defined in a ZIP and implemented as 
+part of a future Network Upgrade. 
+
+
+Non-requirements
+================
+
+General on-chain governance is outside the scope of this proposal.
+
+Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or 
+one-person-one-vote) are outside the scope of this proposal, though there is 
+prescribed room for integrating them once available.
+
+The mechanism by which funds held in the Dev Fund Reserve Lockbox are to be 
+distributed is outside the scope of this proposal. 
+
+
+Specification
+=============
+
+Consensus changes implied by this specification are applicable to the Zcash 
+Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be 
+applied to the Zcash Testnet for testing purposes.
+
+
+Dev Fund allocation
+-------------------
+
+Starting at the second Zcash halving in 2024, until block height 3566400 
+(which is expected to occur approximately two years after the second Zcash 
+halving), 20% of the block subsidy of each block SHALL be allocated to a Dev 
+Fund that consists of the following three slices:
+
+* 32% for the Zcash Foundation (denoted **ZF slice**);
+* 40% for the Financial Privacy Foundation, for "Zcash Community Grants" for
+  large-scale long-term projects (denoted **ZCG slice**);
+* 28% for the Dev Fund Reserve (denoted **DFR slice**).
+
+The slices are described in more detail below. The fund flow will be 
+implemented at the consensus-rule layer, by sending the corresponding ZEC to 
+the designated address(es) for each block. This Dev Fund will end at block 
+height 3566400 (unless extended/modified by a future ZIP).
+
+
+ZF slice (Zcash Foundation)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This slice of the Dev Fund will flow as charitable contributions from the 
+Zcash Community to ZF, to be used at its discretion for any purpose within its 
+mandate to support financial privacy and the Zcash platform, including: 
+development, education, supporting community communication online and via 
+events, gathering community sentiment, and awarding external grants for all of 
+the above, subject to the requirements of Section 501(c)(3). The ZF slice will 
+be treated as a charitable contribution from the Community to support these 
+educational, charitable, and scientific purposes.
+
+
+ZCG slice (Zcash Community Grants)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This slice of the Dev Fund is intended to fund independent teams entering the
+Zcash ecosystem, to perform major ongoing development (or other work) for the
+public good of the Zcash ecosystem, to the extent that such teams are 
+available and effective.
+
+The funds SHALL be received and administered by FPF. FPF MUST disburse them 
+for "Zcash Community Grants" and expenses reasonably related to the 
+administration of Zcash Community Grants, but subject to the following 
+additional constraints:
+
+1. These funds MUST only be used to issue Zcash Community Grants to external 
+   parties that are independent of FPF or to Autonomous Entities that operate 
+   under the FPF umbrella, and to pay for expenses reasonably related to 
+   the administration of Zcash Community Grants. They MUST NOT be used by FPF 
+   for its internal operations and direct expenses not related to 
+   administration of Zcash Community Grants. Additionally, ZF is ineligible to 
+   receive Zcash Community Grants while ZF is receiving a slice of the Dev 
+   Fund. 
+
+2. Zcash Community Grants SHOULD support well-specified work proposed by the 
+   grantee, at reasonable market-rate costs. They can be of any duration or 
+   ongoing without a duration limit. Grants of indefinite duration SHOULD be 
+   reviewed periodically (on a schedule that the Zcash Community Grants
+   Committee considers appropriate for the value and complexity of the grant) 
+   for continuation of funding.
+
+3. Priority SHOULD be given to Zcash Community Grants that bolster teams with 
+   substantial (current or prospective) continual existence, and set them up 
+   for long-term success, subject to the usual grant award considerations 
+   (impact, ability, risks, team, cost-effectiveness, etc.). Priority SHOULD 
+   Be given to grants that support ecosystem growth, for example through 
+   mentorship, coaching, technical resources, creating entrepreneurial 
+   opportunities, etc. If one proposal substantially duplicates another's 
+   plans, priority SHOULD be given to the originator of the plans.
+
+4. Zcash Community Grants SHOULD be restricted to furthering the Zcash 
+   cryptocurrency and its ecosystem (which is more specific than furthering
+   financial privacy in general).
+
+5. Zcash Community Grants awards are subject to approval by a five-seat Zcash 
+   Community Grants Committee. The Zcash Community Grants Committee SHALL be 
+   selected by the ZF's Zcash Community Advisory Panel (ZCAP) or successor 
+   process.
+
+6. The Zcash Community Grants Committee's funding decisions will be final, 
+   requiring no approval from the FPF Board, but are subject to veto if FPF
+   judges them to violate Cayman law or the FPF's reporting requirements and 
+   other (current or future) obligations under the Cayman Islands’ Companies 
+   Act (2023 Revision) and Foundation Companies Law, 2017.
+
+7. Zcash Community Grants Committee members SHALL have a one-year term and MAY 
+   sit for reelection. The Zcash Community Grants Committee is subject to the 
+   same conflict of interest policy that governs the FPF Board of Directors 
+   (i.e. they MUST recuse themselves when voting on proposals where they have 
+   a financial interest). At most one person with association with the BP/ECC, 
+   at most one person with association with the ZF and at most one person with 
+   association with the FPF, are allowed to sit on the Zcash Community Grants 
+   Committee.  "Association" here means: having a financial interest, 
+   full-time employment, being an officer, being a director, or having an 
+   immediate family relationship with any of the above. 
+   
+8. A portion of the ZCG Slice shall be allocated to a Discretionary Budget, 
+   which may be disbursed for expenses reasonably related to the 
+   administration of Zcash Community Grants. The amount of funds allocated to  
+   the Discretionary Budget SHALL be decided by the ZF's Zcash Community 
+   Advisory Panel or successor process. Any disbursement of funds from the 
+   Discretionary Budget MUST be approved by the Zcash Community Grants 
+   Committee. Expenses related to the administration of Zcash Community Grants 
+   include, without limitation the following:
+  
+   * Paying for operational management and administration services that 
+     support the purpose of the Zcash Community Grants program, including
+     administration services provided by FPF.
+   * Paying third party vendors for services related to domain name
+     registration, or the design, website hosting and administration of
+     websites for the Zcash Community Grants Committee.
+   * Paying independent consultants to develop requests for proposals that
+     align with the Zcash Community Grants program.
+   * Paying independent consultants for expert review of grant applications.
+   * Paying for sales and marketing services to promote the Zcash Community 
+     Grants program.
+   * Paying third party consultants to undertake activities that support the 
+     purpose of the Zcash Community Grants program. 
+   * Reimbursement to members of the Zcash Community Grants Committee for 
+     reasonable travel expenses, including transportation, hotel and meals 
+     allowance.
+     
+   The Zcash Community Grants Committee's decisions relating to the allocation 
+   and disbursement of funds from the Discretionary Budget will be final, 
+   requiring no approval from the FPF Board, but are subject to veto if FPF 
+   judges them to violate Cayman law or the FPF's reporting requirements and 
+   other (current or future) obligations under Cayman Islands law.
+
+
+9. A portion of the Discretionary Budget MAY be allocated to provide 
+   reasonable compensation to members of the Zcash Community Grants Committee.
+   The time for which each Committee member is compensated SHALL be limited to 
+   the hours needed to successfully perform their positions, up to a maximum 
+   of 15 hours in each month, and MUST align with the scope and 
+   responsibilities of that member's role. The compensation rate for each 
+   Committee member SHALL be $115 per hour (and therefore the maximum 
+   compensation for a Committee member is $1725 per month). The allocation and 
+   distribution of compensation to committee members SHALL be administered by
+   FPF. Changes to the hours or rate SHALL be determined by the ZF’s Zcash 
+   Community Advisory Panel or successor process.
+
+As part of the contractual commitment specified under the `Enforcement`_ section 
+below, FPF SHALL be contractually required to recognize the ZCG slice of the Dev 
+Fund as a Restricted Fund donation under the above constraints (suitably 
+formalized), and keep separate accounting of its balance and usage under its 
+`Transparency and Accountability`_ obligations defined below.
+
+
+DFR slice (Dev Fund Reserve)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This slice of the Dev Fund is to be stored in a Lockbox until such time as the  
+Zcash Community reaches consensus on the design of a disbursement mechanism 
+that is defined in a ZIP and implemented as part of a future Network Upgrade. 
+
+
+Transparency and Accountability
+-------------------------------
+
+Obligations
+~~~~~~~~~~~
+
+ZF, FPF and Zcash Community Grant recipients (during and leading to their award 
+period) SHALL all accept the obligations in this section.
+
+Ongoing public reporting requirements:
+
+* Quarterly reports, detailing future plans, execution on previous plans, and 
+  finances (balances, and spending broken down by major categories).
+* Monthly developer calls, or a brief report, on recent and forthcoming tasks. 
+  (Developer calls may be shared.)
+* Annual detailed review of the organization performance and future plans.
+* Annual financial report (IRS Form 990, or substantially similar 
+  information).
+
+These reports may be either organization-wide, or restricted to the income, 
+expenses, and work associated with the receipt of Dev Fund. 
+
+It is expected that ZF, FPF and Zcash Community Grant recipients will be 
+focused primarily (in their attention and resources) on Zcash. Thus, they MUST
+promptly disclose:
+
+* Any major activity they perform (even if not supported by the Dev Fund) that 
+  is not in the interest of the general Zcash ecosystem.
+* Any conflict of interest with the general success of the Zcash ecosystem.
+
+BP, ECC, ZF, FPF and grant recipients MUST promptly disclose any security or 
+privacy risks that may affect users of Zcash (by responsible disclosure under 
+confidence to the pertinent developers, where applicable).
+
+ZF's and FPF's annual reports on its non-grant operations, SHOULD be at least 
+as detailed as grant proposals/reports submitted by other funded parties, and 
+satisfy similar levels of public scrutiny.
+
+All substantial software whose development was funded by the Dev Fund SHOULD 
+be released under an Open Source license (as defined by the Open Source 
+Initiative [#osd]_), preferably the MIT license.
+
+The ZF SHALL continue to operate the Zcash Community Advisory Panel and SHOULD 
+work toward making it more representative and independent (more on that below).
+
+Enforcement
+~~~~~~~~~~~
+
+For grant recipients, these conditions SHOULD be included in their contract 
+with FPF, such that substantial violation, not promptly remedied, will cause 
+forfeiture of their grant funds and their return to FPF.
+
+ZF and FPF MUST contractually commit to each other to fulfill these conditions, 
+and the prescribed use of funds, such that substantial violation, not promptly 
+remedied, will permit the other parties to issue a modified version of Zcash 
+node software that removes the violating party's Dev Fund slice, and use the 
+Zcash trademark for this modified version. The slice's funds will be reassigned 
+to ZCG (whose integrity is legally protected by the Restricted Fund treatment).
+
+
+Amendments and Replacement of the Dev Fund
+------------------------------------------
+
+Nothing in this ZIP is intended to preclude any amendments to the Dev Fund 
+(including but not limited to, changes to the Dev Fund allocation and/or the 
+addition of new Dev Fund recipients), if such amendments enjoy the consensus 
+support of the Zcash community. 
+
+Nothing in this ZIP is intended to preclude replacement of the Dev Fund with a 
+different mechanism for ecosystem development funding. 
+
+ZF and FPF SHOULD facilitate the amendment or replacement of the Dev Fund if 
+there is sufficient community support for doing so. 
+
+This ZIP recognizes there is strong community support for a non-direct funding 
+model. As such, ZF MUST collaborate with the Zcash community to research and 
+explore the establishment of a non-direct funding model. The research should 
+consider potential designs as well as possible legal and regulatory risks.
+
+
+Future Community Governance
+---------------------------
+
+Decentralized community governance is used in this proposal via the Zcash 
+Community Advisory Panel as input into the Zcash Community Grants Committee 
+which governs the `ZCG slice (Zcash Community Grants)`_.
+
+It is highly desirable to develop robust means of decentralized community
+voting and governance, either by expanding the Zcash Community Advisory Panel 
+or a successor mechanism. ZF, FPF and ZCG SHOULD place high priority on such 
+development and its deployment, in their activities and grant selection.
+
+
+ZF Board Composition
+--------------------
+
+Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current 
+business or employment relationships with ECC or BP.
+
+The Zcash Foundation SHOULD endeavor to use the Zcash Community Advisory Panel 
+(or successor mechanism) as advisory input for future board elections.
+
+
+FPF Board Composition
+---------------------
+
+Members of FPF's Board of Directors MUST NOT hold equity in ECC or have current 
+business or employment relationships with ECC or BP. 
+
+
+Acknowledgements
+================
+
+This proposal is a modification of ZIP 1014 [#zip-1014]_ by the Zcash Foundation based on 
+feedback and suggestions from the community, and incorporating elements of draft ZIPs by 
+community members Jason McGee and Skylar. 
+
+ZIP 1014 is a limited modification of Eran Tromer's ZIP 1012 [#zip-1012]_
+by the Zcash 
+Foundation and ECC, further modified by feedback from the community.
+
+Eran's proposal is most closely based on the Matt Luongo 'Decentralize the
+Dev Fee' proposal (ZIP 1011) [#zip-1011]_. Relative to ZIP 1011 there are substantial 
+changes and mixing in of elements from *@aristarchus*'s '20% Split Evenly 
+Between the ECC and the Zcash Foundation' (ZIP 1003) [#zip-1003]_, Josh Cincinnati's 
+'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) [#zip-1010]_, and 
+extensive discussions in the `Zcash Community Forum`_, including valuable comments 
+from forum users *@aristarchus* and *@dontbeevil*. 
+
+.. _Zcash Community Forum: https://forum.zcashcommunity.com/
+
+
+References
+==========
+
+.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_
+.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_
+.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_
+.. [#trademark] `Zcash Trademark Donation and License Agreement `_
+.. [#osd] `The Open Source Definition `_
+.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_
+.. [#zip-1003] `ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate `_
+.. [#zip-1010] `ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams `_
+.. [#zip-1011] `ZIP 1011: Decentralize the Dev Fee `_
+.. [#zip-1012] `ZIP 1012: Dev Fund to ECC + ZF + Major Grants `_
+.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_
+.. [#zip-2001] `ZIP 2001: Lockbox Funding Streams `_
+.. [#zcap] `Zcash Community Advisory Panel `_
+.. [#section501c3] `U.S. Code, Title 26, Section 501(c)(3) `_
+
diff --git a/zip-0000.rst b/zips/zip-0000.rst
similarity index 97%
rename from zip-0000.rst
rename to zips/zip-0000.rst
index ed56eae6e..b7f9ed50f 100644
--- a/zip-0000.rst
+++ b/zips/zip-0000.rst
@@ -2,16 +2,15 @@
 
   ZIP: 0
   Title: ZIP Process
-  Owners: Daira Emma Hopwood 
-          teor 
-          Jack Grigg 
-          Conrado Gouvea 
-          Aditya Bharadwaj 
+  Owners: Jack Grigg 
+          Conrado Gouvêa 
           Arya 
-  Original-Authors: Daira Emma Hopwood
+  Original-Authors: Daira-Emma Hopwood
                     Josh Cincinnati
                     George Tankersley
                     Deirdre Connolly
+                    teor
+                    Aditya Bharadwaj
   Credits: Luke Dashjr
   Status: Active
   Category: Process
@@ -19,7 +18,6 @@
   License: BSD-2-Clause
 
 
-
 Terminology
 ===========
 
@@ -172,10 +170,8 @@ ZIP Editors
 
 The current ZIP Editors are:
 
-* Daira Emma Hopwood and Jack Grigg, associated with the Electric Coin
-  Company;
-* teor, Conrado Gouvea, and Arya, associated with the Zcash Foundation.
-* Aditya Bharadwaj, associated with Nighthawk Apps.
+* Jack Grigg, associated with the Electric Coin Company;
+* Conrado Gouvêa and Arya, associated with the Zcash Foundation.
 
 All can be reached at zips@z.cash. The current design of the ZIP Process
 dictates that there are always at least two ZIP Editors: at least one
@@ -187,9 +183,10 @@ they have relating to their responsibilities as ZIP Editors.
 ZIP Editors MUST be publicly transparent about any external influence
 or constraints that have been placed or attempted to be placed on their
 actions as ZIP Editors (including from the Electric Coin Company,
-Zcash Foundation, or Nighthawk Apps), whether or not it affects those
-actions. This should not be interpreted as requiring ZIP Editors to
-reveal knowledge of undisclosed security vulnerabilities or mitigations.
+Zcash Foundation, or other organizations with which the Editors are
+associated), whether or not it affects those actions. This should not be
+interpreted as requiring ZIP Editors to reveal knowledge of undisclosed
+security vulnerabilities or mitigations.
 
 Additional Editors may be selected, with their consent, by consensus
 among the current Editors.
@@ -798,6 +795,13 @@ See Also
 * `Zcash Network Upgrade Pipeline `__
 
 
+Acknowledgements
+================
+
+We thank George Tankersley, Deirdre Connolly, Daira-Emma Hopwood, teor,
+and Aditya Bharadwaj for their past contributions as ZIP Editors.
+
+
 References
 ==========
 
diff --git a/zip-0001.rst b/zips/zip-0001.rst
similarity index 100%
rename from zip-0001.rst
rename to zips/zip-0001.rst
diff --git a/zip-0002.rst b/zips/zip-0002.rst
similarity index 100%
rename from zip-0002.rst
rename to zips/zip-0002.rst
diff --git a/zip-0032-orchard-internal-key-derivation.svg b/zips/zip-0032-orchard-internal-key-derivation.svg
similarity index 100%
rename from zip-0032-orchard-internal-key-derivation.svg
rename to zips/zip-0032-orchard-internal-key-derivation.svg
diff --git a/zip-0032-sapling-internal-key-derivation.svg b/zips/zip-0032-sapling-internal-key-derivation.svg
similarity index 100%
rename from zip-0032-sapling-internal-key-derivation.svg
rename to zips/zip-0032-sapling-internal-key-derivation.svg
diff --git a/zip-0032.rst b/zips/zip-0032.rst
similarity index 99%
rename from zip-0032.rst
rename to zips/zip-0032.rst
index a66f930c7..a008a7402 100644
--- a/zip-0032.rst
+++ b/zips/zip-0032.rst
@@ -3,7 +3,7 @@
   ZIP: 32
   Title: Shielded Hierarchical Deterministic Wallets
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Credits: Sean Bowe
            Kris Nuttycombe
            Ying Tong Lai
@@ -319,7 +319,7 @@ The values of :math:`I`, :math:`I_\mathsf{nsk}`, and :math:`R` are the same betw
 a full viewing key, and deriving the corresponding spending key. Both of these derivations
 are shown in the following diagram:
 
-.. figure:: zip-0032-sapling-internal-key-derivation.png
+.. figure:: ../rendered/assets/images/zip-0032-sapling-internal-key-derivation.png
     :width: 900px
     :align: center
     :figclass: align-center
@@ -432,7 +432,7 @@ field relative to the external full viewing key, which results in different
 fields being derived, as specified in [#protocol-orchardkeycomponents]_ and shown in the following
 diagram:
 
-.. figure:: zip-0032-orchard-internal-key-derivation.png
+.. figure:: ../rendered/assets/images/zip-0032-orchard-internal-key-derivation.png
     :width: 720px
     :align: center
     :figclass: align-center
diff --git a/zips/zip-0068.rst b/zips/zip-0068.rst
new file mode 100644
index 000000000..1c22879e8
--- /dev/null
+++ b/zips/zip-0068.rst
@@ -0,0 +1,328 @@
+::
+
+  ZIP: 68
+  Title: Relative lock-time using consensus-enforced sequence numbers
+  Credits: Mark Friedenbach 
+           BtcDrak 
+           Nicolas Dorier 
+           kinoshitajona 
+  Category: Consensus
+  Status: Draft
+  Created: 2016-06-06
+
+
+Terminology
+===========
+
+The key words "MUST" and "MAY" in this document are to be interpreted as described in
+RFC 2119. [#RFC2119]_
+
+The "Median Time Past" of a block in this document is to be interpreted as described in
+[#zip-0113]_.
+
+
+Abstract
+========
+
+This ZIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence
+number field, to enable a signed transaction input to remain invalid for a defined period
+of time after confirmation of its corresponding outpoint.
+
+
+Motivation
+==========
+
+Zcash transactions have a sequence number field for each input, inherited from Bitcoin.
+The original idea in Bitcoin appears to have been that a transaction in the mempool would
+be replaced by using the same input with a higher sequence value. Although this was not
+properly implemented, it assumes miners would prefer higher sequence numbers even if the
+lower ones were more profitable to mine. However, a miner acting on profit motives alone
+would break that assumption completely. The change described by this ZIP repurposes the
+sequence number for new use cases without breaking existing functionality. It also leaves
+room for future expansion and other use cases.
+
+The transaction ``nLockTime`` is used to prevent the mining of a transaction until a
+certain date. ``nSequence`` will be repurposed to prevent mining of a transaction until
+a certain age of the spent output in blocks or timespan. This, among other uses, allows
+bi-directional payment channels as used in [#deployable-lightning]_ and [#zip-0112]_.
+
+
+Specification
+=============
+
+This specification defines the meaning of sequence numbers for transactions in blocks
+after this proposal has activated.
+
+If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to
+the sequence number and can be included in any block under all currently possible
+circumstances.
+
+If bit (1 << 31) of the sequence number is not set, then the sequence number is
+interpreted as an encoded relative lock-time.
+
+The sequence number encoding MUST be interpreted as follows: 
+
+Bit (1 << 22) determines if the relative lock-time is time-based or block based:
+If the bit is set, the relative lock-time specifies a timespan in units of 32 seconds
+granularity. The timespan starts from the Median Time Past of the output’s previous block,
+and ends at the Median Time Past of the previous block. If the bit is not set, the
+relative lock-time specifies a number of blocks.
+
+Note: the 64-second time unit differs from Bitcoin's BIP 68, which uses a 512-second
+time unit.
+
+The flag (1 << 22) is the highest order bit in a 3-byte signed integer for use in
+Zcash scripts as a 3-byte ``PUSHDATA`` with ``OP_CHECKSEQUENCEVERIFY`` [#zip-0112]_.
+
+This specification only interprets 22 bits of the sequence number as relative lock-time,
+so a mask of ``0x003FFFFF`` MUST be applied to the sequence field to extract the relative
+lock-time. The 22-bit specification allows for over 8.5 years of relative lock-time.
+
+.. figure:: ../rendered/assets/images/zip-0068-encoding.png
+    :align: center
+    :figclass: align-center
+
+    A 32-bit field with 'Disable Flag' at bit (1 << 31), 'Type Flag' at bit (1 << 22), and 'Value' in the low 22 bits.
+
+For time-based relative lock-time, 64-second granularity was chosen because the block
+target spacing for Zcash, after activation of the Blossom network upgrade, is 75 seconds.
+So when using block-based or time-based, roughly the same amount of time can be encoded
+with the available number of bits. Converting from a sequence number to seconds is
+performed by multiplying by 64.
+
+When the relative lock-time is time-based, it is interpreted as a minimum block-time
+constraint over the input's age. A relative time-based lock-time of zero indicates an
+input which can be included in any block. More generally, a relative time-based
+lock-time n can be included into any block produced 64 \* n seconds after the mining
+date of the output it is spending, or any block thereafter.
+The mining date of the output is equal to the Median Time Past of the previous block
+that mined it.
+
+The block produced time is equal to the Median Time Past of its previous block.
+
+When the relative lock-time is block-based, it is interpreted as a minimum block-height
+constraint over the input's age. A relative block-based lock-time of zero indicates an
+input that can be included in any block. More generally, a relative block lock-time n
+MAY be included n blocks after the mining date of the output it is spending, or any
+block thereafter.
+
+The new rules are not applied to the ``nSequence`` field of the input of the coinbase
+transaction.
+
+
+Reference Implementation
+========================
+
+.. highlight::c++
+
+   enum {
+       /* Interpret sequence numbers as relative lock-time constraints. */
+       LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
+   };
+
+   /* Setting nSequence to this value for every input in a transaction
+    * disables nLockTime. */
+   static const uint32_t SEQUENCE_FINAL = 0xffffffff;
+
+   /* Below flags apply in the context of ZIP 68. */
+   /* If this flag set, CTxIn::nSequence is NOT interpreted as a
+    * relative lock-time. */
+   static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
+
+   /* If CTxIn::nSequence encodes a relative lock-time and this flag
+    * is set, the relative lock-time has units of 512 seconds,
+    * otherwise it specifies blocks with a granularity of 1. */
+   static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
+
+   /* If CTxIn::nSequence encodes a relative lock-time, this mask is
+    * applied to extract that lock-time from the sequence field. */
+   static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x003fffff;
+
+   /* In order to use the same number of bits to encode roughly the
+    * same wall-clock duration, and because blocks are naturally
+    * limited to occur every 75s on average after Blossom activation,
+    * the minimum granularity for time-based relative lock-time is
+    * fixed at 64 seconds.
+    * Converting from CTxIn::nSequence to seconds is performed by
+    * multiplying by 64, or equivalently shifting up by 6 bits. */
+   static const int SEQUENCE_LOCKTIME_GRANULARITY = 6;
+
+   /**
+    * Calculates the block height and previous block's Median Time Past at
+    * which the transaction will be considered final in the context of ZIP 68.
+    * Also removes from the vector of input heights any entries which did not
+    * correspond to sequence locked inputs as they do not affect the calculation.
+    */
+   static std::pair CalculateSequenceLocks(const CTransaction &tx, int flags, std::vector* prevHeights, const CBlockIndex& block)
+   {
+       assert(prevHeights->size() == tx.vin.size());
+
+       // Will be set to the equivalent height- and time-based nLockTime
+       // values that would be necessary to satisfy all relative lock-
+       // time constraints given our view of block chain history.
+       // The semantics of nLockTime are the last invalid height/time, so
+       // use -1 to have the effect of any height or time being valid.
+       int nMinHeight = -1;
+       int64_t nMinTime = -1;
+
+       // tx.nVersion is signed integer so requires cast to unsigned otherwise
+       // we would be doing a signed comparison and half the range of nVersion
+       // wouldn't support ZIP 68.
+       bool fEnforceZIP68 = static_cast(tx.nVersion) >= 2
+                         && flags & LOCKTIME_VERIFY_SEQUENCE;
+
+       // Do not enforce sequence numbers as a relative lock time
+       // unless we have been instructed to
+       if (!fEnforceZIP68) {
+           return std::make_pair(nMinHeight, nMinTime);
+       }
+
+       for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) {
+           const CTxIn& txin = tx.vin[txinIndex];
+
+           // Sequence numbers with the most significant bit set are not
+           // treated as relative lock-times, nor are they given any
+           // consensus-enforced meaning at this point.
+           if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) {
+               // The height of this input is not relevant for sequence locks
+               (*prevHeights)[txinIndex] = 0;
+               continue;
+           }
+
+           int nCoinHeight = (*prevHeights)[txinIndex];
+
+           if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) {
+               int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast();
+               // NOTE: Subtract 1 to maintain nLockTime semantics
+               // ZIP 68 relative lock times have the semantics of calculating
+               // the first block or time at which the transaction would be
+               // valid. When calculating the effective block time or height
+               // for the entire transaction, we switch to using the
+               // semantics of nLockTime which is the last invalid block
+               // time or height.  Thus we subtract 1 from the calculated
+               // time or height.
+
+               // Time-based relative lock-times are measured from the
+               // smallest allowed timestamp of the block containing the
+               // txout being spent, which is the Median Time Past of the
+               // block prior.
+               nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1);
+           } else {
+               nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1);
+           }
+       }
+
+       return std::make_pair(nMinHeight, nMinTime);
+   }
+
+   static bool EvaluateSequenceLocks(const CBlockIndex& block, std::pair lockPair)
+   {
+       assert(block.pprev);
+       int64_t nBlockTime = block.pprev->GetMedianTimePast();
+       if (lockPair.first >= block.nHeight || lockPair.second >= nBlockTime)
+           return false;
+
+       return true;
+   }
+
+   bool SequenceLocks(const CTransaction &tx, int flags, std::vector* prevHeights, const CBlockIndex& block)
+   {
+       return EvaluateSequenceLocks(block, CalculateSequenceLocks(tx, flags, prevHeights, block));
+   }
+
+   bool CheckSequenceLocks(const CTransaction &tx, int flags)
+   {
+       AssertLockHeld(cs_main);
+       AssertLockHeld(mempool.cs);
+
+       CBlockIndex* tip = chainActive.Tip();
+       CBlockIndex index;
+       index.pprev = tip;
+       // CheckSequenceLocks() uses chainActive.Height()+1 to evaluate
+       // height based locks because when SequenceLocks() is called within
+       // ConnectBlock(), the height of the block *being*
+       // evaluated is what is used.
+       // Thus if we want to know if a transaction can be part of the
+       // *next* block, we need to use one more than chainActive.Height()
+       index.nHeight = tip->nHeight + 1;
+
+       // pcoinsTip contains the UTXO set for chainActive.Tip()
+       CCoinsViewMemPool viewMemPool(pcoinsTip, mempool);
+       std::vector prevheights;
+       prevheights.resize(tx.vin.size());
+       for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) {
+           const CTxIn& txin = tx.vin[txinIndex];
+           CCoins coins;
+           if (!viewMemPool.GetCoins(txin.prevout.hash, coins)) {
+               return error("%s: Missing input", __func__);
+           }
+           if (coins.nHeight == MEMPOOL_HEIGHT) {
+               // Assume all mempool transaction confirm in the next block
+               prevheights[txinIndex] = tip->nHeight + 1;
+           } else {
+               prevheights[txinIndex] = coins.nHeight;
+           }
+       }
+
+       std::pair lockPair = CalculateSequenceLocks(tx, flags, &prevheights, index);
+       return EvaluateSequenceLocks(index, lockPair);
+   }
+
+
+Acknowledgments
+===============
+
+This ZIP is based on BIP 68, authored by Mark Friedenbach, BtcDrak, Nicolas Dorier, and
+kinoshitajona.
+
+Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior
+of this change, which became the basis of the BIP text.
+
+
+Deployment
+==========
+
+At the time of writing it has not been decided which network upgrade (if any) will implement this
+proposal.
+
+This ZIP is designed to be deployed simultaneously with [#zip-0112]_ and [#zip-0113]_.
+
+
+Compatibility
+=============
+
+The only use of sequence numbers by the zcashd reference client software is to disable checking
+the ``nLockTime`` constraints in a transaction. The semantics of that application are preserved
+by this ZIP.
+
+As can be seen from the specification section, a number of bits are undefined by this ZIP to
+allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning
+under this ZIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all
+when bit (1 << 31) is unset.
+
+Unlike BIP 68 in Bitcoin, all of the low 22 bits are used for the value. This reflects the fact
+that blocks are more frequent (75 seconds instead of 600 seconds), and so more bits are needed
+to obtain approximately the same range of time.
+
+The most efficient way to calculate sequence number from relative lock-time is with bit masks
+and shifts:
+
+.. hightlight::c++
+
+       // 0 <= nHeight <= 4194303 blocks (~10 years at post-Blossom block target spacing)
+       nSequence = nHeight;
+       nHeight = nSequence & 0x003fffff;
+
+       // 0 <= nTime <= 268435392 seconds (~8.5 years)
+       nSequence = (1 << 22) | (nTime >> 6);
+       nTime = (nSequence & 0x003fffff) << 6;
+
+
+References
+==========
+
+.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_
+.. [#mailing-list] `Bitcoin mailing list discussion `_
+.. [#zip-0112] `ZIP 112: CHECKSEQUENCEVERIFY `_
+.. [#zip-0113] `ZIP 113: Median Time Past as endpoint for lock-time calculations `_
+.. [#deployable-lightning] `Reaching The Ground With Lightning (draft 0.2) `_
diff --git a/zip-0076.rst b/zips/zip-0076.rst
similarity index 79%
rename from zip-0076.rst
rename to zips/zip-0076.rst
index afd60067f..35ba78a96 100644
--- a/zip-0076.rst
+++ b/zips/zip-0076.rst
@@ -3,7 +3,7 @@
   ZIP: 76
   Title: Transaction Signature Validation before Overwinter
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Consensus
   Discussions-To: 
diff --git a/zips/zip-0112.rst b/zips/zip-0112.rst
new file mode 100644
index 000000000..a6c130c0b
--- /dev/null
+++ b/zips/zip-0112.rst
@@ -0,0 +1,388 @@
+::
+
+  ZIP: 112
+  Title: CHECKSEQUENCEVERIFY
+  Author: Daira Hopwood 
+  Credits: BtcDrak 
+           Mark Friedenbach 
+           Eric Lombrozo 
+  Category: Consensus
+  Status: Draft
+  Created: 2019-06-06
+  License: MIT
+
+
+Terminology
+===========
+
+The key word "MUST" in this document is to be interpreted as described in RFC 2119. [#RFC2119]_
+
+
+Abstract
+========
+
+This ZIP describes a new opcode (``CHECKSEQUENCEVERIFY``) for the Zcash scripting system, that
+in combination with ZIP 68 allows execution pathways of a script to be restricted based on the
+age of the output being spent.
+
+
+Motivation
+==========
+
+ZIP 68 repurposes the transaction ``nSequence`` field meaning by giving sequence numbers new
+consensus-enforced semantics as a relative lock-time. However, there is no way to build Zcash
+scripts to make decisions based on this field.
+
+By making the ``nSequence`` field accessible to script, it becomes possible to construct code
+pathways that only become accessible some minimum time after proof-of-publication. This enables
+a wide variety of applications in phased protocols such as escrow, payment channels, or
+bidirectional pegs.
+
+
+Specification
+=============
+
+``CHECKSEQUENCEVERIFY`` redefines the existing ``NOP3`` opcode. When executed, if any of the
+following conditions are true, the script interpreter MUST terminate with an error:
+
+* the stack is empty; or
+* the top item on the stack is less than 0; or
+* the top item on the stack has the disable flag (1 << 31) unset; and any of the following hold:
+
+  * the transaction version is less than 2; or
+  * the transaction input sequence number disable flag (1 << 31) is set; or
+  * the relative lock-time type is not the same; or
+  * the top stack item is greater than the transaction input sequence (when masked according to
+    [#zip-0068]_;
+
+Otherwise, script execution MUST continue as if a ``NOP`` had been executed.
+
+ZIP 68 prevents a non-final transaction from being selected for inclusion in a block until the
+corresponding input has reached the specified age, as measured in block-height or block-time. By
+comparing the argument to ``CHECKSEQUENCEVERIFY`` against the ``nSequence`` field, we indirectly
+verify a desired minimum age of the the output being spent; until that relative age has been
+reached any script execution pathway including the ``CHECKSEQUENCEVERIFY`` will fail to validate,
+causing the transaction not to be selected for inclusion in a block.
+
+
+Use cases
+=========
+
+Contracts With Expiration Deadlines
+-----------------------------------
+
+Escrow with Timeout
+'''''''''''''''''''
+
+An escrow that times out automatically 30 days after being funded can be established in the
+following way. Alice, Bob and Escrow create a 2-of-3 address with the following redeem script::
+
+   IF
+       2    3 CHECKMULTISIG
+   ELSE
+       "30d" CHECKSEQUENCEVERIFY DROP
+        CHECKSIG
+   ENDIF
+
+At any time funds can be spent using signatures from any two of Alice, Bob or the Escrow.
+
+After 30 days Alice can sign alone.
+
+The clock does not start ticking until the payment to the escrow address confirms. 
+
+
+Retroactive Invalidation
+------------------------
+
+In many instances, we would like to create contracts that can be revoked in case of some future
+event. However, given the immutable nature of the block chain, it is practically impossible to
+retroactively invalidate a previous commitment that has already confirmed. The only mechanism we
+really have for retroactive invalidation is block chain reorganization which, for fundamental
+security reasons, is designed to be very hard and very expensive to do.
+
+Despite this limitation, we do have a way to provide something functionally similar to retroactive
+invalidation while preserving irreversibility of past commitments using ``CHECKSEQUENCEVERIFY``.
+By constructing scripts with multiple branches of execution where one or more of the branches are
+delayed we provide a time window in which someone can supply an invalidation condition that allows
+the output to be spent, effectively invalidating the would-be delayed branch and potentially
+discouraging another party from broadcasting the transaction in the first place. If the
+invalidation condition does not occur before the timeout, the delayed branch becomes spendable,
+honoring the original contract.
+
+Some more specific applications of this idea:
+
+Hash Time-Locked Contracts
+''''''''''''''''''''''''''
+
+Hash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain contract negotiation.
+An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be
+presented within an invalidation time window. By sharing the secret it is possible to guarantee
+to the counterparty that the transaction will never be broadcast since this would allow the
+counterparty to claim the output immediately while one would have to wait for the time window
+to pass. If the secret has not been shared, the counterparty will be unable to use the instant
+pathway and the delayed pathway must be used instead.
+
+Bidirectional Payment Channels
+''''''''''''''''''''''''''''''
+
+Scriptable relative locktime provides a predictable amount of time to respond in the event a
+counterparty broadcasts a revoked transaction: Absolute locktime necessitates closing the channel
+and reopening it when getting close to the timeout, whereas with relative locktime, the clock
+starts ticking the moment the transaction confirms in a block. It also provides a means to know
+exactly how long to wait (in number of blocks) before funds can be pulled out of the channel in
+the event of a noncooperative counterparty.
+
+Lightning Network
+'''''''''''''''''
+
+The lightning network protocol [#lightning]_ extends the bidirectional payment channel idea to
+allow for payments to be routed over multiple bidirectional payment channel hops.
+
+These channels are based on an anchor transaction that requires a 2-of-2 multisig from Alice and
+Bob, and a series of revocable commitment transactions that spend the anchor transaction. The
+commitment transaction splits the funds from the anchor between Alice and Bob and the latest
+commitment transaction may be published by either party at any time, finalising the channel.
+
+Ideally then, a revoked commitment transaction would never be able to be successfully spent; and the
+latest commitment transaction would be able to be spent very quickly.
+
+To allow a commitment transaction to be effectively revoked, Alice and Bob have slightly different
+versions of the latest commitment transaction. In Alice's version, any outputs in the commitment
+transaction that pay Alice also include a forced delay, and an alternative branch that allows Bob
+to spend the output if he knows that transaction's revocation code. In Bob's version, payments
+to Bob are similarly encumbered. When Alice and Bob negotiate new balances and new commitment
+transactions, they also reveal the old revocation code, thus committing to not relaying the old
+transaction.
+
+A simple output, paying to Alice might then look like::
+
+   HASH160  EQUAL
+   IF
+       
+   ELSE
+       "24h" CHECKSEQUENCEVERIFY DROP
+       
+   ENDIF
+   CHECKSIG
+
+This allows Alice to publish the latest commitment transaction at any time and spend the funds
+after 24 hours, but also ensures that if Alice relays a revoked transaction, that Bob has 24 hours
+to claim the funds.
+
+With ``CHECKLOCKTIMEVERIFY``, this would look like::
+
+   HASH160  EQUAL
+   IF
+       
+   ELSE
+       "2015/12/15" CHECKLOCKTIMEVERIFY DROP
+       
+   ENDIF
+   CHECKSIG
+
+This form of transaction would mean that if the anchor is unspent on 2015/12/16, Alice can use this
+commitment even if it has been revoked, simply by spending it immediately, giving no time for Bob
+to claim it.
+
+This means that the channel has a deadline that cannot be pushed back without hitting the blockchain;
+and also that funds may not be available until the deadline is hit. ``CHECKSEQUENCEVERIFY`` allows
+you to avoid making such a tradeoff.
+
+Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated, since in principle they may
+pay either Alice or Bob, depending on whether Alice discovers a secret R, or a timeout is reached,
+but the same principle applies -- the branch paying Alice in Alice's commitment transaction gets a
+delay, and the entire output can be claimed by the other party if the revocation secret is known.
+With ``CHECKSEQUENCEVERIFY``, a HTLC payable to Alice might look like the following in Alice's
+commitment transaction::
+
+   HASH160 DUP  EQUAL
+   IF
+       "24h" CHECKSEQUENCEVERIFY
+       2DROP
+       
+   ELSE
+        EQUAL
+       NOTIF
+           "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
+       ENDIF
+       
+   ENDIF
+   CHECKSIG
+
+and correspondingly in Bob's commitment transaction::
+
+   HASH160 DUP  EQUAL
+   SWAP  EQUAL ADD
+   IF
+       
+   ELSE
+       "2015/10/20 10:33" CHECKLOCKTIMEVERIFY
+       "24h" CHECKSEQUENCEVERIFY
+       2DROP
+       
+   ENDIF
+   CHECKSIG
+
+Note that both ``CHECKSEQUENCEVERIFY`` and ``CHECKLOCKTIMEVERIFY`` are used in the final branch
+above to ensure Bob cannot spend the output until after both the timeout is complete and Alice
+has had time to reveal the revocation secret.
+
+See also the 'Deployable Lightning' paper [#deployable-lightning]_.
+
+
+2-Way Pegged Sidechains
+-----------------------
+
+The 2-way pegged sidechain requires a new ``REORGPROOFVERIFY`` opcode, the semantics of which
+are outside the scope of this ZIP. ``CHECKSEQUENCEVERIFY`` is used to make sure that sufficient
+time has passed since the return peg was posted to publish a reorg proof::
+
+   IF
+       lockTxHeight  nlocktxOut [] reorgBounty Hash160(<...>)  REORGPROOFVERIFY
+   ELSE
+       withdrawLockTime CHECKSEQUENCEVERIFY DROP HASH160 p2shWithdrawDest EQUAL
+   ENDIF
+
+
+
+Reference Implementation
+========================
+
+.. highlight::c++
+
+   /* Below flags apply in the context of ZIP 68 */
+   /* If this flag set, CTxIn::nSequence is NOT interpreted as a
+    * relative lock-time. */
+   static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
+
+   /* If CTxIn::nSequence encodes a relative lock-time and this flag
+    * is set, the relative lock-time has units of 512 seconds,
+    * otherwise it specifies blocks with a granularity of 1. */
+   static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
+
+   /* If CTxIn::nSequence encodes a relative lock-time, this mask is
+    * applied to extract that lock-time from the sequence field. */
+   static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
+
+   case OP_NOP3:
+   {
+       if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
+           // not enabled; treat as a NOP3
+           if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
+               return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
+           }
+           break;
+       }
+
+       if (stack.size() < 1)
+          return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
+
+       // Note that elsewhere numeric opcodes are limited to
+       // operands in the range -2**31+1 to 2**31-1, however it is
+       // legal for opcodes to produce results exceeding that
+       // range. This limitation is implemented by CScriptNum's
+       // default 4-byte limit.
+       //
+       // Thus as a special case we tell CScriptNum to accept up
+       // to 5-byte bignums, which are good until 2**39-1, well
+       // beyond the 2**32-1 limit of the nSequence field itself.
+       const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);
+
+       // In the rare event that the argument may be < 0 due to
+       // some arithmetic being done first, you can always use
+       // 0 MAX CHECKSEQUENCEVERIFY.
+       if (nSequence < 0)
+           return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
+
+       // To provide for future soft-fork extensibility, if the
+       // operand has the disabled lock-time flag set,
+       // CHECKSEQUENCEVERIFY behaves as a NOP.
+       if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0)
+           break;
+
+       // Compare the specified sequence number with the input.
+       if (!checker.CheckSequence(nSequence))
+           return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
+
+       break;
+   }
+
+   bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
+   {
+       // Relative lock times are supported by comparing the passed
+       // in operand to the sequence number of the input.
+       const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;
+
+       // Fail if the transaction's version number is not set high
+       // enough to trigger ZIP 68 rules.
+       if (static_cast(txTo->nVersion) < 2)
+           return false;
+
+       // Sequence numbers with their most significant bit set are not
+       // consensus constrained. Testing that the transaction's sequence
+       // number do not have this bit set prevents using this property
+       // to get around a CHECKSEQUENCEVERIFY check.
+       if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG)
+           return false;
+
+       // Mask off any bits that do not have consensus-enforced meaning
+       // before doing the integer comparisons
+       const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK;
+       const int64_t txToSequenceMasked = txToSequence & nLockTimeMask;
+       const CScriptNum nSequenceMasked = nSequence & nLockTimeMask;
+
+       // There are two kinds of nSequence: lock-by-blockheight
+       // and lock-by-blocktime, distinguished by whether
+       // nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG.
+       //
+       // We want to compare apples to apples, so fail the script
+       // unless the type of nSequenceMasked being tested is the same as
+       // the nSequenceMasked in the transaction.
+       if (!(
+           (txToSequenceMasked <  CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked <  CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) ||
+           (txToSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG)
+       ))
+           return false;
+
+       // Now that we know we're comparing apples-to-apples, the
+       // comparison is a simple numeric one.
+       if (nSequenceMasked > txToSequenceMasked)
+           return false;
+
+       return true;
+   }
+
+
+Deployment
+==========
+
+At the time of writing it has not been decided which network upgrade (if any) will implement this
+proposal.
+
+This ZIP must be deployed simultaneously with ZIP 68 [#zip-0068]_.
+
+
+Acknowledgements
+================
+
+This ZIP is closely based on BIP 112, authored by BtcDrak.
+
+Mark Friedenbach invented the application of sequence numbers to achieve relative lock-time, and
+wrote the reference implementation of ``CHECKSEQUENCEVERIFY`` for Bitcoin.
+
+The Bitcoin reference implementation and BIP 112 was based heavily on work done by Peter Todd for
+the closely related BIP 65. Eric Lombrozo and Anthony Towns contributed example use cases.
+
+
+References
+==========
+
+.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_
+.. [#protocol] `Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling] `_
+.. [#bip-0065] `BIP 65: OP_CHECKLOCKTIMEVERIFY `_
+.. [#zip-0068] `ZIP 68: Relative lock-time through consensus-enforced sequence numbers `_
+.. [#deployable-lightning] `Deployable Lightning `_
+.. [#lightning] `Lightning Network paper `_
+.. [#HTLCs] `HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes `_
+.. [#scaling] `Scaling Bitcoin to Billions of Transactions Per Day `_
+.. [#micropayments] `Jeremy Spilman, Micropayment Channels `_
diff --git a/zips/zip-0113.rst b/zips/zip-0113.rst
new file mode 100644
index 000000000..d7d657a4c
--- /dev/null
+++ b/zips/zip-0113.rst
@@ -0,0 +1,122 @@
+::
+
+  ZIP: 113
+  Title: Median Time Past as endpoint for lock-time calculations
+  Author: Daira Hopwood 
+  Credits: Thomas Kerin 
+           Mark Friedenbach 
+           Gregory Maxwell
+  Category: Consensus
+  Status: Draft
+  Created: 2019-06-07
+  License: MIT
+
+
+Terminology
+===========
+
+The key words "MUST" and "MAY" in this document are to be interpreted as described in
+RFC 2119. [#RFC2119]_
+
+
+Abstract
+========
+
+This ZIP is a proposal to redefine the semantics used in determining a time-locked
+transaction's eligibility for inclusion in a block. The median of the last PoWMedianBlockSpan
+(11) blocks is used instead of the block's timestamp, ensuring that it increases
+monotonically with each block.
+
+
+Motivation
+==========
+
+At present, transactions are excluded from inclusion in a block if the present time or block
+height is less than or equal to that specified in the locktime. Since the consensus rules
+do not mandate strict ordering of block timestamps, this has the unfortunate outcome of
+creating a perverse incentive for miners to lie about the time of their blocks in order to
+collect more fees by including transactions that by wall clock determination have not yet
+matured.
+
+This ZIP proposes comparing the locktime against the median of the past PoWMedianBlockSpan
+blocks' timestamps, rather than the timestamp of the block including the transaction.
+Existing consensus rules guarantee this value to monotonically advance, thereby removing
+the capability for miners to claim more transaction fees by lying about the timestamps of
+their block.
+
+This proposal seeks to ensure reliable behaviour in locktime calculations as required by
+[#bip-0065]_ (CHECKLOCKTIMEVERIFY) and matching the behavior of [#zip-0112]_ (CHECKSEQUENCEVERIFY).
+This also matches the use of Median Time Past in difficulty adjustment as specified in
+section 7.6.3 of [#protocol]_.
+
+
+Specification
+=============
+
+Let PoWMedianBlockSpan be as defined in [#protocol]_ section 5.3, and let the median
+function be as defined in [#protocol]_ section 7.6.3.
+
+The Median Time Past of a block is specified as the median of the timestamps of the
+prior PoWMedianBlockSpan blocks, as calculated by MedianTime(height) in [#protocol]_
+section 7.6.3.
+
+The values for transaction locktime remain unchanged. The difference is only in the
+calculation determining whether a transaction can be included. After activation of
+this ZIP, lock-time constraints of a transaction MUST be checked according to the
+Median Time Past of the transaction's block.
+
+[FIXME make this a proper specification, independent of the zcashd implementation.]
+
+Lock-time constraints are checked by the consensus method ``IsFinalTx()``. This method
+takes the block time as one parameter. This ZIP proposes that after activation calls to
+``IsFinalTx()`` within consensus code use the return value of ``GetMedianTimePast(pindexPrev)``
+instead.
+
+The new rule applies to all transactions, including the coinbase transaction.
+
+
+Reference Implementation
+========================
+
+This will be based on `Bitcoin PR 6566 `_.
+
+
+Acknowledgements
+================
+
+This ZIP is based on BIP 113, authored by Thomas Kerin and Mark Friedenbach.
+
+Mark Friedenbach designed and authored the reference implementation for Bitcoin.
+
+Gregory Maxwell came up with the original idea, in #bitcoin-wizards on
+`2013-07-16 `_ and
+`2013-07-17 `_.
+
+
+Deployment
+==========
+
+At the time of writing it has not been decided which network upgrade (if any) will implement this
+proposal.
+
+This ZIP is designed to be deployed simultaneously with [#zip-0068]_ and [#zip-0112]_.
+
+
+Compatibility
+=============
+
+At the post-Blossom block target spacing of 75 seconds, transactions generated using time-based
+lock-time will take approximately 7.5 minutes longer to confirm than would be expected under the
+old rules. This is not known to introduce any compatibility concerns with existing protocols.
+This delay is less than in Bitcoin due to the faster block target spacing in Zcash.
+
+
+References
+==========
+
+.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_
+.. [#protocol] `Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom] `_
+.. [#bip-0065] `BIP 65: OP_CHECKLOCKTIMEVERIFY `_
+.. [#zip-0068] `ZIP 68: Consensus-enforced transaction replacement signaled via sequence numbers `_
+.. [#zip-0112] `ZIP 112: CHECKSEQUENCEVERIFY `_
+
diff --git a/zip-0143.rst b/zips/zip-0143.rst
similarity index 99%
rename from zip-0143.rst
rename to zips/zip-0143.rst
index f9b44f14d..af07101d5 100644
--- a/zip-0143.rst
+++ b/zips/zip-0143.rst
@@ -3,7 +3,7 @@
   ZIP: 143
   Title: Transaction Signature Validation for Overwinter
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Credits: Johnson Lau
            Pieter Wuille
            Bitcoin-ABC
diff --git a/zip-0155.rst b/zips/zip-0155.rst
similarity index 99%
rename from zip-0155.rst
rename to zips/zip-0155.rst
index 7850c3fad..214091629 100644
--- a/zip-0155.rst
+++ b/zips/zip-0155.rst
@@ -2,7 +2,7 @@
 
   ZIP: 155
   Title: addrv2 message
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Wladimir J. van der Laan
            Zancas Wilcox
   Status: Proposed
diff --git a/zip-0173.rst b/zips/zip-0173.rst
similarity index 98%
rename from zip-0173.rst
rename to zips/zip-0173.rst
index 4df7105b6..70ca789f5 100644
--- a/zip-0173.rst
+++ b/zips/zip-0173.rst
@@ -2,7 +2,7 @@
 
   ZIP: 173
   Title: Bech32 Format
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Pieter Wuille 
            Greg Maxwell 
            Rusty Russell
@@ -300,6 +300,10 @@ Reference implementations
 
   * `In C++ `_
 
+* Encoders and decoders written specifically for Zcash:
+
+  * `For C# `_ (Bech32 and Bech32m)
+
 * Encoders and decoders written for Bitcoin:
 
   * `For C `_
diff --git a/zip-0200.rst b/zips/zip-0200.rst
similarity index 100%
rename from zip-0200.rst
rename to zips/zip-0200.rst
diff --git a/zip-0201.rst b/zips/zip-0201.rst
similarity index 99%
rename from zip-0201.rst
rename to zips/zip-0201.rst
index 9d2de1e91..2aae78503 100644
--- a/zip-0201.rst
+++ b/zips/zip-0201.rst
@@ -2,7 +2,7 @@
 
   ZIP: 201
   Title: Network Peer Management for Overwinter
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Original-Authors: Simon Liu
   Status: Final
   Category: Network
diff --git a/zip-0202.rst b/zips/zip-0202.rst
similarity index 99%
rename from zip-0202.rst
rename to zips/zip-0202.rst
index b14d93940..adc7728df 100644
--- a/zip-0202.rst
+++ b/zips/zip-0202.rst
@@ -2,7 +2,7 @@
 
   ZIP: 202
   Title: Version 3 Transaction Format for Overwinter
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Original-Authors: Simon Liu
   Status: Final
   Category: Consensus
diff --git a/zip-0203.rst b/zips/zip-0203.rst
similarity index 98%
rename from zip-0203.rst
rename to zips/zip-0203.rst
index b1e1fa3bb..3d2dbd036 100644
--- a/zip-0203.rst
+++ b/zips/zip-0203.rst
@@ -2,7 +2,7 @@
 
   ZIP: 203
   Title: Transaction Expiry
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Original-Authors: Jay Graber
   Status: Final
   Category: Consensus
diff --git a/zip-0204.rst b/zips/zip-0204.rst
similarity index 72%
rename from zip-0204.rst
rename to zips/zip-0204.rst
index a018f512f..77b5cdf52 100644
--- a/zip-0204.rst
+++ b/zips/zip-0204.rst
@@ -2,7 +2,7 @@
 
   ZIP: 204
   Title: Zcash P2P Network Protocol
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Network
   Discussions-To: 
diff --git a/zip-0205.rst b/zips/zip-0205.rst
similarity index 99%
rename from zip-0205.rst
rename to zips/zip-0205.rst
index 7d7e2833e..963959a8a 100644
--- a/zip-0205.rst
+++ b/zips/zip-0205.rst
@@ -2,7 +2,7 @@
 
   ZIP: 205
   Title: Deployment of the Sapling Network Upgrade
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Simon Liu
   Status: Final
   Category: Consensus / Network
diff --git a/zip-0206.rst b/zips/zip-0206.rst
similarity index 98%
rename from zip-0206.rst
rename to zips/zip-0206.rst
index aacf39521..16d61138b 100644
--- a/zip-0206.rst
+++ b/zips/zip-0206.rst
@@ -2,7 +2,7 @@
 
   ZIP: 206
   Title: Deployment of the Blossom Network Upgrade
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Simon Liu
   Status: Final
   Category: Consensus / Network
diff --git a/zip-0207.rst b/zips/zip-0207.rst
similarity index 99%
rename from zip-0207.rst
rename to zips/zip-0207.rst
index 0667aad15..8d8ed6b03 100644
--- a/zip-0207.rst
+++ b/zips/zip-0207.rst
@@ -3,7 +3,7 @@
   ZIP: 207
   Title: Funding Streams
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Final
   Category: Consensus
   Created: 2019-01-04
diff --git a/zip-0208.rst b/zips/zip-0208.rst
similarity index 99%
rename from zip-0208.rst
rename to zips/zip-0208.rst
index d85ffe779..cf9840f27 100644
--- a/zip-0208.rst
+++ b/zips/zip-0208.rst
@@ -2,8 +2,8 @@
 
   ZIP: 208
   Title: Shorter Block Target Spacing
-  Owners: Daira Emma Hopwood 
-  Original-Authors: Daira Emma Hopwood
+  Owners: Daira-Emma Hopwood 
+  Original-Authors: Daira-Emma Hopwood
                     Simon Liu
   Status: Final
   Category: Consensus
diff --git a/zip-0209.rst b/zips/zip-0209.rst
similarity index 98%
rename from zip-0209.rst
rename to zips/zip-0209.rst
index 5f11cb9cb..ffb35f6fd 100644
--- a/zip-0209.rst
+++ b/zips/zip-0209.rst
@@ -3,7 +3,7 @@
   ZIP: 209
   Title: Prohibit Negative Shielded Chain Value Pool Balances
   Owners: Sean Bowe 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Final
   Category: Consensus
   Created: 2019-02-25
diff --git a/zip-0210.rst b/zips/zip-0210.rst
similarity index 100%
rename from zip-0210.rst
rename to zips/zip-0210.rst
diff --git a/zip-0211.rst b/zips/zip-0211.rst
similarity index 99%
rename from zip-0211.rst
rename to zips/zip-0211.rst
index 3c9c07db9..f857af188 100644
--- a/zip-0211.rst
+++ b/zips/zip-0211.rst
@@ -2,7 +2,7 @@
 
   ZIP: 211
   Title: Disabling Addition of New Value to the Sprout Chain Value Pool
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Sean Bowe
   Status: Final
   Category: Consensus
diff --git a/zip-0212.rst b/zips/zip-0212.rst
similarity index 100%
rename from zip-0212.rst
rename to zips/zip-0212.rst
diff --git a/zip-0213.rst b/zips/zip-0213.rst
similarity index 100%
rename from zip-0213.rst
rename to zips/zip-0213.rst
diff --git a/zip-0214.rst b/zips/zip-0214.rst
similarity index 99%
rename from zip-0214.rst
rename to zips/zip-0214.rst
index 5d8871d3a..7efbda2d4 100644
--- a/zip-0214.rst
+++ b/zips/zip-0214.rst
@@ -2,7 +2,7 @@
 
   ZIP: 214
   Title: Consensus rules for a Zcash Development Fund
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Final
   Category: Consensus
   Created: 2020-02-28
diff --git a/zip-0215.rst b/zips/zip-0215.rst
similarity index 100%
rename from zip-0215.rst
rename to zips/zip-0215.rst
diff --git a/zip-0216.rst b/zips/zip-0216.rst
similarity index 99%
rename from zip-0216.rst
rename to zips/zip-0216.rst
index 6fc353436..c2aa86548 100644
--- a/zip-0216.rst
+++ b/zips/zip-0216.rst
@@ -3,7 +3,7 @@
   ZIP: 216
   Title: Require Canonical Jubjub Point Encodings
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Final
   Category: Consensus
   Created: 2021-02-11
diff --git a/zip-0217.rst b/zips/zip-0217.rst
similarity index 71%
rename from zip-0217.rst
rename to zips/zip-0217.rst
index 672e4be13..4562d86fc 100644
--- a/zip-0217.rst
+++ b/zips/zip-0217.rst
@@ -2,7 +2,7 @@
 
   ZIP: 217
   Title: Aggregate Signatures
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Consensus
   Discussions-To: 
diff --git a/zip-0219.rst b/zips/zip-0219.rst
similarity index 76%
rename from zip-0219.rst
rename to zips/zip-0219.rst
index 31d135c3f..313032e95 100644
--- a/zip-0219.rst
+++ b/zips/zip-0219.rst
@@ -2,7 +2,7 @@
 
   ZIP: 219
   Title: Disabling Addition of New Value to the Sapling Chain Value Pool
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Consensus
   Discussions-To: 
diff --git a/zip-0220.rst b/zips/zip-0220.rst
similarity index 81%
rename from zip-0220.rst
rename to zips/zip-0220.rst
index 563375a87..5b9b8ee00 100644
--- a/zip-0220.rst
+++ b/zips/zip-0220.rst
@@ -3,7 +3,7 @@
   ZIP: 220
   Title: Zcash Shielded Assets
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Withdrawn
   Category: Consensus
   Discussions-To: 
diff --git a/zip-0221.rst b/zips/zip-0221.rst
similarity index 100%
rename from zip-0221.rst
rename to zips/zip-0221.rst
diff --git a/zip-0222.rst b/zips/zip-0222.rst
similarity index 99%
rename from zip-0222.rst
rename to zips/zip-0222.rst
index 156e65ee4..440ec86e0 100644
--- a/zip-0222.rst
+++ b/zips/zip-0222.rst
@@ -5,7 +5,7 @@
   Owners: Jack Grigg 
           Kris Nuttycombe 
   Credits: Zaki Manian
-           Daira Emma Hopwood
+           Daira-Emma Hopwood
            Sean Bowe
   Status: Draft
   Category: Consensus
@@ -311,7 +311,7 @@ Acknowledgements
 ================
 
 The handler semantics of ``tze_verify`` 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
+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.
 
 We would also like to thank the numerous other individuals who participated in discussions
diff --git a/zip-0224.rst b/zips/zip-0224.rst
similarity index 99%
rename from zip-0224.rst
rename to zips/zip-0224.rst
index 789750bcc..b3b75fa32 100644
--- a/zip-0224.rst
+++ b/zips/zip-0224.rst
@@ -2,11 +2,11 @@
 
   ZIP: 224
   Title: Orchard Shielded Protocol
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
-          Ying Tong Lai 
+  Original-Authors: Ying Tong Lai
   Status: Final
   Category: Consensus
   Created: 2021-02-27
diff --git a/zip-0225.rst b/zips/zip-0225.rst
similarity index 99%
rename from zip-0225.rst
rename to zips/zip-0225.rst
index 08b7c2ea5..a4bf7ce9e 100644
--- a/zip-0225.rst
+++ b/zips/zip-0225.rst
@@ -2,11 +2,11 @@
 
   ZIP: 225
   Title: Version 5 Transaction Format
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
-          Ying Tong Lai 
+  Original-Authors: Ying Tong Lai
   Status: Final
   Category: Consensus
   Created: 2021-02-28
diff --git a/zip-0226.rst b/zips/zip-0226.rst
similarity index 99%
rename from zip-0226.rst
rename to zips/zip-0226.rst
index 0e5e833a4..a498db3cb 100644
--- a/zip-0226.rst
+++ b/zips/zip-0226.rst
@@ -4,7 +4,7 @@
   Title: Transfer and Burn of Zcash Shielded Assets
   Owners: Pablo Kogan 
           Vivek Arte 
-          Daira-Emma Hopwood 
+          Daira-Emma Hopwood 
           Jack Grigg 
   Credits: Daniel Benarroch
            Aurelien Nicolas
diff --git a/zip-0227-asset-identifier-relation.svg b/zips/zip-0227-asset-identifier-relation.svg
similarity index 100%
rename from zip-0227-asset-identifier-relation.svg
rename to zips/zip-0227-asset-identifier-relation.svg
diff --git a/zip-0227-key-components-zsa.svg b/zips/zip-0227-key-components-zsa.svg
similarity index 100%
rename from zip-0227-key-components-zsa.svg
rename to zips/zip-0227-key-components-zsa.svg
diff --git a/zip-0227.rst b/zips/zip-0227.rst
similarity index 99%
rename from zip-0227.rst
rename to zips/zip-0227.rst
index 95708a8f3..7aed636a5 100644
--- a/zip-0227.rst
+++ b/zips/zip-0227.rst
@@ -4,7 +4,7 @@
   Title: Issuance of Zcash Shielded Assets
   Owners: Pablo Kogan 
           Vivek Arte 
-          Daira-Emma Hopwood 
+          Daira-Emma Hopwood 
           Jack Grigg 
   Credits: Daniel Benarroch
            Aurelien Nicolas
@@ -89,7 +89,7 @@ The Orchard-ZSA Protocol adds the following keys to the key components [#protoco
 
 The relations between these keys are shown in the following diagram:
 
-.. figure:: zip-0227-key-components-zsa.png
+.. figure:: ../rendered/assets/images/zip-0227-key-components-zsa.png
     :width: 450px
     :align: center
     :figclass: align-center
@@ -201,7 +201,7 @@ where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concrete
 
 The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:
 
-.. figure:: zip-0227-asset-identifier-relation.png
+.. figure:: ../rendered/assets/images/zip-0227-asset-identifier-relation.png
     :width: 600px
     :align: center
     :figclass: align-center
diff --git a/zip-0228.rst b/zips/zip-0228.rst
similarity index 85%
rename from zip-0228.rst
rename to zips/zip-0228.rst
index 024c4f779..c1c19c70e 100644
--- a/zip-0228.rst
+++ b/zips/zip-0228.rst
@@ -4,7 +4,7 @@
   Title: Asset Swaps for Zcash Shielded Assets
   Owners: Pablo Kogan 
           Vivek Arte 
-          Daira-Emma Hopwood 
+          Daira-Emma Hopwood 
           Jack Grigg 
   Credits: Daniel Benarroch
            Aurelien Nicolas
diff --git a/zip-0230.rst b/zips/zip-0230.rst
similarity index 99%
rename from zip-0230.rst
rename to zips/zip-0230.rst
index 3629a0357..69dd034d2 100644
--- a/zip-0230.rst
+++ b/zips/zip-0230.rst
@@ -2,7 +2,7 @@
 
   ZIP: 230
   Title: Version 6 Transaction Format
-  Owners: Daira-Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
diff --git a/zip-0231.rst b/zips/zip-0231.rst
similarity index 84%
rename from zip-0231.rst
rename to zips/zip-0231.rst
index 9c6275ec4..1bbed3699 100644
--- a/zip-0231.rst
+++ b/zips/zip-0231.rst
@@ -4,7 +4,7 @@
   Title: Decouple Memos from Transaction Outputs
   Owners: Jack Grigg 
           Kris Nuttycombe 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Credits: Sean Bowe
            Nate Wilcox
   Status: Reserved
diff --git a/zips/zip-0236.rst b/zips/zip-0236.rst
new file mode 100644
index 000000000..9b672b758
--- /dev/null
+++ b/zips/zip-0236.rst
@@ -0,0 +1,174 @@
+::
+
+  ZIP: 236
+  Title: Blocks should balance exactly
+  Owners: Daira-Emma Hopwood 
+  Credits: Jack Grigg
+           Kris Nuttycombe
+  Status: Draft
+  Category: Consensus
+  Created: 2024-07-02
+  License: MIT
+  Discussions-To: 
+
+
+Terminology
+===========
+
+The key word "MUST" in this document is to be interpreted as described in BCP 14
+[#BCP14]_ when, and only when, it appears in all capitals.
+
+The term "network upgrade" in this document is to be interpreted as described in
+ZIP 200. [#zip-0200]_
+
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section
+3.12 of the Zcash Protocol Specification. [#protocol-networks]_
+
+The character § is used when referring to sections of the Zcash Protocol Specification
+[#protocol]_.
+
+
+Abstract
+========
+
+In the current Zcash protocol, the miner of a coinbase transaction is permitted to
+claim up to and including the total amount of miner subsidy plus fees from other
+transactions in the block, but is not required to claim the full amount.
+
+This proposal would require the full amount of miner subsidy and fees to be
+collected in coinbase transactions.
+
+
+Motivation
+==========
+
+The current semantics of coinbase transactions creates a potential for miners to
+miscalculate the total amount of miner subsidy plus fees in a block. If they claim
+a higher amount than the actual miner subsidy plus total fees, the block will be
+invalid, but if they claim a lower amount, the excess is effectively burnt. As a
+consequence, the effective ZEC issuance can fall short of the amount calculated
+from the intended issuance curve.
+
+This unnecessarily complicates the question of how much ZEC has been issued: if it
+is defined as not including the amounts that were left unclaimed by miners, then it
+is difficult to calculate, and cannot be predicted exactly in advance for any given
+block height. Alternatively if it is defined to include those amounts, then that
+introduces potentially confusing discrepancies between different definitions of
+issuance or total supply.
+
+
+Requirements
+============
+
+The consensus rule change specified in this ZIP must:
+
+* allow issuance to be predicted exactly in advance, starting from the point at
+  which it activates;
+* preclude errors by miners in computing the total miner subsidy plus fees for
+  transactions in the mined block;
+* be deployable in the NU6 network upgrade, which is not expected to define a new
+  transaction version.
+
+
+Non-requirements
+================
+
+Since this ZIP is intended to activate in a network upgrade that is not expected
+to support a new transaction version, it cannot resolve the issue that the amounts
+of fees are implicit in non-coinbase transactions. That issue results in various
+potential security difficulties and the potential for users' wallets to inadvertently
+overpay the fee, but solving that would require an explicit "fee" field.
+
+(It would technically be possible to encode the fee as a transparent output, but
+that would be a more disruptive change than is desirable, since other consensus
+rules would have to change in order to prevent this output from being spent, and
+since existing consumers of the transaction format could misinterpret such outputs.)
+
+This consensus change is not intended to prevent other methods of provably removing
+ZEC from the circulating supply, such as sending it to an address for which it
+would be demonstrably infeasible to find the spending key.
+
+
+Specification
+=============
+
+From the activation block of this ZIP onward, coinbase transactions MUST claim all
+of the available miner subsidy plus fees in their block. More specifically, the
+following paragraph and consensus rule in § 3.4 "Transactions and Treestates" of
+the Zcash Protocol Specification [#protocol-transactions]_:
+
+  Transparent inputs to a transaction insert value into a transparent transaction
+  value pool associated with the transaction, and transparent outputs remove value
+  from this pool. As in Bitcoin, the remaining value in the transparent transaction
+  value pool of a non-coinbase transaction is available to miners as a fee. The
+  remaining value in the transparent transaction value pool of a coinbase transaction
+  is destroyed.
+
+  **Consensus rule:** The remaining value in the transparent transaction value pool
+  MUST be nonnegative.
+
+is modified to become:
+
+  Transparent inputs to a transaction insert value into a transparent transaction
+  value pool associated with the transaction, and transparent outputs remove value
+  from this pool. The effect of Sapling Spends and Outputs, and of Orchard Actions
+  on the transaction value pool are specified in § 4.13 and § 4.14 respectively.
+
+  As in Bitcoin, the remaining value in the transparent transaction value pool of
+  a non-coinbase transaction is available to miners as a fee. That is, the sum of
+  those values for non-coinbase transactions in each block is treated as an implicit
+  input to the transaction value balance of the block's coinbase transaction (in
+  addition to the implicit input created by issuance).
+
+  The remaining value in the transparent transaction value pool of coinbase transactions
+  in blocks prior to NU-X is destroyed. From activation of NU-X, this remaining value
+  is required to be zero; that is, all of the available balance MUST be consumed by
+  outputs of the coinbase transaction.
+
+  **Consensus rules:**
+
+  * The remaining value in the transparent transaction value pool of a non-coinbase
+    transaction MUST be nonnegative.
+  * [Pre-NU-X] The remaining value in the transparent transaction value pool of a
+    coinbase transaction MUST be nonnegative.
+  * [NU-X onward] The remaining value in the transparent transaction value pool of
+    a coinbase transaction MUST be zero.
+
+where "NU-X" is to be replaced by the designation of the network upgrade in which
+this ZIP will be activated.
+
+Note that the differences in the first two paragraphs of the above replacement text
+are clarifications of the protocol, rather than consensus changes. Those could be
+made independently of this ZIP.
+
+This change applies identically to Mainnet and Testnet.
+
+
+Deployment
+==========
+
+Subject to community agreement, this ZIP is proposed to be deployed with NU6. [#zip-0253]_
+
+
+Reference implementation
+========================
+
+TODO
+
+
+Acknowledgements
+================
+
+The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading
+to the submission of this ZIP.
+
+
+References
+==========
+
+.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_
+.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later `_
+.. [#protocol-transactions] `Zcash Protocol Specification, Version 2023.4.0. Section 3.4: Transactions and Treestates `_
+.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet `_
+.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_
+.. [#zip-0253] `ZIP 253: Deployment of the NU6 Network Upgrade `_
diff --git a/zip-0239.rst b/zips/zip-0239.rst
similarity index 99%
rename from zip-0239.rst
rename to zips/zip-0239.rst
index 65ff5cd88..23f18ffa4 100644
--- a/zip-0239.rst
+++ b/zips/zip-0239.rst
@@ -2,7 +2,7 @@
 
   ZIP: 239
   Title: Relay of Version 5 Transactions
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
   Status: Final
   Category: Network
diff --git a/zip-0243.rst b/zips/zip-0243.rst
similarity index 99%
rename from zip-0243.rst
rename to zips/zip-0243.rst
index e11908500..47c574b07 100644
--- a/zip-0243.rst
+++ b/zips/zip-0243.rst
@@ -3,7 +3,7 @@
   ZIP: 243
   Title: Transaction Signature Validation for Sapling
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Credits: Simon Liu
   Status: Final
   Category: Consensus
diff --git a/zip-0244.rst b/zips/zip-0244.rst
similarity index 99%
rename from zip-0244.rst
rename to zips/zip-0244.rst
index 496ae1330..7dce6b2e5 100644
--- a/zip-0244.rst
+++ b/zips/zip-0244.rst
@@ -3,7 +3,7 @@
   ZIP: 244
   Title: Transaction Identifier Non-Malleability
   Owners: Kris Nuttycombe 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
           Jack Grigg 
   Status: Final
   Category: Consensus
diff --git a/zip-0245.rst b/zips/zip-0245.rst
similarity index 99%
rename from zip-0245.rst
rename to zips/zip-0245.rst
index e8350a52b..fd55a7c90 100644
--- a/zip-0245.rst
+++ b/zips/zip-0245.rst
@@ -3,6 +3,7 @@
   ZIP: 245
   Title: Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions
   Owners: Kris Nuttycombe 
+          Daira-Emma Hopwood 
   Status: Draft
   Category: Consensus
   Created: 2021-01-13
diff --git a/zip-0250.rst b/zips/zip-0250.rst
similarity index 98%
rename from zip-0250.rst
rename to zips/zip-0250.rst
index 755c56c59..0c0757a8b 100644
--- a/zip-0250.rst
+++ b/zips/zip-0250.rst
@@ -2,7 +2,7 @@
 
   ZIP: 250
   Title: Deployment of the Heartwood Network Upgrade
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Final
   Category: Consensus / Network
   Created: 2020-02-28
diff --git a/zip-0251.rst b/zips/zip-0251.rst
similarity index 99%
rename from zip-0251.rst
rename to zips/zip-0251.rst
index f9e30de82..c906e0b69 100644
--- a/zip-0251.rst
+++ b/zips/zip-0251.rst
@@ -2,7 +2,7 @@
 
   ZIP: 251
   Title: Deployment of the Canopy Network Upgrade
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Final
   Category: Consensus / Network
   Created: 2020-02-28
diff --git a/zip-0252.rst b/zips/zip-0252.rst
similarity index 99%
rename from zip-0252.rst
rename to zips/zip-0252.rst
index a7a291bc0..93804a61b 100644
--- a/zip-0252.rst
+++ b/zips/zip-0252.rst
@@ -3,7 +3,7 @@
   ZIP: 252
   Title: Deployment of the NU5 Network Upgrade
   Owners: teor 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Final
   Category: Consensus / Network
   Created: 2021-02-23
diff --git a/zips/zip-0253.md b/zips/zip-0253.md
new file mode 100644
index 000000000..b4334c76e
--- /dev/null
+++ b/zips/zip-0253.md
@@ -0,0 +1,90 @@
+
+    ZIP: 253
+    Title: Deployment of the NU6 Network Upgrade
+    Owners: Arya 
+    Status: Draft
+    Category: Consensus / Network
+    Created: 2024-07-17
+    License: MIT
+    Discussions-To: 
+
+# Terminology
+
+The key word "MUST" in this document are to be interpreted as described in
+BCP 14 [^BCP14] when, and only when, they appear in all capitals.
+
+The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [^zip-0200].
+
+The terms "Testnet" and "Mainnet" are to be interpreted as described in
+section 3.12 of the Zcash Protocol Specification  [^protocol-networks].
+
+# Abstract
+
+This proposal defines the deployment of the NU6 network upgrade.
+
+# Specification
+
+## NU6 deployment
+
+
+
+The primary sources of information about NU6 consensus protocol changes are:
+
+* The Zcash Protocol Specification [^protocol].
+* Network Upgrade Mechanism [^zip-0200].
+* Lockbox Funding Streams [^zip-2001].
+* Block Reward Allocation for Non-Direct Development Funding [^draft-nuttycom-funding-allocation].
+* Blocks should balance exactly [^zip-0236].
+
+
+The network handshake and peer management mechanisms defined in ZIP 201 [^zip-0201] also apply to this upgrade.
+
+The following ZIPs have been updated in varying degrees to take into account NU6:
+
+* ZIP 207: Funding Streams [^zip-0207].
+* ZIP 214: Consensus rules for a Zcash Development Fund [^zip-0214].
+
+The following network upgrade constants [^zip-0200] are defined for the NU6 upgrade:
+
+CONSENSUS_BRANCH_ID
+: `0xC8E71055`
+
+ACTIVATION_HEIGHT (NU6)
+: Testnet: TBD
+: Mainnet: TBD
+
+MIN_NETWORK_PROTOCOL_VERSION (NU6)
+: Testnet: `170110`
+: Mainnet: `170120`
+
+For each network (Testnet and Mainnet), nodes compatible with NU6 activation on that network MUST advertise a network protocol version that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU6) for that activation.
+
+# Backward compatibility
+
+Prior to the network upgrade activating on each network, NU6 and pre-NU6 nodes are compatible and can connect to each other. However, NU6 nodes will have a preference for connecting to other NU6 nodes, so pre-NU6 nodes will gradually be disconnected in the run up to activation.
+
+Once the network upgrades, even though pre-NU6 nodes can still accept the numerically larger protocol version used by NU6 as being valid, NU6 nodes will always disconnect peers using lower protocol versions.
+
+NU6 does not define a new transaction version or impose a new minimum transaction version. NU6 transactions are therefore in the same v4 or v5 formats as NU5 transactions. This does not imply that transactions are valid across the NU6 activation, since signatures MUST use the appropriate consensus branch ID.
+
+# References
+
+[^BCP14]: [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14)
+
+[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst)
+
+[^protocol-networks]: [Zcash Protocol Specification, Version v2023.4.0 or later. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks)
+
+[^protocol]: [Zcash Protocol Specification, Version v2023.4.0 or later](protocol/protocol.pdf)
+
+[^zip-2001]: [ZIP 2001 Lockbox Funding Streams](draft-nuttycom-lockbox-streams.rst)
+
+[^zip-0236]: [ZIP 236: Blocks should balance exactly](draft-hopwood-coinbase-balance.rst)
+
+[^draft-nuttycom-funding-allocation]: [ZIP ???: Block Reward Allocation for Non-Direct Development Funding](draft-nuttycom-funding-allocation.rst)
+
+[^zip-0201]: [ZIP 201: Network Peer Management for Overwinter](zip-0201.rst)
+
+[^zip-0207]: [ZIP 207: Funding Streams](zip-0207.rst)
+
+[^zip-0214]: [ZIP 214: Consensus rules for a Zcash Development Fund](zip-0214.rst)
diff --git a/zip-0300.rst b/zips/zip-0300.rst
similarity index 99%
rename from zip-0300.rst
rename to zips/zip-0300.rst
index a3cacdfe1..17eb9b030 100644
--- a/zip-0300.rst
+++ b/zips/zip-0300.rst
@@ -2,7 +2,7 @@
 
   ZIP: 300
   Title: Cross-chain Atomic Transactions
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Original-Authors: Jay Graber
   Status: Proposed
   Category: Informational
diff --git a/zip-0301.rst b/zips/zip-0301.rst
similarity index 99%
rename from zip-0301.rst
rename to zips/zip-0301.rst
index 5c05bc037..c76161db3 100644
--- a/zip-0301.rst
+++ b/zips/zip-0301.rst
@@ -4,7 +4,7 @@
   Title: Zcash Stratum Protocol
   Owners: Jack Grigg 
   Credits: 5a1t
-           Daira Emma Hopwood
+           Daira-Emma Hopwood
            Marek Palatinus (slush) and colleagues
            Jelle Bourdeaud'hui (razakal)
            ocminer
@@ -477,7 +477,7 @@ Thanks to:
 
 - 5a1t for the initial brainstorming session.
 
-- Daira Emma Hopwood for their input on API selection and design.
+- Daira-Emma Hopwood for hir input on API selection and design.
 
 - Marek Palatinus (slush) and his colleagues for their refinements, suggestions, and
   robust discussion.
diff --git a/zip-0302.rst b/zips/zip-0302.rst
similarity index 76%
rename from zip-0302.rst
rename to zips/zip-0302.rst
index 0ce7eed4c..a87ffac51 100644
--- a/zip-0302.rst
+++ b/zips/zip-0302.rst
@@ -25,7 +25,7 @@ memo values carrying different types of data. Users and third-party services ben
 standardized formatting rules that define the type and length of the data contained within.
 
 Specification
-===============
+=============
 
 Section 5.5 of the Zcash protocol specification [#protocol]_ defines three cases
 for the encoding of a memo field:
@@ -40,28 +40,32 @@ This ZIP refines the specification of the third case.
 The following specification constrains a party, called the "reader", that interprets the
 contents of a memo. It does not define consensus requirements.
 
-+ If the first byte (byte 0) has a value of 0xF4 or smaller, then the reader MUST:
++ If the first byte (byte 0) has a value of ``0xF4`` or smaller, then the reader MUST:
 
      + strip any trailing zero bytes
      + decode it as a UTF-8 string (if decoding fails then report an error).
 
-+ If the first byte has a value of 0xF6, and the remaining 511 bytes are 0x00, then the user
-  supplied no memo, and the encrypted memo field is to be treated as empty.
++ If the first byte has a value of ``0xF6``, and the remaining 511 bytes are ``0x00``,
+  then the user supplied no memo, and the encrypted memo field is to be treated as empty.
 
 + If the memo matches any of these patterns, then this memo is from the future, because
   these ranges are reserved for future updates to this specification:
 
-     + The first byte has a value of 0xF5.
-     + The first byte has a value of 0xF6, and the remaining 511 bytes are not all 0x00.
-     + The first byte has a value between 0xF7 and 0xFE inclusive.
+     + The first byte has a value of ``0xF6``, and the remaining 511 bytes are not all
+       ``0x00``.
+     + The first byte has a value between ``0xF7`` and ``0xFE`` inclusive.
 
-+ If the first byte has a value of 0xFF then the reader should not make any other
++ If the first byte has a value of ``0xFF`` then the reader should not make any other
   assumption about the memo. In order to put arbitrary data into a memo field (that
   might have some private non-standard structure), the value of the first byte SHOULD
   be set to 0xFF; the remaining 511 bytes are then unconstrained.
 
++ If the first byte has a value of ``0xF5``, then the reader should not make any other
+  assumption about the memo. This value was used ambiguously in the past by private
+  agreement; applications SHOULD prefer ``0xFF`` which is unambiguously for this purpose.
+
 Rationale
-===========
+=========
 
 The new protocol specification is an improvement over the current memo field content
 specification that was in the protocol spec up to version 2020.1.0, which stated:
@@ -70,24 +74,25 @@ specification that was in the protocol spec up to version 2020.1.0, which stated
     note. The memo field SHOULD be encoded either as:
 
     + a UTF-8 human-readable string [Unicode], padded by appending zero bytes; or
-    + an arbitrary sequence of 512 bytes starting with a byte value of 0xF5 or greater,
-      which is therefore not a valid UTF-8 string.
+    + an arbitrary sequence of 512 bytes starting with a byte value of ``0xF5`` or
+      greater, which is therefore not a valid UTF-8 string.
 
     In the former case, wallet software is expected to strip any trailing zero bytes and
     then display the resulting UTF-8 string to the recipient user, where applicable.
     Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters
-    (U+FFFD).
+    (``U+FFFD``).
 
     In the latter case, the contents of the memo field SHOULD NOT be displayed. A start
-    byte of 0xF5 is reserved for use by automated software by private agreement. A start
-    byte of 0xF6 or greater is reserved for use in future Zcash protocol extensions.
+    byte of ``0xF5`` is reserved for use by automated software by private agreement. A
+    start byte of ``0xF6`` or greater is reserved for use in future Zcash protocol
+    extensions.
 
 See issue `#1849`_ for further discussion.
 
 .. _`#1849`: https://github.com/zcash/zcash/issues/1849
 
 Backwards Compatibility
-===========================
+=======================
 
 Encrypted memo field contents sent without the standardized format proposed here will be
 interpreted according to the specification set out in older versions of the protocol spec.
diff --git a/zip-0303.rst b/zips/zip-0303.rst
similarity index 100%
rename from zip-0303.rst
rename to zips/zip-0303.rst
diff --git a/zip-0304.rst b/zips/zip-0304.rst
similarity index 99%
rename from zip-0304.rst
rename to zips/zip-0304.rst
index a0e48b945..995eefc7b 100644
--- a/zip-0304.rst
+++ b/zips/zip-0304.rst
@@ -3,7 +3,7 @@
   ZIP: 304
   Title: Sapling Address Signatures
   Owners: Jack Grigg 
-  Credits: Daira Emma Hopwood 
+  Credits: Daira-Emma Hopwood 
            Sean Bowe 
   Status: Draft
   Category: Standards / RPC / Wallet
diff --git a/zip-0305.rst b/zips/zip-0305.rst
similarity index 75%
rename from zip-0305.rst
rename to zips/zip-0305.rst
index 1f3d2fbe8..a7695fd06 100644
--- a/zip-0305.rst
+++ b/zips/zip-0305.rst
@@ -2,7 +2,7 @@
 
   ZIP: 305
   Title: Best Practices for Hardware Wallets supporting Sapling
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Wallet
   Discussions-To: 
diff --git a/zip-0306.rst b/zips/zip-0306.rst
similarity index 75%
rename from zip-0306.rst
rename to zips/zip-0306.rst
index 00da5463a..76b95ead2 100644
--- a/zip-0306.rst
+++ b/zips/zip-0306.rst
@@ -2,7 +2,7 @@
 
   ZIP: 306
   Title: Security Considerations for Anchor Selection
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Informational
   Discussions-To: 
diff --git a/zip-0307.rst b/zips/zip-0307.rst
similarity index 99%
rename from zip-0307.rst
rename to zips/zip-0307.rst
index cfc65bf10..720443c80 100644
--- a/zip-0307.rst
+++ b/zips/zip-0307.rst
@@ -3,7 +3,7 @@
   ZIP: 307
   Title: Light Client Protocol for Payment Detection
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Original-Authors: George Tankersley
   Credits: Matthew Green
   Category: Standards / Ecosystem
@@ -53,7 +53,7 @@ There are three logical components to a Zcash light client system:
   update its own view of the chain state. The light client MAY be attached to a wallet
   backend that will track particular Sapling notes.
 
-.. figure:: zip-0307-arch.png
+.. figure:: ../rendered/assets/images/zip-0307-arch.png
     :align: center
     :figclass: align-center
 
diff --git a/zip-0308.rst b/zips/zip-0308.rst
similarity index 99%
rename from zip-0308.rst
rename to zips/zip-0308.rst
index 5ea284020..ed039af23 100644
--- a/zip-0308.rst
+++ b/zips/zip-0308.rst
@@ -2,8 +2,8 @@
 
   ZIP: 308
   Title: Sprout to Sapling Migration
-  Owners: Daira Emma Hopwood 
-  Original-Authors: Daira Emma Hopwood
+  Owners: Daira-Emma Hopwood 
+  Original-Authors: Daira-Emma Hopwood
                     Eirik Ogilvie-Wigley
   Status: Final
   Category: Standards / RPC / Wallet
diff --git a/zip-0309.rst b/zips/zip-0309.rst
similarity index 100%
rename from zip-0309.rst
rename to zips/zip-0309.rst
diff --git a/zip-0310.rst b/zips/zip-0310.rst
similarity index 99%
rename from zip-0310.rst
rename to zips/zip-0310.rst
index e3b665d4b..843f6e3c9 100644
--- a/zip-0310.rst
+++ b/zips/zip-0310.rst
@@ -2,7 +2,7 @@
 
   ZIP: 310
   Title: Security Properties of Sapling Viewing Keys
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
   Status: Draft
   Category: Informational
diff --git a/zips/zip-0311.rst b/zips/zip-0311.rst
new file mode 100644
index 000000000..b55b94bac
--- /dev/null
+++ b/zips/zip-0311.rst
@@ -0,0 +1,446 @@
+::
+
+  ZIP: 311
+  Title: Zcash Payment Disclosures
+  Owners: Jack Grigg 
+  Status: Draft
+  Category: Standards / RPC / Wallet
+  Discussions-To: 
+
+
+Abstract
+========
+
+This ZIP describes a mechanism and format for disclosing information about shielded spends
+and outputs within a transaction. In the typical case, this means enabling a sender to
+present a proof that they transferred funds to a recipient's shielded address.
+
+
+Motivation
+==========
+
+There are various situations where a proof-of-payment may be desired. For example:
+
+- A sender may need to prove that their payment was sent to a recipient, and available to
+  be received (following the Zcash protocol in-band).
+- A third party may need to verify that a payment between a given sender and recipient was
+  executed successfully.
+
+When a transaction involves only transparent addresses, proof-of-payment is simple: The
+sender provides the transaction ID, and the recipient examines the blockchain to confirm
+that the transaction was mined. A third party can also perform this verification if they
+know the transparent addresses of the involved parties.
+
+However, if the transaction involves shielded addresses, the blockchain by itself does not
+contain enough information to allow a record of the payment to be reconstructed and
+verified:
+
+=========== =========== ====== ========= ====== ==================
+Source      Destination Sender Recipient Amount Payment dislosure?
+=========== =========== ====== ========= ====== ==================
+Transparent Transparent 🔍      🔍        🔍     Not required
+Transparent Shielded    🔍      🔐        🔐*    Required
+Shielded    Transparent 🔒      🔍        🔍     Required
+Shielded    Shielded    🔒      🔐        🔐     Required
+=========== =========== ====== ========= ====== ==================
+
+- 🔍 = Visible on the block chain.
+- 🔐 = Cannot be confirmed without information that is not visible on the block chain.
+- 🔐* = Information is revealed, but not enough to confirm the amount paid (due to change).
+- 🔒 = Requires either an interactive payment disclosure, or a non-interactive payment
+  disclosure that reveals the sender's address.
+
+Enabling proof-of-payment for all of these transaction variants (where it is possible to
+do so) is the subject of this ZIP.
+
+
+Use cases
+=========
+
+Managing contributions for an event
+-----------------------------------
+Alice runs an event on behalf of Bob and Carol, who both agree to split the cost equally.
+Alice receives a single payment for half the amount, and wants proof of who it came from
+(so she knows which person to follow up with for the remaining amount). Carol can provide
+a payment disclosure that reveals to Alice:
+
+- The correct amount was sent to the Alice's recipient address in the given transaction.
+- Carol was the sender of that transaction (more precisely, Carol controls the spend
+  authority used in that transaction).
+
+and does not reveal:
+
+- Carol's payment address.
+- Any of Carol's other diversified payment addresses.
+- Any of Carol's other transactions.
+
+For this use case, it is not necessary (and not necessarily intended) that the payment
+disclosure be publically verifiable.
+
+Donation drive
+--------------
+
+Diana is a well-known individual with a public shielded payment address (for receiving
+donations). She runs a matching donation drive to the non-profit Totally Legit Bunnies,
+and wants to prove to her followers that she correctly matched their donations. Diana
+can create a payment disclosure, and post it to her social media account, that reveals:
+
+- The correct amount was sent to the Totally Legit Bunnies' recipient address in the
+  given transaction.
+- The sender of the transaction is the payment address that is associated with Diana.
+
+and does not reveal:
+
+- Any of Diana's other diversified payment addresses.
+- Any of Diana's other transactions.
+
+Merchant dispute
+----------------
+
+Edward goes to CarsRFast to buy a Lamborghini, and sends funds from his shielded address to
+CarsRFast's transparent address. They can see a payment has been made, but claim that they
+have not received a payment from Edward. He can create a payment disclosure that reveals:
+
+- Edward was the sender of the given transaction.
+
+and does not reveal:
+
+- Edward's payment address.
+- Any of Edward's other diversified payment addresses.
+- Any of Edward's other transactions.
+
+Shielded withdrawals from an exchange
+-------------------------------------
+
+CorpBux is an exchange with a transparent hot wallet, and enables customers to withdraw
+their funds to shielded addresses. They can create a payment disclosure, that they can give
+to their customers, that reveals:
+
+- The correct amount was sent to the customer's shielded recipient address in the given
+  transaction.
+- CorpBux was the sender of the given transaction.
+
+
+Requirements
+============
+
+- The payment disclosure may disclose the contents of zero or more shielded outputs within
+  a single transaction. (Zero outputs is useful for z2t transactions.)
+- Payment disclosures can only be created by a sender of the transaction,
+  and are non-malleable (that is, no-one else can take one or more payment
+  disclosures and construct a new one that they would not have been able
+  to make independently).
+- A payment disclosure may be tied to a challenge, creating an interactive proof.
+- Senders with a shielded address may choose to provably reveal that address as part of the
+  payment disclosure.
+- Senders are not required to remember any ephemeral data from the creation of a transaction
+  in order to produce a payment disclosure for that transaction. (Performance may be
+  improved if they do cache witness data for spent notes.)
+- The payment disclosure can be created without requiring another trusted setup.
+
+
+Conventions
+===========
+
+The following functions used in this ZIP are defined in the Zcash protocol specification:
+[#protocol]_
+
+- :math:`\mathsf{DiversifyHash}(\mathsf{d})` [#protocol-concretediversifyhash]_
+
+- :math:`\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})`,
+  :math:`\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)`, and
+  :math:`\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)` [#protocol-concretespendauthsig]_
+
+We reproduce some notation and functions from [#protocol]_ here for convenience:
+
+- :math:`[k] P` means scalar multiplication of the elliptic curve point :math:`P` by the
+  scalar :math:`k`.
+
+- :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)` refers to unkeyed BLAKE2b-256 in
+  sequential mode, with an output digest length of 32 bytes, 16-byte personalization
+  string :math:`p`, and input :math:`x`.
+
+We also define the following notation here:
+
+- :math:`[a..b]` means the sequence of values inclusive of :math:`a` and exclusive of
+  :math:`b`.
+
+- :math:`\mathsf{length}(a)` means the length of the sequence :math:`a`.
+
+
+Specification
+=============
+
+Payment disclosure data structure
+---------------------------------
+
+A payment disclosure has the following fields:
+
+- `txid`: Transaction id for the transaction `tx` being disclosed.
+
+- `msg`: A message field, which could contain a challenge value from the party to whom
+  the payment disclosure is directed.
+
+- :math:`\mathsf{transparentInputs}`: A sequence of the transparent inputs for which we are
+  proving spend authority :math:`[0..\mathsf{length}(\mathsf{tx.vin})]`
+
+  - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.vin}`.
+  - :math:`\mathsf{sig}`: A BIP 322 signature. [#bip-0322]_
+
+    - TODO: `zcashd` currently only supports the legacy format defined in BIP 322. We may
+      want to backport full BIP 322 support before having transparent input support in
+      this ZIP, to ensure it does what we need.
+    - TODO: BIP 322 specifies consensus rule checks as part of the signature verification
+      process. We will likely need to migrate it over to an equivalent ZIP that specifies
+      these for Zcash (which has a different set of script validation consensus rules).
+
+- :math:`\mathsf{saplingSpends}`: A sequence of the Sapling Spends for which we are proving
+  spend authority :math:`[0..\mathsf{length}(\mathsf{tx.shieldedSpends})]`
+
+  - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.shieldedSpends}`.
+  - :math:`\mathsf{cv}`: A value commitment to the spent note.
+  - :math:`\mathsf{rk}`: A randomized public key linked to the spent note.
+  - :math:`\mathsf{zkproof_{spend}}`: A Sapling spend proof.
+  - [Optional] A payment address proof `addr_proof`:
+
+    - Any :math:`(\mathsf{d, pk_d})` such that
+      :math:`\mathsf{pk_d} = [\mathsf{ivk}] \mathsf{DiversifyHash}(\mathsf{d})`
+    - :math:`\mathsf{nullifier_{addr}}`: A nullifier for a ZIP 304 fake note. [#zip-0304]_
+    - :math:`\mathsf{zkproof_{addr}}`: A Sapling spend proof.
+
+  - :math:`\mathsf{spendAuthSig}`
+
+- :math:`\mathsf{saplingOutputs}`: A sequence of the Sapling Outputs that we are disclosing
+  :math:`[0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]`
+
+  - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.shieldedOutputs}`.
+  - :math:`\mathsf{ock}`: The outgoing cipher key that allows this output to be recovered.
+    [#protocol-saplingencrypt]_
+
+TODO: Add support for Orchard.
+
+TODO: Decide on payment disclosure versioning.
+
+TODO: Define encodings for unsigned and signed payment disclosures.
+
+Creating a payment disclosure
+-----------------------------
+
+The inputs to a payment disclosure are:
+
+- The transaction.
+- The SLIP-44 [#slip-0044]_ coin type.
+- The message :math:`msg` to be included (which may be empty).
+- A sequence of :math:`(\mathsf{outputIndex}, \mathsf{ock})` tuples (which may be empty).
+- A sequence of Sapling spend tuples (which may be empty) containing:
+
+  - A Sapling spend index.
+  - Its corresponding expanded spending key :math:`(\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})`.
+  - [Optional] An associated payment address :math:`(\mathsf{d}, \mathsf{pk_d})`.
+
+- A sequence of transparent input tuples (which may be empty) containing:
+
+  - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.vin}`.
+  - The inputs to a BIP 322 signature (excluding `message_data`).
+
+The caller MUST provide at least one input tuple of any type (either a Sapling spend tuple
+or a transparent input tuple).
+
+The payment disclosure is created as follows:
+
+- For each Sapling spend index:
+
+  - Create a Sapling spend proof for the note that was spent in
+    :math:`\mathsf{tx.shieldedSpends[index]}`, using the same anchor, to obtain
+    :math:`(\mathsf{cv}, \mathsf{rk}, \mathsf{zkproof_{spend}})` as well as the random
+    :math:`\alpha` that was generated internally.
+
+  - [Optional] If an associated payment address was provided for this spend index, create
+    a ZIP 304 signature proof for that payment address, [#zip-0304]_ using :math:`\alpha`
+    and :math:`\mathsf{rk}` from the previous step. We obtain
+    :math:`(\mathsf{nullifier_{addr}}, \mathsf{zkproof_{addr}})` from this step.
+
+- For each transparent input index:
+
+  - TODO: Prepare BIP 322 signature inputs using `msg` as the `message_data`.
+
+- Construct an unsigned payment disclosure from the disclosed Sapling outputs, and the
+  above data for the Sapling spends and transparent inputs. Define the encoding of this as
+  :math:`unsignedPaymentDisclosure`.
+
+- For each Sapling spend index:
+
+  - Let :math:`\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(\alpha, \mathsf{ask})`.
+
+  - Let :math:`coinType` be the 4-byte little-endian encoding of the SLIP 44 coin type in its
+    index form, not its hardened form (i.e. 133 for mainnet Zcash).
+
+  - Let :math:`digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, unsignedPaymentDisclosure)`.
+
+  - Let :math:`spendAuthSig = \mathsf{SpendAuthSig.Sign}(\mathsf{rsk}, digest)`.
+
+- For each transparent input index:
+
+  - TODO: Create a BIP 322 signature using `msg` as the `message_data`.
+
+- Return the payment disclosure as the combination of the unsigned payment disclosure and
+  the set of `spendAuthSig` and transparent signature values.
+
+Verifying a payment disclosure
+------------------------------
+
+Given a payment disclosure :math:`\mathsf{pd}`, a transaction :math:`\mathsf{tx}`, and the
+`height` of the block in which :math:`\mathsf{tx}` was mined (which we assume was verified
+by the caller), the verifier proceeds as follows:
+
+- Perform the following structural correctness checks, returning false if any check fails:
+
+  - :math:`\mathsf{pd.txid} = \mathsf{tx.txid}()`
+
+  - Sequence length correctness:
+
+    - :math:`\mathsf{length}(\mathsf{pd.saplingOutputs}) \leq \mathsf{length}(\mathsf{tx.shieldedOutputs})`
+    - :math:`\mathsf{length}(\mathsf{pd.saplingSpends}) \leq \mathsf{length}(\mathsf{tx.shieldedSpends})`
+    - :math:`\mathsf{length}(\mathsf{pd.transparentInputs}) \leq \mathsf{length}(\mathsf{tx.vin})`
+
+  - Index uniqueness:
+
+    - For every :math:`\mathsf{output}` in :math:`\mathsf{pd.saplingOutputs}`,
+      :math:`\mathsf{output.index}` only occurs once.
+    - For every :math:`\mathsf{spend}` in :math:`\mathsf{pd.saplingSpends}`,
+      :math:`\mathsf{spend.index}` only occurs once.
+    - For every :math:`\mathsf{input}` in :math:`\mathsf{pd.transparentInputs}`,
+      :math:`\mathsf{input.index}` only occurs once.
+
+  - Index correctness:
+
+    - For every :math:`\mathsf{output}` in :math:`\mathsf{pd.saplingOutputs}`,
+      :math:`\mathsf{output.index} < \mathsf{length}(\mathsf{tx.shieldedOutputs})`
+    - For every :math:`\mathsf{spend}` in :math:`\mathsf{pd.saplingSpends}`,
+      :math:`\mathsf{spend.index} < \mathsf{length}(\mathsf{tx.shieldedSpends})`
+    - For every :math:`\mathsf{input}` in :math:`\mathsf{pd.transparentInputs}`,
+      :math:`\mathsf{input.index} < \mathsf{length}(\mathsf{tx.vin})`
+
+  - :math:`\mathsf{length}(\mathsf{pd.saplingSpends}) + \mathsf{length}(\mathsf{pd.transparentInputs}) > 0`
+
+- Let :math:`unsignedPaymentDisclosure` be the encoding of the payment disclosure without
+  signatures.
+
+- Let :math:`coinType` be the 4-byte little-endian encoding of the coin type in its index
+  form, not its hardened form (i.e. 133 for mainnet Zcash).
+
+- Let :math:`digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, unsignedPaymentDisclosure)`.
+
+- For every :math:`\mathsf{spend}` in :math:`\mathsf{pd.saplingSpends}`:
+
+  - If :math:`\mathsf{SpendAuthSig.Verify}(\mathsf{spend.rk}, digest, \mathsf{spend.spendAuthSig}) = 0`, return false.
+
+  - [Optional] If a payment address proof :math:`\mathsf{addrProof}` is present in
+    :math:`\mathsf{spend}`, verify :math:`(\mathsf{addrProof.nullifier_{addr}}, \mathsf{spend.rk}, \mathsf{addrProof.zkproof_{addr}})` as a ZIP 304 proof
+    for :math:`(\mathsf{addrProof.d}, \mathsf{addrProof.pk_d})` [#zip-0304]_. If verification fails, return
+    false.
+
+  - Decode and verify :math:`\mathsf{zkproof_{spend}}` as a Sapling spend proof
+    [#protocol-spendstatement]_ with primary input:
+
+    - :math:`\mathsf{tx.shieldedSpends[spend.index].rt}`
+    - :math:`\mathsf{spend.cv}`
+    - :math:`\mathsf{tx.shieldedSpends[spend.index].nf}`
+    - :math:`\mathsf{spend.rk}`
+
+    If verification fails, return false.
+
+- For every :math:`\mathsf{input}` in :math:`\mathsf{pd.transparentInputs}`:
+
+  - TODO: BIP 322 verification.
+
+- For every :math:`\mathsf{output}` in :math:`\mathsf{pd.saplingOutputs}`:
+
+  - Recover the Sapling note in :math:`\mathsf{tx.shieldedOutputs}[\mathsf{output.index}]`
+    via the process specified in [#protocol-saplingdecryptovk]_ with inputs
+    :math:`(height, \mathsf{output.ock})`. If recovery returns :math:`\bot`, return false.
+
+- Return true.
+
+Payment disclosure validity in UIs
+----------------------------------
+
+TODO: Set some standards for how UIs should display payment disclosures, and how they
+should convey the various kinds of validity information:
+
+- One, but not all, of the spenders proved spend authority.
+- All spenders of a specific type proved spend authority.
+- All spenders proved spend authority.
+- These, but also including optional payment address proofs.
+
+
+Rationale
+=========
+
+If a sender elects, at transaction creation time, to use an :math:`\mathsf{ovk}` of
+:math:`\bot` for a specific Sapling output, then they are unable to subsequently create a
+payment disclosure that discloses that output. This maintains the semantics of
+:math:`\mathsf{ovk}`, in that the sender explicitly chose to lose the capability to
+recover that output.
+
+Payment disclosures that prove Sapling spend authority are not required to reveal a
+sender address. This is because it is impossible: we can "prove" the transaction came from
+any of the diversified addresses linked to the spending key. Fundamentally, the "sender"
+of a transaction is anyone who has access to the corresponding spend authority; in the
+case of Sapling, a spend authority corresponds to multiple diversified addresses. In
+situations where a sender address is already known to the verifier of the payment
+disclosure (or publically), it may still be useful to have the option of linking the payment disclosure to
+that address.
+
+
+Security and Privacy Considerations
+===================================
+
+When spending Sapling notes normally in transactions, wallets select a recent anchor to
+make the anonymity set of the spent note as large as possible. By contrast, Sapling spend
+authority in a payment disclosure is proven using the same anchor that was used in the
+transaction itself, instead of a recent anchor. We do this for efficency reasons:
+
+- The anchor is already encoded in the transaction, so can be omitted from the payment
+  disclosure encoding.
+- It is necessary to have a witness for each spent note that is being included in the
+  payment disclosure. Using the same anchor means that the same witness can be used for
+  the transaction spend and the payment disclosure, which in turn means that wallets that
+  support payment disclosures only need to remember that witness, and do not need to
+  continually update witnesses for spent notes in the off-chance that they might be used
+  in a payment disclosure.
+
+There is no privacy benefit to selecting a more recent anchor; the anonymity set of the
+note was "fixed" by the original spend (which revealed that the note existed as of that
+anchor's height).
+
+We require all payment disclosures to prove spend authority for at least one input, in
+order to simplify the verification UX. In particular, if payment disclosures without
+spends were considered valid, an invalid payment disclosure with invalid signatures (that
+would be shown as invalid by UIs) could be mutated into a payment disclosure that would be
+shown as valid by UIs, by stripping off the signatures. We do not believe that this
+prevents any useful use cases; meanwhile if someone is intent on obtaining Sapling output
+disclosures regardless of the validity of their source, they will do so without a common
+standard.
+
+
+Reference implementation
+========================
+
+TBD
+
+
+References
+==========
+
+.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_
+.. [#RFC4648] `RFC 4648: The Base16, Base32, and Base64 Data Encodings `_
+.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_
+.. [#protocol-spendstatement] `Zcash Protocol Specification, Version 2020.1.15. Section 4.15.2: Spend Statement (Sapling) `_
+.. [#protocol-saplingencrypt] `Zcash Protocol Specification, Version 2020.1.15. 4.17.1: Encryption (Sapling) `_
+.. [#protocol-saplingdecryptovk] `Zcash Protocol Specification, Version 2020.1.15. 4.17.3: Decryption using a Full Viewing Key (Sapling) `_
+.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function `_
+.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature `_
+.. [#bip-0322] `BIP 322: Generic Signed Message Format `_
+.. [#slip-0044] `SLIP-0044 : Registered coin types for BIP-0044 `_
+.. [#zip-0304] `ZIP 304: Sapling Address Signatures `_
diff --git a/zips/zip-0312.rst b/zips/zip-0312.rst
new file mode 100644
index 000000000..0033cba50
--- /dev/null
+++ b/zips/zip-0312.rst
@@ -0,0 +1,453 @@
+::
+
+  ZIP: 312
+  Title: FROST for Spend Authorization Multisignatures
+  Owners: Conrado Gouvea 
+          Chelsea Komlo 
+          Deirdre Connolly 
+  Status: Draft
+  Category: Wallet
+  Created: 2022-08-dd
+  License: MIT
+  Discussions-To: 
+  Pull-Request: 
+
+
+Terminology
+===========
+
+{Edit this to reflect the key words that are actually used.}
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to
+be interpreted as described in RFC 2119. [#RFC2119]_
+
+The terms below are to be interpreted as follows:
+
+Unlinkability
+  The property of statistical independence of signatures from the
+  signers' long-term keys, ensuring that (for perfectly uniform
+  generation of Randomizers and no leakage of metadata) it is
+  impossible to determine whether two transactions were generated
+  by the same party.
+
+
+Abstract
+========
+
+This proposal adapts FROST [#FROST]_, a threshold signature scheme,
+to make it unlinkable, which is a requirement for its use in the Zcash protocol.
+The adapted scheme generates signatures compatible with spend authorization
+signatures in the Sapling and Orchard shielded protocols as deployed in Zcash.
+
+
+Motivation
+==========
+
+In the Zcash protocol, Spend Authorization Signatures are employed to authorize
+a transaction. The ability to generate these signatures with the user's
+private key is what effectively allows the user to spend funds.
+
+This is a security-critical step, since anyone who obtains access to the private
+key will be able to spend the user's funds. For this reason, one interesting
+possibility is to require multiple parties to allow the transaction to go
+through. This can be accomplished with threshold signatures, where the private
+key is split between parties (or generated already split using a distributed
+protocol) in a way that a threshold (e.g. 2 out of 3) of them must sign the
+transaction in order to create the final signature. This enables scenarios such
+as users and third-party services sharing custody of a wallet, or a group of
+people managing shared funds, for example.
+
+FROST is one of such threshold signature protocols. However, it can't be used
+as-is since the Zcash protocol also requires re-randomizing public and private
+keys to ensure unlinkability between transactions. This ZIP specifies a variant
+of FROST with re-randomization support. This variant is named "Re-Randomized
+FROST" and has been described in [#frost-rerandomized]_.
+
+
+Requirements
+============
+
+- All signatures generated by following this ZIP must be verified successfully
+  as Sapling or Orchard spend authorization signatures using the appropriate
+  validating key.
+- The signatures generated by following this ZIP should meet the security
+  criteria for Signature with Re-Randomizable Keys as specified in the Zcash
+  protocol [#protocol-concretereddsa]_.
+- The threat model described below must be taken into account.
+
+Threat Model
+------------
+
+In normal usage, a Zcash user follows multiple steps in order to generate a
+shielded transaction:
+
+- The transaction is created.
+- The transaction is signed with a re-randomized version of the user's spend
+  authorization private key.
+- The zero-knowledge proof for the transaction is created with the randomizer
+  as an auxiliary (secret) input, among others.
+
+When employing re-randomizable FROST as specified in this ZIP, the goal is to
+split the spend authorization private key :math:`\mathsf{ask}` among multiple
+possible signers. This means that the proof generation will still be performed
+by a single participant, likely the one that created the transaction in the first
+place. Note that this user already controls the privacy of the transaction since
+they are responsible for creating the proof.
+
+This fits well into the "Coordinator" role from the FROST specification
+[#frost-protocol]_. The Coordinator is responsible for sending the message to be
+signed to all participants, and to aggregate the signature shares.
+
+With those considerations in mind, the threat model considered in this ZIP is:
+
+- The Coordinator is trusted with the privacy of the transaction (which includes
+  the unlinkability property). A rogue Coordinator will be able to break
+  unlinkability and privacy, but should not be able to create signed transactions
+  without the approval of ``MIN_PARTICIPANTS`` participants, as specified in FROST.
+- All key share holders are also trusted with the privacy of the transaction,
+  thus a rogue key share holder will be able to break its privacy and unlinkability.
+
+
+Non-requirements
+================
+
+- This ZIP does not support removing the Coordinator role, as described in
+  [#frost-removingcoordinator]_.
+- This ZIP does not prevent key share holders from linking the signing operation to a
+  transaction in the blockchain.
+- Like the FROST specification [#FROST]_, this ZIP does not specify a key generation
+  procedure; but refer to that specification for guidelines.
+- Network privacy is not in scope for this ZIP, and must be obtained with other
+  tools if desired.
+
+
+Specification
+=============
+
+Algorithms in this section are specified using Python pseudo-code, in the same
+fashion as the FROST specification [#FROST]_.
+
+The types Scalar, Element, and G are defined in [#frost-primeordergroup]_, as
+well as the notation for elliptic-curve arithmetic, which uses the additive
+notation. Note that this notation differs from that used in the Zcash Protocol
+Specification. For example, ``G.ScalarMult(P, k)`` is used for scalar
+multiplication, where the protocol spec would use :math:`[k] P` with the group
+implied by :math:`P`.
+
+An additional per-ciphersuite hash function is used, denote ``HR(m)``, which
+receives an arbitrary-sized byte string and returns a Scalar. It is defined
+concretely in the Ciphersuites section.
+
+
+Key Generation
+--------------
+
+While key generation is out of scope for this ZIP and the FROST spec [#FROST]_,
+it needs to be consistent with FROST, see [#frost-tdkg]_ for guidance. The spend
+authorization private key :math:`\mathsf{ask}` [#protocol-spendauthsig]_ is the
+particular key that must be used in the context of this ZIP. Note that the
+:math:`\mathsf{ask}` is usually derived from the spending key
+:math:`\mathsf{sk}`, though that is not required. Not doing so allows using
+distributed key generation, since the key it generates is unpredictable. Note
+however that not deriving :math:`\mathsf{ask}` from :math:`\mathsf{sk}` prevents
+using seed phrases to recover the original secret (which may be something
+desirable in the context of FROST).
+
+
+Re-randomizable FROST
+---------------------
+
+To add re-randomization to FROST, follow the specification [#FROST]_ with the
+following modifications.
+
+
+Randomizer Generation
+'''''''''''''''''''''
+
+A new helper function is defined, which generates a randomizer. The
+`encode_signing_package` is defined as the byte serialization of the `msg`,
+`commitment_list` values as described in [#frost-serialization]_.
+Implementations MAY choose another encoding as long as all values (the message,
+and the identifier, binding nonce and hiding nonce for each participant) are
+unambiguously encoded.
+
+The function `random_bytes(n)` is defined in [#FROST]_ and it returns a buffer
+with `n` bytes sampled uniformly at random. The constant `Ns` is also specified
+in [#FROST]_ and is the size of a serialized scalar.
+
+::
+
+  randomizer_generate():
+
+  Inputs:
+  - msg, the message being signed in the current FROST signing run
+  - commitment_list = [(i, hiding_nonce_commitment_i,
+    binding_nonce_commitment_i), ...], a list of commitments issued by
+    each participant, where each element in the list indicates a
+    NonZeroScalar identifier i and two commitment Element values
+    (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list
+    MUST be sorted in ascending order by identifier.
+
+  Outputs: randomizer, a Scalar
+
+  def randomizer_generate(msg, commitment_list):
+    # Generate a random byte buffer with the size of a serialized scalar
+    rng_randomizer = random_bytes(Ns)
+    signing_package_enc = encode_signing_package(commitment_list, msg)
+    randomizer_input = rng_randomizer || signing_package_enc
+    return HR(randomizer_input)
+
+
+Round One - Commitment
+''''''''''''''''''''''
+
+Roune One is exactly the same as specified [#FROST]_. But for context, it
+involves these steps:
+
+- Each signer generates nonces and their corresponding public commitments.
+  A nonce is a pair of Scalar values, and a commitment is a pair of Element values.
+- The nonces are stored locally by the signer and kept private for use in the second round.
+- The commitments are sent to the Coordinator.
+
+
+Round Two - Signature Share Generation
+''''''''''''''''''''''''''''''''''''''
+
+In Round Two, the Coordinator generates a random scalar ``randomizer`` by calling
+``randomizer_generate`` and sends it to each signer, over a confidential and
+authenticated channel, along with the message and the set of signing
+commitments. (Note that this differs from regular FROST which just requires an
+authenticated channel.)
+
+In Zcash, the message that needs to be signed is actually the SIGHASH
+transaction hash, which does not convey enough information for the signers to
+decide if they want to authorize the transaction or not. Therefore, in practice,
+more data is needed to be sent (over the same encrypted, authenticated channel)
+from the Coordinator to the signers, possibly the transaction itself, openings of
+value commitments, decryption of note ciphertexts, etc.; and the signers MUST check
+that the given SIGHASH matches the data sent from the Coordinator, or compute the
+SIGHASH themselves from that data. However, the specific mechanism for that process
+is outside the scope of this ZIP.
+
+The randomized ``sign`` function is defined as the regular FROST ``sign``
+function, but with its inputs modified relative to the ``randomizer`` as
+following:
+
+- ``sk_i = sk_i + randomizer``
+- ``group_public_key = group_public_key + G.ScalarBaseMult(randomizer)``
+
+
+Signature Share Verification and Aggregation
+''''''''''''''''''''''''''''''''''''''''''''
+
+The randomized ``aggregate`` function is defined as the regular FROST
+``aggregate`` function, but with its inputs modified relative to the
+``randomizer`` as following:
+
+- ``group_public_key = group_public_key + G.ScalarBaseMult(randomizer)``
+
+The randomized ``verify_signature_share`` function is defined as the regular
+FROST ``verify_signature_share`` function, but with its inputs modified relative
+to the ``randomizer`` as following:
+
+- ``PK_i = PK_i + G.ScalarBaseMult(randomizer)``
+- ``group_public_key = group_public_key + G.ScalarBaseMult(randomizer)``
+
+
+Ciphersuites
+------------
+
+FROST(Jubjub, BLAKE2b-512)
+''''''''''''''''''''''''''
+
+This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function ``H``
+meant to produce signatures indistinguishable from RedJubjub Sapling Spend
+Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
+
+- Group: Jubjub [#protocol-jubjub]_ with base point :math:`\mathcal{G}^{\mathsf{Sapling}}`
+  as defined in [#protocol-concretespendauthsig]_.
+
+  - Order: :math:`r_\mathbb{J}` as defined in [#protocol-jubjub]_.
+  - Identity: as defined in [#protocol-jubjub]_.
+  - RandomScalar(): Implemented by returning a uniformly random Scalar in the range
+    \[0, ``G.Order()`` - 1\]. Refer to {{frost-randomscalar}} for implementation guidance.
+  - SerializeElement(P): Implemented as :math:`\mathsf{repr}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_
+  - DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_,
+    returning an error if :math:`\bot` is returned. Additionally, this function
+    validates that the resulting element is not the group identity element,
+    returning an error if the check fails.
+  - SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
+    of the Scalar value.
+  - DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
+    little-endian 32-byte string. This function can fail if the input does not
+    represent a Scalar in the range \[0, ``G.Order()`` - 1\].
+
+- Hash (``H``): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
+  and Nh = 64.
+
+  - H1(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubR", m), interpreting
+    the 64 bytes as a little-endian integer, and reducing the resulting integer
+    modulo ``G.Order()``.
+  - H2(m): Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting
+    the 64 bytes as a little-endian integer, and reducing the resulting integer
+    modulo ``G.Order()``.
+    (This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined by
+    the :math:`\mathsf{RedJubjub}` scheme instantiated in [#protocol-concretereddsa]_.)
+  - H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting
+    the 64 bytes as a little-endian integer, and reducing the resulting integer
+    modulo ``G.Order()``.
+  - H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubM", m).
+  - H5(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubC", m).
+  - HR(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubA", m), interpreting
+    the 64 bytes as a little-endian integer, and reducing the resulting integer
+    modulo ``G.Order()``.
+
+Signature verification is as specified in [#protocol-concretespendauthsig]_
+for RedJubjub.
+
+
+FROST(Pallas, BLAKE2b-512)
+''''''''''''''''''''''''''
+
+This ciphersuite uses Pallas for the Group and BLAKE2b-512 for the Hash function ``H``
+meant to produce signatures indistinguishable from RedPallas Orchard Spend
+Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
+
+- Group: Pallas [#protocol-pallasandvesta]_ with base point :math:`\mathcal{G}^{\mathsf{Orchard}}`
+  as defined in [#protocol-concretespendauthsig]_.
+
+  - Order: :math:`r_\mathbb{P}` as defined in [#protocol-pallasandvesta]_.
+  - Identity: as defined in [#protocol-pallasandvesta]_.
+  - RandomScalar(): Implemented by returning a uniformly random Scalar in the range
+    \[0, ``G.Order()`` - 1\]. Refer to {{frost-randomscalar}} for implementation guidance.
+  - SerializeElement(P): Implemented as :math:`\mathsf{repr}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_.
+  - DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_,
+    failing if :math:`\bot` is returned. Additionally, this function validates that the resulting
+    element is not the group identity element, returning an error if the check fails.
+  - SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
+    of the Scalar value.
+  - DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
+    little-endian 32-byte string. This function can fail if the input does not
+    represent a Scalar in the range \[0, ``G.Order()`` - 1\].
+
+- Hash (``H``): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
+  and Nh = 64.
+
+  - H1(m): Implemented by computing BLAKE2b-512("FROST_RedPallasR", m), interpreting
+    the 64 bytes as a little-endian integer, and reducing the resulting integer
+    modulo ``G.Order()``.
+  - H2(m): Implemented by computing BLAKE2b-512("Zcash_RedPallasH", m), interpreting
+    the 64 bytes as a little-endian integer, and reducing the resulting integer
+    modulo ``G.Order()``.
+    (This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined by
+    the :math:`\mathsf{RedPallas}` scheme instantiated in [#protocol-concretereddsa]_.)
+  - H3(m): Implemented by computing BLAKE2b-512("FROST_RedPallasN", m), interpreting
+    the 64 bytes as a little-endian integer, and reducing the resulting integer
+    modulo ``G.Order()``.
+  - H4(m): Implemented by computing BLAKE2b-512("FROST_RedPallasM", m).
+  - H5(m): Implemented by computing BLAKE2b-512("FROST_RedPallasC", m).
+  - HR(m): Implemented by computing BLAKE2b-512("FROST_RedPallasA", m), interpreting
+    the 64 bytes as a little-endian integer, and reducing the resulting integer
+    modulo ``G.Order()``.
+
+Signature verification is as specified in [#protocol-concretespendauthsig]_
+for RedPallas.
+
+Rationale
+=========
+
+FROST is a threshold Schnorr signature scheme, and Zcash Spend Authorization are
+also Schnorr signatures, which allows the usage of FROST with Zcash. However,
+since there is no widespread standard for Schnorr signatures, it must be ensured
+that the signatures generated by the FROST variant specified in this ZIP can be
+verified successfully by a Zcash implementation following its specification. In
+practice this entails making sure that the generated signature can be verified
+by the :math:`\mathsf{RedDSA.Validate}` function specified in
+[#protocol-concretereddsa]_:
+
+- The FROST signature, when split into R and S in the first step of
+  :math:`\mathsf{RedDSA.Validate}`, must yield the values expected by the
+  function. This is ensured by defining SerializeElement and SerializeScalar in
+  each ciphersuite to yield those values.
+
+- The challenge c used during FROST signing must be equal to the challenge c
+  computed during :math:`\mathsf{RedDSA.Validate}`. This requires defining the
+  ciphersuite H2 function as the :math:`\mathsf{H}^\circledast(m)` Zcash
+  function in the ciphersuites, and making sure its input will be the same.
+  Fortunately FROST and Zcash use the same input order (R, public key, message)
+  so we just need to make sure that SerializeElement (used to compute the
+  encoded public key before passing to the hash function) matches what
+  :math:`\mathsf{RedDSA.Validate}` expects; which is possible since both `R` and
+  `vk` (the public key) are encoded in the same way as in Zcash.
+
+- Note that ``r`` (and thus ``R``) will not be generated as specified in RedDSA.Sign.
+  This is not an issue however, since with Schnorr signatures it does not matter
+  for the verifier how the ``r`` value was chosen, it just needs to be generated
+  uniformly at random, which is true for FROST.
+
+- The above will ensure that the verification equation in
+  :math:`\mathsf{RedDSA.Validate}` will pass, since FROST ensures the exact same
+  equation will be valid as described in [#frost-primeorderverify]_.
+
+The second step is adding the re-randomization functionality so that each FROST
+signing generates a re-randomized signature:
+
+- Anywhere the public key is used, the randomized public key must be used instead.
+  This is exactly what is done in the functions defined above.
+- The re-randomization must be done in each signature share generation, such
+  that the aggregated signature must be valid under verification with the
+  randomized public key. The ``R`` value from the signature is not influenced by
+  the randomizer so we just need to focus on the ``z`` value (using FROST
+  notation). Recall that ``z`` must equal to ``r + (c * sk)``, and that each
+  signature share is ``z_i = (hiding_nonce + (binding_nonce * binding_factor)) +
+  (lambda_i * c * sk_i)``. The first terms are not influenced by the randomizer
+  so we can only look into the second term of each top-level addition, i.e. ``c
+  * sk`` must be equal to ``sum(lambda_i * c * sk_i)`` for each participant
+  ``i``. Under re-randomization these become ``c * (sk + randomizer)`` (see
+  :math:`\mathsf{RedDSA.RandomizedPrivate}`, which refers to the randomizer as
+  :math:`\alpha`) and ``sum(lambda_i * c * (sk_i + randomizer))``. The latter
+  can be rewritten as ``c * (sum(lambda_i * sk_i) + randomizer *
+  sum(lambda_i)``. Since ``sum(lambda_i * sk_i) == sk`` per the Shamir secret
+  sharing mechanism used by FROST, and since ``sum(lambda_i) == 1``
+  [#sum-lambda-proof]_, we arrive at ``c * (sk + randomizer)`` as required.
+
+- The re-randomization procedure must be exactly the same as in
+  [#protocol-concretereddsa]_ to ensure that re-randomized keys are uniformly
+  distributed and signatures are unlinkable. This is also true; observe that
+  ``randomizer_generate`` generates randomizer uniformly at random as required
+  by :math:`\mathsf{RedDSA.GenRandom}`; and signature generation is compatible
+  with :math:`\mathsf{RedDSA.RandomizedPrivate}`,
+  :math:`\mathsf{RedDSA.RandomizedPublic}`, :math:`\mathsf{RedDSA.Sign}` and
+  :math:`\mathsf{RedDSA.Validate}` as explained in the previous item.
+
+The security of Re-Randomized FROST with respect to the security assumptions of
+regular FROST is shown in [#frost-rerandomized]_.
+
+
+Reference implementation
+========================
+
+The `reddsa` crate [#crate-reddsa]_ contains a re-randomized FROST implementation of
+both ciphersuites.
+
+
+References
+==========
+
+.. [#BLAKE] `BLAKE2: simpler, smaller, fast as MD5 `_
+.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_
+.. [#FROST] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures `_
+.. [#frost-rerandomized] `Re-Randomized FROST `_
+.. [#frost-protocol] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 5: Two-Round FROST Signing Protocol `_
+.. [#frost-removingcoordinator] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 7.3: Removing the Coordinator Role `_
+.. [#frost-primeordergroup] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 3.1: Prime-Order Group `_
+.. [#frost-primeorderverify] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix B: Schnorr Signature Generation and Verification for Prime-Order Groups `_
+.. [#frost-tdkg] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix B: Trusted Dealer Key Generation `_
+.. [#frost-randomscalar] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix C: Random Scalar Generation `_
+.. [#frost-serialization] `The ZF FROST Book, Serialization Format `_
+.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas `_
+.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard) `_
+.. [#protocol-spendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.15: Spend Authorization Signature (Sapling and Orchard) `_
+.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.3: Jubjub `_
+.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta `_
+.. [#crate-reddsa] `reddsa `_
+.. [#sum-lambda-proof] `Prove that the sum of the Lagrange (interpolation) coefficients is equal to 1 `_
diff --git a/zip-0313.rst b/zips/zip-0313.rst
similarity index 99%
rename from zip-0313.rst
rename to zips/zip-0313.rst
index 185b7845b..86cc554a8 100644
--- a/zip-0313.rst
+++ b/zips/zip-0313.rst
@@ -3,7 +3,7 @@
   ZIP: 313
   Title: Reduce Conventional Transaction Fee to 1000 zatoshis
   Owners: Aditya Bharadwaj 
-  Credits: Daira Emma Hopwood
+  Credits: Daira-Emma Hopwood
            Deirdre Connolly
            Nathan Wilcox
   Status: Obsolete
@@ -199,7 +199,7 @@ Acknowledgements
 ================
 
 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
+section. Thanks to Daira-Emma Hopwood and Deirdre Connolly for reviewing and fixing
 the wording in this ZIP.
 
 
diff --git a/zip-0314.rst b/zips/zip-0314.rst
similarity index 100%
rename from zip-0314.rst
rename to zips/zip-0314.rst
diff --git a/zips/zip-0315.rst b/zips/zip-0315.rst
new file mode 100644
index 000000000..519d5d2bc
--- /dev/null
+++ b/zips/zip-0315.rst
@@ -0,0 +1,701 @@
+::
+
+  ZIP: 315
+  Title: Best Practices for Wallet Implementations
+  Owners: Daira-Emma Hopwood 
+          Jack Grigg 
+          Kris Nuttycombe 
+  Credits: Francisco Gindre
+  Status: Draft
+  Category: Wallet
+  Discussions-To: 
+  Pull-Request: 
+
+
+Terminology
+===========
+
+The key words "MUST", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
+and "MAY" in this document are to be interpreted as described in BCP 14 [#BCP14]_
+when, and only when, they appear in all capitals.
+
+The terms below are to be interpreted as follows:
+
+Auto-shielding
+    The process of automatically transferring transparent funds to the most recent
+    shielded pool on receipt.
+
+Auto-migration
+    The process of automatically transferring shielded funds from older pools to the
+    most preferred (usually the most recent) pool on receipt.
+
+Opportunistic migration
+    The process of transferring previously received shielded funds from older pools
+    to the most preferred (usually the most recent) pool as part of a user-initiated
+    transaction.
+
+Transaction output (TXO)
+    An output (transparent coin or shielded note) of a transaction on the consensus
+    block chain or in the mempool visible to a wallet.
+
+TODO: Add informal definitions of:
+* known-spendable and confirmed-spendable TXOs;
+* trusted and untrusted TXOs.
+
+These should forward-reference the specification section with the formal definitions.
+
+
+Motivation
+==========
+
+Zcash wallets have to serve two purposes as a user agent:
+
+* to manage the economic actions dictated by the user;
+* to manage the privacy implications of these actions.
+
+The goal of this ZIP is to document security and privacy best practices when handling
+funds and transactions as the user's agent. These best practices are intended to
+provide as much privacy as is feasible by default, while still enabling the user's
+desired transactions to occur, and exposing any privacy implications to the user so
+that they have enough information to assess the consequences of their economic actions.
+
+This ZIP covers best practices for:
+
+* what information to display to the user about transactions and balances;
+* how to handle interactions between the ZIP 32 [#zip-0032]_ key tree and Unified Addresses [#zip-0316]_;
+* when to use external or internal keys/addresses;
+* sharing addresses and viewing keys;
+* sending and receiving funds (including fee selection);
+* migrating funds between pools.
+
+
+Requirements
+============
+
+User consent
+------------
+
+A wallet typically reveals some information in the process of creating a transaction.
+Which information is revealed depends on the configured wallet privacy policy.
+The guiding principle of these requirements is that users must explicitly consent
+to each instance of information being revealed by the wallet in a transaction.
+
+A user may give blanket consent to reveal a particular kind of information, and
+must also be able to change the configured wallet privacy policy to avoid the
+wallet creating new information leaks of a given type.
+
+The specifications below describe some situations in which blanket consent may be
+inappropriate.
+
+Some varieties of consent may not be revocable, for example if a user chooses to
+share some of their keys.
+
+
+Prompt accessibility of funds
+-----------------------------
+
+Wallets need to take account of two main concerns with respect to
+accessibility of funds:
+
+* enabling funds to be spent as quickly as possible to reduce latency;
+* ensuring that the confirmed-spendable balance is not overestimated,
+  and so can be trusted by the user.
+
+These concerns affect the way that balances should be computed, which
+notes are selected for spending, and how the wallet should ensure that
+sufficient notes are available to cover multiple spends within a short
+period.
+
+To support this we define two kinds of TXOs:
+
+* A trusted TXO is a TXO received from a party where the wallet trusts that
+  it will remain mined in its original transaction, such as TXOs created by
+  the wallet's internal TXO handling.
+* An untrusted TXO is a TXO received by the wallet that is not trusted.
+
+Wallets can then require that untrusted TXOs need more confirmations before
+they become confirmed-spendable than trusted TXOs. This provides an improved
+trade-off between latency on the one hand, and reliability and safety on the
+other.
+
+
+Specification
+=============
+
+Long-term storage of funds
+--------------------------
+
+It is RECOMMENDED that wallets only hold funds as shielded in the long term;
+that is, if a wallet supports receiving transparent funds (or supports
+importing a seed from another wallet that might have done so), then it SHOULD
+auto-shield such funds by default.
+
+A shielding transaction is always linked to the transparent addresses it
+spends from. This can cause undesirable information leaks:
+
+a) if there are multiple transparent addresses, they will be linked to each
+   other;
+b) a link between the input transparent address(es) and the payment will be
+   visible to the recipient(s), or to any other holder of an Incoming Viewing
+   Key for the destination address(es).
+
+Despite the fact that it is not possible to achieve strong privacy guarantees
+from *any* use of transparent addresses, it is undesirable to reveal this
+additional information. In particular, issue b) motivates ruling out the use
+of "opportunistic shielding", i.e. shielding previously received transparent
+funds as part of a user-initiated transaction.
+
+Wallets SHOULD NOT auto-shield from multiple transparent addresses in the
+same transaction, and SHOULD NOT use opportunistic shielding.
+
+Following all of the recommendations in this section improves both collective
+privacy and the user's individual privacy, by maximizing the size of the note
+anonymity set over time and minimizing the potential linkage of shielding
+transactions to other transactions.
+
+The remainder of this specification assumes a wallet that follows all of these
+recommendations, except where explicitly noted.
+
+A wallet MAY allow users to disable auto-shielding, auto-migration,
+and/or opportunistic migration. If it does so, this need not be via
+three independent settings.
+
+Automatic shielding and automatic/opportunistic migration SHOULD NOT be
+applied to inputs where the cost of shielding or migrating them will
+exceed their economic value. If these transactions are paying the
+ZIP 317 conventional fee [#zip-0317]_, that will be the case if the
+amount of the UTXO to be shielded/migrated exceeds the marginal
+fee, and cannot be accommodated by an input that would be present
+in any case due to padding of the number of inputs from a given
+shielded pool.
+
+
+Trusted and untrusted TXOs
+--------------------------
+
+A wallet SHOULD treat received TXOs that are outputs of transactions created
+by the same wallet, as trusted TXOs. Wallets MAY enable users to mark specific
+external transactions as trusted, allowing their received TXOs also to be
+classified as trusted TXOs.
+
+A wallet SHOULD have a policy that is clearly communicated to the user for
+the number of confirmations needed to spend untrusted and trusted TXOs
+respectively. The following confirmation policy is RECOMMENDED:
+
+* 10 confirmations, for untrusted TXOs;
+* 3 confirmations, for trusted TXOs.
+
+Rationale for the given numbers of confirmations
+''''''''''''''''''''''''''''''''''''''''''''''''
+
+The rationale for choosing three confirmations for trusted TXOs is that
+anecdotally, reorgs are usually less than three blocks.
+
+The consequences of attempting to spend a trusted TXO may be less severe in the
+case of a rollback than the consequences of attempting to spend an untrusted TXO.
+The value received from a trusted TXO should always be recoverable, whereas
+recovering value received from an untrusted TXO may require the user to request
+that funds are re-sent.
+
+
+Categories of TXOs according to spendability
+--------------------------------------------
+
+A TXO is *known-spendable*, relative to a given block chain and wallet state,
+if and only if all of the following are true in that state:
+
+* the TXO is unspent at the wallet's view of the chain tip, and that view is
+  reasonably up-to-date;
+
+  TODO: consider undoing the up-to-date part, as when combined with the
+  definition of balance below, it causes wallet balance to drop to zero in
+  the short window between opening and updating the wallet's chain tip view.
+* the TXO is not committed to be spent in another transaction created
+  by this wallet; and
+* the wallet has the TXO's spending key (for whatever protocol the TXO uses).
+
+A TXO is *confirmed-spendable*, relative to a given block chain and
+wallet state, if and only if all of the following are true in that state:
+
+* the wallet is synchronized; and
+* the TXO is known-spendable; and
+* either auto-shielding is not active or the TXO is shielded; and
+* auto-migration *from* whatever protocol the TXO uses is not active; and
+* the TXO is trusted and has at least the required confirmations for
+  trusted TXOs, or it is untrusted and has at least the required
+  confirmations for untrusted TXOs.
+
+A TXO is *unconfirmed-spendable*, relative to a given block chain and
+wallet state, if and only if the TXO is known-spendable but is not
+confirmed-spendable in that state.
+
+A TXO is *watch-only* if and only if the wallet has its full viewing key
+(or address in the case of a transparent TXO) but not its spending key.
+
+A wallet MUST NOT attempt to spend a TXO in a user-initiated transaction
+that is not confirmed-spendable.
+
+Open question: what should be specified about which TXOs can be spent
+in non-user-initiated transactions?
+
+Note: the definition of a TXO includes outputs in mempool transactions
+that are unconflicted from the perspective of the wallet.
+
+
+Reporting of balances
+---------------------
+
+Wallets SHOULD report:
+
+* Confirmed-spendable balance.
+* Pending balance, *or* total balance.
+
+These are calculated as follows:
+
+* The confirmed-spendable balance is the sum of values of
+  confirmed-spendable TXOs.
+* The pending balance is the sum of values of unconfirmed-spendable TXOs.
+* The total balance is the confirmed-spendable balance plus the pending
+  balance.
+
+Note: the definition of "confirmed-spendable" above ensures that:
+
+* if auto-shielding is enabled, transparent funds will be reported in
+  the pending or total balance, but not in the confirmed-spendable
+  balance;
+* if the wallet has not synchronized at least the nullifier set to the
+  chain tip, the confirmed-spendable balance will be zero.
+
+If auto-shielding is disabled, the wallet MAY report shielded and
+transparent balances separately. If it does so, it MUST make clear
+whether each reported balance corresponds to a confirmed-spendable,
+pending, or total subset of funds.
+
+Rationale for reporting of balances
+'''''''''''''''''''''''''''''''''''
+
+If auto-shielding is disabled, then separate shielded and transparent
+balances can constitute useful information. If auto-shielding is enabled
+then the wallet can and will automatically spend transparent TXOs in
+order to shield them, and so transparent TXOs need to be presented as
+pending, not as part of the balance spendable by the user.
+
+Potentially, for expert users, separate shielded balances per pool
+could also be useful.
+
+Open question: Does the specification of balance reporting give the user
+sufficient visibility into the operation of auto-shielding and pool
+migration/usage?
+
+Reporting of transactions
+-------------------------
+
+If a transaction includes watch-only received TXOs, its watch-only incoming
+balance MUST be reported separately to any potentially known-spendable balance.
+
+Incoming transactions
+'''''''''''''''''''''
+
+A transaction is incoming if it contains unconfirmed-spendable TXOs.
+Incoming transactions SHOULD be reported with their number of confirmations
+and their balances as described in `Reporting of balances`_.
+
+Sent transactions
+'''''''''''''''''
+
+A transaction is sent if it was either:
+
+* created by the wallet, or
+* detected by using the wallet's outgoing viewing keys to decrypt
+  Sapling or Orchard outputs, or
+* detected as spending a note that was at some time held by the
+  wallet by recognizing that note's nullifier, or
+* detected as spending a transparent TXO associated with one of
+  the wallet's addresses (including watch-only addresses).
+
+Sent transactions SHOULD be reported with their number of confirmations,
+an estimate of how long until they expire (if they are unmined and
+have an expiry height), and their balances as described in
+`Reporting of balances`_.
+
+
+Transaction creation
+--------------------
+
+Obtaining user consent for information leakage
+''''''''''''''''''''''''''''''''''''''''''''''
+
+Information leakage analysis
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The privacy provided by a Zcash transaction depends on the information leaked
+in the creation of that transaction and the process of it being broadcast for
+inclusion in the block chain.
+
+The requirements in this section are intended to minimize the leakage of such
+information where possible, and to ensure that the user is informed of any
+remaining information that would be leaked, and consents to such leakage.
+
+The list below describes the kinds of information that might be leaked. After
+a candidate transaction has been created and prior to it being revealed
+outside a trusted path to the user, the wallet user interface SHOULD obtain
+the user's consent for all of the leaked information.
+
+Assumption: There is always a transaction confirmation step for transactions
+that send funds out of the wallet.
+
+
+Kinds of information leakage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+* Transaction version (v4 or v5, as of NU5)
+
+It is RECOMMENDED to use v5 transactions unless Sprout funds are being spent.
+
+* Lock time (rarely used; may be a distinguisher if it is)
+
+SHOULD be zero.
+
+* Expiry height and anchor position
+
+See `Anchor selection`_ below.
+
+These give information about what block height the creator was synced to, and
+some policy information.
+
+* Transparent inputs and outputs
+
+See `Linkability of transactions or addresses`_.
+
+* Public value balances
+
+  * Together with the transparent inputs and outputs, these determine the fee
+    and the amount being transferred between pools.
+  * The fee is dependent on policy, but for a given policy we attempt to make
+    it only depend on other already-leaked metadata.
+
+TODO: we SHOULD try to create fully shielded transactions where possible.
+
+* Numbers of JoinSplits, Spends, Outputs, and Actions
+
+  * This could correlate with other information under certain circumstances.
+    For example in a “dusting attack”, the adversary sends a victim lots of
+    small-valued notes (or notes with strategically chosen values),
+    increasing the probability that the victim’s transactions will have a
+    larger number of spends than other transactions (or an identifiable
+    number of spends). There are note management strategies that can mitigate
+    this, but they have not been implemented yet.
+
+* Which spends of given TXOs are repeated across transactions
+
+  * This may happen because a previous transaction expired and the user is
+    trying to spend some of the same TXOs.
+
+* Whether the transaction is coinbase
+
+* For coinbase transactions, the amounts / destination addresses / memos of
+  shielded outputs
+
+* Orchard flags (enableSpends/enableOutputs)
+
+  * Under normal circumstances these only depend on whether the transaction
+    is coinbase.
+
+
+Linkability of transactions or addresses
+''''''''''''''''''''''''''''''''''''''''
+
+Motivation for choices reducing linkability
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We want to support creating unlinkable addresses, in order that a user can
+give different addresses to different counterparties, in such a way that the
+counterparties (even if they collude) cannot tell that the addresses were
+provided by the same or distinct users.
+
+If multiple UTXOs are received at the same transparent address, it is safe
+to shield them all in the same transaction, because that is not leaking
+additional information.
+
+UTXOs received on different transparent receivers SHOULD NOT be shielded
+in the same transaction. Ideally, when they are shielded in separate
+transactions, this should be done in such a way that the timing of those
+transactions is not linkable.
+
+TODO: move this. Daira-Emma thinks that if we only document leakage rather
+than explicitly say in the specification of how to construct transactions
+how to mitigate it, then implementors will ignore it.
+
+When spending transparent UTXOs, they SHOULD only be sent to an internal
+shielded receiver belonging to the wallet, except when they are generated
+and spent ephemerally as part of a ZIP 320 transfer [#zip-0320]_.
+
+A wallet MUST NOT send funds to a transparent address unless all of the
+source funds come from shielded pools, and this SHOULD be a single shielded
+pool.
+
+We want to minimize pool crossing.
+
+Anchor selection
+''''''''''''''''
+
+A wallet SHOULD choose an anchor a number of blocks back from the head of the
+chain equal to the trusted confirmation depth. That is, if the current block
+is at height H, the anchor SHOULD reflect the final treestate of the block at
+height H-3.
+
+TODO: Define a parameter for this depth, and then RECOMMEND a value of 3.
+
+
+Rationale for anchor selection
+''''''''''''''''''''''''''''''
+
+* If the chain rolls back past the block at which the anchor is chosen, then
+  the anchor and the transaction will be invalidated. This is undesirable
+  both for reliability, and because the nullifiers of spent shielded notes
+  will have been revealed, linking this transaction to any future transactions
+  that spend those notes.
+
+  TODO: Reword this given the proposed note management mitigation below.
+* On the other hand, it is undesirable to choose an anchor too many blocks
+  back, because that prevents more recently received shielded notes from
+  being spent.
+* Using a fixed anchor depth (as opposed to a different depth depending on
+  whether or not we are spending trusted shielded notes) avoids leaking
+  information about whether or not the shielded notes we spent were
+  trusted.
+
+
+Note selection
+''''''''''''''
+
+TODO: recommend that when nullifiers are revealed in a transaction that is then
+invalidated (or revealed in some other detectable way), they SHOULD be used in
+a note management tx to avoid linking the invalidated tx with some arbitrary
+future tx. Provided that there are no transparent outputs leaving this wallet's
+control, the same arities and transparent outputs SHOULD be preserved, which
+also avoids revealing whether the user changed their mind about whether to send
+the original semantic transaction.
+
+
+Expiration height
+'''''''''''''''''
+
+A wallet SHOULD create transactions using the default expiration height of
+40 blocks from the current height, as specified in [#zip-0203]_.
+
+
+Open question
+'''''''''''''
+
+How should wallet developers time transactions to avoid linkability?
+
+* when we roll addresses with transparent components, we have to consider
+  how that could allow linking of shielded components
+
+
+TODO: dusting attack mitigation
+
+
+Network-layer privacy
+---------------------
+
+
+Viewing keys
+------------
+
+What they are supposed to reveal; see ZIP 310 for Sapling (needs updating for
+Orchard). https://github.com/zcash/zips/issues/606
+
+
+
+Allowed transfers
+-----------------
+
+* Sprout -> transparent or Sapling
+* Sapling -> transparent or Sapling or Orchard
+* Orchard -> transparent or Sapling or Orchard
+* if auto-shielding is off:
+  *  transparent -> transparent or Sapling or Orchard
+* if auto-shielding is on:
+  *  transparent -> internal Orchard or Sapling
+
+Note: wallets MAY further restrict the set of transfers they perform.
+
+
+Auto-shielding
+--------------
+
+Wallets SHOULD NOT spend funds from a transparent address to an external address,
+unless the user gives explicit consent for this on a per-transaction basis.
+
+TODO: Reword this to define the source transparent address as any transparent
+address (external, internal, or ephemeral), except in the case of ephemeral as
+allowed for implementing ZIP 320.
+
+In order to support this policy, wallets SHOULD implement a system of auto-shielding
+with the following characteristics:
+
+
+If auto-shielding functionality is available in a wallet, then users MUST be able
+to explicitly consent to one of the following possibilities:
+
+* auto-shielding is always on;
+* auto-shielding is always off;
+* the user specifies a policy...
+
+Auto-shielding MUST be one of:
+
+* "must opt in or out" (zcashd will do this -- i.e. refuse to start unless the option
+  is configured), or
+* always on.
+
+
+Auto-migration
+--------------
+
+
+Information leakage for transfers between pools
+-----------------------------------------------
+
+
+If no auto-migration, if you can satisfy a transfer request to Sapling from your
+Sapling funds, do so.
+
+The user's consent is needed to reveal amounts publically (as opposed
+to revealing them to the holder of a viewing key authorized to see that
+amount). Therefore, there should be per-transaction opt-in for any
+transfer that publically reveals amounts on chain.
+
+* there may be a compatibility issue for amount-revealing cross-pool txns that were
+  previously allowed without opt-in
+
+Wallets MUST NOT automatically combine funds across pools to satisfy a transfer
+(since that could reveal the total funds the user holds in some pool).
+
+In order to maintain the integrity of IVK guarantees, wallets should not generate
+unified addresses that contain internal receivers, nor expose internal receivers
+(such as those used for auto-shielding and change outputs) in any way.
+
+Open questions:
+
+* should there be an auto-migration option from Sapling to Orchard?
+
+str4d notes
+'''''''''''
+
+If we want to have both automatic and opportunistic shielding, and keep the two
+indistinguishable, then we can't auto-shield when the transparent balance reaches
+some threshold (otherwise opportunistic would either never be used, or would be
+identifiable when it uses the balance below the threshold).
+
+Instead, a proposition: we define a distribution of "time since last payment to the
+address" from which we sample the time at which the auto-shielding transaction will
+be created. This distribution is weighted by the balance in the address, so as more
+funds accrue, the auto-shielding transaction is more likely to be created.
+
+- It ensures that all funds will eventually be auto-shielded, while preventing
+  fee-dusting attacks (where dust is sent in order to repeatedly consume fees from
+  the wallet), as the auto-shielding transaction is not directly triggered by payment
+  receipt.
+
+- If the user makes a shielding transaction in the meantime, we opportunistically
+  shield, without it being clearly not an auto-shielding transaction.
+
+- If a wallet is offline for a long time, then it would likely auto-shield as soon as
+  it finishes syncing. This maybe isn't enough to reveal that the wallet came online,
+  except that it _might_ result in auto-shielding transactions for multiple
+  transparent addresses being created at the same time. So we might want to
+  special-case this?
+
+Properties we want from auto-shielding:
+
+- Auto-shielding transactions MUST NOT shield from multiple transparent receivers in
+  the same transaction.
+  - Doing so would trivially link diversified UAs containing transparent receivers.
+
+Properties we want from auto-migration:
+
+- Receipt of a shielded payment MUST NOT trigger any on-chain behaviour (as that
+  reveals transaction linkability).
+
+Both auto-shielding and auto-migration are time-triggered actions, not
+receipt-triggered actions. An auto-shielding or auto-migration transaction MUST NOT
+be created as a direct result of a payment being received.
+
+Both of these are opportunistic: if the user's wallet is making a transaction in
+which one of these actions would occur anyway, then the wallet takes the opportunity
+to migrate as much as it would do if it were generating an autoshielding transaction.
+This both saves on a transaction, and removes the need for any kind of transparent
+change address within UAs.
+
+TODO: what pool should change go to?
+
+* Proposal: the most recent pool already involved in the transaction.
+
+Wallet Recovery
+---------------
+
+In the case where we are recovering a wallet from a backed-up mnemonic phrase,
+and not from a wallet.dat, we don't have enough information to figure out what
+receiver types the user originally used when deriving each UA under an account.
+We have a similar issue if someone exports a UFVK, derives an address from it,
+and has a payment sent to the address: zcashd will detect the payment, but has
+no way to figure out what address it should display in the UI. A wallet could
+store this information in the memo field of change outputs, but that adds a
+bunch of coordination to the problem, and assumes ongoing on-chain state
+storage.
+
+- If the receiver matches an address that the wallet knows was derived via
+  ``z_getaddressforaccount``, show that UA as expected (matching the receiver
+  types the user selected).
+- If the receiver matches a UFVK in the wallet, and we are looking it up
+  because we detected a received note in some block, show the UA with the
+  default receiver types that zcashd was using as of that block height
+  (ideally the earliest block height we detect), and cache this for future
+  usage.
+- For zcashd's current policy of "best and second-best shielded pools, plus
+  transparent pool", that would mean Orchard, Sapling, and transparent for
+  current block heights.
+- For each release of a wallet, the wallet should specify a set of receiver
+  types and an associated range of block heights during which the wallet
+  will, by default, generate unified addresses using that set of receiver
+  types.
+- For zcashd we know how the policy evolves because each zcashd release has
+  an approximate release height and End-of-Service height that defines the window.
+- Subsequent releases of a wallet SHOULD NOT retroactively change their
+  policies for previously defined block height ranges.
+- If the receiver type for a note received at a given time is not a member
+  of the set of receiver types expected for the range of block heights, the
+  policy corresponding to the nearest block height range that includes that
+  receiver type SHOULD be used.
+- If the receiver matches a UFVK in the wallet, and we have no information
+  about when this receiver may have been first used, show the UA
+  corresponding to the most recent receiver types policy that includes the
+  receiver's type.
+- As part of this, we're also going to change the "Sapling receiver to
+  UfvkId" logic to trial-decrypt after trying internal map, so that we will
+  detect all receivers linked to UFVKs in the wallet, not just receivers in
+  addresses generated via z_getaddressforaccount. The internal map lookup
+  is then just an optimisation (and a future refactor to have Orchard do
+  the same is possible, but for now we will only trial-decrypt so we don't
+  need to refactor to access the Rust wallet). TODO: express this in a less
+  zcashd-specific way.
+
+TODO: Mention recommendations (not requirements) of receiver types based on
+settled ('accepted') network upgrades, as defined in §3.3 of the
+Zcash Protocol Specification, at the time of the release of the wallet.
+
+TODO: Rationale subsection explaining why earliest block height at detection
+and the rules/recommendations in place at that block height are preferred
+over showing different UAs at different heights
+
+References
+==========
+
+.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_
+.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_
+.. [#zip-0203] `ZIP 203: Transaction Expiry `_
+.. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_
+.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism `_
+.. [#zip-0320] `ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses `_
diff --git a/zip-0316-f3.svg b/zips/zip-0316-f3.svg
similarity index 100%
rename from zip-0316-f3.svg
rename to zips/zip-0316-f3.svg
diff --git a/zip-0316-f4.svg b/zips/zip-0316-f4.svg
similarity index 100%
rename from zip-0316-f4.svg
rename to zips/zip-0316-f4.svg
diff --git a/zip-0316.rst b/zips/zip-0316.rst
similarity index 73%
rename from zip-0316.rst
rename to zips/zip-0316.rst
index 19f6d13b5..91b6c4123 100644
--- a/zip-0316.rst
+++ b/zips/zip-0316.rst
@@ -2,16 +2,16 @@
 
   ZIP: 316
   Title: Unified Addresses and Unified Viewing Keys
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Nathan Wilcox 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
-          Greg Pfeil 
+  Original-Authors: Greg Pfeil
+                    Ying Tong Lai
   Credits: Taylor Hornby
-           Ying Tong Lai
            Stephen Smith
-  Status: Final
+  Status: Revision 0: Final, Revision 1: Proposed
   Category: Standards / RPC / Wallet
   Created: 2021-04-07
   License: MIT
@@ -21,9 +21,9 @@
 Terminology
 ===========
 
-The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are
-to be interpreted as described in BCP 14 [#BCP14]_ when, and only when, they
-appear in all capitals.
+The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this
+document are to be interpreted as described in BCP 14 [#BCP14]_ when, and only
+when, they appear in all capitals.
 
 The terms below are to be interpreted as follows:
 
@@ -38,8 +38,8 @@ Consumer
   that it is given.
 Sender
   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.
+  side effects to consensus state that may be defined in future. Senders are a
+  subset of Consumers.
 Receiver
   The necessary information to transfer an asset to a Recipient that generated
   that Receiver using a specific Transfer Protocol. Each Receiver is associated
@@ -90,6 +90,9 @@ Unified QR Encoding
 Address Encoding
   The externally visible encoding of an Address (e.g. as a string of
   characters or a QR code).
+Unix Epoch Time
+  An integer representing a UTC time in seconds relative to the Unix Epoch
+  of 1970-01-01T00:00:00Z.
 
 Notation for sequences, conversions, and arithmetic operations follows the
 Zcash protocol specification [#protocol-notation]_.
@@ -215,9 +218,9 @@ Receivers
 ---------
 
 Every wallet must properly *parse* encodings of a Unified Address or
-Unified Viewing Key containing unrecognized Items.
+Unified Viewing Key containing unrecognised Items.
 
-A wallet may process unrecognized Items by indicating to the user their
+A wallet may process unrecognised Items by indicating to the user their
 presence or similar information for usability or diagnostic purposes.
 
 Transport Encoding
@@ -244,7 +247,7 @@ The encoding must support sufficiently many Recipient Types to allow
 for reasonable future expansion.
 
 The encoding must allow all wallets to safely and correctly parse out
-unrecognized Receiver Types well enough to ignore them.
+unrecognised Receiver Types well enough to ignore them.
 
 Transfers
 ---------
@@ -252,7 +255,7 @@ Transfers
 When executing a Transfer the Sender selects a Receiver via a Selection
 process.
 
-Given a valid UA, Selection must treat any unrecognized Item as though
+Given a valid UA, Selection must treat any unrecognised Item as though
 it were absent.
 
 - This property is crucial for forward compatibility to ensure users
@@ -281,7 +284,7 @@ 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]_.
+as described in the Zcash Protocol Specification [#protocol]_.
 
 For a Transparent P2PKH Address that is derived according to BIP 32
 [#bip-0032]_ and BIP 44 [#bip-0044]_, the nearest equivalent to a
@@ -300,10 +303,52 @@ Open Issues and Known Concerns
 Privacy impacts of transparent or cross-pool transactions, and the
 associated UX issues, will be addressed in ZIP 315 (in preparation).
 
-
 Specification
 =============
 
+Revisions
+---------
+
+.. _`Revision 0`:
+
+* Revision 0: The initial version of this specification.
+
+.. _`Revision 1`:
+
+* Revision 1: This version adds support for `MUST-understand Typecodes`_
+  and `Address Expiration Metadata`_. It also drops the restriction that
+  a UA/UVK must contain at least one shielded Item.
+
+A Revision 0 UA/UVK is distinguished from a Revision 1 UA/UVK by its
+Human-Readable Part, as follows.
+
+Let *prefix* be:
+
+* “``u``”, if this is a UA/UVK prior to `Revision 1`_;
+* “``ur``”, if this is a UA/UVK from `Revision 1`_ onward.
+
+The Human-Readable Parts (as defined in [#bip-0350]_) of Unified
+Addresses are defined as:
+
+* *prefix*, for Unified Addresses on Mainnet;
+* *prefix* || “``test``”, for Unified Addresses on Testnet.
+
+The Human-Readable Parts of Unified Viewing Keys are defined as:
+
+* *prefix* || “``ivk``” for Unified Incoming Viewing Keys on Mainnet;
+* *prefix* || “``ivktest``” for Unified Incoming Viewing Keys on Testnet;
+* *prefix* || “``view``” for Unified Full Viewing Keys on Mainnet;
+* *prefix* || “``viewtest``” for Unified Full Viewing Keys on Testnet.
+
+While support for Revision 1 UAs/UVKs is still being rolled out across
+the Zcash ecosystem, a Producer can maximize interoperability by
+generating a Revision 0 UA/UVK in cases where the conditions on its
+use are met (i.e. there are no MUST-understand Metadata Items, and at
+least one shielded item). At some point when Revision 1 UA/UVKs are
+widely supported, this will be unnecessary and it will be sufficient
+to always produce Revision 1 UA/UVKs.
+
+
 Encoding of Unified Addresses
 -----------------------------
 
@@ -348,7 +393,7 @@ 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, in ascending order of Typecode:
+of the constituent Receivers, in ascending order of Typecode:
 
 * :math:`\mathtt{typecode} : \mathtt{compactSize}` — the Typecode from the
   above Priority List;
@@ -390,9 +435,8 @@ procedure:
 * Parse the result as a raw encoding as described above, rejecting the
   entire Unified Address if it 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``”.
+The Human-Readable Part is as specified for a Unified Address in
+`Revisions`_.
 
 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
@@ -420,7 +464,7 @@ The following FVK or IVK Encodings are used in place of the
 :math:`\mathtt{addr}` field:
 
 * An Orchard FVK or IVK Encoding, with Typecode :math:`\mathtt{0x03},` is
-  is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming
+  the raw encoding of the Orchard Full Viewing Key or Orchard Incoming
   Viewing Key respectively.
 
 * A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is the
@@ -438,7 +482,7 @@ The following FVK or IVK Encodings are used in place of the
   P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be
   diversified in an unlinkable way). The Typecode :math:`\mathtt{0x01}`
   MUST NOT be included in a UFVK or UIVK by Producers, and MUST be
-  treated as unrecognized by Consumers.
+  treated as unrecognised by Consumers.
 
 * For Transparent P2PKH Addresses that are derived according to BIP 32
   [#bip-0032]_ and BIP 44 [#bip-0044]_, the FVK and IVK Encodings have
@@ -452,13 +496,8 @@ The following FVK or IVK Encodings are used in place of the
   external (non-change) child key at the Change level, i.e. at path
   :math:`m / 44' / coin\_type' / account' / 0`.
 
-The Human-Readable Parts (as defined in [#bip-0350]_) of Unified Viewing
-Keys are defined as follows:
-
-* “``uivk``” for Unified Incoming Viewing Keys on Mainnet;
-* “``uivktest``” for Unified Incoming Viewing Keys on Testnet;
-* “``uview``” for Unified Full Viewing Keys on Mainnet;
-* “``uviewtest``” for Unified Full Viewing Keys on Testnet.
+The Human-Readable Part is as specified for a Unified Viewing Key in
+`Revisions`_.
 
 Rationale for address derivation
 ''''''''''''''''''''''''''''''''
@@ -485,12 +524,10 @@ and this should be taken into account in the design of such Items.
 Requirements for both Unified Addresses and Unified Viewing Keys
 ----------------------------------------------------------------
 
-* A Unified Address or Unified Viewing Key MUST contain at least one
-  shielded Item (Typecodes :math:`\mathtt{0x02}` and :math:`\mathtt{0x03}`).
-  The rationale is that the existing P2SH and P2PKH transparent-only
-  address formats, and the existing P2PKH extended public key format,
-  suffice for representing transparent Items and are already supported
-  by the existing ecosystem.
+* A `Revision 0`_ Unified Address or Unified Viewing Key MUST contain
+  at least one shielded Item (Typecodes :math:`\mathtt{0x02}` and
+  :math:`\mathtt{0x03}`). This requirement is dropped for `Revision 1`_
+  UA/UVKs.
 
 * The :math:`\mathtt{typecode}` and :math:`\mathtt{length}` fields are
   encoded as :math:`\mathtt{compactSize}.` [#Bitcoin-CompactSize]_
@@ -511,8 +548,8 @@ Requirements for both Unified Addresses and Unified Viewing Keys
   upgrade [#zip-0211]_) to send funds into the Sprout chain value
   pool, this would not be generally useful.
 
-* Consumers MUST ignore constituent Items with Typecodes they do not
-  recognize.
+* With the exception of MUST-understand Metadata Items, Consumers
+  MUST ignore constituent Items with Typecodes they do not recognise.
 
 * Consumers MUST reject Unified Addresses/Viewing Keys in which the
   same Typecode appears more than once, or that include both P2SH and
@@ -522,7 +559,7 @@ Requirements for both Unified Addresses and Unified Viewing Keys
 * Consumers MUST reject Unified Addresses/Viewing Keys in which *any*
   constituent Item does not meet the validation requirements of its
   encoding, as specified in this ZIP and the Zcash Protocol Specification
-  [#protocol-nu5]_.
+  [#protocol]_.
 
 * Consumers MUST reject Unified Addresses/Viewing Keys in which the
   constituent Items are not ordered in ascending Typecode order. Note
@@ -536,6 +573,29 @@ Requirements for both Unified Addresses and Unified Viewing Keys
   in an abridged form due to lack of space, at least the first 20
   characters MUST be included.
 
+Rationale for dropping the "at least one shielded Item" restriction
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+.. raw:: html
+
+   
      
+   Click to show/hide
+
+The original rationale for this restriction was that the existing P2SH
+and P2PKH transparent-only address formats, and the existing P2PKH
+extended public key format, sufficed for representing transparent Items
+and were already supported by the existing ecosystem.
+
+However, as of `Revision 1`_ there are uses for transparent-only UAs
+and UVKs that are not covered by the existing formats. In particular,
+they can use Metadata Items to represent expiration heights/dates as
+described in `Address Expiration Metadata`_, or source restrictions as
+proposed in ZIP 320 [#zip-0320]_.
+
+.. raw:: html
+
+   
      
+
 Rationale for Item ordering
 '''''''''''''''''''''''''''
 
@@ -547,7 +607,7 @@ Rationale for Item ordering
 The rationale for requiring Items to be canonically ordered by Typecode
 is that it enables implementations to use an in-memory representation
 that discards ordering, while retaining the same round-trip serialization
-of a UA / UVK (provided that unrecognized Items are retained).
+of a UA/UVK (provided that unrecognised Items are retained).
 
 .. raw:: html
 
@@ -599,20 +659,151 @@ to give access only to view incoming payments (as opposed to change).
 Metadata Items
 --------------
 
-Typecodes :math:`\mathtt{0xE0}` to :math:`\mathtt{0xFC}` inclusive
+Typecodes :math:`\mathtt{0xC0}` to :math:`\mathtt{0xFC}` inclusive
 are reserved to indicate Metadata Items other than Receivers or
 Viewing Keys. These Items MAY affect the overall interpretation of
-the UA / UVK (for example, by specifying an expiration date).
+the UA/UVK (for example, by specifying an expiration date).
+
+.. _`MUST-understand Typecodes`:
+
+As of `Revision 1`_ of this ZIP, the subset of Metadata Typecodes in
+the range :math:`\mathtt{0xE0}` to :math:`\mathtt{0xFC}` inclusive are
+designated as "MUST-understand": if a Consumer is unable to recognise
+the meaning of a Metadata Item with a Typecode in this range, then it
+MUST regard the entire UA/UVK as unsupported and not process it further.
+
+A `Revision 0`_ UA/UVK (determined by its HRP as specified in
+`Revisions`_) MUST NOT include any Metadata Items with a MUST-understand
+Typecode; a Consumer MUST reject as invalid any UA/UVK that violates
+this requirement.
 
 Since Metadata Items are not Receivers, they MUST NOT be selected by
 a Sender when choosing a Receiver to send to, and since they are not
 Viewing Keys, they MUST NOT provide additional authority to view
 information about transactions.
 
-Currently no Metadata Types are defined. New Metadata Types SHOULD be
-introduced either by a modification to this ZIP or by a new ZIP, in
-accordance with the ZIP Process [#zip-0000]_.
+New Metadata Types SHOULD be introduced either by a modification to this
+ZIP or by a new ZIP, in accordance with the ZIP Process [#zip-0000]_.
+
+Rationale for making Revision 0 UA/UVKs with MUST-understand Typecodes invalid
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 
+.. raw:: html
+
+   
      
+   Click to show/hide
+
+A Consumer implementing this ZIP prior to `Revision 1`_ will not
+recognise the Human-Readable Parts beginning with “``ur``” that mark a
+`Revision 1`_ UA/UVK. So if a UA/UVK that includes MUST-understand
+Typecodes is required to use these `Revision 1`_ HRPs, this will ensure
+that the MUST-understand specification is correctly enforced even for
+such implementations.
+
+.. raw:: html
+
+   
      
+
+
+Address Expiration Metadata
+---------------------------
+
+As of `Revision 1`_, Typecodes :math:`\mathtt{0xE0}` and :math:`\mathtt{0xE1}`
+are reserved for optional address expiry metadata. A producer MAY choose to
+generate Unified Addresses containing either or both of the following Metadata
+Item Types, or none.
+
+The value of a :math:`\mathtt{0xE0}` item MUST be an unsigned 32-bit integer in
+little-endian order specifying the Address Expiry Height, a block height of the
+Zcash chain associated with the UA/UVK. A Unified Address containing metadata
+Typecode :math:`\mathtt{0xE0}` MUST be considered expired when the height of
+the Zcash chain is greater than this value.
+
+The value of a :math:`\mathtt{0xE1}` item MUST be an unsigned 64-bit integer in
+little-endian order specifying a Unix Epoch Time, hereafter referred to as the
+Address Expiry Time. A Unified Address containing Metadata Typecode
+:math:`\mathtt{0xE1}` MUST be considered expired when the current time is
+after the Address Expiry Time.
+
+A Sender that supports `Revision 1`_ of this specification MUST set
+a non-zero ``nExpiryHeight`` field in transactions it creates that are
+sent to a Unified Address that defines an Address Expiry Height. If the
+``nExpiryHeight`` normally constructed by the Sender would be greater than the
+Address Expiry Height, then the transaction MUST NOT be sent. If only an
+Address Expiry Time is specified, then the Sender SHOULD choose a value for
+``nExpiryHeight`` such that the transaction will expire no more than 24 hours
+after the current time. If both :math:`\mathtt{0xE0}` and :math:`\mathtt{0xE1}`
+Metadata Items are present, then both restrictions apply.
+
+If a Sender sends to multiple Unified Addresses in the same transaction, then
+all of the Address Expiry constraints imposed by the individual addresses apply.
+
+If a wallet user attempts to send to an expired address, the error presented
+to the user by the wallet SHOULD include a suggestion that the user should
+attempt to obtain a currently-valid address for the intended recipient. A
+wallet MUST NOT send to an address that it knows to have expired.
+
+Address expiration imposes no constraints on the Producer of an address. A
+Producer MAY generate multiple Unified Addresses with the same Receivers but
+different expiration metadata and/or any number of distinct Diversified Unified
+Addresses with the same or different expiry metadata, in any combination. Note
+that although changes to metadata will result in a visually distinct address,
+such updated addresses will be directly linkable to the original addresses
+because they share the same Receivers.
+
+When deriving a UIVK from a UFVK containing Typecodes :math:`\mathtt{0xE0}`
+and/or :math:`\mathtt{0xE1}`, these Metadata Items MUST be retained unmodified
+in the derived UIVK.
+
+When deriving a Unified Address from a UFVK or UIVK containing a Metadata Item
+having Typecode :math:`\mathtt{0xE0}`, the derived Unified Address MUST contain
+a Metadata Item having Typecode :math:`\mathtt{0xE0}` such that the Address
+Expiry Height of the resulting address is less than or equal to the Expiry Height
+of the viewing key.
+
+When deriving a Unified Address from a UFVK or UIVK containing a Metadata Item
+having Typecode :math:`\mathtt{0xE1}`, the derived Unified Address MUST contain
+a Metadata Item having Typecode :math:`\mathtt{0xE1}` such that the Address
+Expiry Time of the resulting address is less than or equal to the Expiry Time
+of the viewing key.
+
+Producers of Diversified Unified Addresses should be aware that the expiration
+metadata could potentially be used to link addresses from the same source.
+Normally, if Diversified Unified Addresses derived from the same UIVK contain
+only Sapling and/or Orchard Receivers and no Metadata Items, they will be
+unlinkable as described in [#protocol-concretediversifyhash]_; this property
+does not hold when Metadata Items are present. It is RECOMMENDED that when
+deriving Unified Addresses from a UFVK or UIVK containing expiry metadata that
+the Expiry Height and Expiry Time of each distinct address vary from one
+another, so as to reduce the likelihood that addresses may be linked via their
+expiry metadata.
+
+Rationale
+'''''''''
+
+The intent of this specification is that Consumers of Unified Addresses must
+not send to expired addresses. If only an Address Expiry Time is specified, a
+transaction to the associated address could be mined after the Address Expiry
+Time within a 24-hour window.
+
+The reason that the transaction MUST NOT be sent when its ``nExpiryHeight`` as
+normally constructed is greater than the Address Expiry Height is to avoid
+unnecessary information leakage in that field about which address was used as
+the destination. If a sender were to instead use the expiry height to directly
+set the ``nExpiryHeight`` field, this would leak the expiry information of the
+destination address, which may then be identifiable.
+
+When honoring an Address Expiry Time, the reason that a sender SHOULD choose a
+``nExpiryHeight`` that is expected to occur within 24 hours of the time of
+transaction construction is to, when possible, ensure that the expiry time is
+respected to within a day. Address Expiry Times are advisory and do not
+represent hard bounds because computer clocks often disagree, but every effort
+should be made to ensure that transactions expire instead of being mined more
+than 24 hours after a recipient address's expiry time. When chain height
+information is available to the Sender, it is both permissible and advisable to
+set this bound more tightly; a common expiry delta used by many wallets is 40
+blocks from the current chain tip, as suggested in ZIP 203
+[#zip-0203-default-expiry]_.
 
 Deriving Internal Keys
 ----------------------
@@ -664,6 +855,19 @@ Change level is non-hardened.
 Deriving a UIVK from a UFVK
 ---------------------------
 
+As a consequence of the specification in `MUST-understand Typecodes`_,
+as of `Revision 1`_ a Consumer of a UFVK MUST understand the meaning of
+all "MUST-understand" Metadata Item Typecodes present in the UFVK in
+order to derive a UIVK from it.
+
+If the source UFVK is Revision 1 then the derived UIVK SHOULD be
+Revision 1; if the source UFVK includes any Metadata Items then
+the derived UIVK MUST be Revision 1.
+
+For Metadata Items recognised by the Consumer, the processing of the
+Item when deriving a UIVK is specified in the section or ZIP describing
+that Item.
+
 The following derivations are applied to each component FVK:
 
 * For a Sapling FVK, the corresponding Sapling IVK is obtained as
@@ -678,15 +882,27 @@ The following derivations are applied to each component FVK:
 
 In each case, the Typecode remains the same as in the FVK.
 
-Items (including Metadata Items) that are unrecognized by a given
-Consumer, or that are specified in experiments that the user has not
-opted into (see `Experimental Usage`_), MUST be dropped when deriving
-a UIVK from a UFVK.
-
+Items (including Metadata Items that are not "MUST-understand") that
+are unrecognised by a given Consumer, or that are specified in experiments
+that the user has not opted into (see `Experimental Usage`_), MUST be
+dropped when the Consumer derives a UIVK from a UFVK.
 
 Deriving a Unified Address from a UIVK
 --------------------------------------
 
+As a consequence of the specification in `MUST-understand Typecodes`_,
+as of `Revision 1`_ a Consumer of a UIVK MUST understand the meaning of
+all "MUST-understand" Metadata Item Typecodes present in the UIVK in
+order to derive a Unified Address from it.
+
+If the source UIVK is Revision 1 then the derived Unified Address
+SHOULD be Revision 1; if the source UIVK includes any Metadata Items
+then the derived Unified Address MUST be Revision 1.
+
+For Metadata Items recognised by the Consumer, the processing of the
+Item when deriving a Unified Address is specified in the section or
+ZIP describing that Item.
+
 To derive a Unified Address from a UIVK we need to choose a diversifier
 index, which MUST be valid for all of the Viewing Key Types in the
 UIVK. That is,
@@ -721,11 +937,13 @@ diversifier index:
 
 In each case, the Typecode remains the same as in the IVK.
 
-Items (including Metadata Items) that are unrecognized by a given
-Consumer, or that are specified in experiments that the user has not
-opted into (see `Experimental Usage`_), MUST be dropped when deriving
-a Receiver from a UIVK.
+Items (including Metadata Items that are not "MUST-understand") that
+are unrecognised by a given Consumer, or that are specified in experiments
+that the user has not opted into (see `Experimental Usage`_), MUST be
+dropped when the Consumer derives a Unified Address from a UIVK.
 
+See `Address Expiration Metadata`_ for discussion of potential linking of
+Diversified Unified Addresses via their metadata.
 
 Usage of Outgoing Viewing Keys
 ------------------------------
@@ -817,12 +1035,12 @@ possible to improve on this attack by making use of properties of checksums,
 etc.
 
 The generic attack puts an upper bound on the achievable security: if it takes
-work :math:`w` to produce and verify a UA / UVK, and the size of the character
+work :math:`w` to produce and verify a UA/UVK, and the size of the character
 set is :math:`c,` then the generic attack costs :math:`\sim \frac{w \cdot
 c^{n+m}}{q}.`
 
 There is also a generic brute force attack against nonmalleability. The
-adversary modifies the target UA / UVK slightly and computes the corresponding
+adversary modifies the target UA/UVK slightly and computes the corresponding
 decoding, then repeats until the decoding is valid and also useful to the
 adversary (e.g. it would lead to the Sender using a Transparent Address).
 With :math:`w` defined as above, the cost is :math:`w/p` where :math:`p` is
@@ -870,7 +1088,7 @@ concatenation of
 :math:`\mathsf{I2LEOSP}_{16}(j), u) \text{ for } j \text{ from}`
 :math:`0 \text{ up to } \mathsf{ceiling}(\ell_R/\ell_H)-1].`
 
-.. figure:: zip-0316-f4.png
+.. figure:: ../rendered/assets/images/zip-0316-f4.png
     :width: 372px
     :align: center
     :figclass: align-center
@@ -890,23 +1108,57 @@ zero bytes, to the raw encoding, then applies :math:`\mathsf{F4Jumble}`
 before encoding the result with Bech32m.
 
 The Consumer rejects any Bech32m-decoded byte sequence that is less than
-48 bytes or greater than :math:`\ell^\mathsf{MAX}_M` bytes; otherwise it
+38 bytes or greater than :math:`\ell^\mathsf{MAX}_M` bytes; otherwise it
 applies :math:`\mathsf{F4Jumble}^{-1}.` It rejects any result that does
 not end in the expected 16-byte padding, before stripping these 16 bytes
 and parsing the result.
 
-(48 bytes allows for the minimum size of a shielded UA, UFVK, or UIVK Item
-encoding to be 32 bytes, taking into account 16 bytes of padding. Although
-there is currently no shielded Item encoding that short, it is plausible
-that one might be added in future. :math:`\ell^\mathsf{MAX}_M` bytes is
-the largest input/output size supported by :math:`\mathsf{F4Jumble}.`)
+Rationale for length restrictions
+'''''''''''''''''''''''''''''''''
+
+.. raw:: html
+
+   
      
+   Click to show/hide
+
+A minimum input length to :math:`\mathsf{F4Jumble}^{-1}` of 38 bytes
+allows for the minimum size of a UA/UVK Item encoding to be 22 bytes
+including the typecode and length, taking into account 16 bytes of padding.
+This allows for a UA containing only a Transparent P2PKH Receiver:
+
+* Transparent P2PKH Receiver Item:
+
+  * 1-byte typecode
+  * 1-byte encoding of length
+  * 20-byte transparent address hash
+
+:math:`\ell^\mathsf{MAX}_M` bytes is the largest input/output size
+supported by :math:`\mathsf{F4Jumble}.`
+
+Allowing only a Transparent P2PKH Receiver is consistent with dropping
+the requirement to have at least one shielded Item in Revision 1 UA/UVKs
+(`see rationale <#rationale-for-dropping-the-at-least-one-shielded-item-restriction>`_).
+
+Note that Revision 0 of this ZIP specified a minimum input length to
+:math:`\mathsf{F4Jumble}^{-1}` of 48 bytes. Since there were no sets
+of UA/UVK Item Encodings valid in Revision 0 to which a byte sequence
+(after removal of the 16-byte padding) of length between 22 and 31 bytes
+inclusive could be parsed, the difference between the 38 and 48-byte
+restrictions is not observable, other than potentially affecting which
+error is reported. A Consumer supporting Revision 1 of this specification
+MAY therefore apply either the 48-byte or 38-byte minimum to Revision 0
+UA/UVKs.
+
+.. raw:: html
+
+   
      
 
 Heuristic analysis
 ''''''''''''''''''
 
 A 3-round unkeyed Feistel, as shown, is not sufficient:
 
-.. figure:: zip-0316-f3.png
+.. figure:: ../rendered/assets/images/zip-0316-f3.png
     :width: 372px
     :align: center
     :figclass: align-center
@@ -941,7 +1193,7 @@ 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 24 bytes.
+Note that the size of each piece is at least 19 bytes.
 
 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
@@ -1013,9 +1265,13 @@ similarly structured 4-round unbalanced Feistel cipher.
 Reference implementation
 ========================
 
+Revision 0:
 * https://github.com/zcash/librustzcash/pull/352
 * https://github.com/zcash/librustzcash/pull/416
 
+Revision 1:
+* https://github.com/zcash/librustzcash/pull/1135
+
 
 Acknowledgements
 ================
@@ -1030,17 +1286,18 @@ References
 ==========
 
 .. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_
-.. [#protocol-nu5] `Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal] `_
-.. [#protocol-notation] `Zcash Protocol Specification, Version 2022.2.19. Section 2: Notation `_
-.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components `_
-.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components `_
-.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2022.2.19. Section 4.7.2: Sending Notes (Sapling) `_
-.. [#protocol-orchardsend] `Zcash Protocol Specification, Version 2022.2.19. Section 4.7.3: Sending Notes (Orchard) `_
-.. [#protocol-addressandkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6: Encodings of Addresses and Keys `_
-.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.1: Sapling Payment Addresses `_
-.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.2: Orchard Raw Payment Addresses `_
-.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys `_
-.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing Keys `_
+.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later `_
+.. [#protocol-notation] `Zcash Protocol Specification, Version 2023.4.0. Section 2: Notation `_
+.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2023.4.0. Section 4.2.2: Sapling Key Components `_
+.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2023.4.0. Section 4.2.3: Orchard Key Components `_
+.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2023.4.0. Section 4.7.2: Sending Notes (Sapling) `_
+.. [#protocol-orchardsend] `Zcash Protocol Specification, Version 2023.4.0. Section 4.7.3: Sending Notes (Orchard) `_
+.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2023.4.0. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions `_
+.. [#protocol-addressandkeyencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6: Encodings of Addresses and Keys `_
+.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.3.1: Sapling Payment Addresses `_
+.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.2: Orchard Raw Payment Addresses `_
+.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys `_
+.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.4: Orchard Raw Full Viewing Keys `_
 .. [#zip-0000] `ZIP 0: ZIP Process `_
 .. [#zip-0032-sapling-helper-functions] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions `_
 .. [#zip-0032-sapling-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys `_
@@ -1051,9 +1308,11 @@ References
 .. [#zip-0032-specification-wallet-usage] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Specification: Wallet usage `_
 .. [#zip-0032-sapling-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path `_
 .. [#zip-0032-orchard-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path `_
+.. [#zip-0203-default-expiry] `ZIP 203: Transaction Expiry — Changes for Blossom `_
 .. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool `_
 .. [#zip-0224] `ZIP 224: Orchard Shielded Protocol `_
 .. [#zip-0315] `ZIP 315: Best Practices for Wallet Handling of Multiple Pools `_
+.. [#zip-0320] `ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses `_
 .. [#zip-0321] `ZIP 321: Payment Request URIs `_
 .. [#bip-0032] `BIP 32: Hierarchical Deterministic Wallets `_
 .. [#bip-0032-serialization-format] `BIP 32: Hierarchical Deterministic Wallets — Serialization Format `_
diff --git a/zip-0317.rst b/zips/zip-0317.rst
similarity index 99%
rename from zip-0317.rst
rename to zips/zip-0317.rst
index 54dfce0ef..4bb9986d1 100644
--- a/zip-0317.rst
+++ b/zips/zip-0317.rst
@@ -3,7 +3,7 @@
   ZIP: 317
   Title: Proportional Transfer Fee Mechanism
   Owners: Aditya Bharadwaj 
-          Daira Hopwood 
+          Daira-Emma Hopwood 
   Credits: Madars Virza
            Kris Nuttycombe
            Jack Grigg
@@ -29,7 +29,7 @@ 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.
 
-The terms "Mainnet, "Testnet", and "zatoshi" in this document are defined
+The terms "Mainnet", "Testnet", and "zatoshi" in this document are defined
 as in [#protocol-networks]_.
 
 
diff --git a/zip-0318.rst b/zips/zip-0318.rst
similarity index 81%
rename from zip-0318.rst
rename to zips/zip-0318.rst
index a7d0c24a7..02a3c3aba 100644
--- a/zip-0318.rst
+++ b/zips/zip-0318.rst
@@ -3,7 +3,7 @@
   ZIP: 318
   Title: Associated Payload Encryption
   Owners: Kris Nuttycombe 
-          Daira Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Standards Track
   Created: 2022-09-19
diff --git a/zip-0319.rst b/zips/zip-0319.rst
similarity index 81%
rename from zip-0319.rst
rename to zips/zip-0319.rst
index c58034365..da5134ecf 100644
--- a/zip-0319.rst
+++ b/zips/zip-0319.rst
@@ -3,7 +3,7 @@
   ZIP: 319
   Title: Options for Shielded Pool Retirement
   Owners: Nathan Wilcox 
-          Daira Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Informational
   Created: 2022-09-20
diff --git a/zips/zip-0320.rst b/zips/zip-0320.rst
new file mode 100644
index 000000000..19d4e4968
--- /dev/null
+++ b/zips/zip-0320.rst
@@ -0,0 +1,258 @@
+::
+
+  ZIP: 320
+  Title: Defining an Address Type to which funds can only be sent from Transparent Addresses
+  Owners: Daira-Emma Hopwood 
+          Kris Nuttycombe 
+  Credits: Hanh
+  Status: Proposed
+  Category: Standards / Wallet
+  Created: 2024-01-12
+  License: MIT
+  Discussions-To: 
+                  
+  Pull-Request: 
+                
+                
+
+
+Terminology
+===========
+
+The key words "MUST", "SHOULD", "NOT RECOMMENDED", and "MAY" in this document
+are to be interpreted as described in BCP 14 [#BCP14]_ when, and only when,
+they appear in all capitals.
+
+The terms "Recipient", "Producer", "Consumer", "Sender", "Receiver", "Address",
+and "Unified Address" are to be interpreted as described in ZIP 316
+[#zip-0316-terminology]_.
+
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section
+3.12 of the Zcash Protocol Specification [#protocol-networks]_.
+
+
+Abstract
+========
+
+This ZIP defines a new encoding for transparent Zcash addresses. Wallets must
+ensure that no shielded notes are spent in transactions that send to a
+transparent address encoded in the specified fashion.
+
+
+Background
+==========
+
+In November 2023, the Zcash community received notice from the Binance
+cryptocurrency exchange that Zcash was at risk of being delisted from the
+exchange unless the community could provide a mechanism by which Binance could
+refuse deposits from shielded addresses and return them to the depositor. This
+issue was raised and discussed at length in the Zcash Community forum
+[#binance-delisting]_.
+
+In the course of that discussion thread, wallet developer and community member
+@hanh [#hanh-profile]_ suggested a wallet-oriented approach [#hanh-suggestion]_
+that involved defining a new encoding for Zcash transparent P2PKH addresses. A
+Consumer of such an address, whether it be a wallet or an exchange, could
+recognize this encoding as a directive that the wallet should only spend
+transparent funds when creating an output to that address. This ZIP formalizes
+that proposal.
+
+
+Motivation
+==========
+
+The Binance cryptocurrency exchange requires that funds sent to their deposit
+addresses come from source addresses that are readily identifiable using
+on-chain information, such that if necessary funds may be rejected by sending
+them back to one of the source addresses. This ZIP is intended to standardize
+a transparent address encoding that is not yet understood by preexisting
+Consumers, in order to prevent inadvertent shielded spends when sending to such
+addresses. Then, Consumers that upgrade to support the new encoding will do so
+with the understanding that they must respect the restrictions on sources of
+funds described in this ZIP.
+
+It is not expected that other exchanges or Producers of Zcash addresses will
+generate Transparent-Source-Only Addresses unless they have a specific need to
+be able to identify the address or addresses from which a payment was funded.
+However, all Consumers of Zcash addresses should implement this specification,
+in order to promote interoperability across the Zcash ecosystem.
+
+
+Requirements
+============
+
+1. A Recipient wishing to receive funds from exclusively transparent sources
+   must be able to generate a receiving address such that only transparent
+   funds will be spent in transactions with an output to this address. The
+   purpose of this is to ensure that it is reliably possible for the Recipient
+   to send back funds received from a Sender that conforms to this ZIP.
+2. Wallets and other Consumers that have not been upgraded to recognize the new
+   address format cannot mistake the address for another address type or
+   inadvertently send shielded funds to the address.
+3. No changes to Recipient infrastructure beyond changes to address encoding
+   and decoding should be required as a consequence of this ZIP. In particular,
+   conversion between a Transparent-Source-Only Address and the corresponding
+   unrestricted transparent address should be possible using only dependencies
+   that are available to Binance's front-end code.
+
+
+Non-requirements
+================
+
+1. It is only required to support a Transparent-Source-Only form of P2PKH
+   addresses; P2SH address support is not necessary.
+2. It is not required to limit the source of transparent funds sent to a
+   Transparent-Source-Only Address to a single source address. This implies that
+   if the Recipient chooses to send back the funds, it is acceptable for it to
+   send them back to any of the source addresses if there is more than one.
+3. It is not necessary for the restriction on the source of funds to be enforced
+   as a consensus rule. If a Sender fails to adhere to the restriction, it risks
+   loss of funds, which is acceptable in the case of a non-conforming Sender
+   implementation.
+
+
+Specification
+=============
+
+A TEX Address, also called a Transparent-Source-Only Address, is a Bech32m [#bip-0350]_
+reencoding of a transparent Zcash P2PKH address [#protocol-transparentaddrencoding]_.
+
+Wallets and other Senders sending to a TEX address (as any output) MUST ensure that
+only transparent (P2SH or P2PKH) UTXOs are spent in the creation of the transaction.
+For simplicity of parsing and interpreting such transactions, they also SHOULD only
+send to transparent outputs.
+
+A TEX address can be produced from a Mainnet Zcash P2PKH Address by executing the
+following steps:
+
+1. Decode the address to a byte sequence using the Base58Check decoding
+   algorithm [#Base58Check]_.
+2. If the length of the resulting byte sequence is not 22 bytes or if its two-byte
+   address prefix is not :math:`[\mathtt{0x1C}, \mathtt{0xB8}]`, return an error.
+   Otherwise, let the **validating key hash** be the remaining 20 bytes of the
+   sequence after removing the two-byte address prefix.
+3. Reencode the 20-byte **validating key hash** using the Bech32m encoding
+   defined in [#bip-0350]_ with the human-readable prefix (HRP) ``"tex"``.
+
+For Testnet addresses, the required lead bytes of a P2PKH address in step 2 are
+:math:`[\mathtt{0x1D}, \mathtt{0x25}]`, and the ``"textest"`` HRP is used when
+reencoding in step 3.
+
+A TEX address can be parsed by reversing this encoding, i.e.:
+
+1. Decode the address to a byte sequence using Bech32m [#bip-0350]_, checking
+   that the HRP is ``"tex"`` for a Mainnet TEX Address and ``"textest"`` for a
+   Testnet TEX Address.
+2. If the length of the resulting byte sequence is not 20 bytes, return an error.
+   Otherwise, the **validating key hash** is this byte sequence.
+
+Design considerations for Senders
+---------------------------------
+
+For a transaction that spends only from transparent funds to a TEX Address,
+this specification imposes no additional requirements.
+
+If, on the other hand, a user desires to spend shielded funds to a TEX Address,
+a Sender supporting this ZIP MUST create two transactions: one that unshields
+the funds to an ephemeral transparent address, and one that spends from that
+ephemeral address to the destination TEX Address. This does not defeat the
+intent of the ZIP, because it is still possible for a Recipient to return the
+funds to the Sender by sending them back to the ephemeral address.
+
+Wallets MUST be able to recognize funds that have been returned in this way
+and spend them if desired. In order for this to be possible without use of
+TEX Addresses increasing the risk of loss of funds, wallets based on ZIP 32
+[#zip-0032]_ SHOULD choose ephemeral addresses in a way that allows the
+corresponding private keys to be recovered from a ZIP 32 master seed.
+
+However, ephemeral addresses SHOULD NOT be chosen in a way that allows them
+to be linked between transactions, without knowledge of the wallet seed or
+the relevant transparent viewing keys. This also implies that they SHOULD be
+chosen in a way that avoids collisions with addresses for previously generated
+outputs (including change outputs), such as might have been created by a
+transparent-only wallet using Bitcoin-derived code based on BIP 44 [#bip-0044]_.
+
+In order to show accurate transaction history to a user, wallets SHOULD
+remember when a particular transaction output was sent to a TEX Address, so
+that they can show that form rather than its P2PKH form. It is acceptable that
+this information may be lost on recovery from seed.
+
+
+Reference Implementation
+========================
+
+Javascript::
+
+   import bs58check from 'bs58check'
+   import {bech32m} from 'bech32'
+   
+   // From t1 to tex
+   var b58decoded = bs58check.decode('t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC')
+   console.assert(b58decoded.length == 22, 'Invalid length');
+   console.assert(b58decoded[0] == 0x1C && b58decoded[1] == 0xB8, 'Invalid address prefix');
+   var pkh = b58decoded.slice(2)
+   var tex = bech32m.encode('tex', bech32m.toWords(pkh))
+   console.log(tex)
+   
+   // From tex to t1
+   var bech32decoded = bech32m.decode('tex1s2rt77ggv6q989lr49rkgzmh5slsksa9khdgte')
+   console.assert(bech32decoded.prefix == 'tex', 'Invalid address prefix')
+   var pkh2 = Uint8Array.from(bech32m.fromWords(bech32decoded.words))
+   console.assert(pkh2.length == 20, 'Invalid length');
+   var t1 = bs58check.encode(Buffer.concat([Uint8Array.from([0x1C, 0xB8]), pkh2]))
+   console.log(t1)
+
+Rationale
+=========
+
+TEX addresses are the simplest possible approach to creating a new address type that
+indicates that only transparent sources of funds should be used.
+
+As required by Binance, it will be possible to convert between a TEX address and an
+unrestricted transparent P2PKH address using extremely straightforward code that
+depends only on Base58Check and Bech32m encoding/decoding, as shown in the above
+`Reference Implementation`_.
+
+An earlier version of this ZIP also described another alternative using metadata
+in Unified Addresses, as specified in ZIP 316 [#zip-0316]_. That alternative was
+designed to enable better integration with the Zcash Unified Address ecosystem, and
+had the advantage of being able to combine different types of metadata along with
+the Transparent-Source-Only indicator, such as an expiration block height or time
+[#zip-0316-address-expiry]_ [#binance-address-expiry]_.
+
+However, ultimately the Unified Address-based approach did not meet all of the
+requirements, since it would in practice have required dependencies on address
+handling libraries that Binance did not want to depend on in their front-end code.
+
+Some design elements of that approach that apply to metadata in general have
+been incorporated into ZIP 316 Revision 1 [#zip-0316-revision-1]_. A more general
+form of Source Restriction Metadata is also under consideration.
+
+Disadvantages
+-------------
+
+A disadvantage of TEX Addresses (and also of the alternative approach using
+Unified Addresses) is that the information that a TEX Address was used does not
+appear on-chain, i.e. a transaction sending to a TEX Address is indistinguishable
+from one sending to the underlying P2PKH address. This is inevitable given the
+desire not to change the underlying consensus protocol to support this functionality.
+
+
+References
+==========
+
+.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_
+.. [#binance-delisting] `Zcash Community Forum thread "Important: Potential Binance Delisting" `_
+.. [#hanh-profile] `Zcash Community Forum user @hanh `_
+.. [#hanh-suggestion] `Ywallet developer @hanh's proposal `_
+.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_
+.. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_
+.. [#zip-0316-terminology] `ZIP 316: Unified Addresses and Unified Viewing Keys — Terminology `_
+.. [#zip-0316-revision-1] `ZIP 316: Unified Addresses and Unified Viewing Keys — Revision 1 `_
+.. [#zip-0316-address-expiry] `ZIP 316: Unified Addresses and Unified Viewing Keys — Address Expiration Metadata `_
+.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet `_
+.. [#protocol-transparentaddrencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.1.1 Transparent Addresses `_
+.. [#binance-address-expiry] `Zcash Community Forum post describing motivations for address expiry `_
+.. [#Base58Check] `Base58Check encoding — Bitcoin Wiki `_
+.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets `_
+.. [#bip-0350] `BIP 350: Bech32m format for v1+ witness addresses `_
diff --git a/zip-0321.rst b/zips/zip-0321.rst
similarity index 99%
rename from zip-0321.rst
rename to zips/zip-0321.rst
index 14f4e7ac8..42f0be20a 100644
--- a/zip-0321.rst
+++ b/zips/zip-0321.rst
@@ -2,8 +2,8 @@
 
   ZIP: 321
   Title: Payment Request URIs
-  Owners: Kris Nuttycombe (kris@electriccoin.co)
-          Daira Emma Hopwood (daira@electriccoin.co)
+  Owners: Kris Nuttycombe 
+          Daira-Emma Hopwood 
   Credits: Francisco Gindre
   Status: Proposed
   Category: Standards / Wallet
diff --git a/zip-0322.rst b/zips/zip-0322.rst
similarity index 78%
rename from zip-0322.rst
rename to zips/zip-0322.rst
index a1b26ef4f..adc37295f 100644
--- a/zip-0322.rst
+++ b/zips/zip-0322.rst
@@ -3,7 +3,7 @@
   ZIP: 322
   Title: Generic Signed Message Format
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Standards / RPC / Wallet
   Discussions-To: 
diff --git a/zip-0323.rst b/zips/zip-0323.rst
similarity index 78%
rename from zip-0323.rst
rename to zips/zip-0323.rst
index fa33921b7..5e5465e6f 100644
--- a/zip-0323.rst
+++ b/zips/zip-0323.rst
@@ -2,7 +2,7 @@
 
   ZIP: 323
   Title: Specification of getblocktemplate for Zcash
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
   Status: Reserved
   Category: RPC / Mining
diff --git a/zips/zip-0324.rst b/zips/zip-0324.rst
new file mode 100644
index 000000000..93f861e56
--- /dev/null
+++ b/zips/zip-0324.rst
@@ -0,0 +1,461 @@
+::
+
+  ZIP: 324
+  Title: URI-Encapsulated Payments
+  Owners: Jack Grigg 
+          Daira-Emma Hopwood 
+          Kris Nuttycombe 
+  Original-Authors: Ian Miers
+                    Eran Tromer
+                    Jack Grigg
+                    Kevin Gorham
+                    Daira-Emma Hopwood
+  Credits: Sean Bowe
+           Deirdre Connolly
+           Linda Naeun Lee
+           George Tankersley
+           Henry de Valence
+  Status: Draft
+  Category: Standards / Wallet
+  Created: 2019-07-17
+  License: MIT
+
+
+Terminology
+===========
+
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
+interpreted as described in BCP 14 [#BCP14]_ when, and only when, they appear in all
+capitals.
+
+Zcash protocol terms are as defined in the Zcash Protocol Specification. [#protocol]_
+
+.. _applink:
+
+By “applink” we mean a platform mechanism for triggering local applications using
+HTTPS links, such as App Links [#app-links]_ on Android, Universal Links [#universal-links]_
+on iOS, or App URI handlers [#app-uri-handlers]_ on Windows.
+
+
+Abstract
+========
+
+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.
+
+The proposal specifies the syntax and semantics of URI-Encapsulated Payments, the workflow of generating and handling them, and requisite infrastructure.
+
+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.
+
+Usage Story
+-----------
+
+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.
+
+Bob receives the message, which looks as follows:
+
+    This message contains a Zcash payment.
+    Click the following link to view it and receive the funds using your Zcash wallet app:
+
+    https://pay.withzcash.com:65536/v1#amount=1.23&desc=Payment+for+foo&key=...
+
+    If you do not yet have a Zcash wallet app, see: https://z.cash/wallets
+
+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.
+
+
+Motivation
+==========
+
+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.
+
+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.
+
+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.
+
+Additionally, the proposal greatly improves the scalability of Zcash. If a recipient only receives URI payments, they need not scan the blockchain or delegate their view keys to a third party to do so.
+
+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.
+
+The proposal is complementary to ZIP 321 [#zip-0321]_, which will standardize *Payment Request URIs* using which the payment *recipient* can convey their persistent payment address to the *sender*, for subsequent fund transfers (to be done using the normal on-chain mechanism rather than the encapsulated payments described in the current proposal).
+
+
+Requirements
+============
+
+This proposal's specification of URI-Encapsulated Payments, and the intended protocols for using them, is meant to fulfill the following requirements:
+
+* The protocol must not require the sender of a payment to stay online until the recipient receives the URI (let alone finalizes the payment).
+
+* For convenient rendering, URIs should be short; this also maximizes compatibility with length-limited messaging platforms.
+
+* It must not be feasible for someone who has not seen the URI (or has compromised a party who has) to collect the funds.
+
+* The URIs and protocol should minimize the likelihood of inadvertent misuse, and in particular the risks discussed in “Security Considerations” below.
+
+* The protocol must not leak any information (sender identity, recipient identity, amount, description) to third parties, other than inevitable metadata about the existence of a transaction, the inevitable network communication around sending/receipt of transactions, whatever leakage is induced by the communication channel used to transmit the URI, and whatever is voluntarily shared by the parties.
+
+* The URIs should allow for future modifications and expansion of the format, without risk of ambiguous parsing.
+
+* The on-chain footprint of payments that use this mechanism should be indistinguishable from normal fully-shielded transactions (except, possibly, for the statistics of the number of shielded inputs and outputs).
+
+* Don't lose funds, even if wallets crash, or everything but the sending wallet master secret is lost.
+
+Non-requirements
+================
+
+* 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.
+
+* 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).
+
+
+Specification
+=============
+
+A Payment-Encapsulating URI represents the capability to claim the Zcash funds from specific on-chain transactions, as long as they're unspent. See `Usage Story`_ for an example.
+
+Syntax
+------
+
+A Payment-Encapsulating URI is a Universal Resource Locator (URL), as defined in RFC 3986 [#RFC3986]_, of the following form.
+
+Scheme: ``https``
+
+Host: ``pay.withzcash.com``
+
+Port: ``65536`` (this is intentionally not a valid TCP/IP port number)
+
+Path: ``payment/v1``
+
+Fragment parameters: these attribute-value pairs, in this order, separated by ``&``, and with all values percent-encoded where necessary:
+
+* ``amount=...`` where the attribute is a decimal number representing the amount of ZEC included in the payment. MUST be present.
+  If a decimal fraction is present then a period (.) MUST be used as the separating character to separate the whole number from the decimal fraction, and both the whole number and the decimal fraction MUST be nonempty. No other separators (such as commas for grouping or thousands) are permitted. Leading zeros in the whole number or trailing zeros in the decimal fraction are ignored. There MUST NOT be more than 8 digits in the decimal fraction.
+* ``desc=...`` where the attribute is a human-readable string associated with the payment. MAY be present.
+  If present, it MUST be encoded as “textual data consisting of characters from the Universal Character Set” as specified in RFC 3986 section 2.5.
+* ``key=`` is a 256-bit random number encoded with Bech32 as specified in Section 5.6.9 of the Zcash Protocol Specification [#protocol]_). MUST be present.
+
+
+Semantics
+---------
+
+The values of ``key`` and ``amount`` deterministically imply a unique *payment note* 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 ``key``. The derivation of this note is done by the following procedure:
+
+*DerivePaymentNote(key,amount)*:
+
+* Derive *pk_d* from *key* via the process defined in [#protocol]_ Section 4.2.2 (setting *sk = key*).
+* Fix the diversified d = DefaultDiversifier(key).
+* Derive *rseed = PRF^expand(sk_m || [0xFIXME])* as specified in [#protocol]_ Section 5.4.2.
+* Define the corresponding *payment note* as *n = (d, pk_d, amount, rseed)*  (see [#protocol]_ Section 3.2 (https://zips.z.cash/protocol/protocol.pdf#notes)).
+
+TODO: Possible alternate way to derive pk_d and rseed from key:
+
+* Use PRF^expand on key with to-be-defined domain separation to obtain 64 bytes. Split this into two 32-byte values.
+
+  * First 32-byte value is sk; derive pk_d from this as in the spec.
+  * Second 32-byte value is rseed.
+
+* Could also mix in other parts of the URI (amount, desc) to bind them here, without interfering with the existing key derivation process in the spec.
+
+Construct a shielded zcash transaction containing that note as an output.
+
+The payment note SHOULD be unspent at the time it is intended to be received by the recipient.
+
+Clients MAY generate and send the URI before the transaction is built, sent, or confirmed.
+
+The ``amount`` parameter MUST match the total amount of ZEC in the payment note plus the standard transaction fee for fully-shielded transactions (currently 0.00001 ZEC).
+
+There MUST NOT exist any other notes on the blockchain, or broadcast to the node network, beyond the payment note derived from the Payment URI, that are addressed to any payment address derived from ``key`` (with any diversifier). Such notes MAY be generated within an implementation (e.g., as speculative pre-generation with various note values) but MUST NOT be broadcast for mining.
+
+Wallet software MUST NOT expose the ephemeral payment address corresponding to a payment URI (which helps to ensure the prior paragraph).
+
+The ``desc`` parameter MAY convey a human-readable description of the payment, entered manually by the user or generated by the application in any reasonable manner.
+
+The encrypted memo fields in the output description containing the payment note commitment SHOULD be either empty (all-zero), or identical to the ``desc`` parameter (padded with zeros).
+
+The payment associated with an URI is not deemed “received” by the recipient until they execute a “finalization” process (see section `Finalization`_).
+
+When conveying payment to users, the sender's and recipient's wallet software MAY convey the description encoded in the ``desc`` parameter.
+
+The recipient's wallet software SHOULD convey to the user that the ``desc`` value is merely a claim made by the party who sent the URI, and may be tentative, inaccurate or malicious.
+
+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 ``amount`` parameter, and may change (possibly to zero), until the finalization process has been completed.
+
+
+Centralized Deployment
+----------------------
+
+The owner of the ``withzcash.com`` domain name MUST NOT create a DNS record for the ``pay.withzcash.com`` 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 ``withzcash.com`` domain name. (See `Rationale for URI Format`_ and `Security Considerations`_ below for discussion.)
+
+Applink_ 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 ``withzcash.com`` domain effectively controls the whitelist of apps that may be launched by users' platform to handle URI-Encapsulated Payments (see `Security Considerations`_). This whitelist should protect users from installing rogue apps that intercept incoming payments. Thus, the domain owner MUST do the following:
+
+* Maintain such a whitelist and serve it as needed for the applink_ mechanisms of major platforms.
+* Publish a policy for inclusion of apps in this whitelist.
+* Use all feasible means to whitelist only apps that comply with the published policy.
+* Publish the whitelist's content in human-readable form.
+* Provide clear and effective means for rapid removal of apps from the whitelist when required as security response.
+* Use all feasible means to protect the whitelist's integrity (in particular, this includes protecting the web server that serves the whitelist, the domain's TLS certificate, and the means by which the whitelist is modified).
+* Use effective means for keeping a precise, irrevocable and public history of the whitelist (e.g., using a timestamped Git repository, or an accountability mechanism akin to Certificate Transparency).
+
+They also SHOULD:
+
+* 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.
+
+
+Testing
+-------
+
+For testing purposes, all of the above specification is duplicated for the Zcash testnet network, substituting ``TAZ`` (Zcash testnet coins) for ``ZEC`` and ``testzcash.com`` for ``withzcash.com``.
+
+A separate “testnet whitelist” MUST be maintained by the owner of the ``testzcash.com`` 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.
+
+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.
+
+
+Lifecycle Specification
+=======================
+
+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:
+
+Generating the notes and URI
+----------------------------
+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.
+
+Ephemeral key derivation
+````````````````````````
+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.
+
+The derivation mechanism is as follows:
+
+* Use a ZIP 32 derivation pathway to obtain a child extended spending key from path ``m_Sapling/324'/coin_type'/payment_index'``
+
+  - Implementations need to remember which payment_index values they have used (in range 0..2^31), and not reuse them.
+
+* Compute *key = BLAKE2b-256(extended spending key, personal='Zcash_PaymentURI')*
+
+URI Transmission
+----------------
+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).
+
+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).
+
+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).
+
+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.
+
+Message Rendering
+-----------------
+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.
+
+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.
+
+
+Payment Rendering and Blockchain Lookup
+---------------------------------------
+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.
+
+In parallel, the wallet app SHOULD retrieve the relevant transactions from the Zcash blockchain, by looking up the transaction given by the ``cmu`` parameter (this MAY use an efficient index, perhaps assisted by a server), and check whether:
+
+* such transactions are indeed present on the blockchain
+* the notes are unspent
+* the notes can be spent using an ephemeral spending keys given by the ``key`` parameter.
+
+The wallet conveys to the user one of the following states:
+
+* *Ready-to-finalize*: The tests all verify, and the payment is ready to be finalized. The wallet SHOULD present the user with an option to finalize the payment (e.g., a “Finalize” button).
+* *Invalid*: The tests fail irreversibly (e.g., some of the notes are already spent, or the amounts to not add up). The wallet MAY convey the reason to the user, but in any case MUST convey that the funds cannot be received.
+* *Pending*: The tests fail in a way that may be remedied in the future, namely, some of the notes are not yet present on the blockchain (and no other tests are violated).
+
+Within the *Pending* 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 *Ready-to-finalize* state (since unmined notes cannot be immediately spent.)
+
+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.
+
+Finalization
+------------
+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).
+
+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.
+
+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.
+
+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.
+
+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.
+
+Payment Cancellation
+--------------------
+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.
+
+Cancellation requires the sender to know the ephemeral spending key. If the sender has lost this state, it can be recovered deterministically (see `Recovery From Wallet Crash`_, below).
+
+Status View
+-----------
+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 *Pending* inbound payment, and MAY offer the ability to cancel any outbound payment.
+
+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.
+
+
+Recovery From Wallet Crash
+--------------------------
+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.
+
+We define a “gap limit” *N*, similar to the “address gap limit” in BIP 44. If a wallet implementation observes *N* 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.
+
+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 ``ivk``\s, and the likelihood of missing on-chain funds due to out-of-order payment URI generation, we specify a standard gap limit of ``N = 3``.
+
+The process for determining the position of this gap during wallet recovery is as follows:
+
+* Derive the first *N* payment URI keys.
+* Derive the *N* ``ivk``\s corresponding to these keys via the process defined in [#protocol]_ Section 4.2.2 (setting ``sk = key``).
+* Scan the chain for spent nullifiers (for the wallet's own notes, or any payment URI notes it currently knows about). This is part of the normal chain-scanning process for wallets.
+* When a nullifier is detected as spent, trial-decrypt every output of the corresponding transaction with the current set of payment URI ``ivk``\s. If a note is detected:
+
+  * Store the note details along with the corresponding payment URI (which can be derived from the note).
+  * Add the note's nullifier to the set of wallet nullifiers (to enable discovery of funded payment URIs that the sender has recalled).
+  * Drop the ``ivk`` from the set of current payment URI ``ivk``\s.
+  * Derive the next ``ivk`` in line, and add it to the set.
+
+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 ``ivk``\s within the set of ``ivk``\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 ``N = 3``, and a wallet with one Sapling account).
+
+
+Security Considerations
+=======================
+
+* 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.
+
+  * The Payment-Encapsulating URI is like a magic spell that will teleport the money to the first person that clicks it and then does "finalize".
+
+* URI-Encapsulated Payments may be captured by malicious local apps on the sender or receiver's platform, e.g., by screen capturing or clipboard eavesdropping. Wallet apps should use the platform's interaction and communication facilities in a way that minimizes these risks (e.g., use the “Share” API rather than a clipboard that is visible to all apps).
+
+* Likewise, if the URI is transferred by presenting and optically scanning a QR code, anyone who observes this QR code may be able to finalize the payment and thus take ownership of the funds before the intended recipient. For example, an attacker may use a telephoto lens aimed at a point-of-sale terminal to steal QR-encoded payments sent to that terminal.
+
+* Users may have casually-established communication channels (e.g., they have entered the phone number of a new contact without bothering to double-check it), but may later mistakenly consider these to be adequately-authenticated secure channels for the purpose of sending Payment-Encapsulating URI. Wallet apps should mitigate this where feasible, e.g., by indicating that the chosen messaging channel is previously-unused and thus should be more carefully checked.
+
+* Users may incorrectly believe that the payment has been irrevocably received even though they have not invoked the finalization procedure, or even though the finalization procedure has failed. Wallet software should correctly convey the status and set expectations, as discussed above.
+
+* Payment recipients may not notice the incoming payment notification and act on it (i.e., invoke finalization) in a timely fashion. By the time they see it, the payment may have been cancelled by the sender.
+
+* Users may not understand that URI-Encapsulated Payments are for one-time use, and attempt to use the same URI for multiple people or payments, resulting in race conditions on who receives the funds.
+
+* Users may confuse URI-Encapsulated Payments (as specified in the current ZIP) with Payment Request URIs of the form ``zcash:payment-address?amount=...`` as specified in ZIP 321 [#zip-0321]_. Normally these serve different workflows, and work in opposing directions (send vs. receive of funds), and thus ought to not arise in ambiguous context. Wallet apps should take care to not create or send a Payment-Encapsulating URI (which is for *sending* funds) in a context where the user may be intending to *receive* funds.
+
+* Users may attempt to use a Payment-Encapsulating URI as a “cold wallet”, e.g., by writing the URI on paper and putting it in a safe. This is dangerous. The spending key is known to the sending wallet at the time when the URI is produced, and possibly also at other times (e.g., if there are storage remnants, or if deterministic derivation is used; see “Ephemeral key derivation” below). Thus, an adversary who compromises the sending wallet may drain the cold wallet.
+
+* The act and timing of finalizing a payment is visible to the sender, which may be a privacy leak. Likewise, if the on-chain transactions are sent in advance, their timing can be linked to the later payment, which may be a privacy leak.
+
+* The payment amount is readily visible to anyone who observes the Payment-Encapsulating URI, even in retrospect after payment has already been finalized (e.g., if their device or chat log backups are later compromised). This may be a privacy concern, and in particular may put recipients of large payments at risk of undesired attention.
+
+* Users attempting to follow URI-Encapsulated Payments as a regular HTTPS hyperlink may inadvertently leak the payment information to a remote attacker, if all layers of defense listed in `Rationale for URI Format`_ are somehow breached.
+
+* The owner of the ``withzcash.com`` domain effectively controls the whitelist of apps that may be launched by users' platform to handle URI-Encapsulated Payments using the applink_ mechanism. If the whitelist is too *permissive* and includes a malicious or vulnerable app, and a user installs that app (which itself may be subject to the platform vendor's app review mechanism), then the user is placed at risk of having their payments intercepted by an attacker. Conversely, if the whitelist is too *restrictive*, or altogether unavailable, then users would not be able to trigger desirable wallet apps by simply following links, and would need to instead ”share” the message containing the URI into their wallet app (note that, as discussed above, clipboard copy-and-paste is insecure).
+
+* 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.
+
+
+Design Decisions and Rationale
+==============================
+
+Rationale for URI Format
+------------------------
+
+The URI format ``https://pay.withzcash.com:65536/v1#...``  was chosen to allow automatic triggering of wallet software on mobile devices, using the platform's applink_ 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:
+
+* The ``pay.withzcash.com`` domain should not resolve.
+* A valid TLS certificate for ``pay.withzcash.com`` should not exist..
+* The port number ``65536`` is not valid for the TCPv4, TCPv6 or UDP protocols. Empirically, the common behavior in browsers and messaging apps, when following HTTPS links with port number port number 65536, is to render an empty or ``about:blank`` page rather than a DNS error; a network fetch is not triggered. (This may change if a network proxy protocol is used, but SOCKS5 also cannot represent port 65536.)
+* The contents of the fragment identifier are specified by HTTP as being resolved locally, rather than sent over the network (but see the caveat about active JavaScript attacks below).
+
+The downside is that if the user follows the link prior to installing a suitable wallet app, they get a weird-looking DNS error or a blank page. Also, the URL looks weird due to the port number.
+
+Several alternatives were considered, but found to have inferior usability and/or security ramifications:
+
+1.  ``https://pay.withzcash.com/v1#...``: similar to above, but without the port number, and backed by a DNS record, TLS certificate and web server for ``pay.withzcash.com`` that serves an informative HTML page (e.g., “Please install a wallet to receive this payment”). This still allows handling by wallet apps using an applink_ mechanism, and provides a friendlier fallback in case the user follows the link prior to installing a suitable app. However, it creates a security risk. If the web server serving that web page is compromised, or impersonated using an DNS+TLS attack, then the attacker can capture they payment parameters and steal the funds. (Note that the sensitive information is in the fragment following the ``#``, which is not sent in an HTTP GET request; but the malicious server can serve JavaScript code which retrieves the fragment.)
+
+2. ``zcash-data:payment/v1?amount=1.23&desc=Payment+for+foo&key=...``: a custom URI scheme, such as ``zcash-data``. This still allows for triggering application action (e.g., using Mobile Deep Links). However, on most platorms, *any* app installed on the device is able to register to handle links from (almost) any custom URI scheme. If the request is received by a rogue party, then the funds could be stolen. Even if received by an honest operator, funds could be stolen if they are compromised. Also, custom URI schemes are not linkified when displayed in some messaging apps.
+
+   Note the use of the ``zcash-data`` URI scheme, rather than the more elegant ``zcash``, because URIs of the form ``zcash:address?...`` are already used to specify Zcash addresses and payment requests in ZIP 321 [#zip-0321]_, by analogy to the ``bitcoin`` URIs of BIP 21. An alternative is to use ``zcash:v1/payment?...``; legacy software may parse this as a payment request to the address ``v1``, which is invalid. Another alternative is to use ``zcash-payment:v1?...``, which is appealing in terms of length and readability, but may be gratuitous pollution of the URI scheme namespace.
+
+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.
+
+Identifying Notes
+-----------------
+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.
+
+**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.**
+
+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).
+
+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:
+
+:math:`\hspace{0.9em}`\0. Explicitly list the note commitments within the URI.
+
+1. 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.
+
+2. 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).
+
+3. 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).
+
+4. 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.
+
+Additional rationale
+--------------------
+
+1. 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.
+
+2. 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.
+
+3. We do not include the sender or receiver's identity in the URI, because the sending wallet many not know the name of who it is sending to (or even from). Moreover there is the risk that fraudulent sender/recipient information could be used. If necessitated by circumstances (e.g., the FinCEN "Travel Rule" [#fincen-travel-rule]_), claimed sender and recipient identity can be included in ``desc`` parameter.
+
+
+Open Questions
+==============
+
+URI Usability
+-------------
+The URI could  be changed in several ways due to usability concerns:
+
+1. It may be desirable to prevent the ``amount`` and ``desc`` 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).
+
+2. Perhaps the URI should be contain the phrase “password” early on (e.g., ``zcash-data:/payment/v1/password=``, as a cue that this string must be kept secret. (Note that technically nothing here is a password in the usual sense of the term.)
+
+3. Perhaps we should actually use BIP 39 words as an actual password. So you could memorize it or read it over the phone. The BIP 39 words can be embedded in the URI itself (which is highly unusual):
+
+   ``zcash-data:payment/v1/password=witch+collapse+practice+feed+shame+open+despair+creek+road+again+ice+least``
+
+   or
+
+   ``zcash-data:payment/v1/password=WitchCollapsePracticeFeedShameOpenDespairCreekRoadAgainIceLeast``
+
+   This provides an additional cue that the URI contains a sensitive password (for users who are accustomed to BIP 39 style word lists; to others the Base 64 encoding may be more evocative of a password). Moreover, users may discover the fact that they can manually send these words to recipients, in writing or verbally, as a way to send money without a textual messaging service.
+   Alternatively, the BIP 39 words can be used as an alternative syntax for the encapsulation, without the confusing-to-humans URI syntax (but generating this alternative syntax this may complicate the UI).
+
+Note retrieval
+--------------
+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.
+
+Other Questions
+---------------
+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)?
+
+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?
+
+
+References
+==========
+
+.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_
+.. [#RFC3986] `Uniform Resource Identifier (URI): Generic Syntax `_
+.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later `_
+.. [#zip-0321] `ZIP 321: Payment Request URIs `_
+.. [#app-links] `Android Developer Guides: Handling Android App Links `_
+.. [#universal-links] `Apple Xcode Documentation: Allowing apps and websites to link to your content `_
+.. [#app-uri-handlers] `Microsoft Universal Windows Platform Documentation: Enable apps for websites using app URI handlers `_
+.. [#fincen-travel-rule] `FinCEN Guidance FIN-2019-G001. May 9, 2019. Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies `_
+
+
+Publication Blockers
+====================
+
+* Clean up semantics.
+* Clean up rationale.
diff --git a/zip-0332.rst b/zips/zip-0332.rst
similarity index 78%
rename from zip-0332.rst
rename to zips/zip-0332.rst
index 81b2d27b1..27ee7e630 100644
--- a/zip-0332.rst
+++ b/zips/zip-0332.rst
@@ -3,7 +3,7 @@
   ZIP: 332
   Title: Wallet Recovery from zcashd HD Seeds
   Owners: Kris Nuttycombe 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Wallet
   Discussions-To: 
diff --git a/zip-0339.rst b/zips/zip-0339.rst
similarity index 71%
rename from zip-0339.rst
rename to zips/zip-0339.rst
index 91ac9df98..aa1cb8bc6 100644
--- a/zip-0339.rst
+++ b/zips/zip-0339.rst
@@ -2,7 +2,7 @@
 
   ZIP: 339
   Title: Wallet Recovery Words
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Wallet
   Discussions-To: 
diff --git a/zip-0400.rst b/zips/zip-0400.rst
similarity index 100%
rename from zip-0400.rst
rename to zips/zip-0400.rst
diff --git a/zip-0401.rst b/zips/zip-0401.rst
similarity index 99%
rename from zip-0401.rst
rename to zips/zip-0401.rst
index 49521c625..e319996a8 100644
--- a/zip-0401.rst
+++ b/zips/zip-0401.rst
@@ -2,7 +2,7 @@
 
   ZIP: 401
   Title: Addressing Mempool Denial-of-Service
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Active
   Category: Network
   Created: 2019-09-09
diff --git a/zip-0402.rst b/zips/zip-0402.rst
similarity index 100%
rename from zip-0402.rst
rename to zips/zip-0402.rst
diff --git a/zip-0403.rst b/zips/zip-0403.rst
similarity index 100%
rename from zip-0403.rst
rename to zips/zip-0403.rst
diff --git a/zip-0416.rst b/zips/zip-0416.rst
similarity index 87%
rename from zip-0416.rst
rename to zips/zip-0416.rst
index eb435a1c9..f8ccc6911 100644
--- a/zip-0416.rst
+++ b/zips/zip-0416.rst
@@ -2,7 +2,7 @@
 
   ZIP: 416
   Title: Support for Unified Addresses in zcashd
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
diff --git a/zip-1001.rst b/zips/zip-1001.rst
similarity index 100%
rename from zip-1001.rst
rename to zips/zip-1001.rst
diff --git a/zip-1002.rst b/zips/zip-1002.rst
similarity index 100%
rename from zip-1002.rst
rename to zips/zip-1002.rst
diff --git a/zip-1003.rst b/zips/zip-1003.rst
similarity index 100%
rename from zip-1003.rst
rename to zips/zip-1003.rst
diff --git a/zip-1004.rst b/zips/zip-1004.rst
similarity index 100%
rename from zip-1004.rst
rename to zips/zip-1004.rst
diff --git a/zip-1005.rst b/zips/zip-1005.rst
similarity index 100%
rename from zip-1005.rst
rename to zips/zip-1005.rst
diff --git a/zip-1006.rst b/zips/zip-1006.rst
similarity index 100%
rename from zip-1006.rst
rename to zips/zip-1006.rst
diff --git a/zip-1007.rst b/zips/zip-1007.rst
similarity index 100%
rename from zip-1007.rst
rename to zips/zip-1007.rst
diff --git a/zip-1008.rst b/zips/zip-1008.rst
similarity index 100%
rename from zip-1008.rst
rename to zips/zip-1008.rst
diff --git a/zip-1009.rst b/zips/zip-1009.rst
similarity index 100%
rename from zip-1009.rst
rename to zips/zip-1009.rst
diff --git a/zip-1010.rst b/zips/zip-1010.rst
similarity index 99%
rename from zip-1010.rst
rename to zips/zip-1010.rst
index a5b65d82b..95f41ac08 100644
--- a/zip-1010.rst
+++ b/zips/zip-1010.rst
@@ -348,7 +348,7 @@ References
 .. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. `_
 .. [#tromer-comment] `Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019. `_
 .. [#restricted-funds] `“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018. `_
-.. [#zfnd-grants] `ZF Grants — Funding for Zcash ecosystem projects `_
+.. [#zfnd-grants] `ZF Grants — Funding for Zcash ecosystem projects `_
 .. [#zfnd-state] `The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. `_
 .. [#acityinohio-comment] `Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019. `_
 .. [#zip-1007] `ZIP 1007: Enforce Development Fund Commitments with a Legal Charter `_
diff --git a/zip-1011.rst b/zips/zip-1011.rst
similarity index 100%
rename from zip-1011.rst
rename to zips/zip-1011.rst
diff --git a/zip-1012.rst b/zips/zip-1012.rst
similarity index 100%
rename from zip-1012.rst
rename to zips/zip-1012.rst
diff --git a/zip-1013.rst b/zips/zip-1013.rst
similarity index 100%
rename from zip-1013.rst
rename to zips/zip-1013.rst
diff --git a/zip-1014.rst b/zips/zip-1014.rst
similarity index 99%
rename from zip-1014.rst
rename to zips/zip-1014.rst
index 8b6684824..f6934e1f5 100644
--- a/zip-1014.rst
+++ b/zips/zip-1014.rst
@@ -8,7 +8,7 @@
   Credits: Matt Luongo
            @aristarchus
            @dontbeevil
-           Daira Emma Hopwood
+           Daira-Emma Hopwood
            George Tankersley
            Josh Cincinnati
            Andrew Miller
diff --git a/zips/zip-2001.rst b/zips/zip-2001.rst
new file mode 100644
index 000000000..9be3855cd
--- /dev/null
+++ b/zips/zip-2001.rst
@@ -0,0 +1,116 @@
+::
+
+  ZIP: 2001
+  Title: Lockbox Funding Streams
+  Owners: Kris Nuttycombe 
+  Credits: Daira-Emma Hopwood 
+           Jack Grigg 
+  Status: Draft
+  Category: Consensus
+  Created: 2024-07-02
+  License: MIT
+  Pull-Request: 
+
+Terminology
+===========
+
+The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this
+document are to be interpreted as described in BCP 14 [#BCP14]_ when, and only
+when, they appear in all capitals.
+
+Abstract
+========
+
+This ZIP specifies a change to the Zcash consensus protocol to define a pool
+of issued Zcash value to be used to fund future development efforts within the
+Zcash ecosystem.
+
+This ZIP builds upon the funding stream mechanism defined in ZIP 207
+[#zip-0207]_. It defines a new "DEFERRED_POOL" funding stream type such that
+portions of the block reward sent to a stream of this type are deposited
+directly into the deferred funding pool instead of being sent to a recipient
+address. Other ways of adding to the pool, such as allowing for direct deposits
+or fee value currently allocated to miners may be defined in the future.
+
+Motivation
+==========
+
+In accordance with ZIP 1014, [#zip-1014]_ the Zcash block reward is allocated
+with 80% going to miners, and the remaining 20% distributed among the Major
+Grants Fund (8%), Electric Coin Company (ECC) (7%), and the Zcash Foundation
+(ZF) (5%). This funding structure supports various essential activities such as
+protocol development, security, marketing, and legal expenses. However, this
+model will expire in November 2024, leading to the entire block reward being
+allocated to miners if no changes are made.
+
+Several draft ZIPs under consideration for replacing the existing direct
+allocation of block rewards suggest that part of the block reward be directed
+to a reserve, the distribution of which is to be determined via a future ZIP.
+This ZIP is intended to provide a common mechanism that can be used to
+implement these various proposals.
+
+Requirements
+============
+
+The Zcash protocol will maintain a new Deferred chain pool value balance
+:math:`\mathsf{PoolValue}_{Deferred}` for the deferred funding pool, in much
+the same fashion as it maintains chain pool value balances for the transparent,
+Sprout, Sapling, and Orchard pools.
+
+The funding stream mechanism defined in ZIP 207 [#zip-0207]_ is modified such
+that a funding stream may deposit funds into the deferred pool.
+
+Specification
+=============
+
+Deferred Development Fund Chain Value Pool Balance
+--------------------------------------------------
+
+Full node implementations MUST track an additional
+:math:`\mathsf{PoolValue}_{Deferred}` chain value pool balance, in addition to
+the Sprout, Sapling, and Orchard chain value pool balances. This balance is
+set to zero prior to the activation of Network Upgrade 6.
+
+ZIP 207 [#zip-0207]_ is modified as follows:
+
+In the section **Funding streams** [#zip-0207-funding-streams]_, instead of:
+
+    Each funding stream has an associated sequence of recipient addresses,
+    each of which MUST be either a transparent P2SH address or a Sapling address.
+
+it will be modified to read:
+
+    Each funding stream has an associated sequence of recipients, each of which
+    MUST be either a transparent P2SH address, a Sapling address, or the identifier
+    `DEFERRED_POOL`.
+
+In the section **Consensus rules** [#zip-0207-consensus-rules]_, the following
+will be added:
+
+    The "prescribed way" to pay to the `DEFERRED_POOL` is to add
+    :math:`\mathsf{FundingStream[FUND].Value}(\mathsf{height})` to
+    :math:`\mathsf{PoolValue}_{Deferred}`.
+
+The protocol specification is modified to define the "total issued supply" such
+that the total issued supply as of a given height is given by the function:
+
+.. math::
+
+    \begin{array}{ll}
+    \mathsf{IssuedSupply}(\mathsf{height}) := &\!\!\!\!\mathsf{PoolValue}_{Transparent}(\mathsf{height}) \\
+    &+\;\; \mathsf{PoolValue}_{Sprout}(\mathsf{height}) \\
+    &+\,\; \mathsf{PoolValue}_{Sapling}(\mathsf{height}) \\
+    &+\,\; \mathsf{PoolValue}_{Orchard}(\mathsf{height}) \\
+    &+\,\; \mathsf{PoolValue}_{Deferred}(\mathsf{height})
+    \end{array}
+
+References
+==========
+
+.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to
+    Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs
+    Lowercase in RFC 2119 Key Words" `_
+.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_
+.. [#zip-0207] `ZIP 207: Funding Streams `_
+.. [#zip-0207-funding-streams] `ZIP 207: Funding Streams. Section: Funding streams `_
+.. [#zip-0207-consensus-rules] `ZIP 207: Funding Streams. Section: Consensus rules `_
diff --git a/zips/zip-guide-markdown.md b/zips/zip-guide-markdown.md
new file mode 100644
index 000000000..4cc0091cb
--- /dev/null
+++ b/zips/zip-guide-markdown.md
@@ -0,0 +1,257 @@
+
+    ZIP: Unassigned {numbers are assigned by ZIP editors}
+    Title: {Something Short and To the Point}
+    Owners: First Owner 
+            ...
+    Credits: First Credited
+             ...
+    Status: Draft
+    Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational | Process}
+    Created: yyyy-mm-dd
+    License: {usually MIT}
+    Pull-Request: 
+
+
+# Don't Panic
+
+If this is your first time writing a ZIP, the structure and format may look
+intimidating. But really, it's just meant to reflect common-sense practice and
+some technical conventions. Feel free to start with a simple initial draft that
+gets ideas across, even if it doesn't quite follow this format. The community
+and ZIP editors will help you figure things out and get it into shape later.
+
+{Delete this section.}
+
+
+# Terminology
+
+{Edit this to reflect the key words that are actually used.}
+The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this
+document are to be interpreted as described in BCP 14 [^BCP14] when, and
+only when, they appear in all capitals.
+
+{Avoid duplicating definitions from other ZIPs. Instead use wording like this:}
+
+The terms "Mainnet" and "Testnet" in this document are to be interpreted as
+defined in the Zcash protocol specification [^protocol-networks].
+
+The term "full validator" in this document is to be interpreted as defined in
+the Zcash protocol specification [^protocol-blockchain].
+
+The terms below are to be interpreted as follows:
+
+{Term to be defined}
+
+: {Definition.}
+
+{Another term}
+
+: {Definition.}
+
+
+# Abstract
+
+{Describe what this proposal does, typically in a few paragraphs.
+
+The Abstract should only provide a summary of the ZIP; the ZIP should remain
+complete without the Abstract.
+
+Use links where applicable, e.g. [^protocol] [^protocol-introduction].}
+
+
+# Motivation
+
+{Why is this proposal needed?
+
+This is one of the most important sections of the ZIP, and should be detailed
+and comprehensive. It shouldn't include any of the actual specification --
+don't put conformance requirements in this section.
+
+Explain the status quo, why the status quo is in need of improvement,
+and if applicable, the history of how this area has changed. Then describe
+*at a high level* why this proposed solution addresses the perceived issues.
+It is ok if this is somewhat redundant with the abstract, but here you can
+go into a lot more detail.}
+
+
+# Requirements
+
+{Describe design constraints on, or goals for the solution -- typically one
+paragraph for each constraint or goal. Again, don't actually specify anything
+here; this section is primarily for use as a consistency check that what is
+specified meets the requirements.}
+
+
+# Non-requirements
+
+{This section is entirely optional. If it is present, it describes issues that
+the proposal is *not* attempting to address, that someone might otherwise think
+it does or should.}
+
+
+# Specification
+
+{Replace this entire section.}
+
+The Specification section describes what should change, using precise language and
+conformance key words. Anything that is *required in order to implement the ZIP*
+(or follow its process, in the case of a Process ZIP) should be in this section.
+
+Avoid overspecification! Also avoid underspecification. Specification is hard.
+Don't be afraid to ask for help.
+
+Feel free to copy from other ZIPs doing similar things, e.g. defining RPC calls,
+consensus rules, etc.
+
+ZIPs MUST take into account differences between the Zcash Mainnet and Testnet
+[^protocol-networks] where applicable. A consensus ZIP MUST be able to be deployed
+on both Mainnet and Testnet.
+
+Unless the specification is particularly simple, you will need to organise it under
+subheadings.
+
+## Example subheading
+
+At least while the ZIP is in Draft, we encourage writing open questions and TODOs.
+
+### Open questions
+
+* What happens if a full validator can't parse the fandangle as a doohicky?
+
+TODO: define byte encoding for the Jabberwock.
+
+## Comparison of ZIPs to RFCs
+
+Like RFCs, ZIPs are precise technical documents that SHOULD give enough
+implementation information to implement part of a Zcash-related protocol or follow a
+Zcash-related process [^zip-0000].
+
+ZIPs are different from RFCs in the following ways:
+
+* Many (but not all) ZIPs are "living documents"; they are updated in-place as
+  the relevant areas of the protocol or process change. Unlike in the RFC process,
+  making a change in an area described by a published ZIP does not *necessarily*
+  require creating a new ZIP, although that is an option if the change is extensive
+  enough to warrant it.
+* The expected structure of a ZIP is more constrained than an RFC. For example,
+  the Specification section is REQUIRED, and all of the conformance requirements
+  MUST go in that section. The ZIP editors will help you to ensure that things
+  go in the right sections.
+* Security considerations SHOULD be spread throughout the text, in the places
+  where they are most relevant.
+
+## Using mathematical notation
+
+Embedded LaTeX $x + y$ is allowed and encouraged in ZIPs. The syntax for inline
+math is "`:math:`latex code``" in reStructuredText or "`$latex code$`" in
+Markdown. The rendered HTML will use KaTeX [^katex], which only supports a subset
+of LaTeX, so you will need to double-check that the rendering is as intended.
+
+In general the conventions in the Zcash protocol specification SHOULD be followed.
+If you find this difficult, don't worry too much about it in initial drafts; the
+ZIP editors will catch any inconsistencies in review.
+
+## Notes and warnings
+
+:::info
+"`.. note::`" in reStructuredText, or "`:::info`" (terminated by
+"``:::``") in Markdown, can be used for an aside from the main text.
+
+The rendering of notes is colourful and may be distracting, so they should
+only be used for important points.
+:::
+
+:::warning
+"`.. warning::`" in reStructuredText, or "`:::warning`" (terminated by
+"`:::`") in Markdown, can be used for warnings.
+
+Warnings should be used very sparingly — for example to signal that a
+entire specification, or part of it, may be inapplicable or could cause
+significant interoperability or security problems. In most cases, a "MUST"
+or "SHOULD" conformance requirement is more appropriate.
+:::
+
+## Valid markup
+
+This is optional before publishing a PR, but to check whether a document is valid
+reStructuredText or Markdown, first install `rst2html5` and `pandoc`. E.g. on
+Debian-based distros::
+
+    sudo apt install python3-pip pandoc perl sed
+    pip3 install docutils==0.19 rst2html5
+
+Then, with `draft-myzip.rst` or `draft-myzip.md` in the root directory of a clone
+of this repo, run::
+
+    make draft-myzip.html
+
+(or just "`make`") and view `draft-myzip.html` in a web browser.
+
+## Citations and references
+
+Each reference should be given a short name, e.g. "snark" [^snark]. The syntax to cite
+that reference is "`[#snark]_`" in reStructuredText, or "`[^snark]`" in Markdown.
+
+The corresponding entry in the [References] section should look like this in
+reStructuredText:
+```rst
+.. [#snark] `The Hunting of the Snark _. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+```
+
+or like this in Markdown::
+```markdown
+[^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+```
+
+Note that each entry must be on a single line regardless of how long that makes the
+line. In Markdown there must be a blank line between entries.
+
+The current rendering of a Markdown ZIP reorders the references according to
+their first use; the rendering of a reStructuredText ZIP  keeps them in the same 
+order as in the References section.
+
+To link to another section of the same ZIP, use
+```rst
+`Section title`_
+```
+in reStructuredText, or
+```markdown
+[Section title]
+```
+in Markdown.
+
+### Citing the Zcash protocol specification
+
+For references to the Zcash protocol specification, prefer to link to a section
+anchor, and name the reference as `[^protocol-]`. This makes it more likely
+that the link will remain valid if sections are renumbered or if content is moved.
+The anchors in the protocol specification can be displayed by clicking on a section
+heading in most PDF viewers. References to particular sections should be versioned,
+even though the link will point to the most recent stable version.
+
+Do not include the "`https://zips.z.cash/`" part of URLs to ZIPs or the protocol spec.
+
+
+# Reference implementation
+
+{This section is entirely optional; if present, it usually gives links to zcashd or
+zebrad PRs.}
+
+
+# References
+
+[^BCP14]: [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14)
+
+[^protocol]: [Zcash Protocol Specification, Version 2022.3.8 or later](protocol/protocol.pdf)
+
+[^protocol-introduction]: [Zcash Protocol Specification, Version 2022.3.8. Section 1: Introduction](protocol/protocol.pdf#introduction)
+
+[^protocol-blockchain]: [Zcash Protocol Specification, Version 2022.3.8. Section 3.3: The Block Chain](protocol/protocol.pdf#blockchain)
+
+[^protocol-networks]: [Zcash Protocol Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks)
+
+[^katex]: [KaTeX - The fastest math typesetting library for the web](https://katex.org/)
+
+[^zip-0000]: [ZIP 0: ZIP Process](zip-0000.rst)
+
+[^snark]: [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
diff --git a/zip-guide.rst b/zips/zip-guide.rst
similarity index 81%
rename from zip-guide.rst
rename to zips/zip-guide.rst
index 950a78c53..048594048 100644
--- a/zip-guide.rst
+++ b/zips/zip-guide.rst
@@ -132,7 +132,7 @@ Comparison of ZIPs to RFCs
 
 Like RFCs, ZIPs are precise technical documents that SHOULD give enough
 implementation information to implement part of a Zcash-related protocol or follow a
-Zcash-related process.
+Zcash-related process [#zip-0000]_.
 
 ZIPs are different from RFCs in the following ways:
 
@@ -180,23 +180,50 @@ Notes and warnings
     significant interoperability or security problems. In most cases, a "MUST"
     or "SHOULD" conformance requirement is more appropriate.
 
-Valid reStructuredText
-----------------------
+Valid markup
+------------
 
 This is optional before publishing a PR, but to check whether a document is valid
-reStructuredText, first install ``rst2html5``. E.g. on Debian-based distros::
+reStructuredText or Markdown, first install ``rst2html5`` and ``pandoc``. E.g. on
+Debian-based distros::
 
   sudo apt install python3-pip pandoc perl sed
   pip3 install docutils==0.19 rst2html5
 
-Then, with ``zip-xxxx.rst`` in the root directory of a clone of this repo, run::
+Then, with ``draft-myzip.rst`` or ``draft-myzip.md`` in the root directory of a
+clone of this repo, run::
 
-  make zip-xxxx.html
+  make draft-myzip.html
 
-(or just ``make``) and view ``zip-xxxx.html`` in a web browser.
+(or just "``make``") and view ``draft-myzip.html`` in a web browser.
 
-Conventions for references
---------------------------
+Citations and references
+------------------------
+
+Each reference should be given a short name, e.g. "snark" [#snark]_. The syntax to cite
+that reference is "``[#snark]_``" in reStructuredText, or "``[^snark]``" in Markdown.
+
+The corresponding entry in the `References`_ section should look like this in
+reStructuredText::
+
+  .. [#snark] `The Hunting of the Snark `_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+
+or like this in Markdown::
+
+  [^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+
+Note that each entry must be on a single line regardless of how long that makes the
+line. In Markdown there must be a blank line between entries.
+
+The current rendering of a Markdown ZIP reorders the references according to
+their first use; the rendering of a reStructuredText ZIP keeps them in the same
+order as in the References section.
+
+To link to another section of the same ZIP, use "```Section title`_``" in reStructuredText,
+or "``[Section title]``" in Markdown.
+
+Citing the Zcash protocol specification
+---------------------------------------
 
 For references to the Zcash protocol specification, prefer to link to a section
 anchor, and name the reference as ``[#protocol-]``. This makes it more likely
@@ -225,3 +252,4 @@ References
 .. [#protocol-networks] `Zcash Protocol Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet `_
 .. [#katex] `KaTeX - The fastest math typesetting library for the web `_
 .. [#zip-0000] `ZIP 0: ZIP Process `_
+.. [#snark] `The Hunting of the Snark `_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.