The Bug That Let Someone Rewrite Your Receipt After You Paid

You've just paid. The coins left your wallet, the transaction hit the mempool, and somewhere in that relay chain a node quietly tweaks a single byte inside your signature. The spend is identical. The destination is identical. The network accepts it. But the transaction ID your software wrote down no longer exists, replaced by a fingerprint you've never seen, pointing at a transaction you didn't track.

That was Bitcoin's transaction malleability problem, and it was not a theoretical edge case.

SegWit fixed it by changing one specific thing: what data gets included when Bitcoin calculates a transaction ID. Not the amounts, not the addresses. The signatures. That's the whole story, but the details are worth understanding, because the fix turns out to be more elegant than most explainers let on.

What a Transaction ID Actually Is

A Bitcoin transaction ID (txid) is a SHA-256 hash, applied twice, over the raw bytes of a serialized transaction. Feed the transaction data in, get a 32-byte fingerprint out. Change a single byte of input and the fingerprint changes completely. That's the hash function's whole point.

Before SegWit, the transaction data fed into that hash included everything: inputs, outputs, amounts, and the witness data (the signatures and scripts that prove you're allowed to spend the coins). All of it, in one blob, hashed together.

Here's the wrinkle. Signatures in Bitcoin use ECDSA, a scheme where a given private key can produce multiple valid signatures for the same message. They're all cryptographically legitimate. A miner, a relay node, or even the original sender could take a valid transaction, tweak a byte inside the signature, and produce a transaction that:

  • Spends the same coins
  • Sends them to the same destination
  • Is accepted by the network as valid
  • Has a completely different txid

The spend is identical. The receipt number is not.

Why That Mattered More Than It Sounds

For a simple payment between two people, malleability is annoying but containable. The coins arrive; you just have to search for the right txid. The real damage showed up in anything that chains transactions together.

Consider a payment channel, the kind of construction Lightning Network is built on. Two parties, call them Priya and Marco, collaboratively build a refund transaction before they broadcast the funding transaction. The refund transaction references the funding transaction's txid. If that txid changes after broadcast because someone mutated the signature in transit, the refund transaction references a txid that no longer exists on-chain. The channel breaks. The safety net is gone.

This isn't hypothetical. The attack was used in practice. It was one reason that trustless payment channels were essentially impossible to build safely on Bitcoin without a protocol fix, and Lightning, as designed, required malleability to be solved first. Anyone who tells you SegWit was primarily a scaling upgrade has the story backwards.

How SegWit Rearranges the Ingredients

SegWit's solution is almost insultingly simple once you see it: take the witness data (signatures, scripts) out of the data that gets hashed into the txid.

A SegWit transaction has two parts. The base transaction contains inputs, outputs, and amounts but no signatures. The witness is a separate, appended structure containing the signatures. The txid is calculated by hashing only the base. The signatures live in the witness, which is committed to separately in the block's coinbase transaction via a witness merkle root.

The result: you can no longer change a signature and get a new txid, because the txid never included the signature in the first place. The receipt number is now derived from the parts of the transaction that cannot be legitimately altered without changing the actual spend.

To see it concretely: Priya and Marco build their Lightning channel. The funding transaction is broadcast. Even if a node along the way tweaks a signature byte in the witness, the txid is unchanged. The refund transaction, which references that txid, remains valid. The channel is safe.

The Weight System: A Side Effect That Became a Feature

Stripping signatures out of the base transaction had an accounting side effect that turned into a deliberate policy lever.

Bitcoin blocks are limited by size, measured in bytes. Witness data is bulky; signatures are large. Once SegWit separated witness from base data, the protocol needed a new way to measure transactions that accounted for both. The answer was weight units (sometimes called vbytes in shorthand).

Base data counts at 4 weight units per byte. Witness data counts at 1 weight unit per byte. A block can hold up to 4 million weight units. This means witness data is effectively discounted 75% relative to base data when calculating how much of a block a transaction consumes.

The practical consequence: SegWit transactions fit more efficiently into blocks, and fees drop for SegWit users. Not because anything was made magically faster, but because the accounting changed. Still, here is what most guides skip entirely: the fee reduction was not the goal. It was a byproduct of a security fix. The discount on witness data was a deliberate adoption incentive bolted onto a structural change that was already necessary.

Think of it like a hospital redesigning its filing system to fix a records-tampering vulnerability, then discovering the new layout also makes the filing clerks 30% faster. The speed improvement is real and welcome. It was not the reason for the renovation.

What People Get Wrong About SegWit

The popular narrative frames SegWit as a scaling upgrade: more transactions per block, lower fees, bigger throughput. That framing isn't wrong. It's incomplete in a way that obscures what actually changed.

The primary fix was malleability. Scaling was the consequence. If you think of SegWit only as a block size tweak, you'll miss why it was a prerequisite for Lightning Network, and why the Bitcoin development community treated it as non-negotiable rather than optional.

There's also a persistent misconception that SegWit transactions carry weaker security because the signatures are "separated" from the transaction. They're not separated in the sense of being unlinked. The witness data is committed into the block via the witness merkle root, recorded in the coinbase transaction. A full node verifying the block checks both the base transaction and the witness. Nothing is floating loose.

The catch: light clients (SPV clients) that don't download witness data are not verifying signatures. They're trusting block headers and miner honesty. That was true before SegWit too. SegWit didn't worsen that tradeoff; it just made it more explicit. If you're running a light client and assuming full validation, that's a conversation worth having with yourself regardless of SegWit.

The Signature Is No Longer the Name Tag

Before SegWit, a Bitcoin transaction's identity was partly defined by how it was signed. That's like naming a legal contract after the pen used to sign it rather than what the contract says. Change the pen, change the name, even if every clause is identical.

SegWit made the txid a function of economic intent: who is paying whom, how much, from which coins. The signatures that authorize it are verified, committed to the block, and immutably recorded. But they no longer define the transaction's name.

For anyone building on top of Bitcoin, that distinction is not a footnote. It is the difference between a foundation you can build on and one that occasionally shifts under your feet.