Skip to content

Latest commit

 

History

History
74 lines (49 loc) · 5.44 KB

zenip-42204.md

File metadata and controls

74 lines (49 loc) · 5.44 KB
Raw

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: Proposed
Type: Consensus
Created: 2023-01-04
License: MIT

Table of Contents

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. 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();)
  4. 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.
  5. After the fork, transaction with version "-3" containing public inputs are allowed provided they do not move funds to the shielded pool (this can be checked by requiring vpub_old = 0 for each joinsplit)
    • 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.