Transaction Malleability

What Is Transaction Malleability?

Transaction malleability is a property of Bitcoin's original transaction format that allowed the transaction ID to be changed without invalidating the transaction itself. Because the txid was computed as a hash over the entire serialized transaction (including signatures), anyone who could modify the signature encoding could produce a different txid for the same economic transfer.

The core issue was a circular dependency: a transaction's signature cannot sign over itself. The signature must exist inside the transaction data that gets hashed into the txid, yet the signature is created before being placed there. This gap meant that alternative representations of the same valid signature produced entirely different txids while moving the same funds between the same addresses.

For simple payments, malleability was mostly a bookkeeping nuisance: wallets and exchanges tracking transactions by txid could lose track of confirmed payments. But for protocols that built chains of dependent transactions referencing unconfirmed txids, it was catastrophic.

How It Works

A Bitcoin txid is the double SHA-256 hash of the serialized transaction. In the original format, that serialization includes the version, inputs (each containing the previous txid, output index, scriptSig, and sequence number), outputs, and locktime. The scriptSig contains the unlocking script: typically an ECDSA signature and a public key.

Sources of Malleability

BIP 62 cataloged nine distinct sources of malleability. The most significant ones:

• ECDSA signature complement: for any valid ECDSA signature (r, s), the pair (r, -s mod n) is also valid. Anyone observing a transaction on the network could flip the S value, producing a different signature encoding and therefore a different txid. No private key was required.
• Non-standard DER encoding: OpenSSL accepted multiple encodings for the same signature. Extra padding bytes or alternative length fields produced different byte sequences that all validated correctly.
• Superfluous scriptSig operations: extra data pushes or non-standard push opcodes (using OP_PUSHDATA2 where OP_PUSHDATA1 would suffice) changed the scriptSig bytes without affecting validation.
• Self-malleability: the original signer could always produce a new valid signature using a different random nonce. This is inherent to ECDSA and cannot be prevented by consensus rules.

A Concrete Example

Consider a transaction with txid ABC123 broadcast to the network. An attacker (or any relay node) intercepts it, flips the S value in the ECDSA signature, and rebroadcasts the modified version with txid DEF456. Both versions are valid. Whichever reaches miners first gets confirmed. If DEF456 wins, any child transaction referencing ABC123 becomes permanently invalid.

# Original transaction
txid: ABC123
scriptSig: <sig_original> <pubkey>

# Malleated transaction (same funds, same recipient)
txid: DEF456
scriptSig: <sig_flipped_s> <pubkey>

# Child transaction referencing the original
input: ABC123:0  ← breaks if DEF456 confirms instead

Why It Matters

Breaking Payment Channels

The most consequential impact of transaction malleability was on payment channels. A bidirectional payment channel requires two transactions:

1. A funding transaction that locks funds into a 2-of-2 multisig address
2. A commitment (refund) transaction that spends the funding transaction's output back to the participants as a safety mechanism

The commitment transaction must be created and signed before the funding transaction is broadcast. This is essential: once funds enter the multisig, both parties must cooperate to spend them. Without a pre-signed refund path, a malicious counterparty could refuse to cooperate, trapping funds permanently.

The commitment transaction references the funding transaction by its txid. If a third party malleates the funding transaction before it confirms, the txid changes and the commitment transaction becomes invalid. The party who funded the channel loses their safety net and their funds are stuck.

This single issue made the Lightning Network's payment channel architecture fundamentally unsafe. The entire design depends on chains of transactions that reference each other by txid: HTLCs, revocation keys, and justice transactions all require stable txids to function.

Mt. Gox and Real-World Impact

In February 2014, Mt. Gox, then the world's largest Bitcoin exchange, halted withdrawals and cited transaction malleability attacks. The exchange eventually filed for bankruptcy, claiming losses of approximately 850,000 BTC.

Subsequent research by Christian Decker and Roger Wattenhofer analyzed over a year of network data. They found 35,202 malleability attack instances but concluded that at most 386 BTC could have been stolen via this technique: a tiny fraction of Mt. Gox's claimed losses. Malleability was likely a contributing factor to bookkeeping confusion rather than the primary cause of the exchange's collapse.

