Zcash launched with support for upstream Bitcoin version 1 transactions and a custom version 2 transaction format which added fields required for shielded transactions.
The version field is always serialized in little-endian format.
Version 1 transaction 5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061
- begins with 0x01000000
- 32-bit integer 00 00 00 01 == 1
Version 2 transaction 4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b
- begins with 0x02000000
- 32-bit integer 00 00 00 02 == 2
Legacy parsers require the version to be positive.
Overwinter parsers require the version to be negative and should set the most significant bit of the 32-bit signed integer. When serialized, a Version 3 Overwinter transaction will take the form:
- begins with 0xfdffffff
- 32-bit integer ff ff ff fd == -3
Legacy parsers will expect the version to be a positive value, such as 1 or 2, and will thus reject Overwinter transactions as invalid.
Consider an example where the raw little-endian bytes of the version field of an Overwinter transaction begin 0xFDFFFFFF ( binary 11111101111111111111111111111111 )
Legacy parsers will deserialize the raw version field as a 32-bit signed integer. With a negative version value of -3, legacy parsers will reject the transaction.
Overwinter parsers will deserialize the raw version field as a 32-bit signed integer. With a negative raw value of -3, the Overwinter parser will accept the transaction as the most significan bit of the 32-bit signed integer has been set.
Overwinter parsers can retrieve the transaction format version of 3 by getting the absolute value of the raw version field e.g. using standard library call std::abs()
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.::
bool isLegacyFormat() // return true if the msb of nVersion is not set
unsigned int32 getVersion() // return absolute value of raw version field which is compatible with Legacy and Overwinter
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
