OP_TXHASH

OP_TXHASH is a proposed, experimental Bitcoin opcode described in BIP 346, authored by Steven Roose and Brandon Black. It is not part of Bitcoin consensus, has no scheduled activation, and would require a soft fork adopted by the network's economic majority to ever go live. We present it neutrally as one of several covenant-enabling ideas under discussion as of 2026 — a design worth understanding precisely because the debate around it maps the trade-off space for Bitcoin's scripting future.

The idea in one paragraph

Today, Bitcoin Script can verify signatures over a transaction but cannot directly inspect or constrain the transaction's own contents — a script cannot say "these coins may only move to that address." Opcodes that add such restrictions are called covenants. OP_TXHASH would activate as new semantics for an OP_SUCCESS opcode inside Tapscript (the upgrade path Taproot deliberately left open). It produces a hash over a caller-chosen set of transaction fields, selected via a structure called a TxFieldSelector — specific inputs, specific outputs, amounts, scripts, locktimes, or global fields, in nearly any combination. A script can then require that hash to equal a committed value, enforcing that the selected parts of the spending transaction are exactly as pre-defined while leaving every unselected field free to change at spending time.

Comparison to CTV

The natural reference point is OP_CHECKTEMPLATEVERIFY (CTV, BIP 119), which commits to an entire transaction template in one rigid hash. OP_TXHASH is best understood as CTV's granular relative: where CTV fixes essentially everything, TXHASH lets the script author pick precisely which pieces are constrained and which remain flexible — pin the outputs but not the fee-bearing input, pin one output and let others float, and so on. Paired with a signature-introspection primitive like OP_CHECKSIGFROMSTACK, it becomes more expressive still, allowing scripts that verify signatures over arbitrary selected transaction data. Proponents argue this granularity improves privacy and coordination in multiparty protocols and Layer 2 designs — vault constructions, congestion-control batching, payment pools — since participants fix only the fields that matter to the contract. Critics counter that flexibility is exactly the concern: a rich field selector is more consensus surface to specify, implement, and test than a single rigid template, and its interactions with future opcodes are harder to reason about.

Status and stakes

The proposal remains a topic of active, generally respectful debate on the mailing list and in covenant research circles, alongside CTV, OP_CAT, OP_CHECKCONTRACTVERIFY, and the MATT framework. The disagreement is less about whether TXHASH works than about Bitcoin's meta-question: how much expressiveness Script should gain, in what increments, and with how much accumulated caution. Consensus changes to a monetary network are meant to be slow, and no covenant proposal — this one included — has demonstrated the overwhelming consensus that activation requires.

What a practical Bitcoiner should take away

Nothing about OP_TXHASH affects how you hold or spend coins today, and any wallet or service claiming to offer TXHASH-based vaults on mainnet is describing vaporware. Experimenters can explore covenant semantics on testnet-class networks where such opcodes are trialed. The realistic takeaway is vocabulary: covenants are coming up in every serious conversation about Bitcoin's future, and TXHASH marks the "flexible, composable" end of the design spectrum — proposed, not consensus, no timeline.

For miners specifically, covenant debates are worth following at a distance because activated covenants would change what transactions look like, not how mining works: SHA-256, block construction, and the fee market carry on regardless, though widely adopted covenant protocols could shift fee patterns by batching or restructuring on-chain activity. The sober posture is the one Bitcoin rewards generally — watch the research, respect the caution, and treat any claim that a covenant opcode is "coming soon" with the same skepticism you would apply to a spec sheet without a wall-measurement behind it.