Protocol Bundles

This ZIP refines and codifies the concept of "protocol bundles" that emerged from the implementation of the ZIP 225 9 transaction format. It makes bundles first-class objects and defines a registry of bundle type and variant identifiers. Within the period that a given transaction format version is used on the Zcash network, the semantics of the bundle associated with a given (bundleType, bundleVariant) pair are fixed.

A protocol bundle is a self-contained component of a transaction that implements a specific piece of protocol functionality. Each bundle is identified by a (bundleType, bundleVariant) pair, where:

• The bundle type identifies the protocol or value pool that the bundle operates on (e.g., Transparent, Sapling, Orchard).
• The bundle variant identifies a specific variant of that protocol. New variants of an existing bundle type may be introduced by subsequent ZIPs to evolve a protocol's functionality while preserving the association with the same value pool.

A transaction MUST NOT contain more than one variant of any given bundle type. This constraint is enforced by the map structure of the transaction encoding: the maps mEffectBundles, and mAuthBundles are each keyed by bundleType alone; mValuePoolDeltas is keyed by bundle type and asset ID.

Each bundle type/variant pair defines:

• What effecting data the bundle contains — the data that determines what state changes the bundle produces (e.g., which notes are spent, which outputs are created, which transparent UTXOs are consumed or produced).
• What authorizing data the bundle contains — the proofs and signatures that authorize the state changes specified by the effecting data.
• How the bundle affects the transparent transaction value pool — whether the bundle adds value to, removes value from, or has no effect on this ephemeral pool that balances value flows within a transaction.

Transaction Format

mValuePoolDeltas is interpreted as a map keyed by the tuple \((\mathsf{BundleType}, \mathsf{AssetUuid})\!\) ; this logical map MUST NOT contain more than a single entry for a given key. The ValuePoolDelta records that represent the entries this map MUST be encoded in increasing order of (bundleType, assetClass, assetUuid) Lookups in this map are denoted with the syntax \(\mathsf{mValuePoolDeltas}[(\mathsf{BundleType}, \mathsf{AssetUuid})].\)

mEffectBundles and mAuthBundles are interpreted as maps keyed by bundleType. The records that represent each map entry map MUST be encoded in increasing order of bundleType. Each map MUST NOT contain more than a single entry for a given bundleType. For each bundleType that exists in mAuthBundles, a corresponding entry with the same bundleVariant must exist in mEffectBundles.

ValuePoolDelta

mValuePoolDeltas is interpreted as a map keyed by the tuple \((\mathsf{BundleType}, \mathsf{AssetUuid}).\) The map MUST NOT contain more than a single entry for a given key. Lookups in this map are denoted with the syntax \(\mathsf{mValuePoolDeltas}[(\mathsf{BundleType}, \mathsf{AssetUuid})].\)

All entries in mValuePoolDeltas having the same bundleType MUST have the same bundleVariant.

Let \(\mathsf{Zec}\) be a distinguished value representing the ZEC asset. It is used as the asset identifier when \(\mathsf{assetClass} = 0\!\) .

Let \(\mathsf{AssetUuid}(\mathsf{d})\) be the asset indicated by the mValuePoolDeltas entry \(\mathsf{d}.\)

BundleData

Transparent Bundle

Sapling Bundle

Orchard Bundle

Consensus Rules

This ZIP requires the following modifications to the consensus rules in the Zcash Protocol Specification.

Let FeeBundleId be the identifier of the fee bundle. In V6 transactions, \(\mathsf{FeeBundleId} = 4\) as defined in the table above.

The following transaction validity rules are added:

