Bitcoin News Today: Bitcoin's Emergency Data Limits Risk Breaking Key Transactions, Developer Warns

Generated by AI AgentCoin WorldReviewed byRodder Shi
Thursday, Nov 13, 2025 1:30 pm ET1min read
Speaker 1
Speaker 2
AI Podcast:Your News, Now Playing
Aime RobotAime Summary

-

Bitcoin
developer Mononaut warns proposed RDTS soft fork risks breaking 54,000+ historical transactions and experimental use cases by restricting data storage.

- Supporters argue temporary limits on scriptPubKeys, OP_RETURN, and witness versions would reduce legal risks and node burdens, but critics highlight censorship risks and protocol breaks.

- Taproot transactions using control blocks or conditional logic (OP_IF) face invalidation, affecting 560,000+ spends and undermining script-path spending for keypath-disabled users.

- Debate mirrors past tensions over data growth, with Bitcoin community weighing short-term security benefits against long-term innovation and flexibility trade-offs.

Bitcoin Developer Warns of Disruption from Proposed Reduced Data Soft Fork

A leading

Bitcoin
developer has raised alarms over a proposed temporary soft fork aimed at curbing excessive data storage on the blockchain, warning that the measures could inadvertently disable critical transaction types and experimental use cases. Mononaut, an analyst and developer at mempool.space, detailed the risks in a recent assessment of the Reduced Data Temporary Softfork (RDTS) proposal, which
seeks to impose strict limits on script and data features
for roughly one year.

The RDTS initiative, backed by proponents as an emergency measure to mitigate legal risks and node operator burdens, introduces several restrictive rules. These include capping scriptPubKeys at 34 bytes, limiting OP_RETURN outputs to 83 bytes, and banning undefined witness versions. While supporters argue these changes would prevent arbitrary data uploads and preserve Bitcoin's core monetary utility, Mononaut's analysis highlights significant collateral damage. Historical transaction data reveals that over 54,000 past transactions using unconventional outputs to bypass OP_RETURN limits would be invalidated under the proposal. Additionally, scriptPubKey size restrictions would render all pay-to-public-key (P2PK) and multisig (P2MS) outputs non-compliant,

affecting both legacy and modern transaction formats
.

The developer also identified risks to Taproot-based transactions, including large control blocks used for data embedding and valid script constructs like OP_SUCCESS and OP_IF. Mononaut noted that approximately 560,000 historical Taproot spends rely on keypath-disabled outputs, making conditional logic (e.g., OP_IF) essential for fund mobility. Critics argue that such restrictions could introduce de facto censorship, disabling legitimate applications and breaking existing protocols. For instance,

11 transactions have utilized Taproot annexes
for data-heavy purposes, and over 32,000 spends include control blocks exceeding depth limits proposed in RDTS.

Supporters of the soft fork maintain that users affected by these rules could revert to keypath spending, but Mononaut's data challenges this assumption. Many users have intentionally disabled keypaths, leaving script-path spending as the only viable option. This debate echoes earlier tensions over inscription-driven data growth, with opponents arguing Bitcoin should remain open to experimental uses while proponents prioritize minimizing non-financial data.

The proposal, currently in draft form, has sparked intense discussion among developers and stakeholders. While advocates frame RDTS as a short-term safeguard against potential legal and operational risks, critics warn it could undermine Bitcoin's flexibility and innovation ecosystem. As the community weighs the trade-offs between security and functionality, the final outcome remains uncertain.