The Achievable Floor: What Consensus Can and Cannot Close on Arbitrary Data

Contents

• I. Framing the Problem
• II. Taxonomy of Channels by Cost
• III. What Consensus Can Actually Close
• IV. Why the Free Channels Resist Closure
• V. Custody of Data That Already Exists
• VI. The Actual Floor
• VII. Implementation Path
• VIII. Conclusion

I. Framing the Problem

Bitcoin spam debate blurs two layers. Consensus forces every validating node to accept whatever is in a valid block, monkey jpegs included. Relay and storage are policy. No node must relay a transaction before confirmation, and no node must keep storing everything after validation. Pruning exists because storage is optional.

Pruning costs self-sovereignty. A pruned node cannot re-verify the full chain from its own copy without asking another node.

Refusing to relay is not banning. A transaction that pays enough fee reaches the chain through some miner or permissive node, whatever one operator's mempool policy says. Policy limits on OP_RETURN and similar fields can be raised, lowered, or dropped by whoever runs the defaults. Consensus caps bind every participant or fail to activate.

The fight is usually about consensus capture, forking risk, and who decides which use cases are legitimate. For OP_RETURN, BIP-110, and data-embedding politics, see Who Controls Bitcoin, §V and Argument Map, Parts VI–VII.

Set politics aside. If consensus could change freely, how low can arbitrary data be pushed, and where is the hard limit?

II. Taxonomy of Channels by Cost

Data reaches the chain through channels that vary widely in cost. Fee per vbyte is only part of it. Operators can also filter or refuse to relay a channel, which is a business risk separate from fee math. Rollups posting data availability to the base layer are the current example.

The ladder below is technical cost only.

Figure: Channel cost ladder. Consensus can close the top tiers without touching monetary fields.

Free channels cost nothing beyond the transaction fee.

The main one is any field that holds a hash rather than the preimage, such as P2PKH or P2WPKH destinations, HTLC preimage commitments, and P2SH or P2WSH script hashes. A fake 20 or 32 byte string looks the same as a real hash. Pay-to-Fake-Key and Pay-to-Fake-Multisig predate OP_RETURN. The 2010 WikiLeaks Cablegate dump used this method.

Inviscription chunks ciphertext into hash locks, multisig pubkey slots, or CLTV values. The key may appear in a later transaction or never on-chain.

Output amounts are free too. Consensus cannot tell whether a chosen value encodes data or is just a payment. Published attacks use matrix decomposition on amounts to raise embedding rate.

Structural fields add more. nSequence carries four bytes in the disable-flag range; nLockTime four more under the same condition; input and output order is unconstrained. Closing any of these means dictating how people structure valid transactions. The same trade as amounts is worse usability, not a spam fix.

Near-free channels cost a bounded number of trial attempts.

Taproot's 32 byte x-only pubkey field is the standard example. Roughly half of all 32 byte strings are valid x-coordinates on secp256k1. A chosen payload embedded as a fake pubkey takes about two attempts on average.

The same property applies across ordinary address fields. Published blockchain measurements put achievable scale in the hundreds of kilobytes.

Expensive channels scale as two to the power of the number of chosen bits. Grinding a private key or signature nonce until the result hits a target pattern is the same math as vanity addresses, pointed at arbitrary targets.

Unenforced channels have no content validation today.

Undefined witness versions and OP_SUCCESS opcodes are upgrade hooks. Consensus treats anything after an OP_SUCCESS byte in Tapscript as valid regardless of content. The Taproot annex is a witness element excluded from the signature hash, with no constraint on its contents. Data there need not look like a hash or pubkey.

Dedicated channels carry no monetary function, or hold large uninterpreted script data.

OP_RETURN is an output with no spending condition. Core v30 relay policy allows up to 100,000 bytes of aggregate OP_RETURN scriptPubKey per transaction, with multiple outputs, while consensus places no byte cap. The Taproot envelope pushes data inside an OP_FALSE OP_IF branch that never executes. SegWit's witness discount and Taproot's removal of the 10,000 byte tapscript ceiling made large envelope payloads practical.

III. What Consensus Can Actually Close

Dedicated and unenforced channels can close at consensus. Neither carries monetary function Bitcoin needs.

A consensus hard cap on OP_RETURN closes bulk dedicated-data outputs and binds every participant. Policy limits bind only operators who choose to run them.

Cap data in non-executing script branches, including the OP_FALSE OP_IF envelope, without touching legitimate large witness use. Multisig, Lightning, and covenant scripts do not hide logic in branches that never run.

Restrict witness versions, disallow or cap the annex, cap control block size.

A dynamic minimum output value tied to fee rate prices output count when bytes inside each output are nearly free to embed.

Higher baseline fees make every measure bite harder.

Figure: §III closes OP_RETURN, envelope, annex, control block, and min-output channels. §IV fields cannot.

IV. Why the Free Channels Resist Closure

You cannot close free or near-free channels without breaking payments or barely raising cost.

Curve-membership checks on pubkey fields fail for the same reason. Near-free grinding means a validity filter blocks almost nothing.

Requiring the real pubkey, or a zero-knowledge proof of one, at output creation closes hash-based channels but ends hash-then-reveal privacy for every user. P2PKH and P2WPKH withhold the pubkey until spend time in case discrete log breaks. Bad trade for a spam fix.

