OP_TXHASH

What Is OP_TXHASH?

OP_TXHASH is a proposed Bitcoin Script opcode, specified in BIP 346 by Steven Roose and Brandon Black, that computes a hash over a configurable subset of the spending transaction's fields and pushes the resulting 32-byte digest onto the stack. By selecting which parts of the transaction to commit to, scripts can enforce spending conditions on specific outputs, amounts, or sequences while leaving other fields unconstrained.

The proposal generalizes the approach taken by OP_CHECKTEMPLATEVERIFY (CTV). Where CTV hashes a fixed set of transaction fields and verifies the result against an expected value, OP_TXHASH introduces a TxFieldSelector structure that gives script authors fine-grained control over what gets hashed. This makes OP_TXHASH strictly more expressive: any covenant that CTV can enforce, TXHASH can replicate by selecting the same fields and checking the hash with OP_EQUALVERIFY. In fact, an empty TxFieldSelector defaults to the same field set that CTV uses, making the equivalence explicit.

The opcode is designed for Tapscript only, redefining OP_SUCCESS189, one of the reserved success codes that Taproot set aside for future soft-fork upgrades. The BIP was merged into the bitcoin/bips repository in January 2026 as a draft, though no activation timeline has been set.

How It Works

OP_TXHASH operates in three steps: it reads a TxFieldSelector from the stack, serializes the selected transaction fields, hashes them with a tagged SHA-256, and pushes the 32-byte result back onto the stack. The script can then use this hash for further logic: compare it against a committed value, pass it to OP_CHECKSIGFROMSTACK, or combine it with other stack operations.

1. The script places a serialized TxFieldSelector byte string onto the stack
2. OP_TXHASH pops the selector and interprets its flags
3. The opcode reads the specified fields from the spending transaction (version, locktime, selected inputs, selected outputs, etc.)
4. Those fields are serialized and hashed using tagged SHA-256
5. The 32-byte hash is pushed onto the stack for further script operations

Each invocation costs 25 units from the BIP 342 validation budget (the same budget used by signature checks), preventing denial-of-service attacks through excessive hash computation.

The TxFieldSelector

The TxFieldSelector is the core innovation. It is a compact, variable-length byte structure that specifies which transaction components to include in the hash. The design draws inspiration from Bitcoin's existing SIGHASH flags but provides much finer granularity. The selector supports three forms: an empty selector (equivalent to CTV), a one-byte shorthand that maps to standard SIGHASH modes, and a multi-byte format for full control.

Global transaction fields selectable via the first byte of the multi-byte format:

• Transaction version
• Locktime
• Current input index (the input executing the script)
• Current input control block and spent script
• Current input Taproot annex
• A control bit that includes the TxFieldSelector itself in the hash (anti-malleability)

Per-input fields (selected via the second byte):

• Previous outpoint (txid and vout of the UTXO being spent)
• Sequence number
• ScriptSig data
• ScriptPubKey of the spent UTXO
• Value of the spent UTXO
• Taproot annex

Per-output fields:

• Output value (amount)
• Output ScriptPubKey (destination)

Additional bytes control which inputs and outputs to include. The selector supports several modes: all inputs or outputs, only the current input, a contiguous range of leading items (up to 8,191), or up to 32 individually selected items by index. This means a script can commit to one particular output's destination while leaving everything else unconstrained.

Example: Replicating CTV Behavior

Because OP_TXHASH pushes a hash onto the stack rather than verifying it directly, replicating CTV's behavior requires an additional check:

# CTV-equivalent using OP_TXHASH:
# 1. Push the expected hash (committed at script creation time)
<expected_hash>
# 2. Push an empty TxFieldSelector (defaults to CTV's field set)
OP_0
# 3. Compute the hash of the selected fields
OP_TXHASH
# 4. Verify the computed hash matches the expected value
OP_EQUALVERIFY

This equivalence is important: it means OP_TXHASH is a strict superset of CTV's functionality. Any use case CTV enables, TXHASH can also handle, while supporting additional patterns that CTV cannot express.

Pairing with OP_CHECKSIGFROMSTACK

OP_TXHASH becomes especially powerful when combined with OP_CHECKSIGFROMSTACK (CSFS). While TXHASH alone enables static covenants (where allowed transaction patterns are fixed at script creation time), the TXHASH + CSFS combination enables dynamic, signature-based covenants:

1. OP_TXHASH computes a hash over selected transaction fields
2. CSFS verifies that an authorized key signed that specific hash
3. The key holder can authorize different spending patterns at different times, providing delegation without sacrificing security

This pairing can also emulate SIGHASH_ANYPREVOUT (BIP 118) by selecting the appropriate fields in the TxFieldSelector. The one-byte shorthand format includes explicit mappings for all standard SIGHASH modes plus ANYPREVOUT variants. CSFS itself is specified in BIP 348, authored by Brandon Black and Jeremy Rubin.

