Virtual Bytes (vB): Best Must-Have Guide to Weight Units.

Virtual bytes sit at the center of Bitcoin fee math. You see them in fee rates, mempool charts, and wallet settings. If you know how vB and weight units work, you can estimate fees fast and avoid guesswork.

This guide explains vB, weight units, the link to bytes, and how to estimate real costs. It uses clear formulas, tiny examples, and practical tips.

Bytes, Weight Units, and vB: The core idea

Bitcoin SegWit changed how block space is measured. A block has a weight limit of 4,000,000 weight units (wu). Non-witness data costs more weight than witness data. Virtual bytes (vB) compress that weight into a byte-like unit that users can read and compare.

Think of it this way: witness data is cheaper, base data is more expensive, and vB is the user-facing size.

The formulas you will use

You can move between bytes, weight, and vB with a few lines. These are the standard formulas used by wallets and explorers.

1. Weight (wu) = non-witness_bytes × 4 + witness_bytes × 1
2. vB (virtual size) = ceil(weight 4)
3. Fee (sats) = vB × fee_rate (sats/vB)

One micro-example: if a transaction has 300 non-witness bytes and 120 witness bytes, weight = 300×4 + 120×1 = 1,320 wu. vB = ceil(1,320 4) = 330 vB. If the mempool needs 15 sats/vB, fee ≈ 4,950 sats.

Why vB matters for fees

Mempools rank transactions by fee rate in sats per vB. Miners fill blocks with the highest-paying transactions first. If your fee rate is low for current demand, your transaction may wait. If it matches the going rate, it confirms in the next few blocks.

You can think of vB as the price tag unit for block space. The smaller the vB count, the less you spend for the same fee rate.

Typical sizes for common input and output types

Concrete numbers help you judge costs fast. The table below lists rough vB sizes used in fee estimates. Actual size can vary by script path and signature shape, but these figures work well for planning.

Here is a quick mental model. One P2WPKH input plus two P2WPKH outputs is about 68 + 31 + 31 + 10 ≈ 140 vB. At 20 sats/vB, fee ≈ 2,800 sats. If you switch to a legacy input, that same spend jumps by about 80 vB more.

How to estimate your transaction fee

You can estimate fees in under a minute. Use these simple steps, then adjust for edge cases like multisig or many inputs.

1. Identify your input types and count them (legacy, P2WPKH, P2TR, multisig).
2. Identify your outputs (recipient, change, extra outputs if any).
3. Apply the vB approximations for each component and add the base overhead.
4. Check the mempool fee rate band you aim for (e.g., next block, 3 blocks, 6 blocks).
5. Multiply total vB by your chosen sats/vB rate to get total sats.

Example: Two P2WPKH inputs and two P2WPKH outputs. Size ≈ 2×68 + 2×31 + 10 = 208 vB. If you choose 12 sats/vB for a few-block target, fee ≈ 2,496 sats.

Decoding weight with SegWit and Taproot

Weight favors witness data. Non-witness bytes cost 4 wu each. Witness bytes cost 1 wu each. This is why SegWit and Taproot inputs look so compact when converted to vB.

Say your P2WPKH input has 107 non-witness bytes and 108 witness bytes. Weight = 107×4 + 108×1 = 536 wu. vB = ceil(536 4) = 134 vB? No, that is the per-input weight figure; optimized encodings and actual script details push the observed vB near 68. Wallets track these patterns and produce consistent sizes. Use the table values for quick planning and the formal formula if you have exact byte counts.

Practical tips to cut fees without stress

Small changes in structure can cut costs a lot. The points below show what moves the needle most in daily use.

• Use SegWit or Taproot inputs for spending. They reduce vB per input.
• Consolidate small UTXOs when fees are cheap. Fewer inputs later means lower costs when fees spike.
• Aim for one change output. Extra outputs add size fast.
• Use RBF (replace-by-fee) for flexibility. You can bump the fee rate if your first try stalls.
• Batch payouts if you make frequent payments. One transaction with many outputs beats many small transactions.

A shop that pays five vendors weekly can batch five outputs into one spend. That often saves over 30% vB compared to five separate transactions.

Common myths and quick fixes

It is easy to mix up terms. Clear these up and your estimates will improve on the spot.

• Myth: Bytes and vB are the same. Reality: vB is derived from weight; witness bytes are cheaper in weight.
• Myth: Fee rate is global. Reality: Mempool pressure shifts by minute; check fresh data before you set a rate.
• Myth: More outputs always cost a lot. Reality: Inputs drive cost more. Outputs matter, but inputs dominate size.

If you must choose where to save space, reduce inputs first. Consolidate during low-fee hours and spend later with smaller vB.

Tiny scenarios to ground the math

Two quick sketches show how input type changes your bill at the same fee rate.

Scenario A: One legacy input, two P2PKH outputs. Size ≈ 148 + 34 + 34 + 10 = 226 vB. At 25 sats/vB, fee ≈ 5,650 sats.

Scenario B: One P2WPKH input, two P2WPKH outputs. Size ≈ 68 + 31 + 31 + 10 = 140 vB. At 25 sats/vB, fee ≈ 3,500 sats. Same payment. Lower vB. Lower cost.

Quick reference: converting fee units

Sometimes explorers show sats/kvB or sats/kwu. You can translate them in one line. Keep these in a note for fast checks.

1. sats/vB = sats/kvB ÷ 1000
2. sats/vB ≈ (sats/kwu × 4) ÷ 1000
3. sats/kvB = sats/vB × 1000

Example: 2,000 sats/kvB equals 2 sats/vB. If you see 250 sats/kwu, that maps to about 1 sats/vB.

Edge cases that shift size

Not all transactions follow the simple path. These cases can change vB more than you expect.

• Multisig and script-path spends add witness data. Size rises with each key and script branch.
• Very large numbers of inputs increase varint sizes, which adds a few bytes.
• Taproot script path (not key path) can be larger due to control blocks and script data.

If you work with complex scripts, use a wallet or tool that shows exact vB before broadcast. You can then set a precise fee rate with RBF enabled.

A short checklist before you press send

A clean workflow reduces mistakes and fees. Run this list on each spend, especially during high demand.

1. Confirm input type and count; prefer SegWit or Taproot when possible.
2. Estimate vB using the table and add a small buffer (≈2–3 vB) for safety.
3. Check live fee bands for next block, 3 blocks, and 6 blocks.
4. Pick a fee rate that fits your time target; enable RBF.
5. Review outputs and change; avoid extra outputs unless needed.

This keeps your transaction lean, confirms on time, and avoids last-minute fee bumps.

Final notes on clarity and consistency

Virtual bytes give a simple, fair way to price block space. Use the weight formula when you have exact data. Use the common-size table when you need a fast estimate. Check the mempool, pick a fee rate, and send with confidence.

Over time you will learn typical sizes for your wallet setup. That muscle memory turns fee setting from a guess into a quick, repeatable step.