Bitcoin Weight Units and SegWit Fee Rates Explained
You're staring at a fee estimator that wants an answer in sat/vB. Satoshis, fine. The "vB" part you can probably reverse-engineer. But underneath it sits a unit called a weight unit that your wallet computes silently, never explains, and never apologizes for hiding. That invisibility is harmless until you're manually constructing a transaction, batching a dozen payments, or simply trying to understand why a SegWit input is meaningfully cheaper to spend than a legacy one.
So let's do the actual arithmetic.
Raw Bytes Are Not What Miners Price
Before SegWit, block space had a clean 1 MB ceiling. Every byte counted equally. Fee rate was satoshis per byte, full stop.
SegWit changed the accounting by splitting each transaction into two parts: the base data (version, inputs, outputs, locktime) and the witness data (the signatures and scripts that prove ownership). The rule, codified in BIP 141, weights them differently.
- Base data: 4 weight units per byte
- Witness data: 1 weight unit per byte
The block limit shifted from 1 MB of raw bytes to 4,000,000 weight units. A block stuffed entirely with base data still hits 1 MB. A block heavy with SegWit transactions can carry more total bytes while staying inside the weight ceiling, because witness data is cheap. Witness bytes cost one-quarter what base bytes cost, fee-rate-wise. That ratio is the whole engine.
The Virtual Byte, Concretely
Virtual bytes are weight units divided by four. That's the complete formula: `vbytes = weight / 4`. Fee estimators work in vbytes because it maps legacy transactions back to a 1:1 ratio with raw bytes. A pure-legacy transaction carries zero witness data, so its weight equals raw bytes times four, and dividing by four returns the original byte count. Nothing changes for legacy users. SegWit users collect a discount.
Here is a worked example with plausible but invented figures.
Consider a transaction with one native SegWit (P2WPKH) input and two outputs. The non-witness total, covering version, the input outpoint, sequence, outputs, and locktime, comes to roughly 109 bytes. The witness field carries a 72-byte DER signature, a 33-byte compressed public key, and overhead: call it 108 bytes.
Weight = (109 × 4) + (108 × 1) = 436 + 108 = 544 weight units.
Virtual bytes = 544 / 4 = 136 vB.
At 10 sat/vB, the fee is 1,360 satoshis.
Now run the same economic transfer as legacy P2PKH. The signature and public key live in the scriptSig, not the witness field, so every byte is base data. A comparable legacy input runs about 148 bytes on its own; the full transaction lands near 226 raw bytes. Weight = 226 × 4 = 904. Virtual bytes = 226. Fee at 10 sat/vB: 2,260 satoshis.
The SegWit version costs roughly 40% less. At scale, that gap is real money, and any serious operator who ignores it is leaving meaningful savings on the table.
One Thing the Arithmetic Won't Tell You
Weight units measure block space consumed. They say nothing about what fee rate you need to actually get confirmed, because that is a function of mempool congestion at broadcast time, not transaction structure.
Take two users, call them Priya and Daniel, sending structurally identical P2WPKH transactions an hour apart. Priya's clears in the next block. Daniel's sits for six hours because a wave of higher-fee transactions arrived in between. Their weight calculations are identical. Their confirmation times are not. The weight formula is a cost-per-unit calculation, not a queue-position guarantee, and conflating the two is one of the more persistent misconceptions in this space.
There is also a scaling property worth knowing before you batch payments. Adding a second P2WPKH input adds roughly 41 base bytes (41 × 4 = 164 WU) plus about 108 witness bytes (108 × 1 = 108 WU), totaling 272 WU, or 68 vB per additional input. Outputs are cheaper, around 31 vB each. Adding recipients by appending outputs is far more efficient per recipient than sending separate transactions. If you are moving funds to ten addresses and doing it ten separate times, you are, bluntly, overpaying.
The weight-unit system is, at its core, a pricing mechanism shaped like a subsidy: it rewards transactions that push signature data to the witness field without pretending that data has no cost. Think of it as a two-lane toll road where the lane carrying the heaviest structural load charges four times as much per foot. Miners still haul the witness data. You just pay a lower rate for the privilege, because the protocol decided that encouraging smaller base blocks was worth the accounting complexity.
Understand that trade-off and the sat/vB figure your wallet hands you stops being a black box.