Draft ZIP: Disabling Addition of New Value to the Transparent Pool

Community Collaborations protocol
1

Summary for Public

This draft ZIP intends to stop adding new ZEC to the Transparent pool of Zcash. To be clear, users who exclusively use transparent wallets and never interacts with shielded pools (such as Trust Wallet or Exodus Wallet users) won’t be affected, as it doesn’t impact regular transparent-to-transparent transactions. However, it will prevent the transfer of ZEC to Transparent addresses from shielded pools, namely Sapling and Orchard protocols. The primary goal of this ZIP is to reduce the complexities of the Zcash protocol for future generations. The secondary goal is to keep future mining rewards in shielded pools, gradually decreasing the proportion of ZEC in the transparent pool. Another secondary goal of this ZIP is to increase the use and storage of ZEC in these shielded pools. Note that the author also proposed that this ZIP to be activated on the 10th birthday of Zcash, more than 2 years from today.

Important note: The decision to adopt this proposed ZIP is at the hand of the Zcash users and contributors community. Check out Principles for deprecating t2t transactions and Retire Transparent Pool on the 10th Zcash Birthday - Let's Make It Official! for discussions and community preference on this matter.

::

ZIP: unassigned
Title: Disabling Addition of New Value to the Transparent Pool
Status: Draft
Category: Consensus
Created: 2024-10-28 :wink:
License: MIT

Terminology