The zero-knowledge variant keeps privacy but still fails. Grind a real keypair until its hash encodes a payload, and add SNARK verification to every payment.

The amount channel costs the attacker nothing. Sequence numbers, locktimes, and input or output ordering are the same.

Canonical denomination removes low-order bits, not the channel. The attacker still picks which multiple. Across 21 million bitcoin, coarsening still leaves tens of bits per output at the cost of payment precision for every user.

Canonical ordering or fixed sequence and locktime values run into the same limit. There is no single correct value, only a range. One mandated choice breaks ordinary wallet use.

Homomorphic amount commitments, as in Liquid and Mimblewimble, hide amounts but kill supply auditability.

Inscriptions, BRC-20, and Rune issuance pay fees and look like ordinary payments at consensus. Users will pay to keep using them. Politics gets harder; the channels stay open.

Bitcoin was built for payments, not token registries, inscriptions, or bulk data availability. The free fields exist because payments need them.

V. Custody of Data That Already Exists

Sections I–IV are about new data. Storage for data already on chain is a separate problem.

Fake hash outputs stay in the UTXO set until spent. Without the preimage, no one knows whether an output will ever move. Inscription outputs already dominate UTXO count with almost no monetary value.

UTXO set commitments let a node hold a root hash and verify spends through inclusion proofs the spender supplies. Every node no longer carries the full set; only spenders who need to prove ownership do. Utreexo is one design. A consensus-committed root in the block header removes dependence on bridge nodes.

Selective sync applies the same idea to bootstrap. Validate from headers, proof of work, and a UTXO commitment, without full historical witness data.

Some production designs resolve the root through peer consensus rather than a consensus-committed value. That requires trusting a sampled peer majority.

VI. The Actual Floor

OP_RETURN, the Taproot envelope, undefined witness versions, and the annex can close at consensus. Payments do not need them.

Dedicated and witness-discounted channels drove bandwidth. What remains is built into payment design. That is hash fields, amounts, sequence, locktime, and ordering. Close those and you lose hash-then-reveal privacy, satoshi precision, or supply auditability. UTXO commitments fix storage for old data; they do not stop new embedding.

Hidden data capacity is structural. In Bitcoin the carrying fields are security requirements.

Cost per embedded byte

Structural arithmetic on §II channel sizes, BIP141 accounting, and Core v30 relay defaults. Not chain measurements.

Payload density. Core v30 defaults -datacarriersize to 100,000 bytes of aggregate OP_RETURN scriptPubKey per transaction. Consensus imposes no byte cap. Both dedicated rows use 1,024 bytes of payload. The per-transaction vsize limit binds before the datacarrier limit. The hash row uses 20 bytes per fake P2WPKH output; the near-free row uses 32 bytes per fake P2TR pubkey (§II).

Witness discount (BIP141). Witness bytes count one weight unit; non-witness four. Envelope payload sits in witness. Hash and pubkey payloads in scriptPubKey are non-witness and cost four times the vbyte rate per embedded byte.

Marginal vbytes. An OP_RETURN with a 1,024-byte push is 1,039 vbytes (8-byte value, 3-byte varint, 1,028-byte script). P2WPKH with a 20-byte fake hash is 31 vbytes. P2TR with a 32-byte fake pubkey is 43 vbytes. Envelope at 1,024 witness payload bytes is 43 vbytes of output plus 256 vbytes of witness (wrapper and spend overhead omitted; full minimal spend ≈377 vbytes).

§III floor. Dust defaults at 3 sat/vbyte (DUST_RELAY_TX_FEE = 3000 sat/kvB) are 294 sat for P2WPKH-shaped outputs and 330 sat for P2TR-shaped. OP_RETURN outputs are zero-value and omitted. Dedicated rows show fee cost only; hash and pubkey rows add the dust floor because embedding mints spendable-looking outputs.

Closing dedicated channels does not make embedding cheaper. It removes witness-discounted envelopes and bulk OP_RETURN, and forces data into hash and pubkey outputs with a dust floor on each. At every fee rate in the table, hash and pubkey rows cost more per byte than OP_RETURN at 1,024 bytes.

Policy and fees still matter. Consensus can close high-bandwidth channels and lift per-node storage load. Zero arbitrary data means stripping payment properties Bitcoin needs. The realistic goal is to keep non-monetary use costly and unwelcome.

VII. Implementation Path

The OP_RETURN cap and envelope push cap are straightforward. They subtract from valid transaction shapes. Witness version, annex, and control block caps need language for reopening a version or redefining a placeholder later. The dynamic minimum output value needs a fee-rate reference and update cadence; static dust thresholds already run as policy on several implementations.

UTXO commitments and selective sync are more involved, mainly on trust model tightening.

Each §III measure can soft-fork independently or together. Selective sync waits on commitments. Grandfather outputs that would fail a new rule.

Policy tools (mempool heuristics, envelope detection, pool multipliers) stay useful and non-binding. Enough fee still reaches a miner that does not enforce them. Only consensus binds everyone.

VIII. Conclusion

Even if consensus could change without a political fight, arbitrary data cannot reach zero. Payments still need hash addresses, flexible amounts, and auditable supply.

Off-chain data and unrevealed Taproot leaves are out of scope.

The §III caps belong in a formal spec. The Bitcoin Commons consensus spec is the reference.