MASTERING-BITCOIN · Interactive Practice | Unit 6 · Video 5

Why Bitcoin's Signatures Were in the Wrong Place — and How SegWit Fixed Everything

IKey Concepts Reference

Concept	Definition
Witness	Data that proves a locking condition is satisfied (e.g., a digital signature)
txid	Transaction identifier: $\text{txid} = \text{SHA256d}(\text{transaction bytes})$
Malleability	Ability to change a transaction's bytes (and txid) without changing its economic effect
SegWit Rule	$\text{txid}_{\text{SegWit}} = \text{hash}(\text{version, inputs, outputs, locktime})$ — witness data excluded
Soft Fork	Backward-compatible upgrade: new rules are strictly more restrictive than old rules

IIInteractive Visualization 1: Transaction Structure — Legacy vs SegWit

Conceptual question: What gets included in the txid hash, and how does that change between legacy Bitcoin and SegWit?

Toggle between the two formats below to see exactly which fields contribute to the transaction identity.

⚙ interactive visualization — coming to this page format soon

Notice: In the legacy format, the red signature box is inside the txid bracket — meaning any change to the signature changes the txid. In SegWit, the witness structure sits outside the bracket. The signatures still exist and are still verified by every node, but they no longer affect the transaction's identity.

IIIInteractive Visualization 2: The Malleability Attack

Conceptual question: What happens to a chain of transactions when a third party modifies a signature's encoding?

Use the toggle to apply a malleability attack to Alice's transaction and watch the downstream chain break.

⚙ interactive visualization — coming to this page format soon

Reflect: Try all four combinations. With legacy format, an attacker who never steals anything can still break the entire downstream payment chain just by re-encoding a signature. With SegWit, the same attack has no effect on the txid — so Bob's reference still resolves and Carol gets paid. The economic effect was always identical; only the bytes differed.

IVInteractive Visualization 3: The Authorize-Authenticate Pattern

Conceptual question: How has Bitcoin's locking and unlocking mechanism evolved across three eras while preserving the same fundamental pattern?

Select an era to see how authorization (the lock) and authentication (the proof) are expressed.

⚙ interactive visualization — coming to this page format soon

Notice: Across all three eras, the structure is identical — the output defines what's required; the input proves it's been satisfied. What changes is the level of abstraction. SegWit's contribution wasn't inventing this pattern; it was moving the proof component (the witness) outside the txid calculation, while preserving the authorize-authenticate relationship.

VQuiz Questions

Question 1

In a legacy Bitcoin transaction, which of the following fields are included in the txid hash?

✅ Correct! All four sections — including the input script with signatures — feed into the txid hash. That's the root cause of malleability.

❌ Not quite. Remember: in the legacy format, the txid hashes the entire transaction, including the input scripts that hold the signatures.

Show solution

Solution:

A legacy Bitcoin transaction has four sections, and the txid is computed by hashing all of them:

$\text{txid}_{\text{legacy}} = \text{SHA256d}(\text{version} \,\|\, \text{inputs (incl. signatures)} \,\|\, \text{outputs} \,\|\, \text{locktime})$

Because the input script — which contains the signatures — is part of the hashed data, any change to the signature bytes changes the txid. This is precisely the design choice that caused Bitcoin's three malleability problems.

SegWit changed this by excluding the witness data from the txid hash, while still keeping signatures in the transaction so nodes can verify them.

Question 2

True or False: SegWit removes signatures from Bitcoin transactions entirely.

✅ Correct! SegWit segregates signatures — moving them out of the txid calculation while keeping them in the transaction for verification.

❌ Not quite. SegWit doesn't remove signatures — every node still verifies them. It just moves them so they no longer affect the txid.

Show solution

Solution:

SegWit does not remove signatures — it segregates them. The name "Segregated Witness" describes exactly what happens:

The input script field is left empty
A new field, the witness structure, holds the signatures
The witness structure travels with the transaction across the network
Every full node still receives, parses, and verifies the witness
Only the txid hash excludes the witness structure

This is why SegWit fixes malleability: signatures are still verified (so security is preserved), but changing them no longer changes the transaction's identity.

A common misconception is that SegWit somehow makes signatures optional or removes them — it doesn't.

Question 3

Alice and Bob want to open a payment channel using a 2-of-2 multisig funding transaction, with a pre-signed refund transaction as a safety net. In legacy Bitcoin, why does this create a circular dependency?

✅ Correct! The dependency loop — refund → txid → signatures → refund — is broken when signatures no longer feed into the txid.

❌ Not quite. The issue isn't with multisig support itself, but with the order of operations: computing a txid that depends on signatures that depend on a refund that depends on the txid.

Show solution

Solution:

The circular dependency arises from three constraints that contradict each other:

The refund references the funding txid. Its input field must contain the funding transaction's identifier.
The funding txid depends on signatures. In legacy Bitcoin, the txid is computed over the entire transaction including the input scripts where Alice's and Bob's signatures live.
Neither party will sign without a refund first. If Alice signs the funding tx and Bob disappears, Alice's coins are stuck in multisig forever. Same for Bob. They each need a pre-signed refund as a safety net before signing.

So we have: $\text{refund} \to \text{needs funding txid} \to \text{needs signatures} \to \text{needs refund}$

A perfect chicken-and-egg loop. SegWit breaks this loop by computing the txid before signatures are added — since signatures no longer affect the txid, you can compute the funding txid first, build the refund referencing it, then sign safely.

Question 4

Why was SegWit able to deploy as a soft fork rather than requiring all nodes to upgrade?

✅ Correct! Both node types accept the transaction — old nodes under permissive rules, new nodes under stricter rules. That's the soft fork pattern.

❌ Not quite. Soft forks work because new rules are strictly more restrictive than old rules. Both node types must accept the same transactions; new nodes just enforce additional checks.

Show solution

Solution:

A soft fork is a backward-compatible consensus change where new rules are strictly more restrictive than old rules. SegWit achieves this through a clever output script template:

A SegWit output looks like: [version byte] [witness program]
Old nodes don't recognize this pattern as a standard script. To them, it appears to be an anyone-can-spend output — trivially valid under permissive legacy rules.
New nodes recognize the version byte (e.g., v0 for P2WPKH/P2WSH, v1 for Taproot) and enforce full witness validation, requiring a valid signature.

Both node types accept the same transaction:

Old nodes accept it because their permissive rules don't reject it
New nodes accept it because their stricter rules are satisfied by a valid witness

Since new rules are a subset (strictly more restrictive) of old rules, no old node is ever forced to reject a transaction that new nodes accept. Consensus is maintained without forcing upgrades.

This same mechanism reserved witness versions 1–16 for future upgrades — Taproot (2021) used version 1.

Solved: 0 / 4