Transparent Extensions

Transparent Extensions are modular software components that are distributed as part of the code of consensus implementations. An extension defines interpretation rules for several new pieces of data that are included as part of a transaction.

A Transparent Extension is identified by a numeric type. A Transparent Extension may also have several modes of operation, corresponding to different kinds of encumbrance within the extension's overall protocol.

The following three values are made available to the extension (in addition to type):

• A numeric mode.
• A byte sequence precondition containing an encoding of the precondition that is prefix-free within this (type, mode).
• A byte sequence witness containing an encoding of evidence purporting to satisfy the precondition. This encoding MUST be prefix-free within this (type, mode).

The extension is responsible for providing mode-specific parsing and serialization of these data fields. In addition, the extension MUST implement a deterministic verification algorithm tze_verify that takes as arguments mode, precondition, witness, and a context object. The context object provides deterministic public information about the transaction as well as the block chain (up to and including the block that the transaction is mined in). It returns true if the precondition is satisfied in that context, and false otherwise.

An extension MAY request that arbitrary public information about the transaction and block chain be included in the context object provided to it; these requirements MUST be satisfied by a caller integrating the extension at the integration point. Extensions SHOULD restrict the information requested to that which may be provided by node implementations in an efficient manner. For example, an extension SHOULD NOT require that it be provided full blocks in order to be able to construct or validate a precondition, and SHOULD minimize transaction data requested to that which are essential for its computational needs. In addition, while some preprocessing by the consensus-validating node may be requested, construction of such contextual data SHOULD NOT impose significant computational costs.

ZIPs that define a new transparent extension MUST completely specify the structure of all three of the specified values for each defined mode, as well as the behavior of tze_verify and any contextual information required.

The encoded forms of precondition and witness are not required to be constant-length, but SHOULD be solely determined by the pair (type, mode).

The introduction of TZEs by this ZIP produces a new transparent unspent outpoint set, distinct from the UTXO set, such that indices into this set of outpoints may be referred to by TZE inputs in spending transactions.

Encoding in transactions

We define a new transaction format that contains two new fields:

• tze_outputs: A list of pairs of:
  • The value being encumbered.
  • The precondition that must be satisfied to spend the value.
• tze_inputs: A list of pairs of:
  • An outpoint referencing a prior precondition.
  • A witness that satisfies it.

The transaction format is required to be non-malleable, in the sense that any change to the effects of the transaction will change its transaction ID, but any valid change to a witness inside tze_inputs will not change the transaction ID. This will be specified in a separate ZIP.

A new version <TBD> transaction format and corresponding version group identifier <TBD> will be introduced in the hard-fork network upgrade that introduces TZE functionality. The version <TBD> format differs from the version 4 transaction format as follows: a length-prefixed encoding of TZE inputs and outputs are added to the serialized transaction format immediately following the fields representing transparent inputs and outputs.

Both tze_in and tze_out vectors make use of the common serialized form tze_data described below. Serialization of all integer and vector types is as with Bitcoin.

tze_data encoding:

TZE Input Encoding:

TZE Output Encoding:

Consensus rules

Once this ZIP becomes active, the following new consensus rules are enforced:

• For each (outpoint, witness) pair in tze_inputs:
  • outpoint MUST reference a precondition of the same type and mode in an already-mined transaction.
  • tze_verify(mode, precondition, witness, context) MUST return true.
• If a transaction has non-empty tze_inputs and non-empty tze_outputs, then every element in both fields MUST have the same type in order to eliminate the possibility for cross-extension attacks. As this is not a consideration in the case that only tze_inputs or only tze_outputs are present, the extension type MAY vary between elements in that case.
• Non-coinbase transactions MUST have at least one of the following: - nonempty transparent inputs - nonempty shielded inputs - nonempty tze_inputs

The above rule replaces [Sapling onward] At least one of tx_in_count, nShieldedSpend, and nJoinSplit MUST be nonzero in 4.

• Transactions MUST have at least one of the following: - nonempty transparent outputs - nonempty shielded outputs - nonempty tze_outputs
• All amount field values of tze_output records MUST be nonnegative and not greater than MAX_MONEY.
• The sum of amounts going out of the transparent value pool of a transaction (that is, Bitcoin-style outputs and TZE outputs, plus JoinSplit vpub_old values) MUST NOT exceed the sum of amounts going into that pool (that is, Bitcoin-style inputs and TZE inputs, plus JoinSplit vpub_new values, plus the Sapling valueBalance amount).

Changes to signatures over transaction digests

This ZIP MUST be deployed in conjunction with or after ZIP 244 7, which defines new non-malleable transaction identifier and signature digest algorithms.

The newly added parts of the transaction, excluding witness information (i.e. not the witness fields of TZE Input Encodings), will be included in transaction digests for transaction identifiers and signatures. See ZIP 245 8 for the specification of these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well.