• The assetClass value for any entry in mValuePoolDeltas having bundleType = FeeBundleId is 0 (fee amounts are denominated in ZEC and no other asset.)
• For coinbase transactions, the value of \(\mathsf{mValuePoolDeltas}[(\mathsf{FeeBundleId}, \mathsf{Zec})]\) must be nonnegative. This represents the total transaction fees collected from all other transactions in the block.
• For non-coinbase transactions, the value of \(\mathsf{mValuePoolDeltas}[(\mathsf{FeeBundleId}, \mathsf{Zec})]\) must be nonpositive. This represents the transaction fee paid by the transaction (expressed as a negative value, since it is removed from the transparent transaction value pool).
• Within the scope of a block, the sum of the fee bundle values must equal 0. That is, the fees collected by the coinbase transaction must equal the sum of fees paid by all other transactions in the block.
• For each bundleType that appears in any of mValuePoolDeltas, mEffectBundles, or mAuthBundles, all entries for that bundleType across all three maps MUST have the same bundleVariant. (This, combined with the constraint that each map is keyed by bundleType, ensures that a transaction uses at most one variant of any given bundle type.)
• For the coinbase transaction, the sum of value pool deltas in the ZEC asset is equal to the negative of the block subsidy for that block; the block subsidy adds an implicit input value to the transparent transaction value pool that the coinbase outputs consume.
  \(\sum_{\mathsf{d} \in \mathsf{mValuePoolDeltas} | \mathsf{AssetUuid}(\mathsf{d}) = \mathsf{Zec}} \mathsf{d.value} = -\mathsf{BlockSubsidy}(\mathsf{height})\)

  where \(\mathsf{BlockSubsidy}\) is defined in § 7.8 'Block Subsidy and Founders' Reward'. 5

• For all non-coinbase transactions, the sum of value pool delta values in each asset equals 0.
  \(\forall \mathsf{a}. \sum_{\mathsf{d} \in \mathsf{mValuePoolDeltas} | \mathsf{AssetUuid}(\mathsf{d}) = \mathsf{a}} \mathsf{d.value} = 0\)

Digest Algorithms

All digests are personalized BLAKE2b-256 hashes. In cases where no elements are available for hashing (for example, if there are no transparent transaction inputs), a personalized hash of the empty byte array will be used. The personalization string therefore provides domain separation for the hashes of even empty data fields.

The notation BLAKE2b-256(personalization_string, []) is used to refer to hashes constructed in this manner.

TxId Digest

A new transaction digest algorithm is defined that constructs the identifier for a V6 transaction from a tree of hashes. The overall structure of the hash is as follows:

txid_digest
├── header_digest
├── value_pool_deltas_digest
└── effects_bundles_digest
    ├─ (bundle_type_id || bundle_variant || transparent_effects_digest)
    ├─ (bundle_type_id || bundle_variant || sapling_effects_digest)
    │   ├── sapling_spends_digest
    │   │   ├── sapling_spends_compact_digest
    │   │   └── sapling_spends_noncompact_digest
    │   └── sapling_outputs_digest
    │       ├── sapling_outputs_compact_digest
    │       ├── sapling_outputs_memos_digest
    │       └── sapling_outputs_noncompact_digest
    ├─ (bundle_type_id || bundle_variant || orchard_effects_digest)
    │   ├── orchard_actions_compact_digest
    │   ├── orchard_actions_memos_digest
    │   └── orchard_actions_noncompact_digest
    └─ (bundle_type_id || bundle_variant || unknown_bundle_effects_digest) ...

Each node written as snake_case in this tree is a BLAKE2b-256 hash of its children, initialized with a personalization string specific to that branch of the tree. Nodes that are not themselves digests are written in camelCase. In the specification below, nodes of the tree are presented in depth-first order.

txid_digest

A BLAKE2b-256 hash of the following values:

T.1: header_digest             (32-byte hash output)
T.2: value_pool_deltas_digest  (32-byte hash output)
T.3: effects_bundles_digest    (32-byte hash output)

The personalization field of this hash is set to:

"ZcashTxHash_" || CONSENSUS_BRANCH_ID

ZcashTxHash_ has 1 underscore character.

As in ZIP 143 6, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction.

T.1: header_digest

A BLAKE2b-256 hash of the following values:

T.1a: version             (4-byte little-endian version identifier including overwintered flag)
T.1b: nVersionGroupId    (4-byte little-endian version group identifier)
T.1c: nConsensusBranchId (4-byte little-endian consensus branch id)
T.1d: lock_time           (4-byte little-endian nLockTime value)
T.1e: nExpiryHeight       (4-byte little-endian block height)

The personalization field of this hash is set to:

"ZTxIdHeadersHash"

T.2: value_pool_deltas_digest

