Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£861.31
EST. MONTHLY
205
DAYS
EST. ROI
This guide explains BIP 140 Normalized TXID in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 140 proposed normalized transaction identifiers, or NTXIDs, that excluded malleable signature scripts and recursively replaced previous transaction references with normalized identifiers. It paired the scheme with OP_CHECKSIGEX and new UTXO tracking.
- Why it matters: BIP 140 was an ambitious attempt to create a stable transaction identity before SegWit. Its closed NTXID and OP_CHECKSIGEX design remains valuable history, but modern operations must use the transaction and witness identifiers defined by deployed rules.
- Current position: The soft-fork proposal is Closed; SegWit later addressed transaction malleability through a different deployed design.
BIP 140 Normalized TXID in simple English
BIP 140 Normalized TXID: For non-coinbase transactions the proposal removed each scriptSig, normalized inputs by substituting prior normalized identifiers when available, then double-SHA256 hashed the result.
Simple example
A node operator is checking BIP 140 Normalized TXID. A transaction identifier historically committed to signature encodings that could sometimes change without changing the payment.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- UTXO:
- An unspent transaction output: a piece of bitcoin that can be used as an input to a later transaction.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
The malleability problem
A transaction identifier historically committed to signature encodings that could sometimes change without changing the payment. A dependent unconfirmed transaction referencing the original identifier could then become invalid when a modified instance confirmed. Multi-party protocols were especially exposed because one signer could produce another valid signature.
Normalizing the transaction
For non-coinbase transactions the proposal removed each scriptSig, normalized inputs by substituting prior normalized identifiers when available, then double-SHA256 hashed the result. Coinbase script data remained to prevent collisions. The NTXID represented a class of semantically equivalent signed transaction instances.
Two identifiers and recursive state
The ordinary transaction instance ID remained in peer messages and normal outpoint indexing, while version-two outputs also carried a normalized identity. Signature verification could follow normalized ancestors recursively. Nodes therefore needed extra UTXO metadata and exact rules for version-one outputs that lacked an NTXID.
OP_CHECKSIGEX design
The proposal replaced OP_NOP4 with an extensible verification opcode taking a version parameter. Version one described normalized hashing and Schnorr signatures, without reproducing CHECKMULTISIG’s extra-stack-item bug. Unknown versions behaved as a no-op under the proposed soft-fork pattern, making deployment details security-critical.
Why the proposal closed
The design changed signature semantics, script templates and state indexing together. SegWit instead separated witness data from the legacy transaction identifier for witness spends and deployed with established script-version rules. A historical NTXID implementation is not compatible merely because both designs address malleability.
Wallet and mining implications
Template chains could be prepared before every signature was gathered, but nodes, wallets, pools and explorers had to agree which identifier applied at each boundary. Logging only one hash could make incident analysis ambiguous. Production systems today should follow deployed txid and wtxid semantics rather than invent an NTXID field.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is the main point of BIP 140 Normalized TXID?
BIP 140 Normalized TXID: For non-coinbase transactions the proposal removed each scriptSig, normalized inputs by substituting prior normalized identifiers when available, then double-SHA256 hashed the result.
For BIP 140 Normalized TXID, what should a beginner know about the malleability problem?
A transaction identifier historically committed to signature encodings that could sometimes change without changing the payment.
For BIP 140 Normalized TXID, what should a beginner know about normalizing the transaction?
For non-coinbase transactions the proposal removed each scriptSig, normalized inputs by substituting prior normalized identifiers when available, then double-SHA256 hashed the result.
For BIP 140 Normalized TXID, what should a beginner know about two identifiers and recursive state?
The ordinary transaction instance ID remained in peer messages and normal outpoint indexing, while version-two outputs also carried a normalized identity.
Conclusion
BIP 140 was an ambitious attempt to create a stable transaction identity before SegWit. Its closed NTXID and OP_CHECKSIGEX design remains valuable history, but modern operations must use the transaction and witness identifiers defined by deployed rules.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.