Bitcoin Developer Embeds 66KB Image in Single Transaction, Challenging BIP-110 Data Restrictions

Slovak Bitcoin developer Martin Habovštiak published a proof-of-concept on March 1, 2026, embedding a 66-kilobyte TIFF image file contiguously in the Bitcoin blockchain as a single transaction without using OP_RETURN, Taproot, or OP_IF opcodes.

The demonstration directly challenges assertions from proponents of BIP-110, a temporary soft fork proposal that would restrict arbitrary data storage on Bitcoin, by showing that data can be stored using standard transaction structures targeted by the proposed restrictions. The transaction is publicly verifiable through any Bitcoin full node, and approximately 8.8% of the network currently runs nodes with BIP-110 support, implemented exclusively through the Bitcoin Knots client.

Developer Demonstrates Contiguous Data Storage Without Targeted Opcodes

Habovštiak, a maintainer of the Rust Bitcoin library, constructed a transaction that stores a complete TIFF image file within a single Bitcoin transaction. The image depicts Luke Dashjr, a prominent Bitcoin Knots developer and BIP-110 proponent, and can be reconstructed from the transaction’s raw hex data using standard node commands.

The demonstration is notable for avoiding the data storage methods typically targeted by proposed restrictions. The transaction contains no OP_RETURN outputs, does not utilize Taproot (using SegWit version 0 instead), and includes no OP_IF instructions. These are among the primary vectors that BIP-110 seeks to restrict.

Users can verify the demonstration independently by running bitcoin-cli getrawtransaction followed by xxd -r -p to reconstruct the image file from the transaction data.

BIP-110 Proposal Aims to Restrict Data-Carrying Transaction Fields

BIP-110, originally introduced as BIP-444 in October 2025, proposes a temporary one-year soft fork that would impose new consensus-level restrictions on transaction structures commonly used for data storage.

The proposal would cap OP_RETURN outputs at 83 bytes, limit individual data pushes to 256 bytes, restrict witness stack element sizes, and invalidate new output scripts exceeding 34 bytes. Supporters frame these measures as protecting node operators from runaway storage costs and preserving Bitcoin’s primary function as a monetary network.

The proposal was introduced following Bitcoin Core’s v30 release, which effectively removed previous OP_RETURN data limits. BIP-110 is implemented exclusively through the Bitcoin Knots client, which has seen its node count grow approximately tenfold since early 2025, now representing about 8.8% of the network.

Luke Dashjr, who maintains Bitcoin Knots and serves as CTO of Ocean mining pool, has been a vocal proponent of limiting arbitrary data on Bitcoin, characterizing inscriptions and similar data storage as “spam.”

Technical and Economic Arguments in the Data Debate

Habovštiak’s demonstration highlights fundamental distinctions in how Bitcoin processes transactions. The network operates with two layers of rules: consensus rules determining block validity, and policy rules governing what transactions nodes relay by default.

Consensus rules cannot enforce “money-only meaning” on transaction bytes. Any transaction that follows structural rules, regardless of embedded data, is consensus-valid and can be mined if it pays sufficient fees. Policy rules can create friction but cannot guarantee prevention.

The demonstration also produced a BIP-110-compliant version of the image transaction tested against Bitcoin Knots’ regtest environment. This compliant version was reportedly larger than the original, suggesting that restrictions could potentially increase total blockchain data rather than reduce it.

Even when nodes refuse to relay non-standard transactions, economic incentives create workarounds. Mining pools can accept transactions through direct submission channels that bypass the relay network. Services such as MARA’s Slipstream already provide direct submission pipelines for large or non-standard transactions that follow consensus rules but may be excluded from mempools.

At current fee rates, occupying one megabyte of blockspace costs approximately 0.1 BTC at 10 satoshis per virtual byte, rising to 1.0 BTC at 100 satoshis per virtual byte.

UTXO Bloat and Second-Order Effects

Restricting popular data storage methods can potentially backfire by pushing usage toward encodings that impose higher long-term network costs. When developers create outputs that appear spendable to carry arbitrary data, they increase the Unspent Transaction Output set, the database every full node must maintain in accessible storage.

UTXO growth represents a more persistent burden than witness data or OP_RETURN payloads, which can be pruned. An output encoding an image file remains in the UTXO set until spent, potentially indefinitely. This dynamic explains Bitcoin Core’s historical reluctance to impose harsh limits on OP_RETURN, as the alternative may increase long-term operating costs for nodes.

Governance Implications and Network Coordination

BIP-110 represents an escalation from policy-level filtering to consensus-level restriction, carrying governance implications beyond immediate technical questions. The proposal’s temporary one-year framing implicitly acknowledges that permanent solutions may not exist, only tactical management with limited effectiveness.

The demonstration arrives amid ongoing disputes between Bitcoin Core and Bitcoin Knots developer communities over data storage policies. Habovštiak stated he was motivated by what he considered “untruths” from Knots supporters regarding the impossibility of contiguous data storage without targeted opcodes. He described himself as opposed to blockchain spam but argued that the proposed restrictions are based on incorrect technical claims.

The developer indicated this was a one-time effort and that he would not publish his code, explicitly to avoid enabling a new wave of inscription activity. The Block was unable to reach Habovštiak or Dashjr for comment at the time of publication.

FAQ: Bitcoin Data Storage and BIP-110

What did the Bitcoin developer demonstrate with the embedded image?

Martin Habovštiak embedded a 66-kilobyte TIFF image in a single Bitcoin transaction without using OP_RETURN, Taproot, or OP_IF. The demonstration proves that arbitrary data can be stored contiguously on the blockchain using standard transaction structures targeted by proposed restrictions, challenging claims that such storage requires specific opcodes or features.

What is BIP-110 and what would it do?

BIP-110 is a temporary soft fork proposal that would restrict data-carrying transaction fields at the consensus level. It would cap OP_RETURN outputs at 83 bytes, limit individual data pushes to 256 bytes, restrict witness stack element sizes, and invalidate new output scripts exceeding 34 bytes. The proposal is implemented exclusively through the Bitcoin Knots client and currently has approximately 8.8% network support.

Can Bitcoin technically prevent arbitrary data storage?

Full prevention of arbitrary data storage is likely not technically feasible while maintaining Bitcoin’s consensus rules. The network validates transaction structure, not meaning, and cannot distinguish between “monetary transactions” and “data transactions.” Prevention would require either economic constraints through fee markets or consensus restrictions that carry governance risks and potential second-order effects such as UTXO bloat.