Solving Transaction Malleability with SegWit

Before SegWit, Bitcoin suffered from a critical vulnerability known as Transaction Malleability. While harmless for basic on-chain transfers, this flaw was a fatal barrier to building Layer-2 scalability solutions like the Lightning Network.

By separating signatures from the core transaction, SegWit completely eliminated transaction malleability.

---

🔬 Understanding Transaction Malleability

A legacy transaction's hash (its TxID) is computed by hashing the entire serialized transaction byte stream:

$$\text{Legacy TxID} = SHA256(SHA256(\text{Full Serialized Transaction Data}))$$

Because the signatures (stored in the input's scriptSig) were part of the serialized data, any change to the signature changed the resulting TxID.

As explored in our digital signature guides, ECDSA signatures are naturally malleable: * An attacker can alter the DER padding bytes, add dummy stack operations, or negate the $s$ component to $-s \pmod n$. * These changes do not break the signature's validity. * An attacker could intercept Alice's pending transaction in the mempool, modify her signature slightly, and broadcast this "malleated" version. * If a miner included the malleated version in a block, Alice's transfer would still succeed, but her transaction's TxID would be completely different from the one her wallet originally calculated.

---

⚡ The Fatal Threat to the Lightning Network

The Lightning Network operates by chaining unbroadcasted, pre-signed transactions offline between two parties. Let's look at why malleability made this impossible:

                            THE MALLEABILITY TRAP
┌──────────────────────────────────────┐
│  1. Alice & Bob Funding Tx (TxID A)  │ (Broadcasted on-chain)
└──────────────────┬───────────────────┘
                   │
                   ▼ (Unbroadcasted Commitment Tx refers to Parent TxID A)
┌──────────────────────────────────────┐
│  2. Commitment Transaction (Offline)  │ (Refers to parent: TxID A)
└──────────────────────────────────────┘

                              [ ATTACK WINDOW ]
                     Bob malleates the signature of (1)
                        before it gets mined!
                                     │
                                     ▼
┌──────────────────────────────────────┐
│  3. Mined Funding Tx has TxID B!     │ (On-chain parent hash changed!)
└──────────────────────────────────────┘
                                     │
                                     ▼
┌──────────────────────────────────────┐
│  4. Commitment Transaction INVALID!   │ (Refers to non-existent TxID A)
├──────────────────────────────────────┤
│ • Alice's funds are locked forever!  │
└──────────────────────────────────────┘

1. Alice and Bob lock funds on-chain using a 2-of-2 multi-sig Funding Transaction. Let's assume its TxID is TxID A.
2. Offline, they pre-sign Commitment Transactions spending from the funding output. These commitment transactions explicitly point to parent TxID A.
3. Alice broadcasts the funding transaction. Bob intercepts it in the mempool, malleates the signature, and gets it mined. The transaction succeeds, but its on-chain ID is now TxID B.
4. The Trap: Because the on-chain parent is now TxID B, Alice's pre-signed commitment transactions (which point to TxID A) are now completely invalid and permanently unbroadcastable. Bob has successfully locked Alice's funds on-chain forever!

---

🔒 How SegWit Cured Malleability

SegWit solved this issue by moving the signatures out of the core transaction body and placing them in the Witness Area.

Crucially, under SegWit rules, the transaction's TxID is computed by hashing only the core transaction body, which completely excludes the Witness Area:

                      SEGWIT TxID HASHING BOUNDARY
┌────────────────────────────────────────────────────────┐
│               CORE TRANSACTION BODY (TXID)             │
├────────────────────────────────────────────────────────┤
│ • Version, Inputs (TXIDs, Indices), Outputs, Locktime  │ ◄── Hashed for TxID!
└────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────┐
│               WITNESS AREA (WITNESS TXID)              │
├────────────────────────────────────────────────────────┤
│ • Signatures, Public Keys                              │ ◄── Hashed only for wTxID
└────────────────────────────────────────────────────────┘

If Bob intercepts Alice's SegWit transaction and malleates her signature in the Witness Area: 1. He alters the witness hash (the wTxID). 2. But the core TxID remains 100% identical and unchanged!

Because the TxID is computed strictly from the inputs, outputs, and amounts, the transaction hash is completely deterministic and immune to signature-level tampering. This secure foundation allowed developers to safely build the Lightning Network, enabling instantaneous, off-chain Bitcoin micro-payments globally.