A BLAKE2b-256 hash of the concatenated encodings of all entries in mValuePoolDeltas, in transaction order. For each entry, the following values are concatenated:

T.2a: bundleType    (compactSize encoding)
T.2b: bundleVariant (compactSize encoding)
T.2c: assetClass    (1 byte)
T.2d: assetUuid     (0 or 64 bytes, depending on assetClass)
T.2e: value         (8-byte signed little-endian)

The personalization field of this hash is set to:

"ZTxIdVPDeltaHash"

In the case that the transaction has no value pool delta entries (which would only occur for transactions that have no effect on any value pool), value_pool_deltas_digest is:

BLAKE2b-256("ZTxIdVPDeltaHash", [])

T.3: effects_bundles_digest

A BLAKE2b-256 hash of the concatenated tagged bundle effect digests for all bundles present in mEffectBundles, in transaction order. For each bundle, the following values are concatenated:

T.3a: bundleType            (compactSize encoding)
T.3b: bundleVariant         (compactSize encoding)
T.3c: bundle_effects_digest (32-byte hash output)

where bundle_effects_digest is the root hash of the bundle's effecting data tree, as defined below for each known bundle type.

The personalization field of this hash is set to:

"ZTxIdEffBndHash"

In the case that the transaction has no effect bundles, effects_bundles_digest is:

BLAKE2b-256("ZTxIdEffBndHash", [])

T.3.0: transparent_effects_digest

In the case that transparent inputs or outputs are present, the transparent effects digest is a BLAKE2b-256 hash of the following values:

T.3.0a: prevouts_digest  (32-byte hash)
T.3.0b: sequence_digest  (32-byte hash)
T.3.0c: outputs_digest   (32-byte hash)

The personalization field of this hash is set to:

"ZTxIdTranspaHash"

In the case that the transaction has no transparent components, transparent_effects_digest is:

BLAKE2b-256("ZTxIdTranspaHash", [])

T.3.0a: prevouts_digest

A BLAKE2b-256 hash of the field encoding of all (prevout_hash, prevout_index) pairs from the transparent effecting data.

The personalization field of this hash is set to:

"ZTxIdPrevoutHash"

In the case that the transaction has transparent outputs but no transparent inputs, prevouts_digest is:

BLAKE2b-256("ZTxIdPrevoutHash", [])

T.3.0b: sequence_digest

A BLAKE2b-256 hash of the 32-bit little-endian representation of all nSequence field values from the transparent effecting data.

The personalization field of this hash is set to:

"ZTxIdSequencHash"

In the case that the transaction has transparent outputs but no transparent inputs, sequence_digest is:

BLAKE2b-256("ZTxIdSequencHash", [])

T.3.0c: outputs_digest

A BLAKE2b-256 hash of the concatenated field encodings of all transparent outputs. The field encoding of each output consists of the encoded output value (8-byte little endian) followed by the scriptPubKey byte array (with leading compactSize length).

The personalization field of this hash is set to:

"ZTxIdOutputsHash"

In the case that the transaction has transparent inputs but no transparent outputs, outputs_digest is:

BLAKE2b-256("ZTxIdOutputsHash", [])

T.3.2: sapling_effects_digest

In the case that Sapling spends or outputs are present, the Sapling effects digest is a BLAKE2b-256 hash of the following values:

T.3.2a: sapling_spends_digest   (32-byte hash)
T.3.2b: sapling_outputs_digest  (32-byte hash)
T.3.2c: anchorSapling           (32 bytes)

The personalization field of this hash is set to:

"ZTxIdSaplingHash"

Note that unlike ZIP 244, the value balance is not included here; it is committed via value_pool_deltas_digest instead.

In the case that the transaction has no Sapling spends or outputs, sapling_effects_digest is:

BLAKE2b-256("ZTxIdSaplingHash", [])

T.3.2a: sapling_spends_digest

In the case that Sapling spends are present, this digest is a BLAKE2b-256 hash of the following values:

T.3.2a.i:  sapling_spends_compact_digest    (32-byte hash)
T.3.2a.ii: sapling_spends_noncompact_digest (32-byte hash)

The personalization field of this hash is set to:

"ZTxIdSSpendsHash"

