A new soft fork proposal designed to curb excessive data storage on the Bitcoin blockchain is drawing sharp criticism in recent times. On Wednesday, the independent analyst and mempool.space developer, Mononaut, published an assessment outlining the potential collateral damage the rule set may cause.

The proposal, known as the Reduced Data Temporary Softfork (RDTS), introduces a suite of consensus-level restrictions intended to reduce data-heavy transactions—an effort developers say is necessary following the Bitcoin Core v30 update that removed limits on OP_RETURN data.

RDTS would apply for roughly one year if activated, limiting scriptPubKeys to 34 bytes, capping OP_RETURN outputs at 83 bytes, restricting Taproot control blocks, banning undefined witness versions, and disabling entire categories of Tapscript logic. Proponents of the BIP argue the measures act as an emergency brake against arbitrary data uploads that could expose node operators to legal liability if illegal material were embedded in the chain.

Mononaut’s assessment, however, quantifies the practical fallout of those restrictions by reviewing historical blockchain activity to see which real transactions would have violated the proposed rules. His findings suggest significant disruption. Under the scriptPubKey size limit alone, all pay-to-public-key (P2PK) and multisig (P2MS) outputs would be invalid. That restriction also affects a small number of non-standard outputs in past transactions.

The rule set change “affects all P2PK and P2MS outputs, as well as a small number of non-standard SPKs,” Mononaut said.

One of the more sweeping rules—invalidating OP_PUSHDATA operations with payloads above 256 bytes—would not affect inscription envelopes, assuming only executed pushes qualify. But Mononaut stressed that undefined witness versions would impact more than 54,000 historic transactions, many of which used unconventional outputs to bypass OP_RETURN data caps. Because witness version lengths are tightly defined in BIPs 141 and 341, the proposal as written would even block some valid modern formats such as P2A anchors.

Also read: Bitcoin Core Developers Merge Controversial Policy Changes: Is a Fork Ahead?

Mononaut detailed that RDTS also invalidates witness stacks containing a Taproot annex. While rare, the mempool.space developer notes that at least 11 transactions have used an annex for data-heavy purposes. A more significant category, Mononaut emphasized, is large Taproot control blocks: about 32,000 past spends include depth-100+ control blocks often used for data embedding, but even some non-data experiments rely on smaller, legitimate configurations that would be disabled. One active address consistently spends at control-block depth 11, which would be rejected under RDTS.

The proposal’s strictest line items—banning OP_SUCCESS* and any Tapscript executing OP_IF or OP_NOTIF—reach well beyond inscription envelopes. Mononaut highlights two historic OP_SUCCESS transactions, including Burak’s lightning-breaking transaction, and roughly 70 non-inscription OP_IF-based Taproot spends. Several of these are financial primitives, including decaying multisig templates and hash-time-locked contract (HTLC) designs. Some originate from wallets that intentionally disabled their keypath, leaving script-path spending as the only way to move funds.

RDTS advocates have argued that users with affected scripts could fall back on keypath spending. Still, Mononaut’s data challenges that assumption directly: about 560,000 historical Taproot spends come from outputs whose keypath was provably disabled, making OP_IF and similar functions essential rather than optional.

Supporters of the temporary soft fork maintain that RDTS is a short-term protective measure designed to preserve Bitcoin’s monetary utility, prevent legal hazards, and reduce node burdens by limiting data storage. Critics counter that broad restrictions on Tapscript behavior risk introducing de facto censorship, disabling valid transaction types, and breaking existing applications.

The debate mirrors earlier disputes over inscription-driven data growth, reflecting deeper disagreements over whether Bitcoin should remain strictly monetary or continue accommodating experimental uses. As the proposal remains in draft form, discussion is ongoing among developers, researchers, and ecosystem participants.

• What is RDTS?
  A temporary soft fork proposal that restricts several Bitcoin script and data features.
• Why is RDTS being debated?
  Supporters want to curb data abuse, while critics say it disables valid transactions.
• What did Mononaut find?
  His analysis shows many historical transactions would fail under RDTS rules.
• How long would RDTS last?
  The proposal outlines a one-year activation window if adopted.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。