Every byte, equal.
BIP: ? Layer: Consensus (soft fork) Title: Removal of Witness Discount Authors: ARTEL 21 Status: Draft Type: Specification Assigned: 2026-06-26 License: BSD-3-Clause
This proposal removes witness discount accounting introduced by Segregated Witness and replaces the current block weight limit with a strict serialized block size limit of 1,000,000 bytes. All transaction data, including witness data, SHALL count equally toward the block size limit.
SegWit serialization, witness commitments, transaction malleability fixes, script versioning, and compatibility with existing SegWit and Taproot outputs are preserved.
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 quantum of one block. These invariants establish fixed ratios between value, memory, and time. The monetary ceiling defines the value domain. The block size limit defines the maximum informational surface that may be instantiated in one quantum of time. The block interval defines the temporal domain. Together they form a closed thermodynamic system in which energy, information, and time are coupled through proof-of-work.
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. Bytes of identical network cost are assigned different weights in consensus accounting. The chain may grow at up to four times the original byte rate. The informational geometry of the protocol has been altered.
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 encoded at Genesis, where every byte carries equal weight in consensus accounting and the maximal informational surface per block is bounded by the original constant.
Segregated Witness introduced a distinction between witness and non-witness bytes for block accounting. Witness data currently receives a 75% discount.
This:
Every byte transmitted, validated, and stored imposes costs. Consensus accounting should therefore correspond directly to serialized size.
The following constants define the economic and physical constraints of the protocol:
Three of these constants are protocol-defined. Planck energy is a physical constant consumed directly by proof-of-work. Together they establish fixed ratios: joules per satoshi, sats per byte, bytes per block, and blocks per halving.
The original 1,000,000-byte block size limit established a fixed economic relationship between energy expenditure, value issuance, and committed storage. Segregated Witness introduced a witness discount that assigns witness bytes a lower weight than non-witness bytes in consensus accounting despite both consuming identical network resources (storage, bandwidth, and validation cost). This discount effectively revalues the block size limit for witness-heavy transactions and distorts the original constant ratio.
This proposal restores uniform accounting by removing the witness discount and enforcing a strict 1,000,000-byte serialized block size limit.
Lightning Network compatibility is preserved. The witness discount is independent of the SegWit features that Lightning requires, including transaction malleability fixes, witness serialization, script versioning, native SegWit outputs, and Taproot.
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.
The 1,000,000-byte limit was the original block size cap defined by Satoshi Nakamoto at Genesis. 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 technically 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. However, the deployment introduced entirely new consensus concepts that did not exist before: witness data as a separate serialization stream, block weight as a new accounting dimension, virtual size (vsize) as a user-facing abstraction, and the WITNESS_SCALE_FACTOR as an arbitrary multiplier. These concepts were not present in the pre-SegWit protocol. Old nodes did not validate them; they simply did not see them.
This proposal removes those added concepts and returns to a single, transparent metric: serialized bytes. The rule change is a soft fork because the valid block set is strictly reduced. Any block valid under a 1,000,000-byte serialized limit is automatically valid under the current weight limit, because weight = stripped_size × 3 + total_size ≤ 4 × total_size ≤ 4,000,000.
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.
No. The witness discount is independent from the features these protocols depend on:
These features remain unchanged.
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.
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.
In the framework of Bitcoin: The Architecture of Time (The Bitcoin Lens, §11.1–§11.2), the block size limit is structurally analogous to the Planck length ℓP: the maximum memory-width resolvable in one quantum of time. The block is the native unit of time that the megabytes themselves produce, so MB/block is the more fundamental unit. The maximal informational surface of one block admits three equivalent forms — 1 block2, 1 block · 1 MB, and 1 MB2 — paralleling the Planck-area identity AP = tP2 = tP · ℓP = ℓP2. Under the 1 MB cap all three are equal at the upper bound; under the 4 MB cap the memory2 term is 16 MB2 while the time2 term remains 1 block2. Memory and time are dimensionally equivalent: each block is a rectangular cell of timespace, and the block size limit is the maximal informational surface writable in one quantum of constructed time. Restoring the 1 MB cap returns this surface to its original upper bound. The block size limit, defined by Satoshi Nakamoto at Genesis, is a protocol-level invariant of the same kind as the 21-million-coin supply cap. Any alteration requires hardfork-level consensus.
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.
No. Existing transactions remain valid. However, transactions designed under discount economics may require higher fees to achieve the same confirmation priority under the new scarcity. The transactions themselves do not need to be resigned or reformatted.
No. This proposal changes block accounting rules, not script validation rules. All existing outputs remain spendable by their rightful owners. There is no output format that becomes invalid and no script path that is closed.
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.
Beginning at activation height H:
A block is valid if:
SerializedBlockSize ≤ 1,000,000 bytes
where SerializedBlockSize includes witness data.
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.
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.
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.
The following consensus-level abstractions are eliminated:
Consensus validation SHALL no longer enforce weight-based limits.
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 identifiers continue to exclude witness data as defined by SegWit.
The following source locations in the reference implementation are the primary points of change:
src/consensus/consensus.h — MAX_BLOCK_SERIALIZED_SIZE (lowered to 1,000,000), new HISTORICAL_MAX_BLOCK_SERIALIZED_SIZE = 4,000,000, MAX_BLOCK_WEIGHT, WITNESS_SCALE_FACTOR, MIN_TRANSACTION_WEIGHT, MIN_SERIALIZABLE_TRANSACTION_WEIGHTsrc/consensus/validation.h — GetTransactionWeight(), GetBlockWeight(), GetTransactionInputWeight()src/validation.cpp — CheckBlock() size pre-check, ContextualCheckBlock() final block size check, and MAX_BLOCK_SERIALIZED_SIZE references in LoadExternalBlockFile()src/net.cpp — MAX_BLOCK_SERIALIZED_SIZE reference in buffer sizing for block-inv trackingsrc/consensus/tx_check.cpp — per-transaction size checksrc/consensus/tx_verify.cpp — sigop cost multiplier in GetTransactionSigOpCost()This proposal MAY be deployed as a soft fork. Because every block valid under the new rules is also valid under the current rules, the valid block set is strictly reduced.
Non-upgraded miners producing blocks under the old weight rules risk having their blocks orphaned if the majority hashrate enforces the new limit.
This proposal is a soft fork for two reasons:
Old nodes validate the stripped size of a block, which excludes witness data. The current weight-based rule is stripped_size × 4 + total_size ≤ 4,000,000, which satisfies weight ≤ 4 × total_size because stripped_size ≤ total_size. 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, and the new rule accepts exactly those blocks. The valid block set is therefore strictly 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.
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 as a soft fork 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.
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 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.
The legacy MAX_BLOCK_SERIALIZED_SIZE = 4,000,000 constant is replaced by the active consensus limit of 1,000,000 bytes. A new constant HISTORICAL_MAX_BLOCK_SERIALIZED_SIZE = 4,000,000 is introduced in its place wherever the legacy value was 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. This is not a consensus limit. Without the historical constant, lowering MAX_BLOCK_SERIALIZED_SIZE to 1,000,000 would break synchronization for nodes loading pre-activation block history.
This proposal reduces the maximum amount of data committed to the blockchain.
A reduction in available block space may increase transaction fees and mempool competition.
Higher settlement costs may encourage greater utilization of payment channels and other higher-layer protocols.
The effect on miner revenue depends on future demand for block space and cannot be predicted in advance.
ARTEL 21 and The Bitcoin Lens.
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.