In the case that the transaction has Sapling outputs but no Sapling spends, sapling_spends_digest is:

BLAKE2b-256("ZTxIdSSpendsHash", [])

T.3.2a.i: sapling_spends_compact_digest

A BLAKE2b-256 hash of the field encoding of all nullifier field values of Sapling spends belonging to the transaction.

The personalization field of this hash is set to:

"ZTxIdSSpendCHash"

T.3.2a.ii: sapling_spends_noncompact_digest

A BLAKE2b-256 hash of the non-nullifier information for all Sapling spends belonging to the transaction. For each spend, the following elements are included in the hash:

T.3.2a.ii.1: cv     (32 bytes)
T.3.2a.ii.2: anchor (32 bytes)
T.3.2a.ii.3: rk     (32 bytes)

The anchor is hashed for each spend (even though it is shared in the encoding).

The personalization field of this hash is set to:

"ZTxIdSSpendNHash"

T.3.2b: sapling_outputs_digest

In the case that Sapling outputs are present, this digest is a BLAKE2b-256 hash of the following values:

T.3.2b.i:   sapling_outputs_compact_digest    (32-byte hash)
T.3.2b.ii:  sapling_outputs_memos_digest      (32-byte hash)
T.3.2b.iii: sapling_outputs_noncompact_digest (32-byte hash)

The personalization field of this hash is set to:

"ZTxIdSOutputHash"

In the case that the transaction has Sapling spends but no Sapling outputs, sapling_outputs_digest is:

BLAKE2b-256("ZTxIdSOutputHash", [])

T.3.2b.i: sapling_outputs_compact_digest

A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP 307 12 CompactBlock format for all Sapling outputs belonging to the transaction. For each output, the following elements are included:

T.3.2b.i.1: cmu                  (32 bytes)
T.3.2b.i.2: ephemeralKey         (32 bytes)
T.3.2b.i.3: encCiphertext[..52]  (first 52 bytes)

The personalization field of this hash is set to:

"ZTxIdSOutC__Hash" (2 underscore characters)

T.3.2b.ii: sapling_outputs_memos_digest

A BLAKE2b-256 hash of the memo field data for all Sapling outputs belonging to the transaction. For each output:

T.3.2b.ii.1: encCiphertext[52..564] (512 bytes, encrypted memo)

The personalization field of this hash is set to:

"ZTxIdSOutM__Hash" (2 underscore characters)

T.3.2b.iii: sapling_outputs_noncompact_digest

A BLAKE2b-256 hash of the remaining Sapling output information not included in the CompactBlock format. For each output:

T.3.2b.iii.1: cv                    (32 bytes)
T.3.2b.iii.2: encCiphertext[564..]  (post-memo AEAD tag, 16 bytes)
T.3.2b.iii.3: outCiphertext         (80 bytes)

The personalization field of this hash is set to:

"ZTxIdSOutN__Hash" (2 underscore characters)

T.3.3: orchard_effects_digest

In the case that Orchard actions are present, the Orchard effects digest is a BLAKE2b-256 hash of the following values:

T.3.3a: orchard_actions_compact_digest    (32-byte hash)
T.3.3b: orchard_actions_memos_digest      (32-byte hash)
T.3.3c: orchard_actions_noncompact_digest (32-byte hash)
T.3.3d: flagsOrchard                      (1 byte)
T.3.3e: anchorOrchard                     (32 bytes)

The personalization field of this hash is set to:

"ZTxIdOrchardHash"

Note that unlike ZIP 244, the value balance is not included here; it is committed via value_pool_deltas_digest instead.

In the case that the transaction has no Orchard actions, orchard_effects_digest is:

BLAKE2b-256("ZTxIdOrchardHash", [])

T.3.3a: orchard_actions_compact_digest

A BLAKE2b-256 hash of the subset of Orchard action information intended for inclusion in the CompactBlock format. For each action:

T.3.3a.i:   nullifier            (32 bytes)
T.3.3a.ii:  cmx                  (32 bytes)
T.3.3a.iii: ephemeralKey         (32 bytes)
T.3.3a.iv:  encCiphertext[..52]  (first 52 bytes)

The personalization field of this hash is set to:

"ZTxIdOrcActCHash"

