← Index
ARTEL 21: Removal of Witness Discount
ARTEL 21 / Articles

BIP-?: Removal of Witness Discount and Restoration of Serialized Block Size Limit

Every byte, equal.

Draft proposal. Not yet submitted to the bitcoin/bips repository. Pending community review and editorial assignment.
  BIP: ?
  Layer: Consensus (hard fork)
  Title: Removal of Witness Discount
  Status: Draft
  Type: Specification
  Assigned: 2026-06-26
  License: BSD-3-Clause

Abstract

The witness discount introduced by Segregated Witness broke three protocol invariants:

  1. The fee market no longer prices what it delivers. Senders are invoiced for virtual bytes while the network stores raw bytes.
  2. Phantom bytes were introduced. These are bytes that exist permanently on every full node’s disk that no sender paid for. The fee market prices vsize; the network stores raw_size. The difference is unpaid for.
  3. Byte identity was broken. One witness byte no longer equals one non-witness byte in consensus accounting, despite both consuming identical network resources.

This proposal removes the witness discount and restores the 1,000,000-byte serialized block size limit. Every byte counts equally.

SegWit serialization, witness commitments, transaction malleability fixes, script versioning, and compatibility with existing SegWit and Taproot outputs are preserved.

Motivation

SegWit was de facto a hard fork

Segregated Witness was technically deployed as a soft fork, but in practice it introduced a new accounting model that created two incompatible views of the same blocks. Pre-SegWit nodes see stripped bytes; SegWit nodes see weight and vsize. The two node types no longer agree on the cost, size, or fee structure of the same transaction data. Old nodes do not see witness data at all. They cannot compute block weight or virtual size. They operate on a different view of the chain.

This is de facto a hard fork: the protocol's accounting model changed in a way that creates two incompatible views of the same blocks. This proposal reverses that hard fork. It removes the witness discount and returns to uniform byte accounting. Every node sees the same bytes, priced the same way. The accounting model is unified again. See Section 007: Hard Fork Classification for the formal argument.

The witness discount broke the fee market

The fee market charges senders for virtual bytes. The network stores raw bytes. These are not the same quantity. The fee market invoices for vsize bytes of storage while committing raw_size bytes to the permanent record. The gap is structural:

The fee market charges for what it does not deliver. The gap is an externality borne by every node operator, in storage, bandwidth, and validation time, forever.

The witness discount broke byte identity

Before SegWit, one byte of block data equaled one byte of block data. Every byte was priced equally by the fee market. The identity ratio was 1.0.

After SegWit, one witness byte counts as one-quarter of a byte in fee calculations. Both bytes require identical storage, validation, and propagation by every full node. Both are permanent and unerasable. But one costs 4× more in fees. The identity ratio climbs from 1.0 toward 4.0 for witness-heavy blocks.

One byte no longer equals one byte. The accounting does not add up.

The witness discount altered protocol invariants

Bitcoin enforces three protocol-level invariants that together define the system’s conserved boundaries: a monetary ceiling of 21 million coins, an informational ceiling of 1,000,000 bytes per block, and a temporal rhythm of approximately 600 seconds per block. These invariants establish fixed ratios between value, memory, and time.

Segregated Witness altered the informational invariant. By discounting witness data and introducing block weight as a new accounting dimension, the protocol increased the effective memory extension per block from approximately 1 MB to approximately 4 MB. This changes the maximal informational surface from 1 MB2 to 16 MB2 — a sixteenfold increase in the memory2 term while the time2 term remains fixed at 1 block2.

This proposal restores the original 1,000,000-byte serialized block size limit and removes the witness discount. The purpose is to return the protocol to the invariant ratios of this limit, where every byte carries equal weight in consensus accounting and the maximal informational surface per block is bounded by the original constant.

Empirical Evidence

You are billed for a smaller box than you are shipped. The difference is carried by everyone else.

Chain-wide analysis of raw blk*.dat files confirms the structural divergence between consensus accounting and actual storage. Every block since SegWit activation at block 481,824 has accumulated phantom bytes — bytes written to the permanent record that the fee market did not price.

Case studies

Block Date Raw Size Priced As Phantom Bytes Ratio
483,329 Sep 5, 2017 378,501 B 378,038 vB 272 1.0007×
515,076 Mar 25, 2018 103,409 B 42,371 vB 1,280 1.0302×
836,903 2024 3,993,936 B 994,608 vB ~2,999,328 4.016×