Use Cases

Vaults

Vaults require spending conditions with a time-delayed withdrawal process, allowing owners to cancel unauthorized transactions. OP_TXHASH improves on CTV-based vault designs by enabling selective field commitment. A vault script can constrain the output destination and enforce a CSV timelock while leaving inputs flexible for fee management. With CTV, the entire transaction template must be predetermined, making fee estimation a challenge. For a deeper look at vault designs, see the Bitcoin script vaults explainer.

Payment Pools

Payment pools (also called joinpools) allow multiple users to share a single UTXO with pre-committed exit paths. OP_TXHASH enables pool designs where individual exits can be constrained to specific outputs without committing to the full transaction structure. This flexibility allows participants to exit independently while the remaining pool funds stay intact, and new participants can potentially be added without rebuilding the entire commitment tree.

Congestion Control

During high-fee periods, a payer can batch many payments into a single confirmed transaction that commits to expansion paths via covenants. Recipients can later claim their individual outputs when fees drop. OP_TXHASH is well suited here because scripts can commit to the outputs (payment destinations and amounts) while leaving inputs unconstrained, allowing the spender to attach additional inputs for fee bumping via RBF or CPFP. This is a practical advantage over CTV, which commits to inputs and can make fee adjustment difficult. For background on CTV and congestion control, see the OP_CTV deep dive.

Fee-Flexible Covenants

One of the most practical advantages of OP_TXHASH over fixed-template approaches is fee flexibility. By selectively excluding inputs from the hash, scripts can allow additional inputs to be attached at spend time purely for fee contribution. This solves a persistent problem in covenant design: predicting future fee rates at the time the covenant is created. The Bitcoin fee market is inherently unpredictable, and covenants that lock in the entire transaction structure force users to guess fees days or weeks in advance.

OP_TXHASH vs. OP_CTV

The relationship between OP_TXHASH and OP_CTV is central to the Bitcoin covenant debate. Both enable covenant logic, but they represent different points on the simplicity-versus-expressiveness spectrum.

Some developers argue for deploying CTV first as a simpler stepping stone, with TXHASH potentially following later. Others prefer the "do it once, do it right" approach, arguing that deploying CTV creates ecosystem fragmentation if TXHASH is added afterward. For a broader view of the covenant landscape, see the Bitcoin covenants explainer.

Why It Matters

OP_TXHASH represents one path toward making Bitcoin Script significantly more expressive without introducing unbounded complexity. Covenants unlock use cases that are impossible today: trustless vaults, shared UTXOs for scaling, and non-interactive payment batching. The flexibility of the TxFieldSelector approach means that a single opcode can serve many of these use cases rather than requiring separate, purpose-built opcodes for each.

For Bitcoin Layer 2 protocols, including the Lightning Network and newer designs, covenants enabled by OP_TXHASH could improve channel factory efficiency, enable more flexible exit mechanisms, and reduce on-chain footprint during high-fee periods. Projects building on Bitcoin's programmability, including Spark, benefit from the broader trend toward more expressive script capabilities.

Risks and Considerations

Consensus Change Complexity

OP_TXHASH introduces a new data structure (TxFieldSelector) into consensus-critical code. Every combination of flags must be analyzed for potential interactions with existing script semantics, transaction validation rules, and future upgrade paths. This is a substantially larger review surface than CTV's fixed-template approach, and Bitcoin's consensus change process prioritizes exhaustive review over speed of deployment. Concerns have been raised about potential quadratic hashing with arbitrary input combinations, though the proposal includes caching strategies and validation budget limits to mitigate this.

Draft Status

As of mid-2026, BIP 346 remains in draft status. While the BIP was merged into the bitcoin/bips repository in January 2026, it has not entered the formal activation process, and the Bitcoin Core implementation PR was closed pending further discussion. The broader Bitcoin covenant conversation remains fragmented, with CTV, OP_CAT, and APO each drawing different levels of community support. CTV in particular has concrete activation parameters proposed for 2026-2027.

Expressiveness vs. Analyzability

More flexible covenants are harder to reason about. With CTV, the set of possible spending transactions is fully determined at script creation time. With OP_TXHASH, the set of possible transactions depends on which fields the selector constrains, meaning wallet software and block explorers need more sophisticated logic to display what a covenant actually enforces. This tradeoff between power and transparency is a recurring theme in Bitcoin Script evolution.

Interaction with Other Proposals

OP_TXHASH is designed to compose with CSFS and potentially OP_CAT. If multiple covenant proposals are deployed, the combined expressiveness could exceed what any individual proposal was reviewed for. This "combinatorial blowup" concern is one reason some developers prefer deploying covenant opcodes one at a time, with careful evaluation of interactions before adding more.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.