SegWit and Witness Data

What You’ll Learn

• The structure of the witness field in a SegWit transaction
• How SegWit fixes transaction malleability
• The weight discount and its impact on fees

What Is Segregated Witness?

Segregated Witness (SegWit), activated in August 2017, separates signature data from the transaction body. Instead of embedding signatures in the ScriptSig field of each input, SegWit moves them to a dedicated witness section that sits between the outputs and the locktime.

This seemingly small restructuring solves several critical problems and enables technologies like the Lightning Network.

Witness Structure

In a SegWit transaction, each input has a corresponding witness stack. For a P2WPKH (Pay-to-Witness-Public-Key-Hash) input, the witness contains exactly two items:

02                          # Stack item count: 2
47                          # Item 1 length: 71 bytes
3044022047ac...0121          # DER-encoded signature + SIGHASH byte
21                          # Item 2 length: 33 bytes
03b8f12c...a4e9             # Compressed public key (33 bytes)

The witness stacks appear in the serialized transaction in the same order as the inputs. If a transaction has 3 inputs, there are 3 witness stacks — even if some inputs are legacy (their witness stack is empty: 00).

Complete SegWit Transaction

Here is the full layout of our signed transaction:

02000000                    # Version 2
0001                        # Marker (0x00) + Flag (0x01) → "this is SegWit"
01                          # 1 input
  <32-byte prev tx hash>
  00000000                  # vout 0
  00                        # Empty ScriptSig (SegWit!)
  fdffffff                  # Sequence
02                          # 2 outputs
  e093040000000000          # 300,000 sats
  160014<recipient-hash>    # P2WPKH output
  b882020000000000          # 198,590 sats (change)
  160014<change-hash>       # P2WPKH output
                            # === Witness data starts ===
  02                        # 2 witness items for input 0
    47 <71-byte signature>
    21 <33-byte pubkey>
                            # === Witness data ends ===
00000000                    # Locktime

Note: the marker 0x00 and flag 0x01 after the version tell parsers that this transaction contains witness data. Legacy nodes that don’t understand SegWit see the marker as a zero-input transaction and skip it — this is how SegWit achieves backward compatibility as a soft fork.

Fixing Transaction Malleability

Before SegWit, the transaction ID (txid) was computed from the entire serialized transaction, including the ScriptSig. Because ECDSA signatures can be mathematically modified without invalidating them (e.g., negating the S value), a third party could change a transaction’s txid without altering its meaning.

This was a real problem:

• The Lightning Network requires building chains of transactions that reference each other by txid. If a txid can change, the chain breaks.
• The 2014 Mt. Gox incident involved exploiting malleability to confuse the exchange’s transaction tracking.

SegWit fixes this by computing the txid from only the non-witness data. Since signatures are in the witness (not the main body), modifying them does not change the txid. A separate wtxid (witness txid) covers the full transaction including witness data.

The Weight Discount

SegWit replaces the 1 MB block size limit with a 4,000,000 weight unit (WU) limit. The key insight is that witness data receives a discount:

Non-witness data: 1 byte = 4 weight units
Witness data:     1 byte = 1 weight unit

This means a transaction with 100 bytes of non-witness data and 100 bytes of witness data has:

Weight = (100 × 4) + (100 × 1) = 500 WU
vBytes = 500 ÷ 4 = 125 vB

Compare to a legacy transaction where all 200 bytes count at full weight:

Weight = 200 × 4 = 800 WU
vBytes = 800 ÷ 4 = 200 vB

The practical result: SegWit transactions are 30-40% cheaper in fees than equivalent legacy transactions.

Why the Discount Makes Sense

The discount is not arbitrary. Witness data is only needed during validation — once a transaction is verified, nodes can discard it. Non-witness data (inputs referencing UTXOs, outputs creating new UTXOs) has a lasting impact on the UTXO set that nodes must store permanently. Cheaper pricing for temporary data reflects its lower long-term cost to the network.

Next Step

Continue to Broadcasting Your Transaction to send your signed transaction to the Bitcoin network.