BIP: X Layer: Consensus (soft fork) Title: Discounting Normal Transactions without a Block Size Increase via Median Fees and Constrained Data Bucket Sizes Author: Colby Serpa <npub1t89vhkp66hz54kga4n635jwqdc977uc2crnuyddx7maznwfrpupqwra5h9>, Daisugi Status: Draft Type: Standards Track Created: 2025-10-16 License: MIT Activation: User-Activated Soft Fork (UASF)
This BIP proposes safer data bucket size constraints within bitcoin transactions to minimize arbitrary data storage on-chain, while preserving basic Lightning Network functionality. By limiting witness data to 300 bytes, taproot trees to 2 leaves, outputs to 6, and scriptPubKey size to 36 bytes, we make all the viable paths for spam more expensive.
Non-qualifying transactions pay 3.14× (π) the median fee rate of qualifying transactions, creating equal economic punishment for all types of spam. For the first time ever, a transaction discount is achieved at the consensus level without a block size/weight increase.
Bitcoin's transaction structure has evolved through two major upgrades that inadvertently expanded the attack surface for arbitrary data storage:
2017 - SegWit: Segregated Witness moved signature data into a separate witness structure with a 75% fee discount. Each input gets its own witness bucket in every transaction, meaning a single transaction can contain many witness data buckets. While solving transaction malleability and enabling Lightning, SegWit created per-input witness data buckets that attackers could use to embed data across multiple inputs, benefiting from the increase in storage area per transaction and from the discount meant for SegWit.
2021 - Taproot: Taproot introduced tapscript trees where each P2TR output could commit to multiple spending paths. Each output gets its own taproot tree and taproot scripts/leaves. Attackers exploited this by embedding massive data payloads in witness-revealed tapscript leaves, creating "inscriptions" - larger arbitrary files stored on-chain than ever before (sometimes with an entire photo in a single transaction).
Since late 2022, the Bitcoin network has been flooded with inscription transactions storing images, videos, and other non-monetary data directly in the blockchain. This abuse manifests in two patterns:
- Single-transaction inscriptions: Full files embedded in one transaction's witness
- Fragmented inscriptions: Bits of file data spread across many small transactions
- UTXO bloat: Inscriptions, or fragmentation via other spam methods, create thousands of outputs that must be tracked indefinitely
- Legal liability: Illegal content embedded on-chain creates risks for node operators globally
- Blockchain bloat: Permanent storage of arbitrary data crowds out monetary transactions
- Fee market distortion: Spam transactions price out legitimate economic activity
Previous proposals have suggested blocking non-standard transactions entirely. This approach fails because:
- Misaligned incentives: Miners lose fee revenue by rejecting transactions
- Difficult enforcement: Requires widespread miner cooperation
A transaction qualifies for normal fee rates if ALL of the following constraints are met:
Background: SegWit (BIP141, 2017) introduced witness data with a 75% fee discount. Each input has its own witness vector, allowing attackers to spread inscription data across multiple inputs while benefiting from the discount.
Constraint: Total witness size across all inputs ≤ 300 bytes
This is calculated by summing all witness vectors including CompactSize prefixes. Inputs are unlimited to preserve UTXO consolidation incentives, but they share one small witness budget.
Rationale: Lightning Network HTLCs require up to 278 bytes for their largest witness (offered HTLC success path with two signatures). The 300-byte limit provides 22 bytes of safety margin while making inscriptions economically disincentivized.
Background: Taproot (BIP341, 2021) allows P2TR outputs to commit to script trees. When spending via script path, one tapscript leaf is revealed in the witness. Inscriptions exploit this by embedding massive data payloads in leaves.
Constraint: Maximum tree depth ≤ 1 (allows up to 2 script leaves)
- Depth 0: Single leaf with 33-byte control block
- Depth 1: Two leaves with 65-byte control block (33 base + 32 merkle proof)
Background: Outputs define payment destinations. While batching improves efficiency, unlimited outputs enable spam patterns.
Constraint: Maximum 6 outputs per transaction
Rationale: Lightning commitment transactions with anchors for fee bumping require 6 outputs minimum (2 balances + 2 anchors + 2 HTLC outputs) to enable secure bidirectional payments off-chain. Transactions with this limited number of six outputs will qualify and may reduce fees for users/exchanges sending coins to five or less recipients at once (5 addresses + 1 change address).
Background: Each output contains a scriptPubKey defining spending conditions. This is the only variable-size portion besides witness data.
Constraint: Each output's scriptPubKey ≤ 36 bytes
Implications:
- P2TR (Taproot): 34 bytes ✓
- P2WPKH (Native SegWit): 22 bytes ✓
- OP_RETURN: Limited to 34 bytes of data payload ✓
Rationale: Limiting the OP_RETURN area to a single hash with a single hash-prefix is the rule. 32 bytes for one hash and 4 bytes for the CID v1 hash-prefixes, in case Merkle Root pointers to off-chain data are stored in the OP_RETURN/ScriptPubKey area.
The penalty system creates a two-tier fee market where qualifying transactions pay market rates while non-qualifying transactions must pay a multiple of those rates. This mechanism operates through three components:
1. Rolling Window Calculation: Every node maintains a 2016-block rolling window (approximately 2 weeks) of all qualifying transaction fees. This is similar to Bitcoin's difficulty adjustment period but is a rolling window instead - Satoshi's choice of two weeks balanced adaptability with stability, avoiding both stale data (too old) and volatility (too new) in his pursuit for homeostasis.
2. Median Determination: From this rolling window, nodes calculate the median fee rate of qualifying transactions. The "median" is used rather than the "mean" because it cannot be skewed by outliers - a few extremely high or low fee transactions cannot manipulate the baseline median as easily as a mean.
3. Penalty Application: Non-qualifying transactions must pay at least 3.14× this median rate or the block containing them is rejected.
For each block at height H: 1. Collect all qualifying transactions from blocks [H-2016, H-1] 2. Calculate MEDIAN_FEE = median(qualifying_fee_rates) 3. Required fee for non-qualifying tx ≥ MEDIAN_FEE × 3.14 4. Reject blocks violating this rule
Traditional discount mechanisms require expanding block capacity:
- SegWit (2017): Created 4MB block weight to provide 75% witness discount
- OP_RETURN2 proposals: Adam Back suggested 8MB blocks to gain the data carrier discount
- Problem: Larger blocks increase node requirements and centralization pressure, hence why Bitcoin Cash was rejected
- Block capacity: Unchanged at 4MB weight
- Qualifying transactions: Pay market rate (effective discount)
- Non-qualifying transactions: Pay 3.14× penalty
- Result: 68% relative discount for qualifying vs non-qualifying, no capacity change
A unique property emerges from calculating the median over qualifying transactions only:
Attack scenario: Attacker floods network with high-fee qualifying transactions to raise the median
- Attacker must create qualifying transactions (limited to 504 bytes of data each)
- These transactions must pay above-median fees to influence the calculation
- As median rises, penalty for non-qualifying transactions increases proportionally
- Result: Attack makes spam more expensive, not less
- Creating many simple transactions with low fees to lower the median would be very expensive to sustain for weeks
- Attacker must sustain >50% of all qualifying transaction volume, making it more costly than paying for the spam tax directly
- Attacker must gain 51%+ of hash power if they do not sustain >50% of all qualifying transaction volume, so the miner can only choose transactions with low fees, making the 51% attack even more costly than usual
- Leveraging unforgeable costliness mitigates both economic attack vectors
The 2016-block period provides optimal balance:
- Statistical significance: ~300,000+ qualifying transactions (assuming ~150 per block)
- Manipulation resistance: Requires sustaining attack for 2 weeks
- Market responsiveness: Adjusts to fee conditions every fortnight
- Calculation efficiency: Single median computation per block
The penalty multiplier was precisely calculated to create symmetric (equal) punishment for all types of spam, whether it's inscriptions or something yet to come. It's designed to be future-proof.
Attack Vector Analysis:
With our constraints, storing 1MB of data requires either:
- Single inscription: One transaction with 1MB in witness
- Transaction size: ~262,264 vbytes
- Cost at market rate R: 262,264 × R sats
- Fragmented storage: Split across many constrained transactions
- Data per transaction: 300 (witness) + 204 (6×34 OP_RETURN) = 504 bytes
- Transactions needed: 2,081 for 1MB
- Transaction size: ~396.5 vbytes each
- Total size: 2,081 × 396.5 = ~825,116 vbytes
- Cost at market rate R: 825,116 × R sats
For equal economic discouragement:
Single inscription with penalty = Fragmented storage at market rate 262,264 × R × P = 825,116 × R P = 825,116 / 262,264 P = 3.146 (rounded to 3.14 for memorability and mathematical elegance)
At P = 3.14×:
- Single inscription: Pays 3.14× market rate
- Fragmentation: Costs 3.14× as much total as single inscription
- Both attacks equally discouraged
Luke Dashjr's Fork:
- Blocks non-standard transactions entirely
- Requires miner adoption with no economic incentive
- Miners lose fees by rejecting transactions
- Creates adversarial relationship with miners
- Higher risk of chain split due to miner defection
- Non-qualifying transactions remain valid but expensive
- Miners earn MORE from penalized transactions (3.14× fees)
- Creates aligned incentives - miners profit from enforcement
- Market dynamics determine spam viability
- Gradual economic pressure rather than hard cutoffs
- Minimum for Lightning: 278 bytes (offered HTLC success)
- Safety margin: 22 bytes
- Spam impact: Makes inscriptions require ~2,000 transactions per MB
- Lightning requirement: Exactly 2 leaves (success + timeout paths)
- Key insight: Revocation uses key-path, not a script leaf
- No over-restriction: Deeper trees unnecessary for legitimate use
- Modern Lightning minimum: 2 outputs for balances + 2 outputs for anchors to enable fee bumping + 2 HTLCs
- Anchors: Luke Dashjr is currently blocking anchors in Knots. Anchors enable Lightning channel participants to fee bump their on-chain transactions for managing the channel when their original transaction isn't being processed. RBF cannot be used for this due to the two parties locked in the contract, therefore Anchors were invented. Anchors are worth preserving.
- Enables: Bidirectional routing, basic batching
- Accommodates: All standard output types
- OP_RETURN: 34-byte payload (32-byte hash + 2-byte prefix)
- Tightest possible: P2TR needs 34 bytes, leaving only 2-byte margin
This proposal uses a User-Activated Soft Fork (UASF) following the precedent of BIP148.
- Users define consensus: Economic nodes, not miners, determine valid blocks
- Miners provide proof-of-work: For chains that comply with user rules
- No permission needed: Users activate directly without miner signaling
- Flag Day: Block height TBD (few months after implementation release)
- No miner signaling: Direct activation at predetermined height
- Enforcement: Mandatory for participating nodes at activation height
- Miners benefit financially: They earn 3.14× fees from spam transactions
- No lost revenue: Unlike outright blockade, penalties increase miner income
- Users protect their network: Users running this node will force spammers to pay more fees
- Proven mechanism: BIP148 demonstrated UASF effectiveness
This is a soft fork. All blocks valid under new rules remain valid under old rules.
Old nodes:
- Accept all transactions (no penalty awareness)
- See all blocks as valid
- Continue normal operation
- Enforce penalty requirements, forcing spam to pay a fee 3.14x higher than basic non-spam
- Reject blocks containing unqualified transactions that do not pay the required 3.14x penalty
- Create economic pressure through block orphaning
Post-activation metrics to track:
- Percentage of qualifying vs non-qualifying transactions
- Median fee evolution
- Inscription transaction volume
- UTXO set growth rate
- Lightning Network impacts
Nash Equilibrium: Once a critical mass of economic nodes enforce penalties, miners must comply or have their blocks orphaned. But unlike outright blockade proposals, miners want to comply because they may earn more.
# Lightning HTLC settlement (qualifies) Witness: 278 bytes (maximum Lightning requirement) Outputs: 4 (to_local, to_remote, anchor_local, anchor_remote) ScriptPubKeys: All ≤34 bytes (P2TR) Result: Qualifies, pays market rate # Simple payment (qualifies) Witness: 107 bytes (single signature + pubkey) Outputs: 2 (payment + change) ScriptPubKeys: 34 bytes each (P2TR) Result: Qualifies, pays market rate # 5-recipient batch payment (qualifies) Witness: 107 bytes Outputs: 6 (5 payments + 1 change) ScriptPubKeys: All ≤34 bytes Result: Qualifies, pays market rate
# Inscription attempt Witness: 10,000 bytes (image data) Outputs: 1 ScriptPubKeys: 34 bytes Result: Non-qualifying, must pay 3.14× median fee # Excessive outputs Witness: 100 bytes Outputs: 7 ScriptPubKeys: All 22 bytes (P2WPKH) Result: Non-qualifying, must pay 3.14× median fee # Deep taproot tree Witness: 200 bytes Outputs: 2 Taproot tree depth: 5 Result: Non-qualifying, must pay 3.14× median fee
- Satoshi Nakamoto for creating Bitcoin with a clear monetary purpose
- The SegWit developers for enabling Lightning Network
- The Bitcoin Core developers for maintaining reference implementation
- The Lightning Network developers for defining minimum viable constraints
- The UASF community for proving user sovereignty
- BIP 141: Segregated Witness
- BIP 341: Taproot
- BIP 148: UASF SegWit
- Lightning Network BOLTs
- Ordinal Theory Documentation
This document is licensed under the MIT License.