Block 483,329 contains the first SegWit transactions — 4 out of 565. The identity ratio is barely above 1.0. The violation has just begun. Block 836,903 is an inscription-era extreme: the writer paid for 0.99 MB but the chain stores 3.99 MB. The factor is 4.03×.

Transition economics

Under uniform accounting, the fee increase depends on how witness-dense a transaction is:

Transaction Type Current Ratio Fee Increase
Legacy (no witness) 1.0× 0% — no change
Simple SegWit (P2WPKH) ~1.3–1.5× 30–50%
Multi-sig / Taproot trees ~2.0–3.0× 100–200%
Inscription (max witness) ~4.0× ~300%

Legacy transactions pay nothing more. The fee increase falls entirely on transactions that consume disproportionate witness space — the same transactions that currently externalize persistence costs onto every node operator.

Rationale

Why remove the witness discount entirely rather than reduce it?

A discount of any magnitude introduces a weighting factor between bytes of identical network cost. Reducing the discount would still treat witness bytes and non-witness bytes unequally in consensus accounting. Uniform accounting — one byte, one byte — is the only rule that aligns consensus cost with actual resource consumption.

Why 1,000,000 bytes specifically?

The 1,000,000-byte limit was the first known block size cap. It established a fixed economic relationship between energy expenditure, value issuance, and committed storage. This proposal returns the protocol to that original constant rather than introducing a new parameter.

SegWit was de facto a hard fork. This proposal reverses it.

SegWit was technically deployed as a soft fork: old nodes continued to accept blocks because they validated only the stripped serialization (without witness data), which remained within the 1,000,000-byte limit. But in practice, SegWit introduced a new accounting model that old nodes cannot see or validate. Old nodes see stripped bytes; SegWit nodes see weight and vsize. The two node types no longer operate on the same data model. Old nodes do not see witness data at all. They cannot compute block weight or virtual size. They operate on a different view of the chain.

This is de facto a hard fork: the protocol's accounting model changed in a way that creates two incompatible views of the same blocks. Old nodes and new nodes no longer agree on the cost, size, or fee structure of the same transaction data.

This proposal reverses that hard fork. It removes the witness discount and returns to uniform byte accounting. Every node sees the same bytes, priced the same way. The accounting model is unified again. This is also a hard fork — not by choice, but because the previous change was itself a hard fork. See Section 007: Hard Fork Classification for the formal argument.

How does this affect chain growth over time?

Under uniform accounting every block contributes at most 1,000,000 bytes to the chain. Under the witness discount, a block may contribute up to 4,000,000 serialized bytes while still satisfying the weight limit. The following table compares cumulative chain growth at full utilization under both regimes, assuming 52,596 blocks per year (10-minute average interval):

Period Uniform Accounting (1 MB) Discounted Chain (4 MB max)
1 decade 526 GB 2.10 TB
1 century 5.26 TB 21.0 TB
1 millennia 52.6 TB 210 TB
10 millennia 526 TB 2.10 PB
100 millennia 5.26 PB 21.0 PB

Actual observed growth of the discounted chain is lower than the theoretical maximum because not all blocks are witness-heavy. However, the weight mechanism creates a structural incentive for transactions to migrate toward formats that maximize witness data, pushing realized growth upward over time. Uniform accounting removes this incentive and restores a fixed bound on chain growth regardless of transaction composition.

Does this break SegWit, Taproot, or Lightning Network?

No. The witness discount is independent from the features these protocols depend on:

These features remain unchanged.

How does uniform accounting improve decentralization?

Reducing permitted chain growth lowers long-term bandwidth, storage, and synchronization costs for node operators. A smaller chain is easier to validate, archive, and serve.

How does this affect the fee market?

Scarcer block space strengthens fee discovery and encourages migration of routine payments toward higher-layer protocols. Fees reflect the true serialized cost of publishing data to the permanent record.

Two fee markets, one chain

Since block 481,824, Bitcoin has operated two simultaneous fee markets pricing fundamentally different goods:

These markets price different quantities. The raw-byte market prices what the network stores. The virtual-byte market prices what the sender is invoiced for. The gap between them is the witness subsidy — a structural discount that grows with every witness-heavy block. This proposal unifies them into a single market pricing the conserved quantity: permanent replicated storage.

