Bitcoin Transaction Size Reference: Bytes, Weight, and Fees

Bitcoin Transaction Sizes by Type

Every Bitcoin transaction consumes block space, and fees are calculated based on how much space a transaction uses. The size depends on the script types of the inputs being spent and the outputs being created. Understanding these sizes is essential for accurate fee estimation, UTXO management, and wallet development.

Since the SegWit upgrade in 2017, Bitcoin measures transaction size in two ways: raw bytes (the actual data on disk) and weight units (the metric used for block capacity). Fees are quoted in satoshis per virtual byte (sat/vB), where 1 vB equals 4 weight units. The following tables document sizes for every common script type so you can calculate fees precisely.

Common Transaction Templates

The table below shows the total size of standard 1-input, 2-output transactions for each major address type. These are the most common transaction shapes: one UTXO spent, with one payment output and one change output.

P2WPKH delivers the smallest vByte size for single-signature transactions because its outputs (31 bytes each) are smaller than P2TR outputs (43 bytes each). However, P2TR inputs are cheaper to spend (57.5 vB vs 68 vB), so Taproot becomes more efficient for transactions with many inputs. For fee calculations on your own transactions, try the fee estimator tool.

Input Sizes by Script Type

Input size is the primary variable in transaction cost. When you spend a UTXO, the input must contain the proof of authorization: a signature, a public key, and potentially a redeem or witness script. The script type of the UTXO being spent determines how large that proof is.

P2PKH inputs are the most expensive because the entire signature and public key sit in the scriptSig with no witness discount. P2TR key-path inputs are the cheapest: the 64-byte Schnorr signature is smaller than the ~72-byte ECDSA signature used by older types, and no public key is pushed in the witness (it is derived from the output script).

For multisig setups, the difference is dramatic. A legacy P2SH 2-of-3 input costs 296 vB, while the same policy in P2WSH costs just 104 vB: a 65% reduction. Using MuSig2 or FROST with Taproot collapses the multisig into a single key-path spend at 57.5 vB, an 81% savings over legacy multisig. See the multisig planner for help choosing a scheme.

Output Sizes by Script Type

Output sizes are simpler: they consist of an 8-byte amount, a 1-byte varint for the script length, and the locking script itself. Outputs are always non-witness data, so bytes and vBytes are identical.

P2TR and P2WSH outputs are 12 bytes larger than P2WPKH because they use 32-byte SHA256 hashes instead of 20-byte HASH160 hashes. This is why P2TR transactions have a higher vByte count than P2WPKH at the output level, despite having cheaper inputs.

Transaction Overhead

Every transaction includes fixed overhead fields regardless of its inputs and outputs:

For legacy (non-SegWit) transactions, overhead totals 10 bytes (40 WU). For SegWit transactions, the marker and flag add 2 bytes at witness weight, bringing the total to 10.5 vB (42 WU). This overhead is small relative to input costs but matters when optimizing batch transactions with many outputs.

The Witness Discount Explained

The witness discount is the core mechanism that makes SegWit and Taproot transactions cheaper. Introduced in BIP 141, it assigns different costs to different parts of a transaction:

• Non-witness data (version, inputs, outputs, locktime): 4 weight units per byte
• Witness data (signatures, public keys, witness scripts): 1 weight unit per byte

This means witness data receives a 75% discount relative to non-witness data. The discount exists for two reasons. First, witness data does not affect the UTXO set that nodes must keep in memory. Signatures are validated once and then only needed for historical verification. Second, the discount balances the economic incentives between creating outputs (which grow the UTXO set) and spending them (which shrink it).

Blocks are limited to 4,000,000 weight units. Because typical transactions contain roughly 60% witness data by byte count, the effective block size with SegWit transactions is approximately 1.7 to 2.0 MB, compared to the pre-SegWit 1 MB limit.

How to Calculate Transaction Size

To estimate the size of any transaction, sum the overhead, input costs, and output costs:

vBytes = overhead + (sum of input vBytes) + (sum of output bytes)

For example, a transaction spending 3 P2WPKH inputs to 2 P2WPKH outputs:

• Overhead: 10.5 vB
• 3 P2WPKH inputs: 3 × 68 = 204 vB
• 2 P2WPKH outputs: 2 × 31 = 62 vB
• Total: 276.5 vB (round up to 277 vB)

At a fee rate of 10 sat/vB, this transaction would cost 2,770 sats (approximately $2.77 at $100,000/BTC). At 50 sat/vB during peak congestion, the same transaction costs 13,850 sats. The fee estimator can help you find current mempool fee rates. For a deeper look at how fees work in practice, see the research article on Bitcoin fee market dynamics.

Multisig Transaction Sizes

