Introduction
Recent discussions in the Bitcoin community have focused on a contentious new proposal known as the Reduced Data Temporary Softfork (RDTS), aimed at managing the blockchain’s data storage challenges. However, not everyone agrees on the effectiveness or necessity of these measures. Mononaut, a developer associated with mempool.space and a prominent analyst, has published a thorough evaluation expressing serious concerns over the potential consequences of implementing RDTS.
Overview of RDTS
The RDTS initiative, introduced in the wake of Bitcoin Core v30—which eliminated restrictions on OP_RETURN data—is designed to impose a range of consensus restrictions. Should it be enacted, this soft fork would be in effect for approximately one year. The suggested limitations include:
- Reducing scriptPubKey sizes to 34 bytes
- Capping OP_RETURN outputs at 83 bytes
- Placing constraints on Taproot control blocks
- Eliminating undefined witness versions
- Interfering with various forms of Tapscript logic
Support and Criticism
Supporters of this approach argue that it serves as an essential stopgap to prevent arbitrary data uploads that could pose risks to node operators if illegal content is embedded into the blockchain. However, Mononaut’s analysis highlights the potential unintended ramifications of such limitations by analyzing historical transactions that would fall afoul of these new rules.
Key Findings from Mononaut’s Analysis
His review reveals that the proposed scriptPubKey restrictions would invalidate all pay-to-public-key (P2PK) and multisig (P2MS) transactions, along with several historic non-standard outputs. Furthermore, the rule targeting payloads over 256 bytes would not obstruct inscription envelopes, but it does pose risks to some of the other transaction types.
A key finding is that undefined witness versions would affect over 54,000 past transactions that utilized unconventional outputs to circumvent OP_RETURN data quotas. Given that witness version lengths are specified in Bitcoin Improvement Proposals (BIPs) 141 and 341, the current language in RDTS would also prohibit legitimate formats including P2A anchors.
The proposal introduces additional complications by making witness stacks containing Taproot annexes invalid. Although such transactions are uncommon, Mononaut pointed out that at least 11 transactions historically have relied on this construct for handling sizable data. A considerable concern arises from large Taproot control blocks, with around 32,000 transactions involving control blocks of depth greater than 100 being threatened by this proposal.
Impact on Tapscript Functionality
The strictest provisions of RDTS would ban OP_SUCCESS and any Tapscript executing OP_IF or OP_NOTIF, reaching much farther than merely inscription-related transactions. Mononaut provided examples of two historic OP_SUCCESS transactions alongside approximately 70 Taproot spends reliant on OP_IF. Many of these transactions involve financial arrangements, including multisig templates and hash-time-locked contracts (HTLCs), some of which come from wallets that deliberately disabled their keypaths, necessitating script-path spending.
While proponents of RDTS assert that affected users can revert to keypath spending, Mononaut’s data contradicts this claim. Approximately 560,000 historical Taproot spends derive from outputs where the keypath has been verifiably disabled, underscoring the critical nature of functions like OP_IF.
Conclusion
As discussions surrounding RDTS continue, supporters maintain that the proposal serves a vital role in safeguarding Bitcoin’s monetary integrity and minimizing the data load on nodes. Critics argue that sweeping restrictions on Tapscript functionality could lead to unintentional censorship, invalidating functional transactions, and disrupting existing applications. This ongoing debate reflects a broader philosophical divide within the community regarding Bitcoin’s future direction—whether it should strictly aim for monetary utility or adapt to evolving, experimental use cases. As the proposal remains under review, engagement continues among developers, researchers, and other stakeholders in the ecosystem.
