Draft of ZenIP 42204 for the deprecation of the mainchain shielded pool

HorizenOfficial · Jan 4, 2023 · 4b34d67 · 4b34d67 · michaeleangelo · Dec 29, 2023
1 parent b2cccd3
commit 4b34d67
Showing 1 changed file with 77 additions and 0 deletions.
diff --git a/zenip-42204.md b/zenip-42204.md
@@ -0,0 +1,77 @@
+
+# ZenIP-42204
+
+    ZenIP: 42204
+    Title: Deprecating the Mainchain Shielded Pool
+    Owner: Ben Pittman, <ben@horizenlabs.io>
+    Discussions-To: Ben Pittman, <ben@horizenlabs.io>
+    Comments-URI: https://horizen.global/invite/discord
+    Status: Draft
+    Type: Consensus
+    Created: 2023-01-04
+    License: MIT
+
+## Table of Contents
+
+<!--ts-->
+
+- [Abstract](#abstract)
+- [Motivation](#motivation)
+- [Specification](#specification)
+- [Rationale](#rationale)
+- [Security and Privacy Considerations](#security-and-privacy-considerations)
+
+
+## Abstract
+
+This ZenIP is to remove shielded transactions with transparent inputs from the Horizen Mainchain.  The consensus rule changes will activate via a hard fork at mainchain block height #TBD
+
+The consensus rules will include the following changes:
+- The requirement of having to shield coinbase vout will be removed.
+- Coinbase `z_shieldcoinbase` will be disabled.
+- RPC endpoint `z_sendmany` accepts shielded and unshielded addresses as inputs to the from address argument, these will change to shielded addresses only.
+- The `z_mergetoaddress` accepts shielded and unshielded addresses as inputs to the from address argument, these will change to shielded addresses only.
+- Receiving transactions that include public inputs of transaction version -3 after the hard fork activation should increase a peer’s ban score.
+
+## Motivation
+
+The original Zcash release (sprout) has been deprecated in favor of sapling and blossom.   Horizen’s implementation of shielded transactions relies on ZCash’s outdated sprout technology.
+
+Technical debt, combined with the fact that shielded transactions make up a very small percentage of transactions (excluding node tracking system transactions), and not to mention the current regulatory environment, begs the question: “Should Horizen continue to be a privacy coin, and if so, does it need to be natively supported on the mainchain?” Is the regulatory risk worth the utility of shielded transactions?  For context, Horizen has already been delisted on an exchange in the Republic of Korea and excluded from popular industry applications like Crypto.com.
+
+Ultimately Horizen’s vision, that has emerged over several years, relies on a simple mainchain that enables a network of sidechains for a multitude of use cases.  One of those use cases could be shielded pools.  For example, sidechains for Zcash’s sprout, sapling, or blossom.
+
+In an effort to aid growth and minimize risk, this ZenIP proposes to prevent shielding (t -> z) support at the consensus level (Mempool and Blocks).  Specifically shielded transactions with transparent inputs.  Note, this ZenIP is not for the complete removal of the shielded pool as users could face a permanent loss.
+
+## Specification
+
+We propose to prevent shielding (t -> z) support at the consensus level (Mempool and Blocks), specifically shielded transactions with transparent inputs.  Shielded transactions use a transaction version -3.  We will prevent the inclusion of Public Inputs into version -3 transactions by enforcing at the consensus layer that the Vin vector is empty in v-3 transactions.
+
+1. The requirement of having to shield coinbase vout will be removed.
+2. Coinbase `z_shieldcoinbase` will be disabled.
+    - (Client.cpp + server.cpp)  remove z_shieldcoinbase from CRPCConvertParam.
+    - rpcwallet.cpp remove z_shieldcoinbase.
+3. Disable `z_getnewaddress` to prevent new zaddr’s from being created.
+    - rpcwallet.cpp remove z_getnewaddress method.
+    - Wallet.cpp remove GenerateNewZKey.
+4. RPC endpoint `z_sendmany` accepts shielded and unshielded addresses as inputs to the from address argument, these will change to shielded addresses only.
+    - rpcwallet.cpp `z_sendmany` enforce (fromTaddr = zaddr.IsValid();)
+5. The `z_mergetoaddress` accepts shielded and unshielded addresses as inputs to the from address argument, these will change to shielded addresses only.
+    - rpcwallet.cpp z_mergetoaddress, remove any code not supporting the (address == "ANY_ZADDR") logic flow.
+6. Receiving transactions that include public inputs of transaction version -3 after the hard fork activation should increase a peers ban score.
+    - main.cpp ProcessMessage add check and increase ban score with Misbehaving(), also in main.cpp
+
+This change would activate on a hard fork at block X (Date TBD)
+Users will be given an acceptable amount of time to migrate from the shielded pool.
+
+
+### Rationale
+
+We want to get privacy right and paradoxically deprecating the shielded pool is a step in that direction.  Moving away from outdated Zcash sprout technology will give us room to maneuver regarding privacy tech, if the community so desires.
+
+Strategically it doesn’t make sense to risk our vision of a simple mainchain enabling a network of side chains by supporting the shielded pool on the mainchain.  At the same time the shielded pool is not something that can be removed in one-go as users would lose funds and this is unacceptable.  What we can do is reduce the importance of the shielded pool by preventing new transparent inputs being sent to it, using Martin Fowler’s strangler pattern to arrive at the point where we can reimagine what privacy will look like for Horizen.
+
+
+### Security and Privacy Considerations
+
+Shielded transactions are of benefit to the network because producing many of them increases the privacy set on the network. The more shielded transactions exist and the more nodes that submit shielded tx to the network, the harder it becomes to perform statistical analysis with the goal of deanonymizing users.  This ZenIP will reduce the total amount of shielded transactions.