from X @MajorianBTC
What a soft fork #proposal could look like:
Abstract
This #BIP proposes two consensus rule changes to Bitcoin's protocol:
(1) Enforcing a hard cap of 83 bytes on OP_RETURN data outputs, aligning with long-standing node policy to prevent arbitrary data bloat.
(2) Introducing restrictions on witness data usage in Taproot scripts to curb the "inscriptions" and "ordinals" mechanism, which exploits witness discounts to embed non-financial data, inflating the UTXO set with unspendable outputs. These changes aim to preserve Bitcoin's focus on financial transactions while maintaining backwards compatibility for valid existing outputs.
Motivation
Bitcoin's protocol has evolved to support efficient, secure value transfer, but certain exploits have emerged that prioritize data storage over transaction utility, leading to network congestion, higher node resource demands, and UTXO set bloat.
1. OP_RETURN Data Limit:
For over a decade, Bitcoin nodes have enforced a standardness policy limiting OP_RETURN outputs to 83 bytes (initially 40, later 80+3 for versioning). This prevents excessive null-data spam. However, consensus rules allow unlimited sizes, enabling miners to include larger outputs if they choose, potentially fragmenting the network or encouraging abuse. A consensus hard cap at 83 bytes codifies this policy, ensuring uniformity and reducing risks from oversized data.
2. Inscriptions and Ordinals 'Hack':
Introduced via Ordinal theory, inscriptions embed arbitrary data (e.g., images, NFTs) into witness fields of Taproot spends, leveraging the 4x witness discount to store up to ~4MB cheaply. This creates unspendable UTXOs (e.g., via bare Taproot keys or annulled scripts) that bloat the UTXO set, as nodes must track them indefinitely. Ordinals assign "rarity" to satoshis based on inscription order, turning Bitcoin into a de facto data layer. This has caused chain bloat (e.g., 2023-2024 spikes in block sizes and fees), deviates from Bitcoin's monetary purpose, and burdens full nodes. The proposal mitigates this by restricting witness data in non-standard scripts, without censoring legitimate uses like multisig or covenants.
These issues threaten Bitcoin's scalability and decentralization. This BIP addresses them through targeted consensus rules, drawing from community discussions (e.g., on mailing lists and forums) without introducing soft-fork complexities like CTV or new opcodes.
Specification
1. OP_RETURN Hard Cap
For new blocks after activation height [TBD, e.g., via BIP-9 signaling]:Any transaction output script beginning with OP_RETURN (0x6a) must have a data payload of exactly 0 to 83 bytes (inclusive).
Payload is defined as the bytes following the OP_RETURN opcode, up to the script end.
Transactions violating this are invalid at consensus level.
This aligns with longstanding Bitcoin Core policy (max 83 bytes, including push opcodes).
2. Inscription Mitigation
Target the common inscription pattern: Embedding data in Taproot witness stacks via unexecutable scripts (e.g., OP_FALSE OP_IF ... OP_ENDIF) or bare key spends where the witness holds arbitrary payloads.
New consensus rules post-activation:
For Taproot key-path spends (no script path): Limit witness stack size to 1 element (the signature), disallowing extra data.
For Taproot script-path spends: If the script is non-standard (e.g., contains OP_SUCCESS or unverifiable paths leading to data drops), and the witness exceeds 520 bytes (standard push limit), mark as invalid.
Introduce a "data-bearing output" flag: Outputs with witness-discounted data >1KB must be provably spendable (e.g., require a valid key or script that doesn't annul itself). Unspendable outputs (e.g., OP_RETURN-like in Taproot) are rejected if they embed >83 bytes of data.
Exemptions: Legitimate uses like MAST (Merkleized Abstract Syntax Trees) or small metadata remain allowed if under limits.
Activation: Via BIP-9 (version bits) with a 95% miner threshold over 2016 blocks, start height [TBD], timeout [1 year post-start].
Rationale
OP_RETURN Cap:
83 bytes balances utility (e.g., for timestamps, commitments) with anti-spam measures. It's a de facto standard, minimizing disruption. Larger limits encourage abuse like file storage.
Inscription Restrictions:
Focuses on witness exploits without banning Taproot. Limits are inspired by existing stack/item size rules (e.g., 520 bytes). This reduces UTXO pollution (~10-20% bloat from inscriptions as of 2025) while preserving innovation. Alternatives like fee adjustments were considered but deemed insufficient, as they don't address unspendables.
Soft fork design ensures old nodes see new blocks as valid, but new rules enforce on upgraded nodes.
Community feedback: Builds on proposals like Luke Dashjr's inscription filters (2023) and avoids "censorship" debates by using objective size/spendability criteria.
Backwards Compatibility
All pre-activation transactions/outputs remain valid.
Post-activation, non-compliant txs are rejected, but existing inscriptions/OP_RETURNs are grandfathered.
Miners/nodes must upgrade; non-upgraded nodes may fork if activation occurs.
No impact on wallets unless they create oversized data.
#btc #bitcoin
#datacarrier
#non-witness #tolerant #minority
#usecases #economic #node #nodes #game #theory #financial #incentives #fee #estimation #ossification #mempool #logic
#L2 #security #model #public #private #merge #softfork #disintermediation
#user #free