How does the mechanism work?
A transaction’s ordinary identifier excludes witness data. A witness transaction identifier includes it. This distinction addresses unwanted identifier changes caused by signature data for witness spends, while the exact guarantees depend on the transaction’s inputs.
Weight assigns different costs to base and witness data. Virtual size expresses that weight in fee-rate units. This is why the byte length of a full serialization and the virtual size used for fees need not be equal.
Witness weighting is a rule for measuring a transaction’s contribution to limits and fee-rate units. It should not be described as removing signatures from the blockchain altogether. The validation data still has a defined representation and commitment. When reading an explanation, ask whether it describes the base serialization, the full serialization or the weighted measure. All can be correct measurements of the same transaction while having different numeric values. This distinction becomes especially useful when comparing an older input type with a witness input type: identify the actual byte components before drawing conclusions about size or cost from the labels alone.
What would you see in an example?
Imagine comparing transactions with the same payment amount but different input types. One spends an older output; another spends a native witness output. Their spending data is represented differently, so you cannot infer equal virtual sizes from the equal amount. Inspect the actual transaction structure rather than assuming every payment has the same size.
How does separating the witness affect measured size?
A useful worked example starts with an invented base size of 100 bytes and total size of 250 bytes. Under the SegWit formula the weight is 100 × 3 + 250 = 550 weight units. Virtual size is ceiling(550 / 4), or 138 vbytes. Total serialization size remains 250 bytes; witness weighting does not erase data from a validating node’s work.
The consensus maximum block weight is 4,000,000 weight units. That limit is not a promise that every block has one fixed byte length or one fixed transaction count. The mix of base and witness data determines how weight relates to serialized size. Dividing the weight limit by an assumed payment size gives only a model based on that assumed transaction shape.
The ordinary transaction identifier, txid, hashes the serialization without witness data. The witness transaction identifier, wtxid, includes the witness serialization. A block also commits to witness data through a commitment associated with its issuance transaction transaction. The header’s transaction Merkle root and the witness commitment have related but distinct jobs; neither is permission to skip signature validation.
For a version-0 witness key-hash spend, the witness supplies a signature and public key. The output being spent committed to the public-key hash. Nodes check that the supplied key matches the program and that the signature satisfies the spending rules. This gives a concrete reason to distinguish the receiving program from the later witness: the earlier output states a condition, and the later input supplies evidence.
Common misunderstandings
Witness data is not an optional attachment that a full validator may ignore while still claiming complete validation. Different node capabilities and serialization views explain what data they receive, but applicable witness rules still define validity.
SegWit does not make the payment amount itself smaller or larger. Weight measures representation and resource accounting, while satoshis measure value. Nor does witness use make every conceivable transaction mutation impossible; identify the input constructions and signature commitments before describing a particular guarantee.
Check yourself
If weight is 550, is the virtual size the same as the 250-byte full serialization?
Reveal the answer
No. The virtual size is 138 vbytes after rounding up. Serialized bytes and virtual bytes are different measurements.
What does this diagram leave out?
SegWit does not make every transaction private, remove fees or promise an immediate confirmation. A witness-address prefix identifies an encoding family, not every feature of a transaction. Legacy outputs still exist, and compatibility depends on the software and output types involved. The diagram omits the detailed serialization and block commitment rules.
Which primary sources explain the rules?
Sources: Segregated witness specification; Witness address encoding specification.