Bitcoin Block Space Cost Calculator by Transaction Type

How Much Does Bitcoin Block Space Cost?

Every Bitcoin transaction competes for space in a block that holds at most 4,000,000 weight units (1,000,000 virtual bytes). The fee you pay is determined by two factors: the size of your transaction in vbytes and the current fee rate in sat/vB. Different transaction types consume different amounts of block space, so the same payment can cost dramatically more or less depending on which address format you use.

The table below shows the cost of a standard 1-input, 2-output transaction (one payment plus one change output) across the most common Bitcoin address types, at four representative fee rates. All sizes assume typical input and output compositions. For more granular sizing with custom input and output counts, see the Bitcoin transaction size reference.

Note: Fee rates fluctuate based on mempool demand. During calm periods, 1-3 sat/vB is common. During congestion spikes (inscriptions surges, halving events), rates can exceed 200 sat/vB. Check the fee estimator for current conditions.

Transaction Size Breakdown

A Bitcoin transaction consists of a fixed overhead plus variable-size inputs and outputs. Understanding each component helps explain why different address types produce different costs.

The fixed overhead is 10 bytes for legacy transactions and 10.5 vbytes for SegWit transactions (the extra 0.5 vB comes from the SegWit marker and flag in the witness). Inputs are the expensive part: they contain the signature data that proves you own the coins being spent. Outputs are cheaper because they only specify a destination address and amount.

