Zcash launched with support for upstream Bitcoin version 1 transactions and a custom version 2 transaction format which added fields required for shielded transactions.
Overwinter parsers also require the transaction version number to be positive, however the serialized version field must have the most significant bit set.
By setting the most significant bit of the version field, we ensure there is replay protection between Legacy and Overwinter compatible software. With two's complement integers, the most significant bit indicates whether an integer is positive or negative, therefore Overwinter version fields will be negative.
Overwinter parsers will accept the transaction as valid as the most significant bit of the 32-bit signed integer has been set. By masking off (unsetting) the most significant bit, the parser can retrieve the actual transaction version number::
Currently, the nVersion field is a public member variable which can be accessed directly. As part of implementing Overwinter, the nVersion field will be made private with access restricted to using getters, e.g.::
Where transaction format version 4* for the "Clone" branch might be substantially different from the expected transaction format version 4 for the "Zcash" branch.
Given forwards compatibility, we want the "Zcash" branch nodes to accept transaction version 4, whilst rejecting version 4* transactions which are intended only for the "Clone" branch.
To achieve this, Overwinter requires a transaction to include a branch ID, to explicitly state which branch of the network this transaction is intended for.
Overwinter introduces a new signature hashing scheme which includes the branch ID, but by including the branch ID into the transaction format, clients can quickly reject transactions during deserialization without having to check signatures.
A simple way to filter transactions might look like this::
if (tx.branchID != CLIENT_BRANCH_ID) { ... }
However given that a branch may support a set of transaction version formats, we should implement such that we can write code like::
if (isBranchSupported(tx.getBranchID())) { ... }
if (tx.isSupportedBranch()) { ... }
Overwinter will introduce a method for developers to easily specify and update a map of supported branch IDs and transaction versions which can be easily accessed throughout the system.
Deployment
==========
This proposal will be deployed with the Overwinter network upgrade.
Testnet:
Mainnet:
Backward compatibility
======================
This proposal intentionally creates what is known as a "bilateral hard fork" between Legacy software and Overwinter compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Legacy software will treat Overwinter transactions as invalid. Overwinter compatible software will reject legacy transactions. Once Overwinter has activated, nodes will only accept transactions based upon supported branch ID and transaction versions.
Reference Implementation
========================
TBC
References
==========
Design hard fork activation mechanism https://github.com/zcash/zcash/issues/2286