Multisig transactions are significantly larger than single-signature transactions because they require multiple signatures and a redeem or witness script that encodes the signing policy. The table below compares input costs for common multisig configurations:

The Taproot row highlights why MuSig2 is transformative for multisig wallets. By aggregating multiple keys into a single Taproot key, a 2-of-3 multisig spend becomes indistinguishable from a single-signature spend on chain: same size, same cost, and better privacy. When a cooperative key-path spend is not possible, Taproot script-path spends are still available but cost more (roughly on par with P2WSH).

Practical Fee Optimization Tips

Knowing transaction sizes enables several cost-saving strategies:

• Migrate to native SegWit (bc1q) or Taproot (bc1p) addresses to reduce per-input fees by 38% to 61% compared to legacy P2PKH
• Consolidate small UTXOs during low-fee periods to avoid paying high rates on many inputs later; use the consolidation calculator to find the optimal time
• Batch multiple payments into a single transaction to amortize the overhead across more outputs; the batch calculator estimates savings
• Use replace-by-fee (RBF) to start with a low fee and bump only if confirmation is slow
• Check the dust limit for your output type: sending below the dust threshold wastes fees on unspendable UTXOs; use the dust calculator to find the threshold

For high-volume use cases like exchanges and payment processors, layer 2 solutions can avoid on-chain size constraints entirely. Spark enables instant Bitcoin and stablecoin transfers off-chain, making transaction byte sizes irrelevant for everyday payments while preserving self-custody on the base layer.

Frequently Asked Questions

What is the size of a typical Bitcoin transaction?

A standard single-signature transaction with 1 input and 2 outputs ranges from 141 vB (native SegWit P2WPKH) to 226 vB (legacy P2PKH). Taproot (P2TR) falls at approximately 154 vB for the same shape. Most real-world transactions have 1 to 3 inputs, so typical sizes range from 140 to 500 vB.

What is the difference between bytes, vBytes, and weight units?

Bytes measure the raw data size of a transaction on disk. Weight units (WU) are the consensus metric for block capacity: non-witness bytes count as 4 WU each, witness bytes count as 1 WU each. Virtual bytes (vBytes) equal weight divided by 4, and are used to express fee rates. For legacy transactions, bytes and vBytes are identical. For SegWit transactions, vBytes are always less than raw bytes because witness data is discounted.

Why are Taproot transactions larger than native SegWit in some cases?

P2TR outputs are 43 bytes compared to 31 bytes for P2WPKH, because Taproot uses a 32-byte x-only public key in the output script versus a 20-byte hash in SegWit v0. For transactions that create more outputs than they spend inputs, P2TR can be slightly more expensive. However, P2TR inputs (57.5 vB) are cheaper than P2WPKH inputs (68 vB), so Taproot wins on multi-input transactions and enables more advanced spending conditions through script-path spending.

How much does a 2-of-3 multisig transaction cost in fees?

It depends on the script type. A P2WSH 2-of-3 multisig input costs approximately 104 vB, so a 1-input, 2-output transaction would be around 190 vB. At 20 sat/vB, that costs roughly 3,800 sats. A legacy P2SH 2-of-3 input costs 296 vB, nearly 3× more. Using MuSig2 with Taproot reduces the input to 57.5 vB, cutting fees by over 80% compared to legacy multisig.

How does the witness discount affect transaction fees?

The witness discount makes signature and script data 75% cheaper than other transaction data when calculating fees. Since signatures make up the bulk of input data, SegWit and Taproot transactions pay significantly less per input than legacy transactions. The discount was designed to incentivize spending UTXOs (which shrinks the UTXO set) and to increase effective block capacity without a hard fork.

What is the maximum Bitcoin transaction size?

A single transaction can be up to 400,000 weight units (100,000 vB), which is one-tenth of the block weight limit. This is a standardness rule enforced by default node policy, not a consensus rule. In theory, a consensus-valid transaction could fill an entire block at 4,000,000 WU. In practice, the standardness limit means a single standard transaction can contain roughly 1,400 P2WPKH inputs or about 670 P2PKH inputs.

How do I estimate fees for a Bitcoin transaction before sending?

Multiply the transaction size in vBytes by the current fee rate in sat/vB. To find the size, sum the overhead (10.5 vB for SegWit), all input sizes, and all output sizes from the tables above. For current fee rates, check the mempool or use the fee estimator tool. Most wallets perform this calculation automatically, but understanding the components helps you verify that your wallet is not overpaying.

This reference is for informational purposes only and does not constitute financial advice. Transaction sizes are approximate and assume compressed public keys and typical signature lengths. Actual sizes may vary by 1 to 2 vBytes due to DER signature encoding variability. Always verify fee estimates against current mempool conditions before broadcasting transactions.