Announcement and AMA:
https://x.com/bitjson/status/1884677494894453208
Summary
This proposal introduces a version 5 transaction format, enables fractional satoshis and fractional CashTokens, simplifies contracts, and optimizes transaction sizes.
Benefits
-
Zero-Overhead Covenants – Enable user-deployed financial and privacy covenants to minimize transaction sizes, matching or outperforming purpose-built, “layer 1” networks. See Example: Zero-Knowledge Proof Covenants.
-
Detached (“Cross-Input”) Signatures – Reduce transaction sizes by enabling multiple inputs to reference the same signature(s). See Example: Single-Signature Sweeps.
-
Comprehensive Malleability Protection – Optionally covers all unlocking bytecode, simplifying security audits and allowing contracts to eliminate piecemeal protections. Non-push unlocking bytecode also enables significant savings for transactions spending multiple similar inputs.
-
Efficient Covenant UTXO Recycling – Enables the economical inclusion of recycling code paths in covenants, allowing covenant systems to recover dust from obsolete UTXOs. See Example: Recycling Covenant Dust.
-
Fractional Satoshis – Prepare Bitcoin Cash for significantly increased scale and adoption (while saving up to 6 bytes per output vs. the existing encoding).
-
Fractional CashTokens – Simplify the operational requirements of large, highly-liquid CashTokens like stablecoins and real-world assets by optionally allowing up to 19 decimal places of additional precision.
Examples
The following examples highlight efficiency improvements made possible by v5 transactions.
Zero-Knowledge Proof Covenants
This proposal enables zero-overhead covenants: user-deployed protocols with the same bandwidth efficiency as “layer 1” networks.
For example, a zero-knowledge proof (ZKP) contract system could be designed to perform validation of proofs within a read-only input known to the covenant (by outpoint) or marked by a tracking CashToken. Such ZKP transactions might include three inputs and two outputs:
-
Input 0(read-only): The ZKP is provided in this unlocking bytecode. The locking bytecode verifies that the transaction is correctly structured and that the ZKP justifies the state transition between the previous application state (Input 1) and the next application state (output 0). -
Input 1: A covenant holding the previous application state and any BCH, spendable only ifInput 0is the expected ZKP-verifying contract. (Any combination of other tokens may be controlled by sidecar UTXOs, omitted or included as necessary for deposits/withdrawals.) -
Input 2: A user-provided input to fund any deposit(s) and the transaction’s mining fee. -
Output 0: The updated covenant holding the new application state and any BCH. -
Output 1: A user-controlled output to hold any withdrawals or remaining “change” in BCH (ifInput 2isn’t entirely consumed).
Note the bandwidth-efficiency of this transaction: it encodes 1) deposited/withdrawn asset amounts and details 2) the covenant’s “after” state (the “before” state is known via Input 1), and 3) the proof. In particular, both the covenants “before” state and the bytecode evaluated to verify the proof – possibly many hundreds or thousands of bytes – is omitted from the transaction (and de-duplicated in the blockchain).
In short, this ZKP protocol is just as bandwidth-efficient as if it were “built-in” to Bitcoin Cash via consensus upgrade.
Following activation of this proposal, Bitcoin Cash covenants could simultaneous support a wide variety of financial and privacy technologies using transaction sizes no larger than those of purpose-built, “layer 1” networks.
Further, Bitcoin Cash covenants are better positioned to safely adopt new technologies: other networks require extensive development, testing, and advocacy prior to the deployment of upgrades, while equally-efficient Bitcoin Cash covenants can be deployed immediately, at negligible cost, without risk to the wider Bitcoin Cash network, and with risks precisely controlled by the end user (i.e. only the minimal assets trusted to a new system can be lost by a vulnerability in that system).
Finally, deployed technologies on other networks often trail significantly behind the “state of the art” (e.g. in proof sizes). Zero-overhead covenants allow Bitcoin Cash to consistently outperform these other networks in transaction sizes, scalability, and overall user experiences.
Single-Signature Sweeps
This proposal enables significant reductions in common transaction sizes by sharing signatures across inputs and re-enabling non-push unlocking bytecode.
For example, a transaction spending many Pay-to-Public-Key-Hash (P2PKH) outputs may unlock the 0th input with unlocking bytecode: OP_0 <a.public_key> (35 bytes), where the OP_0 indicates the 0th detached signature. Later inputs may then be spent simply by evaluating the push instructions from the 0th input: OP_0 OP_INPUTBYTECODE OP_EVAL (3 bytes per input).
Once constructed, the entire encoded transaction can be signed only once (by a.public_key), with the signature placed in the 0th detached signature slot, preventing malleation of any portion of the transaction.
Recycling Covenant Dust
This proposal resolves a long-standing incentive alignment issue in contract design: covenant UTXOs which have reached the end of their lifecycle (and in many cases, may be provably unspendable) often remain in the UTXO set for lack of a fee-efficient recycling code path.
Prior to this proposal, the aggregate cost of replicating a recycling code path across a covenant’s lifecycle often exceeded the recovered value, even for very short bytecode lengths.
For example, consider this “wrapper” allowing a covenant UTXO to be recycled once its value reaches some minimum value (600 sats): OP_INPUTINDEX OP_UTXOVALUE <600> OP_LESSTHAN OP_NOTIF other_contract_code OP_ENDIF (adds 8 bytes). If this covenant were re-created across a chain of 100 transactions, the transaction fees required (currently 1 byte/sat) for the cumulative overhead contributed by the wrapper (800 bytes) would exceed the expected value of the recovered dust.
Following this proposal, any covenant can be designed such that the aggregate cost of recycling code paths are small and constant: by including recycling code path(s) in read-only inputs, fees paid for inclusion of recycling bytecode are limited to the initial setup transaction(s). As recycling bytecode can be omitted from all later transactions, covenant dust can be economically collected in nearly all cases.
High-Liquidity CashTokens
Prior to this proposal, high-liquidity CashTokens (particularly stablecoins) were forced to navigate a minor tradeoff in denominating their CashToken: larger units reduce the encoding size in most transactions and enable a larger overall supply, but smaller units may be necessary for sufficient precision in important markets and use cases.
For example, using indivisible CashTokens, a USD-backed stablecoin issuer might denominate its stablecoin using 6 decimal places (i.e. 1000000 fungible tokens represent $1) – sufficient precision to accommodate the minimum tick size in today’s largest financial markets (allowing on-chain settlements without batching or precision-handling edge cases).
However, at 6 decimal places, nearly all common output amounts require 5 bytes (e.g. $1 is 0xfe40420f00) or more, whereas at 2 decimal places, many smaller output amounts require only 1 byte (e.g. $1 is 0x64) or 3 bytes (e.g. $655.35 is 0xfdffff). Additionally, at 6 decimal places, the maximum indivisible fungible token supply can represent only $9.2 trillion USD, leaving less than one order of magnitude between the current “market cap” of all cryptocurrencies and the stablecoin’s maximum-supportable supply. This leaves room for plausible concern about migration strategies and/or multi-category issuance schemes, particularly in the event of rapid inflation in the underlying fiat currency.
Following this proposal, this minor tradeoff is alleviated: in addition to the issuer’s chosen number of decimal places, **up to 19 decimal places of additional precision are available for all fractional CashTokens.
I’m proposing this upgrade for chipnet lock-in November 2026, mainnet deployment May 2027.
