This BIP proposes a new opcode OP_TXHASH, to be activated as a change to the\nsemantics of OP_SUCCESS189 in tapscript contexts.
This opcode provides a generalized method for introspecting certain details of\nthe spending transaction, which enables non-interactive enforcement of certain\nproperties of the transaction spending a certain UTXO.
\nTogether with an opcode like OP_CHECKSIGFROMSTACK, this opcode effectively\nprovides a fully generalized signature hash construction, fully supporting\nall existing SIGHASH flags, the proposed sighash flags from\nBIP-118 (SIGHASH_ANYPREVOUT) and many other new signature hash\ncombinations.
The constructions specified in this BIP also open up the way for other\npotential updates; see Motivation section for more details.
\nOP_TXHASH redefines the OP_SUCCESS189 tapscript opcode (0xbd) as a soft\nfork upgrade. This opcode is only active in tapscript contexts.
Note that OP_SUCCESS187 is used by BIP-443 (OP_CHECKCONTRACTVERIFY) and\nOP_SUCCESS188 was used by BIP-345 (OP_VAULT) at the time of first draft\nof this BIP, making OP_SUCCESS189 the next available opcode for this purpose.
It has the following semantics:
\nThe TxFieldSelector has the following encoding. We will give a brief conceptual\nsummary, followed by a reference implementation of the CalculateTxHash function.
\nIn the following specifications, the | operator is used for the bitwise OR\noperation.
the empty value, zero bytes long: it is set equal to TXFS_SPECIAL_TEMPLATE,\nthe de-facto default value which means everything except the prevouts and\nthe prevout scriptPubkeys and amounts.
Special case TXFS_SPECIAL_TEMPLATE is 4 bytes long, as follows:
TXFS_VERSION | TXFS_LOCKTIME | TXFS_CURRENT_INPUT_IDXTXFS_INPUTS_SEQUENCES | TXFS_INPUTS_SCRIPTSIGS | TXFS_OUTPUTS_ALLTXFS_INOUT_NUMBER | TXFS_INOUT_SELECTION_ALLTXFS_INOUT_NUMBER | TXFS_INOUT_SELECTION_ALLIf the TxFieldSelector has exactly 1 byte, we use a short notation.\nIt has its 8 bits assigned as follows, from lowest to highest:
\nTXFS_INOUT_SELECTION_NONETXFS_INOUT_SELECTION_CURRENTTXFS_INOUT_SELECTION_ALLTXFS_INOUT_SELECTION_NONETXFS_INOUT_SELECTION_CURRENTTXFS_INOUT_SELECTION_ALLTXFS_INPUTS_PREVOUTSTXFS_INPUTS_PREV_SCRIPTPUBKEYS | TXFS_INPUTS_PREV_VALUESTXFS_CURRENT_INPUT_CONTROL_BLOCK | TXFS_CURRENT_INPUT_SPENTSCRIPT | TXFS_CURRENT_INPUT_LAST_CODESEPARATOR_POSTXFS_CURRENT_INPUT_IDXAdditionally, it includes TXFS_VERSION | TXFS_LOCKTIME | TXFS_CONTROL | TXFS_CURRENT_INPUT_TAPROOT_ANNEX\nas global fields and TXFS_INPUTS_SEQUENCES | TXFS_INPUTS_SCRIPTSIGS | TXFS_OUTPUTS_ALL\nas input and output fields.
These 1-byte selections allow the TxFieldSelector to emulate current\nsignature hashing modes and those defined in BIP-118:
\n| BIP-341/118 sighash type | \n1-byte TxFieldSelector | \n
|---|---|
ALL | \n0b11111111 | \n
SINGLE | \n0b11110111 | \n
NONE | \n0b11110011 | \n
ALL|ANYONECANPAY | \n0b11111101 | \n
SINGLE|ANYONECANPAY | \n0b11110101 | \n
NONE|ANYONECANPAY | \n0b11110001 | \n
ALL|ANYPREVOUT | \n0b11101101 | \n
SINGLE|ANYPREVOUT | \n0b11100101 | \n
NONE|ANYPREVOUT | \n0b11100001 | \n
ALL|ANYPREVOUTANYSCRIPT | \n0b11001101 | \n
SINGLE|ANYPREVOUTANYSCRIPT | \n0b11000101 | \n
NONE|ANYPREVOUTANYSCRIPT | \n0b11000001 | \n
If the TxFieldSelector is longer than one byte, the first byte of the TxFieldSelector\nhas its 8 bits assigned as follows, from lowest to highest:
\nTXFS_VERSION)TXFS_LOCKTIME)TXFS_CURRENT_INPUT_IDX)TXFS_CURRENT_INPUT_CONTROL_BLOCK)TXFS_CURRENT_INPUT_SPENTSCRIPT)OP_CODESEPARATOR position (or 0xffffffff)\n(TXFS_CURRENT_INPUT_LAST_CODESEPARATOR_POS)TXFS_CURRENT_INPUT_TAPROOT_ANNEX)TXFS_CONTROL (i.e. include TxFieldSelector into hash)The highest bit of the first byte (TXFS_CONTROL), we will call the\n"control bit", and it can be used to control the behavior of the opcode. For\nOP_TXHASH, the control bit is used to determine\nwhether the TxFieldSelector itself has to be included in the resulting hash.\n(For potential other uses of the TxFieldSelector (like a hypothetical\nOP_TX), this bit can be repurposed.)
The second byte will be used to indicate fields from the inputs and outputs.\nThe 8 bits are assigned the following variables, from lowest to highest:
\nSpecifying which fields of the inputs will be selected:
\nTXFS_INPUTS_PREVOUTS)TXFS_INPUTS_SEQUENCES)TXFS_INPUTS_SCRIPTSIGS)TXFS_INPUTS_PREV_SCRIPTPUBKEYS)TXFS_INPUTS_PREV_VALUES)TXFS_INPUTS_TAPROOT_ANNEXES)Specifying which fields of the outputs will be selected:
\nTXFS_OUTPUTS_SCRIPTPUBKEYS)TXFS_OUTPUTS_VALUES)We define as follows:
\nTXFS_ALL = TXFS_VERSION | TXFS_LOCKTIME | TXFS_CURRENT_INPUT_IDX | TXFS_CURRENT_INPUT_CONTROL_BLOCK | TXFS_CURRENT_INPUT_LAST_CODESEPARATOR_POS | TXFS_CONTROLTXFS_INPUTS_ALL = TXFS_INPUTS_PREVOUTS | TXFS_INPUTS_SEQUENCES | TXFS_INPUTS_SCRIPTSIGS | TXFS_INPUTS_PREV_SCRIPTPUBKEYS | TXFS_INPUTS_PREV_VALUES | TXFS_INPUTS_TAPROOT_ANNEXESTXFS_OUTPUTS_ALL = TXFS_OUTPUTS_SCRIPTPUBKEYS | TXFS_OUTPUTS_VALUESFor both inputs and then outputs, expect an additional byte as follows:
\nThe highest bit (TXFS_INOUT_NUMBER) indicates whether the "number of\nin-/outputs" should be committed to.
For the remaining bits, there are three exceptional values:
\nTXFS_INOUT_SELECTION_NONE) means "no in/outputs" (hence only the\nnumber of them as 0x80 (TXFS_INOUT_NUMBER)).0x40 (TXFS_INOUT_SELECTION_CURRENT) means "select only the in/output\nof the current input index" (it is invalid when current index exceeds\nnumber of outputs).0x3f (TXFS_INOUT_SELECTION_ALL) means "select all in/outputs".The second highest bit (TXFS_INOUT_SELECTION_MODE) is the "specification mode":
In "leading mode", the third highest bit (TXFS_INOUT_LEADING_SIZE) is\nused to indicate the "index size", i.e. the number of bytes will be used to\nrepresent the number of in/output.
In "individual mode", the third highest bit (TXFS_INOUT_INDIVIDUAL_MODE)\nindicates whether we are passing absolute indices (0) or indices relative\nto the current input (1), the remaining lowest 5 bits will be interpreted\nas n, the number of individual in/outputs follow.
n indices,\nat least one extra byte is expected.n indices,\nat least one extra byte is expected.Effectively, this allows a user to select
\nIt is possible to represent the same selected data using multiple different\nTxFieldSelectors. For this reason, users are advised to always set the\nTXFS_CONTROL field flag that commits to the TxFieldSelector that was used\nto get the hash.
1 1 1 1 1 1 1 1\n| | | | | | | ^ version\n| | | | | | ^ locktime\n| | | | | ^ current input index\n| | | | ^ current input control block\n| | | ^ current input spent script\n| | ^ current script last OP_CODESEPARATOR\n| ^ current input taproot annex\n^ control bit (ie. include TXFS in hash)\n<-> outputs\n| | <---------> inputs\n1 1 1 1 1 1 1 1\n| | | | | | | ^ prevouts\n| | | | | | ^ sequences\n| | | | | ^ scriptSigs\n| | | | ^ prevout scriptPubkeys\n| | | ^ prevout values\n| | ^ taproot annexes\n| ^ scriptPubkeys\n^ values\n"leading 3 in/outputs"
\n1 0 0 0 0 0 1 1\n| | | <-------> integer 0b00011 == 3\n| | ^ index size: single byte\n| ^ leading mode\n^ commit the number of in/outputs\n"leading 257 in/outputs"
\n1 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1\n| | | <------------------------> integer 0b00001 00000001 == 257\n| | ^ index size 1: two bytes\n| ^ leading mode\n^ commit the number of in/outputs\n"indices 1 and 3"
\n0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 1\n| | | | <--------------> second idx: 3\n| | | | <-------------> first idx: 1\n| | | | <-----> selection count: 0b0010 == 2 indices\n| | | ^ index size: single byte per index\n| | ^ absolute index\n| ^ individual mode\n^ don't commit the number of in/outputs\nff ff c2 01 03 83\n | | ^ commit number of outputs + leading 3 outputs\n | | <------> commit number of inputs + inputs at indices 1 and 3\n | ^ all input and output fields\n ^ all regular fields\nUsing the same validation budget ("sigops budget") introduced in BIP-0342,\neach TransactionHash decreases the validation budget by 25. If this brings the\nbudget below zero, the script fails immediately.
The following\nconsiderations should be made:
This BIP specifies a basic transaction introspection primitive that is useful\nto either reduce interactivity in multi-user protocols or to enforce some basic\nconstraints on transactions.
\nAdditionally, the constructions specified in this BIP can lay the groundwork for\nsome potential future upgrades:
\nOP_TX that allows for directly introspecting the transaction by putting the\nfields selected on the stack instead of hashing them together.OP_TXHASH can be combined with OP_CHECKSIGFROMSTACK\n(see BIP-348) to effectively create an\nincredibly flexible signature hash, which would enable constructions like\nSIGHASH_ANYPREVOUT.OP_TXHASH can be introduced as a native\nsighash calculation in a future segwit upgrade, so that signatures using the\nTransactionHash as their sighash can be used in keyspend context.This proposal strictly generalizes BIP-119's OP_CHECKTEMPLATEVERIFY, as the\ndefault mode of our TxFieldSelector is semantically the same (though not\nbyte-for-byte identical) as what OP_CTV accomplishes, without costing any\nadditional bytes. Additionally, using OP_TXHASH allows for more\nflexibility which can help in the case for
Constructions like OP_IN_OUT_VALUE used with OP_EQUALVERIFY can be\nemulated by two OP_TXHASH instances by using the TxFieldSelector to select\na single input value first and a single output value second and enforcing\nequality on the hashes. Neither of these alternatives can be used to enforce\nsmall value differences without the availability of 64-bit arithmetic in\nScript.
Like mentioned above, SIGHASH_ANYPREVOUT can be emulated using OP_TXHASH\nwhen combined with OP_CHECKSIGFROMSTACK: \n<txfs> OP_TXHASH <pubkey> OP_CHECKSIGFROMSTACK effectively emulates SIGHASH_ANYPREVOUT.
A reference implementation in Rust is provided attached as part of this BIP\ntogether with a JSON file of test vectors generated using the reference\nimplementation.
\nThis specification in in Draft and there is definitely still room for feedback\nand improvements. Some considerations that were made but could be revisited:
\n0b10 in/output selector for the shorthand is unused.\nCould possibly be filled in with "current + next", "current + previous" or\nany other semantics.OP_TEMPLATEHASH (BIP number to be assigned, PR),\nwe could not support scriptSigs anymore and remove\nTXFS_INPUTS_SCRIPTSIGS. This field could then possibly be repurposed.OP_TXHASH replaces OP_SUCCESS189. The SUCCESS opcodes were\nintroduced in taproot (BIP-342) to support changing the semantics of opcodes in\nways that do allow the new semantics to change the stack. For this reason,\nOP_TXHASH only works in tapscript context. Since it is overriding a SUCCESS\nopcode, any older version of the software will always accept any script that\nuses the opcode, while the new versions of the software will validate the\nscripts according to the semantics outlined in this BIP. As such, this is also a\nsoft fork change.
This proposal interacts with several other BIPs:
\nBIP-118 (SIGHASH_ANYPREVOUT): OP_TXHASH can be combined with\nOP_CHECKSIGFROMSTACK (BIP-348) to emulate SIGHASH_ANYPREVOUT and other\nsignature hash modes defined in BIP-118. The 1-byte TxFieldSelector format\nexplicitly supports these modes.
BIP-119 (OP_CHECKTEMPLATEVERIFY): OP_TXHASH with the empty\nTxFieldSelector produces a hash semantically equivalent to BIP-119's\nOP_CHECKTEMPLATEVERIFY, making this proposal a generalization of BIP-119.
BIP-347 (OP_CAT): When combined with OP_CAT, OP_TXHASH enables\npowerful transaction introspection capabilities. The bit encoding format is\ndesigned to be explicit about endianness to ensure correct interaction with\nconcatenation operations.
BIP-348 (OP_CHECKSIGFROMSTACK): Together with OP_CHECKSIGFROMSTACK,\nOP_TXHASH provides a fully generalized signature hash construction,\nenabling flexible covenant designs and multi-user protocols.
A reference implementation is included as part of the BIP, see\nhere. This implementation focusses on clarity\nand correctness, not on efficiency. A rudimentary set of test vectors is also\ngenerated from this implementation and included\nhere.
\nFurthermore, following other implementation attempts exist:
\nNOTE: These implementations are slightly outdated as they were made for an\nearlier version of this specification. Updates are in progress.
\nBoth of the above implementations perform effective caching to avoid potential\ndenial-of-service attack vectors.
\nThis BIP can be deployed using a BIP 9 VersionBits deployment. The specific\nstrategy and bit assignment are left unspecified and can later be amended to the\nBIP depending on community preference.
\nCredit for this proposal mostly goes to Jeremy Rubin for his work on BIP-119's\nOP_CHECKTEMPLATEVERIFY and to Russell O'Connor for the original idea of\ngeneralizing OP_CHECKTEMPLATEVERIFY into OP_TXHASH.
Additional thanks to Andrew Poelstra, Greg Sanders, Rearden Code, Rusty Russell\nand others for their feedback on the specification.
\nThis document is licensed under the 3-clause BSD license.
\n","toc":[{"id":"op-txhash","title":"OP_TXHASH","level":2},{"id":"txfieldselector","title":"TxFieldSelector","level":2},{"id":"txfieldselector-malleability","title":"TxFieldSelector malleability","level":3},{"id":"visualization","title":"Visualization","level":3},{"id":"resource-limits","title":"Resource limits","level":2},{"id":"comparing-with-some-alternative-proposals","title":"Comparing with some alternative proposals","level":2},{"id":"interactions-with-other-bips","title":"Interactions with other BIPs","level":2}],"history":{"totalCommits":2,"firstCommit":"2023-09-06T16:16:35+01:00","lastUpdated":"2026-02-04T16:39:50-06:00","events":[{"sha":"10c78888857fc5609a9b0ea1bf360407e3a5f203","date":"2026-02-04T16:39:50-06:00","author":"Paul Miller","message":"Escape pipe character in markdown table (#2095)","url":"https://github.com/bitcoin/bips/commit/10c78888857fc5609a9b0ea1bf360407e3a5f203","kind":"edit"},{"sha":"6a0636da32ff34e100e887df21eb0d8ec1d4b834","date":"2023-09-06T16:16:35+01:00","author":"Steven Roose","message":"Add BIP-346: OP_TXHASH","url":"https://github.com/bitcoin/bips/commit/6a0636da32ff34e100e887df21eb0d8ec1d4b834","kind":"edit"}]}}