Virtual Bytes (vBytes)

What Are Virtual Bytes?

Virtual bytes (vBytes), also called virtual size (vsize), are the standard unit for measuring Bitcoin transaction size since the Segregated Witness (SegWit) upgrade in August 2017. Defined in BIP 141, vBytes normalize a transaction's composite weight into a single number that determines how much block space the transaction consumes and, consequently, the fee it must pay.

Before SegWit, transaction size was measured in plain bytes, and fees were quoted in sat/byte. The problem: SegWit introduced a two-tier data structure where signature data (witness) is stored separately from transaction metadata (non-witness). vBytes bridge the old and new worlds by ensuring that legacy transactions have identical byte and vByte counts, allowing older wallets to continue estimating fees in sat/byte without modification.

The formula is straightforward: take the transaction's weight in weight units (WU), divide by 4, and round up. For a deeper look at how Bitcoin's fee market uses this metric, see the Bitcoin fee market dynamics research article.

How It Works

The vBytes calculation starts with the weight system. Every byte in a Bitcoin transaction is assigned a weight multiplier depending on whether it falls inside or outside the witness section:

The two core formulas are:

Weight = (non-witness bytes × 4) + (witness bytes × 1)
vBytes = Weight / 4  (rounded up)

For legacy transactions with no witness data, every byte counts at 4 WU, so weight equals total bytes times 4, and vBytes equals total bytes exactly. This is the backward-compatibility guarantee: a 226-byte legacy transaction is 226 vB, and the old sat/byte fee rate applies unchanged.

Worked Example

Consider a standard 1-input, 2-output native SegWit (P2WPKH) transaction:

Raw size:         222 bytes
Non-witness data: 112 bytes
Witness data:     110 bytes

Weight = (112 × 4) + (110 × 1)
       = 448 + 110
       = 558 WU

vBytes = 558 / 4
       = 139.5 → 140 vB (rounded up)

Compare this to the same logical transaction as legacy P2PKH: 226 bytes and 226 vB. The SegWit version saves roughly 38% in vBytes, which translates directly to a 38% fee reduction at the same sat/vB rate.

The Weight Discount Rationale

The 4:1 weight ratio was not arbitrary. Witness data (signatures and public keys) is validated once when a transaction enters the mempool and again when it is included in a block, but it does not permanently affect the UTXO set that every full node must store in memory. Non-witness data (inputs referencing UTXOs and outputs creating new ones) directly impacts this set. The discount incentivizes transaction structures that minimize UTXO set growth while still allowing the cryptographic proofs that secure the network.

Block Weight Limit

BIP 141 replaced the legacy 1 MB block size limit with a 4,000,000 WU block weight limit. Dividing by 4, this is equivalent to 1,000,000 vB of transaction capacity per block. In practice, blocks typically range from 1.2 to 2.4 MB of raw data depending on the mix of SegWit and legacy transactions. Non-upgraded nodes only see the stripped (witness-removed) version of each block, which always fits within the original 1 MB constraint: this is what made SegWit deployable as a soft fork.

Impact on Transaction Types

The choice of address type determines how much witness data a transaction contains, and therefore its vByte cost. For a standard 1-input, 2-output single-signature transaction:

The difference grows with transaction complexity. For UTXO consolidation (many inputs, one output), Taproot's smaller per-input cost (57.5 vB vs 68 vB for P2WPKH) makes it the most efficient choice. For transactions with many outputs, P2WPKH's smaller output size (31 bytes vs 43 bytes) can win. Understanding these tradeoffs matters for wallets and services processing high volumes of transactions.

Fee Calculation with vBytes

Miners construct blocks to maximize total fees within the 4,000,000 WU weight limit. They rank mempool transactions by fee rate (sat/vB) and fill blocks from highest to lowest. This means a compact 140 vB transaction at 20 sat/vB (2,800 sats total) is preferred over a 500 vB transaction at 5 sat/vB (2,500 sats total): the smaller transaction generates more revenue per unit of block space consumed.

The practical formula for users:

Total fee = fee rate (sat/vB) × transaction size (vB)

Example:
  Fee rate:          10 sat/vB
  Transaction size:  141 vB (P2WPKH, 1-in-2-out)
  Total fee:         1,410 sats

When the mempool is uncongested, transactions confirm at 1-2 sat/vB. During high demand (such as the Ordinals-driven congestion of 2023-2024), rates can exceed 100 sat/vB. Tools like fee estimators in Bitcoin wallets read current mempool conditions and recommend a sat/vB rate based on the user's desired confirmation speed. Replace-by-fee (RBF) allows users to bump the fee rate of a pending transaction if conditions change after broadcast.

Use Cases

Wallet Fee Estimation

Every Bitcoin wallet uses vBytes to estimate transaction fees before broadcast. The wallet calculates the expected vByte size based on the number and type of inputs and outputs, multiplies by the current fee rate, and displays the total cost. Accurate vByte estimation prevents overpaying (wasting sats) and underpaying (delayed confirmation or rejection).

UTXO Consolidation Planning

Services that accumulate many small UTXOs (exchanges, payment processors, mining pools) use vByte calculations to plan consolidation transactions during low-fee periods. A consolidation spending 100 P2WPKH inputs into 1 output costs roughly 6,822 vB: at 2 sat/vB, that's ~13,644 sats. At 50 sat/vB during congestion, the same consolidation costs ~341,100 sats. The vByte metric makes this cost difference transparent and plannable.

Layer 2 Transaction Efficiency

Lightning Network channel operations (splicing, force closes, anchor outputs) involve on-chain transactions where vByte efficiency directly impacts costs. The child-pays-for-parent (CPFP) pattern used with anchor outputs relies on accurate vByte accounting to ensure the combined fee rate of parent and child transactions meets miner thresholds.

Block Space Market Analysis

Researchers and node operators use vBytes to analyze block space supply and demand. The 1,000,000 vB per-block capacity creates a fixed supply, and the fee rate in sat/vB reflects the clearing price. This data informs mining economics models and mempool monitoring tools.

Risks and Considerations

Witness Discount Debate

The 75% discount on witness data has become controversial following the Ordinals and Inscriptions protocols, which leverage the discount to store arbitrary data (images, text, media) cheaply in witness fields. Critics argue this was not the intended use of the discount and that it inflates block sizes without proportional economic value. Proponents counter that the discount correctly reflects the lower long-term cost of witness data to the network. As of 2026, there are no active BIPs proposing to change the 4:1 weight ratio.

Estimation Complexity

Calculating vBytes precisely requires knowing the exact input and output types before the transaction is constructed. Signature sizes can vary slightly (ECDSA signatures range from 71-73 bytes), and multisig or complex script transactions add further variability. Wallets typically use worst-case estimates to avoid underpaying, which can lead to slight overpayment.

Confusion Between Bytes and vBytes

Users and some tools still conflate raw bytes with vBytes, leading to incorrect fee estimates. A SegWit transaction might be 222 raw bytes but only 141 vBytes: using the raw size would overestimate fees by roughly 57%. Block explorers now generally display both metrics, but older documentation and tools may use only one, creating potential for confusion.

Minimum Relay Feerate

Bitcoin Core enforces a minimum relay feerate: transactions below this threshold are not propagated across the network. Historically set at 1 sat/vB, this default was reduced to 0.1 sat/vB in Bitcoin Core v30 (October 2025). Transactions near this floor may propagate slowly or not at all if individual nodes retain higher thresholds, making the effective minimum dependent on network-wide node configuration.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.