The incident did trigger a surge in malleability attacks: 25,752 attacks occurred in the first two days after the public announcement, compared to only 421 in the entire preceding year. The publicity effectively taught attackers the technique. Silk Road 2.0 reported losing $2.7 million in Bitcoin to a similar attack shortly after.

How SegWit Fixed It

Segregated Witness (BIP 141), activated on August 24, 2017 at block 481,824, restructured the transaction format to eliminate malleability. The core idea: move witness data (signatures and redeem scripts) out of the data used to compute the txid.

The New Transaction Format

SegWit transactions use a new serialization with separate fields for witness data:

# Legacy format (all data hashed into txid)
[version] [inputs + scriptSig] [outputs] [locktime]

# SegWit format
[version] [marker: 0x00] [flag: 0x01] [inputs] [outputs] [witness] [locktime]

# txid: hash of [version][inputs][outputs][locktime] — no witness
# wtxid: hash of full serialization — includes witness

In SegWit transactions, the scriptSig is empty. Signatures are placed in the witness field instead. Since the txid is computed from [version][inputs][outputs][locktime] only, no malleable signature data enters the calculation.

A separate identifier, the wtxid, hashes the full serialization including witness data. Miners commit to a Merkle root of all wtxids in the coinbase transaction, ensuring witness data cannot be altered after block inclusion either.

Enabling the Lightning Network

With stable txids, payment channels became safe. A commitment transaction referencing a SegWit funding transaction's txid is guaranteed to remain valid regardless of what happens to the funding transaction's witness data. This one fix unlocked the entire Lightning Network scaling architecture: multi-hop payments, channel factories, submarine swaps, and every protocol built on chains of dependent transactions.

Layer 2 protocols like Spark also benefit from this foundation. By guaranteeing that transaction references remain stable, SegWit made it possible to build entire off-chain transaction graphs that settle back to Bitcoin's base layer with full security guarantees.

Third-Party vs. Self-Malleability

An important distinction exists between two types of malleability:

• Third-party malleability: any network participant can modify the signature encoding of a transaction they observe. This requires no private key access and is the variant that posed a security threat. SegWit eliminated this entirely for transactions spending SegWit outputs.
• Self-malleability: the original signer can always produce a new valid signature because ECDSA uses a random nonce during signing. Each signing operation with a different nonce produces a completely different signature. No consensus rule can prevent this, as it is fundamental to the cryptographic scheme.

Schnorr signatures, introduced with Taproot (BIP 340) in November 2021, provide an additional layer of protection. Unlike ECDSA, Schnorr signatures are provably non-malleable: there is exactly one valid signature for a given message and key pair, eliminating even the ECDSA complement attack vector.

Use Cases and Legacy

While transaction malleability is largely a historical problem, its legacy shapes Bitcoin development to this day:

• Protocol design: every new Bitcoin protocol considers txid stability as a fundamental requirement, a direct lesson from the malleability era
• SegWit adoption: the urgency to fix malleability drove one of Bitcoin's most significant upgrades, which also delivered a capacity increase and fee reduction as side benefits
• Layer 2 ecosystem: the Lightning Network, state channels, channel splicing, and modern payment channel designs all exist because SegWit made txid references safe
• Signature scheme evolution: the move from ECDSA to Schnorr was partly motivated by Schnorr's provable non-malleability, building a defense-in-depth approach to transaction integrity

Risks and Considerations

Transaction malleability is effectively solved for SegWit transactions, but some considerations remain:

• Legacy transactions: non-SegWit transactions are still malleable. Protocols and wallets that generate legacy transaction formats remain vulnerable. As of 2026, the vast majority of Bitcoin transactions use SegWit, but legacy support persists in older software.
• Multi-party protocols: in multi-signature setups, any co-signer can still malleate a transaction before broadcast because they possess a valid signing key. SegWit prevents third-party malleability but does not prevent signers from re-signing.
• Historical wallet issues: exchanges and wallets that tracked transactions solely by txid during the pre-SegWit era sometimes lost track of payments. Modern wallet implementations use additional confirmation signals and handle txid changes gracefully.
• Protocol assumptions: any new Bitcoin protocol that constructs chains of dependent transactions must use SegWit (or Taproot) outputs. Building on legacy outputs reintroduces malleability risk.

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.