T.3.3b: orchard_actions_memos_digest

A BLAKE2b-256 hash of the memo field data for all Orchard actions. For each action:

T.3.3b.i: encCiphertext[52..564] (512 bytes, encrypted memo)

The personalization field of this hash is set to:

"ZTxIdOrcActMHash"

T.3.3c: orchard_actions_noncompact_digest

A BLAKE2b-256 hash of the remaining Orchard action information not intended for inclusion in the CompactBlock format. For each action:

T.3.3c.i:   cv                   (32 bytes)
T.3.3c.ii:  rk                   (32 bytes)
T.3.3c.iii: encCiphertext[564..] (post-memo AEAD tag, 16 bytes)
T.3.3c.iv:  outCiphertext        (80 bytes)

The personalization field of this hash is set to:

"ZTxIdOrcActNHash"

Signature Digest

A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. This follows closely the algorithm from ZIP 244 11.

For transactions that have no transparent inputs, the signature digest is identical to the transaction identifier digest.

For transactions with transparent inputs, the signature digest replaces effects_bundles_digest with a signature_bundles_digest that incorporates hash_type-dependent transparent signing data:

signature_digest
├── header_digest
├── value_pool_deltas_digest
└── signature_bundles_digest

signature_digest

A BLAKE2b-256 hash of the following values:

S.1: header_digest             (32-byte hash output)
S.2: value_pool_deltas_digest  (32-byte hash output)
S.3: signature_bundles_digest  (32-byte hash output)

The personalization field of this hash is set to:

"ZcashTxHash_" || CONSENSUS_BRANCH_ID

This value has the same personalization as the transaction identifier digest, so that what is being signed in the case that there are no transparent inputs is exactly the transaction id.

S.3: signature_bundles_digest

If the transaction has no transparent inputs, signature_bundles_digest is identical to effects_bundles_digest.

Otherwise, signature_bundles_digest is constructed the same as effects_bundles_digest, except that transparent_effects_digest is replaced with transparent_sig_digest.

S.3.0: transparent_sig_digest

This digest is a BLAKE2b-256 hash of the following values:

S.3.0a: hash_type                (1 byte)
S.3.0b: prevouts_sig_digest      (32-byte hash)
S.3.0c: amounts_sig_digest       (32-byte hash)
S.3.0d: scriptpubkeys_sig_digest (32-byte hash)
S.3.0e: sequence_sig_digest      (32-byte hash)
S.3.0f: outputs_sig_digest       (32-byte hash)
S.3.0g: txin_sig_digest          (32-byte hash)

The personalization field of this hash is set to:

"ZTxIdTranspaHash"

S.3.0a: hash_type

An 8-bit unsigned value. The SIGHASH encodings from the legacy script system are used: one of SIGHASH_ALL (0x01), SIGHASH_NONE (0x02), or SIGHASH_SINGLE (0x03), optionally combined with SIGHASH_ANYONECANPAY (0x80).

The following restrictions apply:

• Using any undefined hash_type (not 0x01, 0x02, 0x03, 0x81, 0x82, or 0x83) causes validation failure.
• Using SIGHASH_SINGLE without a corresponding output at the same index causes validation failure.

For signatures over Sapling Spends or Orchard Actions, hash_type is set to SIGHASH_ALL (0x01).

S.3.0b: prevouts_sig_digest

If the SIGHASH_ANYONECANPAY flag is not set, identical to prevouts_digest (T.3.0a).

Otherwise:

BLAKE2b-256("ZTxIdPrevoutHash", [])

S.3.0c: amounts_sig_digest

If the SIGHASH_ANYONECANPAY flag is not set, a BLAKE2b-256 hash of the concatenation of the 8-byte signed little-endian representations of all value fields for the coins spent by the transparent inputs to the transaction.

The personalization field of this hash is set to:

"ZTxTrAmountsHash"

If the SIGHASH_ANYONECANPAY flag is set:

BLAKE2b-256("ZTxTrAmountsHash", [])

S.3.0d: scriptpubkeys_sig_digest

If the SIGHASH_ANYONECANPAY flag is not set, a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading compactSize) of all scriptPubKey fields for the coins spent by the transparent inputs.