Legacy P2PKH inputs are 148 vB because the full ECDSA signature and public key sit in the scriptSig with no witness discount. Native SegWit P2WPKH moves that data to the witness, where each byte counts as only 0.25 vbytes instead of 1, cutting input cost to 68 vB. Taproot P2TR key-path goes further: the Schnorr signature is a fixed 64 bytes (versus ECDSA's variable 71-73 bytes), and no public key needs to be revealed in the witness, bringing the input down to 57.5 vB.

How Taproot Saves Fees on Complex Scripts

For simple single-signature transactions, P2WPKH (141 vB) is actually smaller than P2TR (154 vB) because P2TR outputs are 43 vB versus 31 vB for P2WPKH. The real advantage of Taproot appears in two scenarios: transactions with multiple inputs, and complex spending conditions like multisig.

With MuSig2 or FROST key aggregation, any N-of-M multisig can be collapsed into a single Schnorr signature on the key-path. A 2-of-3 multisig spend that would cost 104.5 vB per input using P2WSH drops to just 57.5 vB per input on P2TR key-path: a 45% reduction. Compared to legacy P2SH 2-of-3 at 296 vB per input, the savings reach 81%.

The script-path (used as a fallback when the cooperative key-path fails) is slightly more expensive than P2WSH due to control block overhead. But the design assumes the cooperative key-path handles the vast majority of spends, with the script-path reserved for recovery scenarios when a key is lost or a signer is unresponsive.

For a deeper technical analysis, see P2TR spend path deep dive.

Batch Transaction Savings

Transaction batching combines multiple payments into a single transaction. Because the overhead and input cost are paid once regardless of the number of outputs, batching dramatically reduces the per-payment cost.

The following table shows how costs scale for P2WPKH batch transactions with a single input at 20 sat/vB. The "per payment" column divides total cost by the number of payment outputs (total outputs minus one change output).

At 25 outputs, each payment costs only 712 sats at 20 sat/vB compared to 2,820 sats if sent individually. The asymptotic minimum per payment approaches the output size alone (31 vB for P2WPKH, or 620 sats at 20 sat/vB), yielding a theoretical maximum savings of about 78%. Exchanges and payment processors that batch withdrawals can save hundreds of thousands of dollars annually this way. For more on batching economics, see Bitcoin transaction batching savings analysis.

Why Block Space Is Scarce

Bitcoin produces a new block roughly every 10 minutes, and each block is capped at 4,000,000 weight units (1,000,000 vbytes). This is a hard consensus limit: no block exceeding this weight is valid regardless of how many transactions are waiting. At current average transaction sizes, each block fits approximately 4,000-5,000 transactions.

When demand exceeds supply, a fee market emerges. Users bid for inclusion by attaching higher fee rates, and miners prioritize transactions that pay the most per vbyte. During calm periods, fee rates sit at 1-3 sat/vB. During demand spikes, rates can climb to 50-200+ sat/vB, making a simple P2WPKH transaction cost $5-$15 or more. This dynamic makes transaction type selection and batching directly relevant to your operating costs.

The economics of block space also explain why off-chain solutions exist. For a detailed breakdown of demand drivers, see Bitcoin block space demand economics.

On-Chain Costs vs Spark and Lightning

On-chain fees are unavoidable for settlement, but small and frequent payments can avoid the fee market entirely by using off-chain protocols. The Lightning Network routes payments through payment channels with typical fees under 1 sat for small amounts. Spark takes this further: as a Bitcoin Layer 2, it enables instant transfers with near-zero fees and no channel management overhead.

Consider the economics: a 10,000 sat payment on-chain at 50 sat/vB costs 7,050 sats in fees for a P2WPKH transaction: over 70% of the payment value consumed by fees. The same transfer on Spark costs fractions of a sat. For micropayments, tipping, point-of-sale transactions, and streaming payments, the on-chain fee market makes Layer 1 impractical while Layer 2 solutions like Spark keep costs negligible.

On-chain transactions remain essential for large-value settlement, opening and closing channels, consolidating UTXOs, and anchoring state to the base layer. The practical strategy is to use the right layer for the right payment size: Layer 1 for high-value settlement, Layer 2 for everyday spending.

Optimizing Your Transaction Costs

Several strategies can reduce the block space your transactions consume:

• Use native SegWit (bc1q) or Taproot (bc1p) addresses to minimize input sizes
• Batch multiple payments into a single transaction when possible
• Consolidate small UTXOs during low-fee periods (1-3 sat/vB) to avoid paying high rates later
• Use MuSig2 key aggregation for multisig setups to reduce N-of-M signatures to a single Schnorr signature
• Route small payments through Spark or Lightning instead of settling on-chain
• Monitor mempool conditions with a fee estimator to time non-urgent transactions

Frequently Asked Questions

How much does a Bitcoin transaction cost in fees?

The cost depends on transaction size and the current fee rate. A standard native SegWit (P2WPKH) transaction is about 141 vbytes. At a calm fee rate of 5 sat/vB, that costs 705 sats. At a congested rate of 100 sat/vB, the same transaction costs 14,100 sats. Legacy P2PKH transactions are larger (226 vB) and cost proportionally more. Taproot key-path transactions fall in between at 154 vB.

What is the cheapest Bitcoin transaction type?

For a single-signature 1-input, 2-output transaction, native SegWit (P2WPKH) is the smallest at approximately 141 vbytes. Taproot (P2TR) key-path spend is slightly larger at 154 vB due to bigger output scripts. However, for transactions spending multiple inputs or using multisig, Taproot with MuSig2 key aggregation is the most efficient option because all signatures collapse to a single 64-byte Schnorr signature.

How does SegWit reduce transaction fees?

SegWit introduces a witness discount: signature and public key data in the witness section counts at 0.25 weight units per byte instead of 1. This means a 68-byte signature that would cost 68 vB in legacy format costs only about 17 vB in the witness. A native SegWit P2WPKH transaction is roughly 38% smaller than an equivalent legacy P2PKH transaction, translating directly to 38% lower fees.

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

A P2WSH 2-of-3 multisig transaction with one input and two outputs is approximately 201 vbytes. At 20 sat/vB, that costs 4,020 sats. Using Taproot with MuSig2 key aggregation, the same spend drops to 154 vB (a P2TR key-path spend), reducing the cost to 3,080 sats: a 23% saving. The legacy P2SH 2-of-3 format would cost even more at roughly 306 vB.

How much can transaction batching save?

Batching 25 payments into a single P2WPKH transaction reduces the per-payment cost by approximately 75% compared to sending 25 separate transactions. The savings come from sharing the fixed overhead and input costs across all recipients. At 20 sat/vB, each payment in a 25-output batch costs about 712 sats versus 2,820 sats individually.

Why is Taproot sometimes larger than native SegWit?

P2TR outputs are 43 vbytes compared to 31 vbytes for P2WPKH outputs. This makes Taproot slightly larger for simple single-input, two-output transactions (154 vB vs 141 vB). The tradeoff is worthwhile because Taproot inputs are smaller (57.5 vB vs 68 vB), which pays off in transactions with multiple inputs. Taproot also enables privacy benefits: all spend types (single-sig, multisig, timelocks) look identical on-chain when using the key-path.

What is the maximum Bitcoin block size?

The maximum block weight is 4,000,000 weight units, equivalent to 1,000,000 vbytes. In raw bytes, SegWit blocks typically range from 2.0 to 2.3 MB due to the witness discount. A fully non-SegWit block would be capped at 1 MB. At current average transaction sizes, each block accommodates roughly 4,000 to 5,000 transactions.

This tool is for informational purposes only and does not constitute financial advice. Transaction sizes are based on typical single-input, two-output configurations and may vary depending on the number of inputs, outputs, and script complexity. Fee rates fluctuate continuously based on network demand. Always verify current fee conditions before broadcasting transactions.