A new proposed improvement to Bitcoin (BIP), dubbed “Temporary Soft Fork to Reduce Data,” proposes to temporarily change the network’s consensus rules to limit the inclusion of metadata (text, images, etc.) embedded in transactions.
A soft fork is a type of update that introduces new rules Compatible with previous And that only requires the consent of some participants.
The objective in this case is to reduce the prevalence of transactions with non-monetary data by many users. Channels that may be “spam” or stored Bitcoin illegal content.
The effort’s repository was published on October 24th by an anonymous developer under the pseudonym Dathon Ohm.
This anonymous collaborator was also reported through the Bitcoin Dev List, a mailing list of Bitcoin developers where technical suggestions and protocol updates are discussed. BIP creator Luke Daschlea well-known maintainer of the Bitcoin Knots client and one of the main critics of Bitcoin Core.
Motivation behind the proposed changes
The body of the proposal warns about the impact of the recently released Bitcoin Core v30. Allowed field size increased OP_RETURN Transactions up to 100,000 kilobytes (kb).
That space can now be filled with large amounts of non-financial information, such as text and images.
The main concern is that if a transaction contains files with illegal content, Bitcoin node operators (who must verify and store all transactions) May face legal or ethical risks By preserving its content.
How does this BIP work with Bitcoin?
Proposed BIP Introduces temporary limits on the size of certain data within a transaction.
Specifically, the BIP establishes that the new rules will govern block 934,864 (scheduled for February 1, 2026) through block 987,424 (scheduled for February 1, 2027).
During that period, transactions and blocks must comply with some additional restrictions. among them:
- overwrite new one script output (scriptPubKeys or public key script), larger than 34 bytes. However, those starting with OP_RETURN are excluded. A maximum of 83 bytes is allowed.
- Refuse data command Payloads greater than 256 bytes, except as defined in BIP-16.
moreover, soft fork Two activation methods are considered. The first, proactive, is based on an activation scheduled for early 2026 to implement rules without conflicts if problematic data does not appear on-chain.
The second, reactive, allows the chain to be retroactively reorganized to invalidate blocks containing illegal content and activate new rules immediately.
Finally, the author notes that, unlike most soft forks, this cause a temporary chain breakBecause it means rejecting blocks that have already been mined.
But he argues that this result is necessary to prevent illegal material from becoming permanently recorded.