Fixing Malleability

The primary motivation for creating the wTXID was to eliminate Third-Party Malleability. This was a bug (or design quirk) in legacy Bitcoin that allowed anyone to change a transaction's ID without changing its validity.

1. What is Malleability?

In the legacy protocol, the ScriptSig (the signatures) was included in the TXID calculation.

• ECDSA signatures can be represented in multiple ways (High-S vs. Low-S).

• Adding a "NOP" (No Operation) opcode to the script doesn't change the script's logic but changes its bytes.

• If a miner changed your signature's byte format, your TXID changed.

2. Why was this bad?

If you sent a transaction (TX A) and then immediately sent another one (TX B) that spent an output of TX A, you had to reference TXID A in your second transaction.

• If a miner changed TX A's signature, the TXID changed to TXID A'.

• Now, TX B is invalid because it is looking for TXID A, which no longer exists in the chainstate.

3. How SegWit Fixed It

By moving signatures to the Witness section and excluding that section from the TXID, the TXID became immutable.

• Even if a miner changes the formatting of your signature, the TXID remains exactly the same.

• The change in signature will be reflected in the wTXID, but since the wTXID is not used for referencing inputs, it doesn't break any "child" transactions.

4. Enabling Layer 2

This fix was the "Unlock Key" for the Lightning Network. Lightning relies on a series of pre-signed transactions that haven't been mined yet. Without a fixed TXID, these transactions would be fragile and easily broken by miners.

Property	Legacy (Malleable)	SegWit (Fixed)
Sig in TXID?	Yes	No
Miner can change ID?	Yes	No
Reliable Unconfirmed Chains?	No	Yes

In the final section, we will build a Python wTXID Calculator.