Virtual Byte (vByte)

A virtual byte (vByte or vB) is the everyday unit Bitcoiners use to size transactions and price fees. It is defined as a transaction's weight divided by four, so one vByte equals four weight units. Because a block holds 4,000,000 weight units, it equivalently holds 1,000,000 virtual bytes. Wallets and mempool explorers quote fee rates in satoshis per virtual byte (sat/vB), which is why the term surfaces every single time you set a fee — it is the denominator behind the number you actually care about.

The word "virtual" trips people up, so it pays to be concrete: a vByte is not a real byte on the wire but an accounting unit that answers a single question — how much of the block's scarce space does this transaction actually consume once the witness discount is applied. Two transactions can occupy the very same number of raw bytes on disk yet have quite different virtual sizes, and it is the virtual size, never the raw size, that the fee market prices. Once that clicks, every fee estimator, mempool-depth chart, and "sat/vB" recommendation reads the same way, and you gain the ability to sanity-check any wallet's proposed fee against the size of the spend it is quietly building on your behalf.

Why not just use bytes?

Before SegWit, transaction size was measured in raw bytes and fees were quoted in sat/byte. SegWit's witness discount broke that one-to-one relationship: witness bytes (the signatures) are weighted at one unit each, while base bytes are weighted at four. The reasoning is that witness data can be pruned once a transaction is deeply buried, so the protocol charges you less block space for it. The virtual byte restores a single, fair number that reflects a transaction's true cost to the network. A transaction's virtual size (vsize) is its total weight divided by four, rounded up to the next whole vByte, so a spend with lots of signature data is cheaper per logical operation than its raw byte count would suggest.

Practical fee math

Suppose your transaction has a weight of 565 units. Its virtual size is 565 ÷ 4 ≈ 142 vB. At a fee rate of 20 sat/vB you would pay roughly 2,840 satoshis. To estimate cost before signing, count your inputs and outputs: a native SegWit input is on the order of 68 vB, an output around 31 vB, plus a small fixed overhead. Choosing native SegWit (bech32) or Taproot addresses shrinks vsize for the same logical spend, directly lowering what you pay — a Taproot key-path spend is one of the most compact ways to move coins on-chain.

Where vsize decides real costs

Because fees are paid per vByte, the number of inputs you spend usually matters more than the amount of value you move. Consolidating many small UTXOs during a low-fee window is cheaper precisely because you pay for their vsize once instead of every time you spend them later. Fee-bumping tools reason in vByte terms too: replace-by-fee raises the sat/vB of a stuck transaction, and child-pays-for-parent attaches a high-fee child whose vsize dilutes the parent's low rate across the pair. Batching several payments into one transaction shares the fixed overhead, lowering the vsize cost of each recipient.

Where it fits

Internally the network reasons in weight units, and the vByte is simply the human-friendly rounding of that figure — but every fee-estimation display, every "sat/vB" recommendation, and every RBF bump is denominated in it. Understanding vsize lets you predict a transaction's cost before you broadcast, compare wallet efficiency across address types, and recognize when a spend is unusually heavy because it sweeps many inputs. This is one of the simplest sovereignty levers available: better address types and disciplined UTXO management mean cheaper self-custody. The virtual byte is derived directly from the weight unit, and the one-million-vByte ceiling is enforced as a hard consensus limit alongside every other check in the consensus rules a full node applies to each block.