The personalization field of this hash is set to:

"ZTxTrScriptsHash"

If the SIGHASH_ANYONECANPAY flag is set:

BLAKE2b-256("ZTxTrScriptsHash", [])

S.3.0e: sequence_sig_digest

Identical to sequence_digest (T.3.0b) regardless of hash_type.

S.3.0f: outputs_sig_digest

If the sighash type is neither SIGHASH_SINGLE nor SIGHASH_NONE, identical to outputs_digest (T.3.0c).

If the sighash type is SIGHASH_SINGLE and a transparent output exists at the same index as the input being signed, a hash of that output's encoding.

Otherwise:

BLAKE2b-256("ZTxIdOutputsHash", [])

S.3.0g: txin_sig_digest

For signatures over a transparent input, a BLAKE2b-256 hash of:

S.3.0g.i:   prevout      (36 bytes: 32-byte hash + 4-byte index)
S.3.0g.ii:  value        (8-byte signed little-endian)
S.3.0g.iii: scriptPubKey (with compactSize length prefix)
S.3.0g.iv:  nSequence    (4-byte unsigned little-endian)

The personalization field of this hash is set to:

"Zcash___TxInHash" (3 underscores)

For signatures over a Sapling Spend or Orchard Action:

BLAKE2b-256("Zcash___TxInHash", [])

auth_digest
└── auth_bundles_digest
    ├─ (bundle_type_id || bundle_variant || transparent_auth_digest)
    ├─ (bundle_type_id || bundle_variant || sapling_auth_digest)
    ├─ (bundle_type_id || bundle_variant || orchard_auth_digest)
    └─ (bundle_type_id || bundle_variant || unknown_bundle_auth_digest) ...

A.1: auth_bundles_digest (32-byte hash output)

"ZTxAuthHash_" || CONSENSUS_BRANCH_ID

A.1a: bundleType          (compactSize encoding)
A.1b: bundleVariant       (compactSize encoding)
A.1c: bundle_auth_digest  (32-byte hash output)

"ZTxAuthBndHash"

BLAKE2b-256("ZTxAuthBndHash", [])

"ZTxAuthTransHash"

BLAKE2b-256("ZTxAuthTransHash", [])

A.1.2a: vSpendProofsSapling    (192 bytes per spend)
A.1.2b: vSpendAuthSigsSapling  (64 bytes per spend)
A.1.2c: vOutputProofsSapling   (192 bytes per output)
A.1.2d: bindingSigSapling      (64 bytes)

"ZTxAuthSapliHash"

BLAKE2b-256("ZTxAuthSapliHash", [])

A.1.3a: proofsOrchard         (aggregated proofs)
A.1.3b: vSpendAuthSigsOrchard (64 bytes per action)
A.1.3c: bindingSigOrchard     (64 bytes)

"ZTxAuthOrchaHash"

BLAKE2b-256("ZTxAuthOrchaHash", [])

Implications for Wallets

Strawman

Modify how we approach transaction format evolution, such that (after one more change to transaction encoding) it is possible for a wallet that has not adopted a parser for a given transaction format to continue to function after an additive change to the transaction format. Another way to state this is that we should make it possible to make "semver-compatible" transaction format changes.

• @str4d: We could use a TLV approach where each "bundle" has a value balance. The NSM burn amount field could be its own bundle, the explicit fee data could be its own bundle and the consensus rule could be that all value balances sum to zero.
  • generically, you want a value balance vector, where you have zero or more value balances moving between bundles in other assets.
• @nuttycom: You could have pre-ZSA and post-ZSA Orchard bundles.

Strawman II

Treat bundles as individually versioned.

• Each bundle is registered with an ID relative to a tx version group ID.
• The bundle ID encoding also has some flag bits indicating how it interacts with the tx as a whole.
• Transactions then have two "bundle maps":
  • The first encodes how value moves between the different bundles.
  • The second encodes data specific to a bundle (e.g. how value moves within a bundle)
  • Bundles that don't have any data would just appear in the first map, and bundles that don't produce or consume value would just appear in the second map.