Tradeoffs

Are there any tradeoffs?

Yes. Transactions that rely heavily on witness data will face higher effective costs per serialized byte. This includes certain multi-signature constructions, privacy-enhancing techniques, and complex script trees that depend on cheap witness space. Users of these constructions will need to pay fees commensurate with their actual on-chain footprint.

Why not let the fee market manage this instead?

The fee market already operates within the constraints set by consensus. The witness discount is a consensus rule that alters the cost function before the fee market can act on it. Uniform accounting removes that distortion and lets the fee market price block space according to actual serialized size.

Specification

Beginning at activation height H:

Block Size Limit

A block is valid if:

SerializedBlockSize ≤ 1,000,000 bytes

where SerializedBlockSize includes witness data.

Per-Transaction Size Limit

A transaction is valid only if its total serialized size, including witness data, does not exceed 1,000,000 bytes. This mirrors the existing per-transaction rule in the reference implementation's CheckTransaction(), which today asserts stripped_size × WITNESS_SCALE_FACTOR ≤ MAX_BLOCK_WEIGHT. Under uniform accounting this becomes total_size ≤ 1,000,000.

WITNESS_SCALE_FACTOR

The constant WITNESS_SCALE_FACTOR is set to 1. All formulas in which non-witness bytes are multiplied by WITNESS_SCALE_FACTOR reduce to plain serialized byte counts.

Historical Block Size Constant

A new constant HISTORICAL_MAX_BLOCK_SERIALIZED_SIZE = 4,000,000 is introduced to preserve the buffer-size semantics of the legacy MAX_BLOCK_SERIALIZED_SIZE. The legacy constant is replaced with the active consensus limit of 1,000,000 bytes; the historical constant is used solely for buffer sizing when reading pre-activation blk*.dat files from disk and as an upper-bound sanity check on the size field in block file headers.

Removed Concepts

The following consensus-level abstractions are eliminated:

Consensus validation SHALL no longer enforce weight-based limits.

Witness Data

Witness serialization, witness programs, and Taproot semantics remain unchanged.

The BIP-141 witness commitment — the merkle root of all witness data stored in the coinbase transaction — remains required. Witness commitments are required to make witness data provable and to preserve the integrity of SegWit's malleability fix.

The block size check MUST be performed after witness commitment validation. This is because the coinbase witness can otherwise be padded to inflate measured size without changing the block hash, which would prevent the block from being permanently failed on size alone. In the reference implementation, the corresponding pre-check in CheckBlock() is therefore augmented with a final, post-commitment check in ContextualCheckBlock().

Transaction IDs

Transaction identifiers continue to exclude witness data as defined by SegWit.

Reference Implementation

The following source locations in the reference implementation are the primary points of change:

Deployment

This proposal is deployed as a hard fork. See Section 007: Hard Fork Classification for the formal argument.

Non-upgraded nodes producing blocks under the old weight rules risk having their blocks orphaned if the majority hashrate enforces the new limit.

Verification

Post-activation, the following invariants hold for every valid block and are verifiable by any node:

These are deterministic post-conditions. Any node can verify them for every block after activation height H by computing raw_size and vsize from the block’s serialized transactions. Under uniform accounting, vsize equals raw_size by construction, so the invariants hold trivially. Their value is as a verifiable signal that the protocol invariant has been restored.

Hard Fork Classification

Segregated Witness was de facto a hard fork. It introduced a new accounting model (block weight, virtual size, witness discount) that created two incompatible views of the same blocks. Pre-SegWit nodes see stripped bytes; SegWit nodes see weight and vsize. The two node types no longer agree on the cost, size, or fee structure of the same transaction data. Old nodes do not see witness data at all. They cannot compute block weight or virtual size. They operate on a different view of the chain.

This proposal is also a hard fork. It changes the accounting model again — from weight-based to uniform byte accounting. But it is a hard fork that reverses a prior hard fork. It restores the original uniform accounting model where every byte counts equally.

The valid block set is strictly reduced. Any block valid under a 1,000,000-byte serialized limit is also valid under the current weight limit, because weight = stripped_size × 3 + total_size ≤ 4 × total_size ≤ 4,000,000. Under the new rule, total_size ≤ 1,000,000 implies stripped_size ≤ 1,000,000. The old rule already accepts every block with stripped size at most 1,000,000 bytes. The valid block set is therefore reduced, not expanded.

