On October 4, two developers presented BIP-447, a Bitcoin Improvement Proposal (BIP-447) that introduces a soft fork, a rule change that nodes can adopt without fragmenting the network.  

Titled “OP_RETURN Pruning without Breaking Merkle Tree Re-verification + Selective Block Space Reduction for Transactions with Arbitrary Data,” BIP-447 addresses the use of inscriptions, such as data like text or images, embedded in Bitcoin via OP_RETURN, a code that adds non-monetary information to transactions.  

OP_RETURN operations have led to the current “client war,” reflecting tensions between different approaches that the authors of BIP-447 consider problematic: 

• On the one hand, Luke Dashjr introduced pattern filtering in Bitcoin Knots to block transactions with inscriptions. This filtering, according to the BIP-447 repository, incentivizes users to bypass the P2P (person-to-person) network and send their transactions directly to large pools, concentrating mining power on those platforms.  

• On the other hand, in Bitcoin Core v.30, the next version of this client due out this month, it was proposed to remove the OP_RETURN limit, which would allow inserting arbitrary data, but would make nodes have to store more information, including potentially illegal content such as child pornography, which could cause problems for them. 

How does BIP-447 work in Bitcoin? 

The text of BIP-447 details its operation in three key points.  First, it aims to mitigate transaction registrations through a soft fork that would increase the costs of complex scripts (programs that execute actions) without expanding block capacity.  

If implemented, the soft fork would cause OP_RETURN registrations to cost 4 times more than they do now. This circumstance would exert economic pressure against what the authors understand as "blockchain abuse," while preserving the efficiency of standard transactions.  

As detailed, new nodes would assign higher weights to transactions with OP_RETURN greater than 32 bytes, but would respect the virtual weight limit of up to 4 megabytes, established by SegWit, which older nodes also recognize.  This would ensure that blocks remain valid for everyone and preserve network consensus. 

Second, BIP-447 follows a deployment model known as “UASF” (user-activated soft fork), which allows node runners to enforce these rules without relying on developer groups that haven’t solved the problem. Thus, this UASF would give nodes the ability to make individual decisions independent of client policy. 

Third, it integrates the prunable storage option of SegData, a method that, inspired by ideas like SegWit (which separates verification data to save space), allows nodes to save only the essential parts of transactions and discard the rest, easing their load.  

This integration would offer node operators economic protection by reducing hardware costs and legal protection by preventing the storage of problematic content. 

What does BIP-447 aim to improve in Bitcoin? 

Among the aspects that the proposal promises to improve are:  

• Reduce the burden on lightweight nodes by allowing them to verify transactions without storing the entire UTXO (unspent transaction output) state, making them more accessible. 

• Reduce bandwidth consumption by transmitting supplementary data only when necessary, optimizing traffic. 

• Facilitate gradual scalability that adapts the network to nodes of different capacities without sacrificing security. Furthermore, by lowering operating costs for less powerful nodes, it encourages more participants to operate them, reinforcing decentralization. 

Promoting a lighter network and the economic impact of BIP-447 on Bitcoin 

To discourage excessive use of space in the Bitcoin file, OP_RETURN outputs larger than 32 bytes would face a four-times higher cost, eliminating the weight discount that allows up to 4 MB to be included per 1 MB of space, as occurs with SegWit.  

In contrast, 32-byte SegData commitments would not incur this additional penalty, as their design avoids the weight increase applied to large data, allowing nodes to handle them without penalizing the space occupied.  This approach would create economic pressure for users to abandon cumbersome registrations or migrate to prunable formats like SegData. 

We can see this with a hypothetical example, provided by the authors of the proposal. According to their document, the economic impact of BIP-447 would be significant. "1 MB inscriptions would be reduced from four to one per block (75% less), and 100 KB inscriptions from 40 to 10 (75% less)."  

These changes would make the registrations too expensive to continue using them indiscriminately, according to the text. The authors of the proposal illustrate how, with a price of 20 satoshis per virtual byte (sat/vB), the cost of Bitcoin transactions varies dramatically depending on their type. 

For example, a simple transaction would cost about 2,800 satoshis (around $2.80 with BTC at $124,000) and a 2-of-3 multisig would cost about 3,200 satoshis ($3.20).  However, for 1 MB subscriptions, the price would skyrocket to 20,000,000 satoshis (about $20,000), four times the current 5,000,000 satoshis ($5,000).