Bitcoin Updates: Developer Cautions That Emergency Data Restrictions Could Disrupt Essential Bitcoin Transactions

Bitcoin Developer Cautions Against Potential Disruptions from Proposed Data-Limiting Soft Fork

A prominent

developer has issued a warning regarding a suggested temporary soft fork designed to restrict excessive data storage on the blockchain, cautioning that such measures might unintentionally block essential transaction types and experimental functionalities. Mononaut, a developer and analyst at mempool.space, outlined these concerns in a recent review of the Reduced Data Temporary Softfork (RDTS) proposal, which for about one year.

The RDTS proposal, supported by advocates as an urgent response to reduce legal exposure and lighten the load on node operators, introduces a set of restrictive guidelines. These include limiting scriptPubKeys to 34 bytes, restricting OP_RETURN outputs to 83 bytes, and disallowing undefined witness versions. While proponents believe these steps would block arbitrary data storage and protect Bitcoin’s primary financial function, Mononaut’s analysis points to considerable unintended consequences. Historical data shows that more than 54,000 previous transactions, which used unconventional outputs to get around OP_RETURN restrictions, would become invalid under these new rules. Furthermore, the scriptPubKey size cap would make all pay-to-public-key (P2PK) and multisig (P2MS) outputs non-compliant,

.

The developer also flagged potential problems for Taproot transactions, such as large control blocks used for embedding data and valid script patterns like OP_SUCCESS and OP_IF. Mononaut highlighted that around 560,000 past Taproot spends depend on outputs where keypath spending is disabled, making conditional logic (like OP_IF) crucial for moving funds. Detractors argue that these restrictions could amount to indirect censorship, preventing legitimate uses and disrupting current protocols. For example,

for storing large amounts of data, and over 32,000 spends involve control blocks that would exceed the depth limits set by RDTS.

Backers of the soft fork argue that those impacted could simply switch to keypath spending, but Mononaut’s findings dispute this, showing that many users have deliberately disabled keypaths, leaving script-path spending as their only option. This ongoing debate mirrors earlier disputes over inscription-related data growth, with critics insisting Bitcoin should remain open to innovation, while supporters focus on reducing non-monetary data.

The draft proposal has ignited vigorous debate among developers and the broader community. While supporters present RDTS as a temporary measure to address possible legal and operational threats, opponents warn it could compromise Bitcoin’s adaptability and stifle innovation. As the community considers the balance between security and versatility, the ultimate resolution is still up in the air.