Segregated Witness v0 and v1 outputs (P2WPKH, P2WSH, P2TR) remain consensus-valid under this proposal. Old nodes that do not enforce SegWit validation rules see these outputs as anyone-can-spend and continue to accept spends against them. The witness data and witness-program validation rules remain active on upgraded nodes; only the accounting weight is removed. No consensus-valid output becomes unspendable.

This is a hard fork not by choice but by history. The previous change was itself a hard fork that altered the protocol's accounting model. This proposal reverses that change and restores uniform byte accounting.

Backward Compatibility

All existing transaction formats remain valid.

Existing SegWit and Taproot outputs continue to function without modification.

Wallets and services using vsize for fee estimation will need to update to serialized size calculations. Mempool policies that rely on weight or vsize need corresponding updates.

Non-upgraded nodes will continue to accept blocks under the old weight rules. If activated with majority hashrate, the upgraded chain will outpace any non-upgraded fork, and the standard chain reorganization mechanism will resolve temporary divergences.

Pre-signed transactions designed under discount economics remain valid but may require higher fees to achieve the same confirmation priority under the new scarcity. No transactions need to be resigned or reformatted.

There is no risk of funds being frozen or lost. The change affects block accounting, not script validation or output spendability.

getblocktemplate and Mining Software

The getblocktemplate RPC currently returns weightlimit, sizelimit, and sigoplimit as distinct fields. Mining software and GBT consumers will need updates because these fields become equivalent under uniform accounting.

WITNESS_SCALE_FACTOR Compilation Impact

WITNESS_SCALE_FACTOR is referenced throughout the codebase, including in init.cpp (CLI argument validation), policy.cpp (dust threshold and vsize), kernel/mempool_entry.h (transaction weight caching), qt/optionsdialog.cpp and qt/optionsmodel.cpp (UI), the wallet/ fee and coin selection code, and various test and bench utilities. All references must be updated or removed for the codebase to compile after this change.

Historical Block File Reads

See Section 006: Specification for details on the HISTORICAL_MAX_BLOCK_SERIALIZED_SIZE constant and its role in preserving compatibility with pre-activation block files.

Security Considerations

Reduced Chain Growth

This proposal reduces the maximum amount of data committed to the blockchain.

Persistence Debt

The current chain carries phantom bytes — data written without the writer paying for persistence. This externality is borne by every full node operator in storage and bandwidth costs, growing monotonically with each witness-heavy block. Under the current regime, this debt compounds at up to 3 MB per block for fully witness-packed blocks. This proposal halts the accumulation by aligning the fee market’s price signal with the actual persistence cost.

Increased Fee Pressure

A reduction in available block space may increase transaction fees and mempool competition.

Layer-Two Incentives

Higher settlement costs may encourage greater utilization of payment channels and other higher-layer protocols.

Miner Revenue

The effect on miner revenue depends on future demand for block space and cannot be predicted in advance.

Copyright

This document is licensed under the BSD 3-Clause License. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the conditions of attribution, warranty disclaimer, and the no-endorsement clause are met. The no-endorsement clause prohibits use of the authors' names to promote derivative works without prior written permission.

  1. BIP-3: Bitcoin Improvement Proposals Process (Updated BIP Process). Clark, A., et al., 2016–2017. The updated BIP editorial workflow, status transitions, and the relationship between BIPs and the bitcoin/bips repository.
  2. BIP-141: Segregated Witness (Consensus layer). Corallo, L., et al., 2015–2017. Defines the witness discount this proposal removes.
  3. BIP-143: Transaction Signature Verification for Version 0 Witness Program. Wuille, P., 2016. Defines the new sighash algorithm for SegWit v0. Unaffected by this proposal.
  4. BIP-144: Segregated Witness (Peer Services). Corallo, L., et al., 2016. Defines the new network serialization for SegWit. Unaffected by this proposal.
  5. BIP-147: Dealing with dummy stack element malleability. Wuille, P., 2016. Eliminates a malleability vector in P2SH witness scripts. Unaffected by this proposal.
  6. BIP-341: Taproot. Wuille, P., et al., 2020. SegWit v1 output type. Unaffected by this proposal.
  7. BIP-173: Base32 address format for native v0-16 witness outputs. Wuille, P., et al., 2017. Bech32 encoding for SegWit addresses. Unaffected by this proposal.