Whether Bitcoin should allow arbitrary data on-chain—in other words, whether the Bitcoin ledger may store data beyond BTC transfers—is a genuinely complex question. I’ll first outline what I see as general Layer 1 (L1) design principles, then analyze what Bitcoin should do.
My general design principles for L1s (including Bitcoin):
- Consensus layer. An L1’s consensus layer provides a censorship-resistant public service. Bitcoin offers censorship-resistant “digital gold,” Ethereum offers censorship-resistant general computation, and CKB offers censorship-resistant general verification. “Censorship-resistant” and “a particular public service” are inherently in tension: the former pushes us to accept any transaction; the latter pushes us to reject transactions that don’t serve the stated public purpose. For L1s (not all blockchains), whether something serves that purpose is ultimately a matter of social consensus, so the boundary is inevitably fuzzy. Nevertheless, boundaries exist, and consensus nodes follow one set of mandatory rules and execute them in a precisely reproducible way so that results are bit-exact.
- Propagation layer. Propagation (p2p message relay) underpins consensus: any transaction must circulate widely among nodes before the majority nodes can possibly agree on it. How transaction data spreads across the network can influence—even determine—the eventual consensus outcome. Unlike consensus, propagation nodes follow some common rules but retain wide room for customization; operators can tune policies however they like as long as they don’t violate consensus rules. Strategies vary. On the question “what data should the network encourage relaying,” there may be coarse social consensus for some data and none at all for others. Either way is totally fine and the diversity can exist forever at the propagation layer.
- The propagation layer is especially important in a UTXO architecture for two reasons: (1) transactions carry post-execution state, not just pre-execution intent, make it possible for relays to implement sophisticated forwarding logic based on the state plus their own preferred policies; (2) because transactions carry composable state, relays can accept partial transactions and assemble them into complete ones—or even split complete transactions and recombine them—effectively serving as venues for transaction composition.
- Presentation layer. This is where end users perceive and interact with L1 transactions and state (block explorers, wallets, etc.). What to show end users is entirely up to each application’s context, preferences, and compliance needs. Consensus decides what exists on L1; presentation decides which slice of it end users see and how they see it.
So how should Bitcoin handle arbitrary data? Two system-level factors matter most: 1. Bitcoin is censorship-resistant digital gold; any approach must preserve that positioning. 2. Bitcoin’s economic model carries real risk: future fee revenue might not sustain miners and thus network security. The first point is uncontroversial; the second is debated. My own view is that under today’s fee model, miner revenue will be insufficient to support Bitcoin’s security and its digital-gold role. What follows is based on those two factors:
- Consensus layer. First, completely preventing arbitrary data from landing on-chain is technically impossible; this has been explained many times. Attempting to block it in consensus would only lead to a cat-and-mouse game. The act of “blocking” itself even incentivizes some users to discover ever more obscure ways to embed data on Bitcoin. This has been proved many times by innovations like colored coins, Counterparty, and Ordinals. Second, once the consensus layer admits subjective judgments about “what must be censored,” consensus loses objectivity and devolves into debates over personal preference—humans will never agree here—and L1 forfeits its status as supra-sovereign infrastructure. A major reason L1s are layer 1s is their unprecedented strong objectivity (also why L1s must use PoW). Third, finding ways to reuse Bitcoin’s security by permitting the ledger to store more general data—thus enabling uses beyond BTC issuance and transfers—can raise network revenue and help close the future security-budget gap. It may even be the only viable path, because it requires no hard or soft forks—literally, simply “do nothing.” Perhaps for the first and second reason, the community is largely aligned on this layer: don’t change consensus; remain neutral.
- The third point is supported by comparing fee revenue during and after the inscriptions boom.
- Precisely for this reason, I started considering CKB as a “Bitcoin L2” and was excited about Cipher’s RGB++ proposal. RGB++ can turn Bitcoin into a strong asset-issuance layer, while CKB, as a quantum-resistant Bitcoin L2, can provide application venues for BTC and RGB++ assets, without overloading the Bitcoin ledger or diluting Bitcoin’s core positioning. This addresses Bitcoin’s latent risks without any changes to Bitcoin itself.
- Propagation layer. The recent controversy centers on Bitcoin Core v30’s default relay-policy change proposals. Before v30, users could stash arbitrary data via
OP_RETURN, but the default relay policy allowed at most oneOP_RETURNoutput per transaction with up to 83 bytes. v30 will change the defaults: multipleOP_RETURNoutputs may be relayed, and each may carry up to 100,000 bytes. Note that v30 only changes defaults; node operators can still adjust-datacarriersize=to restore earlier limits (e.g., 83 bytes). Relay policy is not consensus; diversity and operator choice are expected. Whether Bitcoin Core v30 loosens defaults or Luke Dashjr ships a fork that keeps stricter defaults—both are legitimate actions within Bitcoin’s decentralized governance norms, each backed by its own constituency. Personally, I prefer the v30 change for the reasons above: it helps address Bitcoin’s latent sustainability issues. I respect Luke’s execution even though I disagree with his premise.- “Default relay policy” is just software configuration shipped by default, however defaults do strongly shape user choices and macro network behavior. Strictly speaking, changing defaults—like changing consensus—exercises power and ought to have explicit governance. In practice, L1 governance (Bitcoin included) is not there yet. On the other hand, defaults are far more flexible than consensus: users can override them, and if the direction is wrong, it’s easy to revert. That flexibility reduces the pressure to formalize governance around defaults.
- On-chain governance will only ever be part of L1 governance, not all of it. Because on-chain mechanisms sit atop the consensus layer, they’re poorly suited to governing changes to consensus itself (beware circular dependencies). L1 code is open-source, and L1 history is forkable; fork it and run nodes remains the ultimate dispute-resolution mechanism. A community’s governance philosophy determines whether its blockchain can truly grow into an autonomous L1.
- Presentation layer. Because presentation decisions are entirely application-defined and require no community consensus, there’s no controversy here.
As for Nick Szabo’s tweet, I disagree. I read him as arguing from real-world pressures: if Bitcoin can store arbitrary data, nodes will face mounting regulatory pressure, threatening decentralization or sustainability. But as I’ve argued, if you address this at the consensus layer, Bitcoin immediately loses neutrality and objectivity. The moment we debate what “should” be censored, Bitcoin becomes centralized—these decisions inevitably require a small committee of people. If the debate remains in the propagation layer, it fits squarely within the L1 governance framework, and even persistent disagreement is fine and the network still functions—just as people in different countries can argue indefinitely over which genders to recognize in public spaces and the Earth keeps spinning. Instead, we should educate the public about Bitcoin and L1s: like the internet, they are neutral infrastructure. Any filtering belongs in the presentation or propagation layers, chosen by applications and nodes.
Separately, I don’t read Nick as endorsing Bitcoin Knots; I read him as worried that, if Bitcoin Core mishandles this, users will migrate to Knots—a client with more subjective, censorious rules. Where we differ is on the remedy: to avoid that outcome, the Bitcoin community should do a better job explaining why Bitcoin should allow data beyond BTC transfers and where any necessary filtering should occur, rather than rolling back the change, or adding more data-censorship (bad for long-term sustainability), just to quiet the controversy.
ps. It should be obvious my definition of “L1” are more stricter than most, and when I say “L1” I mean it by my definition. I recognize very few blockchains as L1s.