Segregated Witness and transaction malleability

Wonder

1. Why could a stranger change a transaction’s identity without breaking its validity?
2. How does moving signatures out of the hash fix malleability while keeping them consensus-protected?
3. What is block weight, and why did discounting witness data increase capacity?

Explore

1. Before SegWit, a transaction ID (txid) was the double SHA-256 of the whole transaction, signatures included. A third party could re-encode a signature, for example by negating its s value or changing how it was pushed, without invalidating it, producing a new txid for the same payment. This malleability broke unconfirmed chains: if Alice’s child transaction referenced her parent by ID, a malleated parent would orphan it, confusing wallets and exchanges tracking payments.
2. Mt. Gox cited this mechanism in February 2014 to explain internal chaos during its collapse, though later analysis showed it accounted for little of the reported losses. The vulnerability persisted because ECDSA signatures are inherently mutable in their byte representation; third parties, and after the BIP66 and low-S rules mainly miners, could rewrite them. This instability made it unsafe to build two-way payment channels such as Lightning, where channel states depend on specific, predictable transaction IDs before confirmation.
3. Segregated Witness (BIP141), activated August 24, 2017, at block 481,824, resolved this by separating witness data from the transaction body. The txid now hashes only the non-witness fields, rendering it immutable to signature encoding changes. Witnesses remain in a distinct structure within the raw transaction but are excluded from the identity hash. Third parties can no longer change the txid, while the signatures remain fully checked by consensus.
4. Witness data is committed via a Merkle tree referenced in each block’s coinbase transaction, ensuring it cannot be dropped or modified without invalidating the block. Although segregated from the txid, witnesses still count toward block size limits under a new ‘weight’ metric: 4,000,000 weight units per block. Each non-witness byte counts as 4 weight units and each witness byte as 1, so signature-heavy transactions fit more easily.
5. BIP143 introduced a new signature-hashing scheme that removed quadratic hashing costs for transactions with many inputs. BIP141 defined version 0 witness programs, P2WPKH and P2WSH, which became the standard for new addresses, and BIP144 specified how witness data travels between peers. These changes not only fixed malleability but also laid the groundwork for future upgrades like Taproot by establishing a versioned witness program framework that allows script evolution without breaking existing consensus rules.
6. Open a block explorer and locate a recent P2WPKH transaction. Inspect it: the signatures appear in a separate ‘witness’ field rather than in the input’s scriptSig, and the txid is computed without them. Compare this to a pre-SegWit P2PKH transaction from 2016, where signatures sit in the scriptSig and so feed into the txid. The visual separation confirms that witness data no longer influences the transaction’s identity.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• BIP141: Segregated Witness (Consensus layer)
• BIP143: Transaction Signature Verification for Version 0 Witness Program
• Decker & Wattenhofer, 'Bitcoin Transaction Malleability and MtGox' (2014)
• Bitcoin Core 0.13.1 release notes (SegWit deployment)