The key words “MUST”, “SHOULD”, and “OPTIONAL” 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 term “Transparent pool” in this document refers to the Transparent chain value pool which works as in the Bitcoin Protocol and have been used since the launch of the Zcash network [#protocol]_.

The term “Sapling shielded protocol” in this document refers to the shielded payment protocol
introduced in the Sapling network upgrade [#zip-0205]_ [#protocol]_.

The term “Orchard shielded protocol” in this document refers to the shielded payment protocol
introduced in the network upgrade 5 [#zip-0224]_ [#protocol]_.

The term “shielded pools” in this document refers to both Sapling and Orchard shielded protocols.

Abstract

This proposal disables the ability to add new value to the Transparent pool balance.
This takes a step toward being able to remove the Bitcoin Script entirely from the Zcash protocol, thus reducing the overall complexity and attack surface of Zcash.

Motivation

Zcash implements the Decentralized Anonymous Payment scheme Zerocash [#protocol]_ [#zerocash]_.

While supporting shielded payment protocols for anonymity, it also incorporates a Transparent payment scheme identical to Bitcoin. This addition facilitates Zcash integration into existing tools and services compatible with Bitcoin.

As Zcash develops through various network upgrades, the inclusion of legacy Bitcoin Script in its specification and implementation creates complexity and “technical debt.” This complexity stems from the need to support and test both Transparent and shielded payment protocols, including proposed ones like ZSA.

To address this, the initial step is to disallow additions to the Transparent chain’s value pool balance. This measure aims to reduce complexity and potential risks without preventing the extraction of value from Transparent addresses for subsequent transfers to other Transparent addresses.

Specification

Consensus rule: pending technical discussions.

The author is not technical enough to understand what’s consensus changes required for this ZIP implementation. Any technical input on this matter is greatly appreciated. :hand_with_index_finger_and_thumb_crossed:

When this proposal is activated, nodes and wallets MUST disable any facilities to create transparent transactions that have both one or more outputs to Transparent addresses, and one or more inputs from non-Transparent addresses. This SHOULD be made clear in user interfaces and API
documentation.

Notes:

  • The facility to send to Transparent pool from shielded pools, even before activation of this proposal, is OPTIONAL for a particular node or wallet implementation.

Rationale

pending technical discussion

Deployment

This proposal will be deployed on the 10th birthday of Zcash, October 28th 2026. Specifically, the implementation of this proposal will be activated at the first block mined after Oct 28, 2026 · 16:19 UTC which is exactly 10 years after the mining of the first block of Zcash [#block_1]_. :stuck_out_tongue_winking_eye:

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 2023.4.0 [NU5] or later <protocol/protocol.pdf>_
… [#zip-0200] ZIP 200: Network Upgrade Mechanism <zip-0200.rst>_
… [#zip-0205] ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>_
… [#zip-0224] ZIP 224: Orchard Shielded Protocol <zip-0224.rst>_
… [#zerocash] Zerocash: Decentralized Anonymous Payments from Bitcoin (extended version) <https://eprint.iacr.org/2014/349>_
… [#block_1] Zcash block 1 <https://3xpl.com/zcash/block/1>_

4 Likes
2

I was outraged for the first 5 min (we have zero hardware support now). Then I started to see positive sides of it…

1 Like
3

I like this sort of proposal a lot because its a way to slowly challenge the use of the Transparent Pool, without ever explicitly killing it at a hard date in the future.

The ZF and ECC would be in a lot of trouble if they lost their ability to operate within KYC-AML compliant exchanges. Until there is vast liquidity in DEX for Zcash, it makes for a impossible situation to support. The ZF and ECC need too much $$$ out of ZEC on a monthly basis for their to be any chance to rely on DEX only. Its fortunate that they’re both in a reliable setup currently, where Coinbase, Kraken, Gemini all remain viable options in the USA.

1 Like
4

this is for sure an out of the box idea and very interesting,
however i feel like its not the time to make such moves,
we are not ready for this… the ecosystem isn’t ready

5

Since every coinbase (newly mined block) transaction is T and must be sent to Z before it can be spent, this ZIP would effectively make every coin mined only shielded after minting and only able to interact with shielded pools thereafter, correct?

Or could this (if not implemented correctly) prevent newly mined coins from being spendable at all since they are “value added” to the T pool?

6

This is incorrect. Mining directly to shielded addresses has been supported since the Heartwood network upgrade in 2020: Release v3.0.0 · zcash/zcash · GitHub

1 Like
7

Hm, @nuttycom the ability has been there since Heartwood but I’m curious if there are stats about how many take advantage of it? It’s not a protocol enforced requirement to mine to shielded?

For example, the first block mined by Zebra: Zcash block 2311253 was to a T address.

I stand corrected, if this ZIP were to be adopted then that would in effect mean that blocks mined to shielded would be forever shielded, unable to interact with the T pool.

4 Likes
8

This would be a huge step forward for Zcash.

9

The zip does not take shielded coinbase into consideration, and so there are number of couple of possible scenarios there, but as it stands yes, the funds would be locked in the shielded pools after that. Like nuttycom said, the ability to mine directly to shielded coinbase has existed for quite a while. The metrics on that could probably be retrieved. I know there are few examples here on the forum I could dig up and look at. Only reason I guess it isn’t more common is because of enhanced technical complexity with the required mining software or whatever it is the miner uses being incompatible, unsure, really.

10

Likely correct, BTC mining software can be adapted to T addresses much easier than Z.

1 Like
11

This is basically the equivalent of Zen’s move to be mica compliant, by preventing transactions from shielded to transparent addresses which is what is explicitly stated.

12

T → T : OK
T → Z: OK

Z → Z: OK
Z → T: NOT OK

This proposal may have the opposite result than intended.

Users may end up keeping their funds in the transparent pool because sending them to a shielded pool is one way.
It’s a decision that cannot be reversed.

2 Likes
13

hate to say it but were handcuffed to the decision that they made at block height #1
were gonna be dealing with the transparent coins forever cause theyre completely entrenched in
not to even mention that theres now a handful of newer blockchains that basically stole zcash technology to launch their own projects exact like zcash but they stripped out all the transparency copy pastes

14

This proposal is not intended to “jail” mining rewards that is being mined directly into a t-address. I believe there are two options available here, (A) require all miners to mine to a shielded address OR (B) limit this ZIP to prevent fund transfer from shielded pools to t-address.

I personally prefer option A as it means all new mining rewards will be in the shielded pool.

I don’t really know of what’s happening with ZEN community, but aren’t they removing the entire shielded protocol from the Horizen network?

This is a possible future scenario. Many transparent ZEC users, especially those consistently using transparent wallets, are expected to continue their current practices. I don’t foresee a substantial shift in their preferences. This group encompasses centralized exchanges and institutions relying on Bitcoin-based tools for ZEC transactions. However, if this ZIP is enacted and a compelling incentive emerges (such as a token drop exclusive to shielded ZEC), users will need to consider the opportunity cost of remaining in the transparent pool compared to the advantages of transitioning to the shielded pool. This situation could motivate Zcash builders to take necessary steps for encouraging transparent ZEC users to migrate to shielded pools. Consequently, this may lead to a decrease in activity within the transparent pool, potentially resulting in the eventual removal of t-addresses from Zcash.

I’d also like to highlight that eliminating the Bitcoin-style Transparent pool from Zcash doesn’t mean losing the possibility of having a “transparency” feature in the future. For instance, the turnstile between shielded pools will still function; for example, conducting transactions from the Sapling pool to the Orchard pool reveals the transferred amount of ZEC (for auditability) without depending on the Bitcoin-style Transparent pool. If transparency is necessary, it’s preferable for Zcash to possess its own transparency mechanism (which can be designed to be less complex) rather than relying on legacy Bitcoin-style transparency.

15

This would definitely be an improvement over the status-quo.

I would go “faster and harder” than this personally; particularly as the 10 years of Zcash is certainly an opportunity for inspiring / groundbreaking improvements of the project.

We could certainly implement this ZIP in one year. Let’s regain our place in the exciting projects category!!

16

Like I mentioned above, zip 213 shielded coinbase already enforces that all newly mined funds must pass into the shielded pool i.e. miners cannot mine to a transparent address and then send to another transparent address. It must be a shielding tx so basically satisfies your A requirement.

1 Like
17

The related risk that has occurred to me is that, if transparent and shielded ZEC are not interchangeable, then the value of transparent and shielded ZEC could diverge from one another.

I think that to avoid this outcome, one would also need to disable T->T transfers, in addition to Z->T.

My position has always been that it will make sense to remove the transparent pool when we have made the transparent pool irrelevant. There’s still a ways to go to get there, but I like the idea of framing the removal of the transparent pool in terms of what needs to be in place for it to actually be irrelevant.

3 Likes
18

Certainly, this is another conceivable scenario we must consider. Theoretically, discussions around this kind of price divergence have taken place in Bitcoin concerning “new” BTC received as a block reward without a prior transaction history compared to other BTC that already has a history, most likely with KYC-related data for each transaction. In Zcash, a likely scenario is treating transparent ZEC as an “option” to shielded ZEC. Having one ZEC in the transparent pool would equate to obtaining one ZEC in the shielded pool, and the introduction of this option could lead to a different pricing dynamic compared to the underlying asset. However, it’s important to note that predicting market behavior is uncertain; we can’t definitively determine what Madame Market thinks or will do.

1 Like
19

Also, once shielded, coins can’t be used to pay users of transparent wallets.
Personally, I am not in favor of this zip.

20

Yes, and that is the whole point of this zip. I believe, technically we can in the future develops transactions from shielded address that reveals the amount and destination (not necessarily the receiver address) if this kind of feature is desired by the users. However, I would like for these type of features to not involve the Bitcoin code.

1 Like