Transaction malleability is the ability of someone to change the identifier of a blockchain transaction without changing what the transaction does. The coins still move from the same sender to the same recipient, yet the label that software uses to track the payment is different from the one originally broadcast.
That sounds harmless, and for the movement of funds it usually is. The danger lies in the systems built around transactions: wallets, exchanges, payment channels, and smart contracts that assume an identifier is fixed. This article explains where malleability comes from, how major networks reduced it, and what builders should still watch for.
When the Same Payment Gets a New Name
Picture a merchant system that broadcasts a refund and records its transaction ID, or txid, in a database. A txid is a hash, a fixed-length fingerprint, of the serialized transaction. Minutes later the refund confirms, but under a different txid than the one stored.
The software searches for the original txid, finds nothing, and concludes the refund failed. A support agent might then send the refund again. The customer receives two payments, and the merchant has created its own loss without any attacker touching the funds.
This is the practical shape of the malleability problem. Nothing was stolen through cryptography. Instead, a hidden assumption that a txid is permanent from the moment of broadcast turned out to be false, and business logic built on that assumption made a costly decision.
The same pattern can affect exchanges processing many withdrawals per hour. Without careful matching, a burst of mutated identifiers can trigger a wave of mistaken resends before anyone notices the pattern.
How Transaction IDs Are Calculated
In Bitcoin, the classic txid is the double SHA-256 hash of the full serialized transaction. SHA-256 is a cryptographic hash function: any change to the input, even a single byte, produces a completely different output. This property is normally a strength, because it detects tampering.
The original transaction format included the signatures inside the data being hashed. A signature proves that the owner of a private key authorized spending. Yet the signature itself cannot sign over its own bytes, so parts of its encoding were never covered by the signature check.
This created a gap. If a third party could rewrite the signature into a different but still valid form, the transaction would still pass validation. Because those rewritten bytes were part of the hashed data, the resulting txid would change while inputs, outputs, and amounts stayed identical.
Sources of Malleability in Signatures and Scripts
Malleability did not come from one flaw. Several independent quirks in how signatures and unlocking scripts were encoded allowed valid variations of the same transaction. Two broad groups matter most.
Signature Encoding Variations
Bitcoin uses ECDSA, the Elliptic Curve Digital Signature Algorithm, over the secp256k1 curve. An ECDSA signature consists of two numbers, called r and s. Mathematically, if a pair with value s is valid, the pair using the curve order minus s is also valid.
Anyone observing the transaction could flip this value without knowing the private key. Older software also accepted loosely formatted signature encodings, giving a second route to produce alternative bytes for the same authorization. Neither variation required any secret knowledge, only access to the broadcast transaction.
Unlocking Script Changes
Each Bitcoin input carries an unlocking script, historically called the scriptSig, that supplies signatures and other data. The signature does not cover the scriptSig itself.
A relaying node could therefore add harmless operations, such as pushing extra data that is later discarded, and the script would still evaluate as valid. Each such addition altered the serialized transaction and therefore its hash, producing yet another txid. Policy rules later restricted these additions, but older nodes and nonstandard paths kept the risk alive for some time.
Third-Party Versus Signer Malleability
Security analysis separates two kinds of actors who can change a txid. Third-party malleability means anyone who sees the transaction, such as a relaying node, can alter it without access to private keys. This is the variety that caused most operational trouble.
Signer malleability means the key holder can produce a different valid signature for the same transaction. ECDSA signing uses a secret per-signature value called a nonce, and the key holder can choose a different one or alter signed fields. The owner can therefore always create a new valid signature, and a new txid.
The distinction matters for designing defenses. Network rules can remove third-party malleability by fixing encodings and moving signatures out of the txid. Signer malleability cannot be fully removed, so any protocol involving several parties must assume a counterparty may legitimately rebroadcast with a different identifier.
In practice, a counterparty who re-signs is not attacking anyone. The risk appears only when software treats the first broadcast identifier as binding.
Real Risks for Wallets and Exchanges
Malleability rarely steals funds directly. Its harm comes from how services react when tracking breaks. Common failure patterns appear whenever software treats an unconfirmed txid as a permanent receipt.
- False failure detection: a withdrawal is marked failed because its original txid never confirms, prompting a duplicate payout.
- Broken accounting: reconciliation jobs cannot match confirmed transactions to internal records, leaving balances incorrect.
- Invalid chained spends: a transaction spending an unconfirmed output references the old txid and becomes invalid if the parent is mutated.
- Support confusion: customers are given txids that block explorers never show, eroding trust and inviting social engineering.
Each pattern stems from a logic error rather than a cryptographic break. Malleability simply exposed the gap between what a txid guarantees and what the software believed it guaranteed. Robust services verify by inputs and outputs, not by identifier alone.
Why Payment Channels Needed a Fix
Off-chain payment channels, such as those used by the Lightning Network, depend on transactions that spend outputs of other transactions that may not yet be confirmed. Two parties pre-sign a refund transaction before funding the channel, so either one can recover funds if the other disappears.
That pre-signed refund points to the funding transaction by its txid. If the funding transaction were mutated before confirmation, the refund would reference an identifier that no longer exists. The safety net would vanish, and one party could hold the other’s funds hostage.
For this reason, reliable removal of third-party malleability was a prerequisite for building layered protocols safely. Designers needed confidence that a child transaction signed in advance would stay valid regardless of how the parent was relayed across the network.
Early channel designs worked around the issue with time locks and trust assumptions. A protocol-level fix allowed simpler, safer constructions that do not depend on the parent transaction being relayed untouched.
How Bitcoin Reduced Malleability Step by Step
Bitcoin developers addressed the problem incrementally, combining relay policy with consensus changes so that older transactions continued to work.
- Strict DER encoding: BIP-66 required signatures to follow one exact encoding format, closing the loose-formatting route.
- Low-S policy: node relay policy began rejecting signatures with the high variant of the s value, so only one form propagates normally.
- Clean script rules: policies limited unlocking scripts to pushing data only and rejected extra unused stack items.
- Segregated Witness: BIP-141 moved signature data into a separate witness structure that is excluded from the txid calculation.
The first three measures narrowed the attack surface but could not cover every edge case. Segregated Witness, usually called SegWit, solved third-party malleability for inputs that use the new format by design, because the data an outsider could tamper with no longer affects the identifier.
What Segregated Witness Changed in Practice
Under SegWit, each transaction has two identifiers. The txid excludes witness data and is used to reference outputs in later transactions. The wtxid, or witness transaction ID, includes the witness and is used mainly for relay and block commitments.
Because the txid no longer covers signatures, mutating a signature does not change how other transactions refer to the output. A pre-signed child transaction remains valid, which is exactly what payment channels require. Witness data is still committed in each block through a separate Merkle root.
Protection applies only to inputs spent through SegWit-style scripts. A transaction spending older, non-witness outputs can still be mutated by third parties under some conditions. Services that handle mixed input types should keep that in mind and continue to treat unconfirmed txids from legacy inputs with caution.
Most modern wallets create SegWit or Taproot addresses by default, so the protected path is now the common one. Legacy outputs still exist on the chain, however, and are spent occasionally.
Malleability on Account-Based Chains
Ethereum uses an account model rather than unspent outputs. Each transaction carries a nonce, a counter that increases with every transaction from an account. The nonce, not the hash, determines ordering, and only one transaction per nonce can ever be included.
Ethereum also restricted signatures early in its history, rejecting high-s values for transaction signatures to prevent third-party rewrites. A user can still replace a pending transaction by sending a new one with the same nonce and a higher fee, which naturally produces a different transaction hash.
Applications should therefore track pending activity by account and nonce rather than by hash. If a wallet shows a transaction as dropped, a replacement with the same nonce may already be confirmed. Checking the account’s current nonce on a reliable node clarifies the real state.
Block explorers on account-based chains usually show replaced transactions as dropped, which can alarm users. Explaining nonce replacement in support documentation prevents needless panic and duplicate payments.
Signature Malleability Inside Smart Contracts
The same mathematical property reappears at the application layer. Smart contracts often verify signatures off-chain from users to authorize actions such as gasless approvals. On Ethereum, contracts recover the signer address from a signature using a built-in function called ecrecover.
The raw function accepts both the low and high form of s, so one authorization can exist in two valid encodings. If a contract records used signatures to block replays, an attacker can submit the alternate form and pass the check, executing the same authorized action twice.
The defensive pattern is straightforward. Track a per-user nonce or a unique message hash that excludes signature bytes, and reject high-s signatures explicitly. Well-reviewed signature verification libraries already enforce these checks, so developers should prefer them over hand-written recovery code and confirm the behavior during audits.
Engineering Habits That Prevent Malleability Bugs
Most damage linked to malleability came from code that trusted unconfirmed identifiers. A few disciplined habits remove that weakness regardless of which chain a service supports.
- Treat a txid as final only after the transaction confirms in a block.
- Detect payments and withdrawals by matching inputs, outputs, and amounts, not identifiers alone.
- Never automatically resend a withdrawal; first check whether the spent inputs were consumed.
- Prefer SegWit-style addresses and inputs when building Bitcoin transactions.
- Use nonces, not signature bytes, for replay protection in contracts.
These rules also guard against unrelated issues such as fee replacement and chain reorganizations. Reconciliation logic built around actual coin movement stays correct even when identifiers shift for reasons the operator cannot control.
Building Malleability-Aware Systems Going Forward
Third-party malleability is largely solved for modern Bitcoin transactions and was addressed early on account-based chains. The lesson remains relevant because new protocols, sidechains, and signature schemes keep appearing, and each one makes its own decisions about what an identifier covers.
When evaluating a new network or library, ask direct questions. Which bytes does the transaction ID commit to? Can anyone other than the signer alter them? Are signatures restricted to a single canonical form? Documentation should answer each point clearly, and tests should confirm it.
Schnorr signatures, introduced to Bitcoin through the Taproot upgrade, were designed with non-malleable encoding in mind. Even so, careful teams keep reconciliation, replay protection, and confirmation policies independent of signature details. That separation means the next encoding quirk becomes a minor footnote rather than an expensive incident.
Teams that document these assumptions once, in a shared design note, avoid repeating the same investigation for every new chain they integrate.