Weight Units (WU)

What Are Weight Units?

Weight units (WU) are the measurement system Bitcoin uses to quantify transaction size for the purpose of determining how much data fits in a block. Introduced by BIP 141 as part of the SegWit upgrade in August 2016, weight units replaced the straightforward byte-counting system that previously capped blocks at 1 MB.

Under the weight system, different parts of a transaction contribute different amounts to its overall "weight." Specifically, traditional transaction data (inputs, outputs, amounts) is counted at 4 WU per byte, while witness data (signatures and public keys) is counted at only 1 WU per byte. The maximum block weight is 4,000,000 WU.

This design solved a long-standing debate about Bitcoin's block size limit. Rather than simply increasing the byte limit, SegWit introduced a new metric that effectively increased capacity while aligning transaction fees with the actual long-term costs that different data types impose on the network.

How It Works

The weight of a transaction is calculated using the formula defined in BIP 141:

Weight = (Base size × 3) + Total size

Where:
  Base size  = transaction serialized WITHOUT witness data (bytes)
  Total size = transaction serialized WITH witness data (bytes)

This formula produces the same result as counting non-witness bytes at 4 WU each and witness bytes at 1 WU each. For legacy transactions that contain no witness data, the base size and total size are identical, so the weight equals the byte size multiplied by 4.

The Witness Discount

The 75% discount on witness data was not arbitrary. It reflects the different costs that each data type imposes on the network:

• Non-witness data (transaction outputs, scriptPubKeys) can grow the UTXO set, which every full node must store in memory indefinitely. This is a persistent, ongoing cost.
• Witness data (signatures, public keys) is only needed during initial validation. Once a transaction is confirmed, nodes that have already validated it can discard the witness data. This is a temporary, one-time cost.

By charging less for witness data, the weight system aligns fee incentives with actual resource consumption, encouraging users to adopt transaction formats that minimize the long-term burden on the network.

Virtual Bytes

Because weight units operate on a different scale than raw bytes, Bitcoin introduced virtual bytes (vbytes) as a human-friendly conversion:

Virtual bytes (vB) = Weight (WU) ÷ 4

Example:
  Transaction weight = 561 WU
  Virtual size = 561 ÷ 4 = 140.25 → 141 vB (rounded up)

Fee rates in Bitcoin are denominated in satoshis per virtual byte (sat/vB). To calculate the total fee for a transaction:

Fee = Fee rate (sat/vB) × Virtual size (vB)

Example:
  Fee rate = 20 sat/vB
  Transaction size = 141 vB
  Fee = 20 × 141 = 2,820 satoshis

Weight by Transaction Type

Different Bitcoin address types produce transactions with very different weight profiles. For a standard 1-input, 2-output transaction:

Moving from legacy P2PKH to native SegWit P2WPKH reduces weight by roughly 38%, meaning users pay significantly less in fees for the same economic transaction. This built-in savings is the primary incentive driving SegWit adoption.

Per-Input Weight Comparison

The weight savings become even more pronounced when examining individual inputs, since signature and witness data constitute the bulk of input size:

Taproot key-path spends are the most weight-efficient input type, using roughly 61% less block space than legacy P2PKH inputs. For transactions consolidating many UTXOs, the cumulative savings are substantial.

Use Cases

Fee Estimation

Accurate fee estimation requires knowing the weight of a transaction before broadcasting it. Wallet software estimates weight based on the number and type of inputs and outputs, then multiplies the virtual size by the desired fee rate. For a deeper look at how fees interact with network congestion, see the fee market dynamics research article.

UTXO Management

Weight directly influences UTXO consolidation strategies. Each additional input adds weight to a transaction, so wallets with many small UTXOs face higher fees. Effective coin selection algorithms factor in weight to minimize fees while avoiding the creation of dust outputs. Detailed strategies are covered in the UTXO management strategies guide.

Block Space Optimization

Miners select transactions for inclusion in blocks by maximizing total fees relative to weight consumed. This means transactions with higher fee-per-weight-unit ratios are prioritized. Understanding weight helps users and developers craft transactions that use block space efficiently, lowering costs for everyone in the transaction lifecycle.

Layer 2 Considerations

Weight is especially relevant for Layer 2 protocols that periodically settle on-chain. Lightning Network channel opens and closes, splicing operations, and commitment transactions all consume block space measured in weight units. Minimizing on-chain weight is a core design goal for protocols like Spark, which reduces on-chain footprint by batching operations and keeping most activity off-chain.

Risks and Considerations

Legacy Transactions Are Penalized

Transactions using non-SegWit address types pay the full 4 WU per byte for all data, including signatures. This effectively makes legacy transactions more expensive per unit of economic activity. Wallets and services that have not upgraded to SegWit or Taproot pay a premium, and their users bear unnecessarily high fees during periods of mempool congestion.

Weight Estimation Complexity

Estimating transaction weight before signing introduces complexity. The final signature size can vary slightly (ECDSA signatures are between 71 and 73 bytes), and multisig or complex scripts add further variability. Wallet developers must account for worst-case signature sizes to avoid underpaying fees, which could cause transactions to become stuck in the mempool.

Misconceptions About Block Size

The 4 million WU limit does not mean every block is 4 MB. A block full of legacy transactions would still be approximately 1 MB (since every byte counts as 4 WU). Blocks approach 4 MB only when they contain a high proportion of witness data. In practice, typical blocks with a mix of transaction types average around 1.5 to 2.5 MB.

Interaction with Fee Sniping

Weight-aware fee strategies must also consider fee sniping protections. Setting appropriate locktime values adds minimal weight but prevents miners from re-mining recent blocks to steal high-fee transactions.

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.