← Index
ARTEL 21: Uniform Byte Accounting
ARTEL 21 / Articles

BIP-?: Uniform Byte Accounting for Bitcoin Blocks

Unbundling SegWit: preserve the fix, remove the discount, restore the invariant.

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

Abstract

Segregated Witness (BIP-141) was a bundle. It delivered necessary engineering — transaction malleability fixes, quadratic sighash scaling relief, and a path to script versioning — alongside an economic mechanism that 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 unbundles the bundle. It preserves every engineering advance introduced by SegWit and Taproot: the witness commitment structure, the malleability fix, native SegWit output types, script versioning, Schnorr signatures, and MAST compatibility. Only the witness discount is removed. The WITNESS_SCALE_FACTOR is set to 1. The 1,000,000-byte serialized block size limit is restored. Every byte counts equally.

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

SegWit’s Engineering Legacy: What We Keep

Before examining what changes, it is essential to state what does not. SegWit solved real problems. This proposal preserves every one of them.

Transaction malleability fix

SegWit moved the signature data into the witness field, which is excluded from the transaction identifier hash. Because the signature is no longer part of the txid, no third party can alter the witness and change the txid without invalidating the transaction. This remains untouched. The witness commitment — the Merkle root of all witness data stored in the coinbase transaction — also remains required.

Quadratic sighash scaling relief

BIP-143 replaced the original sighash algorithm with one that scales linearly in the number of inputs. Without this fix, a transaction with many inputs could require computation growing as the square of the input count. The new sighash remains untouched.

Script versioning path

SegWit introduced a version byte in the witness program, creating a clean upgrade path for new script semantics without requiring additional P2SH-like hacks. This path remains untouched. Future soft forks that introduce new script versions can still do so via the existing version byte.

Native SegWit and Taproot compatibility

P2WPKH, P2WSH, and P2TR output types remain fully consensus-valid. Bech32 and Bech32m address encodings remain valid. Schnorr signatures, key-path spends, script-path spends, and MAST trees remain valid. Lightning Network commitment and HTLC scripts continue to function. Nothing in this proposal alters script validation, signature verification, or output spendability.

What changes is strictly the accounting layer. The engineering layer is preserved in its entirety.

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 008: 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.

The inscription era and the node operator subsidy

Since 2023, the witness discount has become not merely a theoretical distortion but a lived frustration. Inscriptions, BRC-20, Runes, and protocol commitments have saturated the witness field with non-monetary data. Block 836,903 stored 3,993,936 bytes of raw data while invoicing senders for 994,608 virtual bytes. The fee market billed for 1 MB; the network wrote 4 MB to disk.

Every full node operator is now storing data they did not agree to host, at a price they did not set. The witness discount is the mechanism that makes this possible: by making witness bytes four times cheaper in fee calculations than non-witness bytes, the protocol created a space where data can be stored at a quarter of its cost. The old nodes are blind to the data. The new nodes are blind to the cost. The gap is the difference.

The node operator subsidy, in dollars

The phantom byte gap is not an abstraction. It has a physical cost. Consider the arithmetic:

These are order-of-magnitude estimates. They are not precise financial statements. But they are precise enough to demonstrate that the externality is real, permanent, and borne by the people who choose to validate the chain for everyone else.

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×.

The phantom byte ledger

The divergence is not occasional. It is structural. The following table estimates cumulative unpaid chain growth under the current regime compared to the 1 MB invariant, assuming average utilization at observed post-SegWit levels:

Period Uniform Accounting (1 MB max) Discounted Chain (observed average ~2 MB raw) Phantom Accumulation
1 decade 526 GB ~1.05 TB ~526 GB unpaid
1 century 5.26 TB ~10.5 TB ~5.26 TB unpaid
1 millennia 52.6 TB ~105 TB ~52.6 TB unpaid

These numbers assume average raw block sizes of ~2 MB, which is conservative compared to fully witness-packed 4 MB blocks. The unpaid accumulation is permanent, replicated across every node, and grows monotonically. The node operator pays the persistence cost; the data writer does not.

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 to 2× would still treat witness bytes and non-witness bytes unequally in consensus accounting. Arbitrage opportunities would persist; the identity ratio would still climb toward 2.0 for witness-heavy blocks. 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 008: 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.

