Signature Malleability

The flaw stems from the mathematical properties of the Elliptic Curve Digital Signature Algorithm (ECDSA) used by Bitcoin and Ethereum. A signature is a pair of integers (r, s). The algorithm is malleable because if (r, s) is valid, then (r, -s mod n) is also a valid signature for the same message and public key. This creates two different transaction IDs (txids) for the same essential transaction.

Because the digital signature is part of the transaction data hashed to create the transaction ID, a malleated signature changes the resulting txid. This can break systems that track transactions by their ID before they are confirmed on-chain, as the expected ID will not appear. Key impacts include:

• Breaking simplistic payment tracking in wallets and exchanges.
• Enabling transaction replay attacks in certain smart contract contexts.
• Complicating the construction of hash-linked structures like the Bitcoin Lightning Network.

Bitcoin initially suffered from this vulnerability, most notably exploited in the Mt. Gox incident. The community addressed it in stages:

• BIP-62 proposed strict rules for signature encoding.
• Segregated Witness (SegWit), activated in 2017, provided the definitive fix. It moves the witness data (signatures) outside the part of the transaction used to calculate the txid, making the txid immutable regardless of signature malleability.

Ethereum transactions are inherently less vulnerable because their unique identifier is the transaction hash, which is computed before being signed. The signature is appended externally. Therefore, altering the signature does not change the transaction hash that nodes use to reference the transaction. However, the signed transaction blob (RLP data) can be malleated, which can affect pending transaction pools but not confirmed state.

In smart contracts, especially those that verify signatures off-chain (e.g., for meta-transactions or token approvals), malleability can be a critical risk. A contract that stores used signatures in a mapping to prevent replay must normalize signatures (e.g., enforce a high-s value) or use a nonce system. Failure to do so allows an attacker to malleate a used signature, creating a new valid one that bypasses the replay protection.

• Transaction Malleability: The broader attack exploiting signature malleability to change a transaction's on-chain ID.
• Replay Attack: Re-submitting or re-using a valid signed message, which malleability can facilitate.
• ECDSA Recovery Parameter (v): In Ethereum, the v value is part of the signature and must be handled correctly to avoid malleability.
• BIP-341 (Taproot): Uses Schnorr signatures, which are non-malleable and aggregate signatures, eliminating this class of vulnerability.

Signature malleability exploits the mathematical property that an Elliptic Curve Digital Signature Algorithm (ECDSA) signature is not unique. A valid signature (r, s) can be transformed into another valid signature (r, -s mod n) without knowing the private key. This creates two different valid signatures for the same message and key pair.

This flaw was famously exploited to manipulate Bitcoin transaction IDs (TXIDs). Attackers could:

• Re-broadcast a malleated version of an unconfirmed transaction.
• Cause the original transaction to appear to fail, while the malleated one confirmed.
• This disrupted services relying on unconfirmed TXIDs, like exchanges and payment processors, leading to significant financial losses.

Bitcoin's Segregated Witness (SegWit) upgrade in 2017 fundamentally fixed this by changing how transaction data is structured. It removes the signature data (witness) from the transaction identifier calculation. Since the TXID is now computed only from the transaction's core data, altering the signature no longer changes the TXID, eliminating the attack vector.

The primary risk of malleability is a transaction replay attack. If a TXID changes after being signed but before confirmation, a system tracking the original TXID will not see the transaction succeed. An attacker could trick a user into resending funds, as their system believes the first payment failed. This was a critical issue for lightning network channels and atomic swaps before fixes were implemented.

Modern blockchain development employs several strategies to prevent malleability attacks:

• Adopt SegWit-style witness isolation.
• Use canonical signature encoding (enforcing low-s values).
• Implement unique transaction nonces or sequence numbers.
• For smart contracts, use checks like ecrecover carefully and avoid relying solely on transaction hashes for state changes.

Understanding signature malleability requires knowledge of related cryptographic and blockchain concepts:

• ECDSA & Schnorr Signatures: Schnorr signatures are non-malleable by design.
• Transaction ID (TXID): The hash of a transaction, which malleability aimed to alter.
• Replay Protection: A network-level defense against replaying transactions across chains (e.g., after a hard fork).
• Smart Contract Security: Vulnerabilities like those exploited in the Parity multisig wallet hack involved signature verification logic.

The most common fix is enforcing a single canonical representation for a signature. For ECDSA (used by Bitcoin and Ethereum), this involves:

• Enforcing DER encoding rules strictly.
• Requiring the 'S' value to be ≤ n/2 (where n is the curve order), known as low-S normalization.
• Rejecting high-S signatures at the consensus or mempool level. This ensures that for any given signed message, only one valid signature representation exists, closing the malleability loophole.

Modern signature schemes like Schnorr (implemented in Bitcoin Taproot) are non-malleable by design.

• Linear Property: Schnorr signatures are linear, allowing secure signature aggregation (MuSig) without introducing malleability.
• Unique Encoding: They have a unique, deterministic representation for a given key and message.
• Batch Verification: Their security properties enable efficient batch verification, further hardening the system. Adoption of Schnorr is a proactive fix against entire classes of malleability-based attacks.

In smart contract platforms, developers implement checks to prevent malleability-related exploits:

• Using tx.origin with Caution: Malleable transactions can affect sender verification.
• Replay Protection: Contracts implement nonces or stateful checks (like a mapping of used hashes) to prevent the same signed message from being executed twice.
• Signature Verification Libraries: Using audited, standard libraries (like OpenZeppelin) that implement EIP-712 for structured data signing helps ensure predictable, non-malleable signature handling off-chain and on-chain.

A primary risk of signature malleability is the transaction replay attack. An attacker can broadcast a modified but still valid version of a signed transaction, causing the same funds to be transferred multiple times if the network does not properly track transaction IDs. This was a critical issue in early Bitcoin implementations before the introduction of BIP 62 and Segregated Witness (SegWit), which fixed the transaction ID calculation.

SegWit is a Bitcoin protocol upgrade that directly addressed signature malleability by separating (segregating) the signature data (witness) from the transaction data. This change meant the signature was no longer part of the data hashed to create the transaction ID (txid), making the txid immutable. As a result, any modification to the signature creates a new, separate witness transaction ID, eliminating the core malleability vector.

The vulnerability often stems from the properties of the Elliptic Curve Digital Signature Algorithm (ECDSA) and its Distinguished Encoding Rules (DER) format. ECDSA signatures are represented as a pair of integers (r, s). Because the mathematics of the curve allows for a complementary point, the value s can be replaced with -s mod n to create a different, yet valid, signature encoding, leading to malleability.

Bitcoin Improvement Proposal 62 (BIP 62) proposed rules to make transactions non-malleable. A key component was enforcing low-S values in signatures, requiring the s value in an ECDSA signature to be less than half the curve order. This eliminated the s-value negation attack by ensuring only one canonical form of a signature is considered standard and valid by the network.

In smart contract platforms like Ethereum, signature malleability can affect protocols that rely on off-chain signatures for authorization (e.g., multi-sig wallets, token approvals, or meta-transactions). A contract that does not properly track used signatures or uses a vulnerable signature recovery method (like ecrecover) could allow a single signed message to be executed multiple times with its malleable variants.

The solution to malleability is enforcing a canonical signature format. This means defining a single, unambiguous byte representation for a valid signature. Methods include:

• Low-S enforcement (as in Bitcoin).
• Using RFC 6979 for deterministic nonce generation.
• Implementing signature nonce registries in smart contracts.
• Adopting non-malleable signature schemes like Schnorr signatures or EdDSA (Ed25519).