• We can re-interpret various other facets of transactions as "bundles"
  • Explicit fees are a bundle that never produces value
  • NSM field similarly never produces value
  • ZSA burns would be split into "value balance out of Orchard pool" and "value balance being removed from ZSA issuance"
  • See also the conversation we had about refactoring coinbase transactions. TODO: Figure out how to integrate the two.
• Privacy effect is minimal
  • We already follow a bundle approach with a transparent transaction value pool, for the turnstiles. This leans into it, while preserving the bundle boundary within which we implement each privacy protocol.
  • Some combinations of bundles would be permitted by the tx format that were not previously permitted.
    • However, we can still restrict which combinations of bundles can be mined in the consensus rules.

Sketch of the format:

• Transaction version (like now)
  • Version
  • Version group ID
• Transaction header
  • Expiry height etc
  • Likely need some kind of key-value map here to allow additional fields to be added, or maybe version the header to allow evolution?
• Transparent transaction value pool "traffic map"
  • Option 1: BundleVariantID -> (valueBalance, AssetId -> valueBalance)
    • Key: Bundle variant ID
    • Value:
      • ZEC valueBalance
      • CompactSize len(generalizedValueBalances)
      • Zero or more generalized value balances
        • AssetId (not AssetBase because those are protocol-specific, and we want generalized value balances to be understandable independently of protocol changes)
        • valueBalance
  • Option 2: (BundleVariantID, Option[AssetId]) -> valueBalance
    • Key: Bundle variant ID encoded as u8 || { Option[AssetId] }
    • Value: valueBalance
  • Option 3: BundleVariantID -> Option[AssetId] -> valueBalance
    • Key: Bundle variant ID
    • Value:
      • Map containing one or more generalized value balances
        • { Option[AssetId] }
        • valueBalance
• Sequence of bundles (maybe with a length prefix?)
  • Bundle variant ID
    • Maybe flag bits, either in the variant ID or next to it, that indicate how an opaquely-parsing wallet should interpret the bundle, e.g.:
      • A bit that says whether or not the bundle interacts with the transparent transaction value pool (which memo bundles would not have).
        • Counterpoint: The traffic map already specifies whether a given bundle does have an interaction with the transparent tx value pool for this tx. This is different from whether that kind of bundle can interact with the transparent tx value pool, but it the latter needed?
      • A bit that says whether the bundle has any other effect than what is specified in the traffic map.
        • Counterpoint: We should split apart effecting and authorizing data in the encoding, and then a bundle must be assumed effecting iff it has non-null effecting data.
  • CompactSize len(effectingData)
  • effectingData
  • CompactSize len(authorizingData)
  • authorizingData
    • effectingData and authorizingData would be opaque to the initial parser.
    • Parsers that support parsing (tx_version, bundle_version) know how to interpret its internals

Questions

• Is it okay for fee calculations to be opaque to wallet parsers, as long as the fee amounts can be calculated in consensus?
  • Yes:
    • When receiving, all you care about is knowing the actual fee amount; you see that in the fee bundle's value balance.
    • When sending, you need to understand all bundles you are including, and then you can calculate the fee.
• Can wallets still compute the txid and wtxid of an arbitrary transaction?
  • Yes, provided that effecting and authorizing data is separated. Then they can hash the effecting data even without understanding it to compute the txid, and they can hash the authorizing data even without understanding it to compute the authorizing data commitment part of the wtxid (ZIP 239 10).
  • However, this reintroduces a more direct linkage between the [w]txid computation and the transaction encoding. It's arguably fine, and potentially simpler -- since the [w]txid computation need not change at all for most protocol changes.
  • If the hashing uses flat hashes over the effectingData and authorizingData of each bundle (which it has to because the internal structure is not known), then it might be more difficult to do Merkle proofs over subsets of the data within a bundle. We haven't used that so far; is it really needed?
  • Should the authorizing data be entirely separate from the effecting data, and encoded at the end of the transaction in a batch, so that pruning is simply truncation?
• The light wallet protocol will be updated to allow the client to specify the set of bundle types that the client understands. In the case that this information is provided, the light client server will then send the root hashes for each bundle type that the client does not understand when returning raw transaction data, so that the light client can correctly recompute and validate the txid; also, the compact transactions can be pruned to exclude bundles of bundle types. that the client will not understand.