Miner revenue under uniform accounting

The most frequent objection to this proposal is economic: if block space in weight terms drops, do miner fees rise enough to compensate? The answer depends on demand elasticity, which historical evidence suggests is inelastic at the margin.

Scenario Demand Assumption Fee Impact Miner Revenue
Perfectly inelastic Users will pay any fee to settle Rise ~4× Increase substantially
Moderately inelastic Settlement demand is sticky; routine payments migrate to L2 Rise 2–3× Rise or stay neutral
Elastic Users abandon on-chain entirely Rise <2× Fall

Historical precedent supports the inelastic scenario. During the 2021 congestion peak, average fees rose above 100 sat/vByte. During inscription surges, fees reached 500–1,000 sat/vByte. Users with time-sensitive settlement needs paid these rates without abandoning the chain. This suggests that block space demand for final settlement is robust even at elevated prices.

It is also important to note that miners do not approve consensus changes. Miners provide sequencing and timestamping; economic nodes provide validation and fee demand. If the economic majority of nodes, exchanges, and custodians adopts uniform accounting, miners follow the fee market. The revenue question is therefore secondary to the question of whether the economic majority values the invariant more than the discount.

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. What changes is their cost. Lightning Network in particular may benefit: higher on-chain settlement costs strengthen the economic case for staying off-chain.

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. The Raspberry Pi full node is viable for longer. The archival burden does not compound at 4× the original rate.

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.

Transition fairness: dust UTXOs and small-value outputs

A legitimate concern is that higher effective fees may strand small-value UTXOs. A P2WPKH spend today costs roughly 5,000 sats at 50 sat/vByte. Under uniform accounting, the same spend might cost 7,000–8,000 sats. UTXOs below ~10,000 sats are already economically marginal at current fee rates.

However, this proposal does not create a new crisis. It marginally accelerates an existing trend. Small UTXOs have been uneconomical for years during fee spikes. The protocol does not owe users a perpetual right to spend sub-dollar outputs at sub-dollar cost. What the protocol does owe is honesty in accounting: the fee paid should equal the bytes stored. Under the current regime, small outputs are subsidized by node operators; under uniform accounting, the subsidy ends.

We acknowledge this as genuinely regrettable. Some users will find that UTXOs they thought spendable have become dust. The honest response is not to maintain a discount that externalizes cost to the network, but to encourage users to consolidate during low-fee periods and to migrate small holdings to custodial or Lightning solutions.

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 008: 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 007: Specification for details on the HISTORICAL_MAX_BLOCK_SERIALIZED_SIZE constant and its role in preserving compatibility with pre-activation block files.

Activation

Bitcoin has never activated a non-emergency hard fork. The burden of proof for this proposal is therefore higher than for a soft fork. The activation path is designed to give the ecosystem years to evaluate, upgrade, and demonstrate support before enforcement begins.

Proposed activation parameters

This proposal recommends activation via BIP8 with the following parameters:

Why BIP8 and not BIP9?

BIP9 (VersionBits) was the mechanism used for SegWit and Taproot. It relies on miner signaling alone and has no timeout enforcement. BIP8 adds a guaranteed timeout window, which is appropriate for a hard fork because non-upgraded nodes face permanent divergence. The timeout creates certainty: either the network demonstrates consensus within two years, or the proposal lapses and the status quo continues.

The political reality

A hard fork requires more than code. It requires a supermajority of the economic layer — exchanges, custodians, payment processors, and large holders — to run the upgraded software. Miners provide sequencing; economic nodes provide the rules. If the economic majority adopts uniform accounting, miners follow the fee market. If miners resist and the economic majority does not adopt, the proposal fails. This is not a bug in the activation design. It is the protocol working as intended.

The purpose of the two-year window is to give the ecosystem time to debate the merits without urgency, to evaluate the empirical cost data, and to upgrade infrastructure without panic. A rushed hard fork is dangerous. A deliberated one is merely difficult.

Common Objections and Rebuttals

1. This breaks Lightning Network!

