Transaction Weight

What Is Transaction Weight?

Transaction weight is the metric Bitcoin uses to measure how much space a transaction occupies in a block. Introduced by the Segregated Witness (SegWit) upgrade in August 2017, it replaced the simple byte-count system with a weighted formula that distinguishes between two types of transaction data: core transaction data (inputs, outputs, version, locktime) and witness data (signatures and public keys used for validation).

Under this system, non-witness bytes cost 4 weight units each while witness bytes cost only 1 weight unit each. This 75% discount on witness data reflects its different role in the network: witness data is needed only for transaction validation, not for tracking the UTXO set, so nodes can prune it after verification. The maximum block weight is 4,000,000 weight units, replacing the old 1 MB block size limit.

How It Works

The weight calculation follows the formula defined in BIP 141:

Weight = (Base size × 4) + (Witness size × 1)

// Equivalently:
Weight = (Base size × 3) + Total size

// Where:
// Base size = transaction size without witness data
// Witness size = size of witness data only
// Total size = base size + witness size

For legacy transactions that predate SegWit, all bytes are non-witness bytes. A 226-byte legacy transaction has a weight of 226 × 4 = 904 WU. There is no discount because there is no witness data to discount.

Virtual Bytes

Because fee rates were historically quoted per byte, virtual bytes (vbytes) provide a backward-compatible unit. The conversion is straightforward:

Virtual size (vB) = Weight / 4  (rounded up)

// Examples:
// 904 WU → 226 vB  (legacy P2PKH)
// 561 WU → 141 vB  (native SegWit P2WPKH)
// 616 WU → 154 vB  (Taproot P2TR key-path)

Fee rates are quoted in sat/vB. A transaction paying 10 sat/vB with a virtual size of 141 vB costs 1,410 satoshis in fees. The same fee rate applied to a 226 vB legacy transaction costs 2,260 satoshis: a 60% premium for using the older format.

Weight by Transaction Type

Different address types produce dramatically different weights for a standard 1-input, 2-output transaction:

The per-input savings tell the more important story. P2TR inputs are only 57.5 vB compared to 148 vB for legacy: a 61% reduction. For input-heavy transactions like UTXO consolidations, Taproot saves roughly 10.5 vB per input over P2WPKH, which adds up quickly. A 10-input consolidation saves about 105 vB, easily offsetting P2TR's slightly larger output size (43 bytes vs 31 bytes for P2WPKH).

Worked Example

Consider a native SegWit (P2WPKH) transaction with 1 input and 2 outputs. Its raw data breaks down as:

Non-witness data (base size):
  Version:        4 bytes
  Input count:    1 byte
  Input:         41 bytes (outpoint + sequence)
  Output count:   1 byte
  Output 1:      31 bytes (value + P2WPKH scriptPubKey)
  Output 2:      31 bytes
  Locktime:       4 bytes
  ─────────────────────────
  Base size:    113 bytes

Witness data:
  Witness items:   1 byte (count)
  Signature:      72 bytes (DER-encoded ECDSA)
  Public key:     34 bytes (compressed + length)
  ─────────────────────────
  Witness size:  107 bytes

Weight = (113 × 4) + (107 × 1) = 452 + 107 = 559 WU
Virtual size = 559 / 4 = 139.75 → 140 vB

If this same transaction used a legacy P2PKH format, the signature and public key would be part of the scriptSig (non-witness data), so every byte would count as 4 WU. The total weight would be roughly 904 WU: 62% heavier.

Why the Witness Discount Exists

The witness discount exists for both technical and economic reasons:

• Witness data serves a different purpose than transaction outputs. Outputs define who owns which coins and must be stored indefinitely in the UTXO set. Witness data proves authorization and can be discarded after validation.
• The discount incentivizes moving signature data into the witness structure, which fixes the transaction malleability problem that previously blocked Lightning Network development.
• By making witness-heavy transactions cheaper, the discount encourages adoption of SegWit and Taproot without requiring a hard fork. Legacy nodes see the weight limit as a ~1 MB base-size limit, maintaining backward compatibility.
• The discount aligns costs with actual resource consumption. Data that nodes must store forever (UTXO-affecting data) costs more than data that can be pruned (signatures).