No. Lightning Network exists because on-chain settlement is too cheap, not because it is too expensive. Higher on-chain fees strengthen the economic incentive to open and maintain payment channels rather than transacting on-chain. The security model of LN — hash time-locked contracts and justice transactions — does not depend on witness discount pricing. LN channel-open transactions are typically single P2WSH inputs and outputs; under uniform accounting they face a moderate fee increase, not a prohibitive one.

2. This reverts SegWit entirely!

No. This proposal unbundles SegWit. The malleability fix, witness commitment, quadratic sighash relief, and script versioning path are all preserved. What is removed is strictly the economic discount. See Section 002: SegWit’s Engineering Legacy for the complete list of preserved features.

3. Why not reduce the discount to 2× instead of removing it?

Any ratio other than 1.0 breaks byte identity. A 2× discount still creates phantom bytes (half the witness cost is unpaid), still creates two fee markets, and still incentivizes transaction composition to maximize witness data. Only a 1.0 ratio aligns the invoice with the storage cost. See Section 005.

4. Miners will lose revenue!

Miner revenue under uniform accounting depends on demand elasticity. Historical evidence from 2021 congestion and inscription peaks suggests that settlement demand is highly inelastic: users paid 100–1,000 sat/vByte without abandoning the chain. With scarcer space, fees per byte may rise enough to offset or exceed the byte reduction. See Section 005: Miner Revenue Under Uniform Accounting for the break-even model. Additionally, miners do not approve consensus changes; the economic majority does.

5. This makes Bitcoin too expensive for small payments!

Small payments already belong on higher-layer protocols. The purpose of the base layer is final settlement, not coffee purchases. Higher fees encourage Lightning adoption, which is the intended design. The witness discount externalized the true cost of on-chain small payments onto node operators; uniform accounting internalizes it.

6. The 1 MB limit was arbitrary!

It was the first invariant. Restoring it is an act of continuity, not an assertion of optimality. The point is not that 1 MB is perfect, but that 4 MB was introduced without economic consensus via a discount that distorted the fee market. If the community later wishes to change the 1 MB limit, it can do so through a separate, explicit proposal that prices all bytes equally.

7. What about Taproot? Doesn’t it need the discount?

Taproot key-path spends are tiny: a 32-byte witness program and a 64-byte Schnorr signature. They are small because the protocol is efficient, not because the discount makes them possible. The discount makes them artificially cheap; removing the discount makes them fairly priced. Script-path spends with large MAST trees are more expensive, but that is the point: the cost should reflect the bytes stored.

8. Hard forks are too dangerous!

SegWit itself was de facto a hard fork: it introduced an accounting model that old nodes cannot validate or even perceive. Old nodes and new nodes have incompatible views of the same block. This proposal reverses that prior hard fork and restores a unified accounting model. The danger is not the hard fork; the danger is the permanent divergence that already exists and is widening with every phantom byte. See Section 008.

9. Let the fee market manage this instead!

The fee market is structurally unable to self-correct a 4× price floor imposed by consensus. Miners sort mempool by sat/vByte. Users bid in sat/vByte. The unit itself is distorted. A market cannot discover the correct price for apples when the government mandates that half the apples are free. Consensus must remove the floor before the market can function.

10. This is anti-innovation!

Complex scripts and multi-sig constructions are not banned. They are priced honestly. Innovation does not require a subsidy. The current discount does not fund innovation; it externalizes storage costs to node operators who have no say in what data they must host. Uniform accounting lets innovators build on a fee market that reflects true cost, which is a stronger foundation than one built on hidden subsidies.

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. See Section 005: Miner Revenue Under Uniform Accounting for the demand-elasticity model.

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-8: Version bits with lock-in by height. Dashjr, L., et al., 2020. Defines the activation mechanism recommended for this proposal.
  3. BIP-141: Segregated Witness (Consensus layer). Corallo, L., et al., 2015–2017. Defines the witness discount this proposal removes.
  4. 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.
  5. BIP-144: Segregated Witness (Peer Services). Corallo, L., et al., 2016. Defines the new network serialization for SegWit. Unaffected by this proposal.
  6. BIP-147: Dealing with dummy stack element malleability. Wuille, P., 2016. Eliminates a malleability vector in P2SH witness scripts. Unaffected by this proposal.
  7. BIP-341: Taproot. Wuille, P., et al., 2020. SegWit v1 output type. Unaffected by this proposal.
  8. 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.