The 4,000,000 WU Block Limit

Bitcoin's maximum block weight is 4,000,000 WU. This replaced the legacy 1 MB block size limit when SegWit activated at block 481,824 on August 24, 2017.

The 4 million WU cap does not mean blocks can be 4 MB. A 4 MB block would require it to contain nothing but witness data, which is impossible in practice. Real-world blocks with a mix of SegWit and legacy transactions typically range from 1.5 to 2.3 MB in serialized size.

In virtual-byte terms, the maximum block holds 1,000,000 vB (4,000,000 WU ÷ 4). This number directly determines the throughput ceiling: at an average transaction size of 140 vB, a block can hold roughly 7,100 transactions, compared to about 4,400 under the old 1 MB limit.

Use Cases

Fee Estimation and Optimization

Understanding transaction weight is essential for accurate fee estimation. Wallets calculate the expected weight before broadcasting, multiply by the current fee rate (sat/vB), and set the transaction fee accordingly. Overestimating weight means overpaying; underestimating risks the transaction being stuck in the mempool.

UTXO Management

Weight calculations drive coin selection decisions. Adding an input to a transaction increases weight by 57.5 to 148 vB depending on address type. When the cost of including a small UTXO exceeds its value at the current fee rate, it becomes dust: economically unspendable until fees drop.

Protocol Design

Layer-2 protocols like the Lightning Network and Spark consider transaction weight when designing on-chain footprints. Commitment transactions, penalty transactions, and channel opens all consume block space. Lower weight means lower costs for opening and closing channels, making Layer-2 solutions more economically viable.

Batch Transactions

Exchanges and payment processors use transaction batching to reduce total weight. Instead of broadcasting 100 individual payments (each with its own overhead), a single batched transaction with 100 outputs shares the fixed-cost bytes across all recipients, dramatically reducing per-payment weight.

Taproot and Weight Efficiency

Taproot (activated November 2021) further optimized weight efficiency through Schnorr signatures. These signatures are 64 bytes (compared to 71-72 bytes for ECDSA) and enable key aggregation via MuSig2, where a multisig spend looks like a single-key spend on-chain.

A 2-of-3 multisig using legacy P2SH requires about 296 vB per input because all signatures and public keys are in non-witness data. The same policy using MuSig2 via a Taproot key-path spend costs only 57.5 vB per input: an 80% reduction. For applications that rely on multisig security, like custody solutions, this weight savings translates directly to lower operational costs.

Risks and Considerations

Weight Is Not the Only Cost

Transaction weight determines the fee a user pays to miners, but it does not capture all costs imposed on the network. Creating new UTXOs adds to the UTXO set that every full node must store in memory. Some proposals have suggested adjusting the weight formula to further discount inputs (which remove UTXOs) relative to outputs (which create them), but no such change has been activated.

Signature Operations Limit

Beyond weight, blocks are constrained by a sigops limit that caps the number of signature verification operations. A transaction could theoretically be light in weight but expensive in computation. In practice, the weight limit is almost always the binding constraint for normal transactions.

Address Type Tradeoffs

Choosing an address type involves tradeoffs beyond input weight. P2TR outputs are 43 bytes versus 31 bytes for P2WPKH. For transactions with many outputs and few inputs (like exchange withdrawals), P2WPKH can produce a lower total weight. For input-heavy transactions like consolidations, Taproot wins. The address type comparison covers these tradeoffs in detail.

Fee Rate Volatility

Weight determines the size of the fee, but the fee market determines the rate. During congestion spikes, the same 141 vB transaction that cost 1,410 sats at 10 sat/vB could cost 141,000 sats at 1,000 sat/vB. Optimizing transaction weight matters most when fee rates are high, which is also when users are least able to wait for lower rates.

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.