A single parameter, a permanent rule, and what the network already knows how to do.
The first article in this series named a problem. This one names the fix.
The Landauer attack.[1] Non-monetary data — inscriptions, BRC-20 tokens, Taproot annex abuse, witness-data stuffing — pays a one-time fee for inclusion in a block and then externalizes the persistence cost onto every full node, forever. The attack exploits the one feature that makes Bitcoin trustworthy: its irreversibility. The network is being asked to remember what it was never paid to hold.
The article named BIP-110 as the right intervention at the right time.[2] It closes the most exploited holes, and it does so with a deliberately minimal rule set. It is also explicitly temporary — a one-year emergency brake. The structural rule BIP-110 implies, the rule that would make the attack economically non-viable rather than merely blocked at known vectors, has not yet been written. This article is an attempt to write it.
The proposal is a single new consensus parameter and a single new consensus rule. It prices memory against value at the protocol level. It is permanent. It is inline with the framework the paper establishes for what Bitcoin is and what it costs.
Every block in Bitcoin pays for itself — by the freshly-minted subsidy the miner earns, or by the fees attached to the transactions inside. The M-Bound says the payment has to cover the bytes the block adds to the chain. A block that carries more bytes than its payment can back is invalid.
Stated formally. For every block at height t, define:
The rule. A block is valid if and only if M(t) ≤ Mmax.
Equivalently: every byte of consensus memory must be backed by at least 1/Mmax satoshi of inscribed value. The block is a thermodynamic event; this rule is its balance sheet.
What this looks like across real history. The empirical M(t) = τt / Wt for every block in a Mass-Value Bound dataset (output of compute_m_max.py). The red Mmax(h) step function is the rule; points above the line would be rejected:
Four parameters are involved. Three of them are not new. τt is the block's serialized size, a quantity the protocol already computes on every block. St is the subsidy, a fixed function of block height. Ft is the sum of fees, already aggregated in the coinbase. The only new piece of state is the function Mmax(h), and that is the only thing the network has to agree on — and it is not a choice: it is a function of the halving schedule and the existing 1 MB cap.
The M-Bound is a single new check in the block-acceptance path. It can be added to Bitcoin Core's validation in well under fifty lines of code. It is consensus-enforced: a block that violates the rule is rejected by every validating node, regardless of who mined it, regardless of how high the fees are, regardless of which soft fork the miner is signaling for.
Bitcoin halves the subsidy every four years. The M-Bound's per-satoshi byte budget doubles in step; the 1 MB cap that subsidy alone can back stays constant. Fees raise the cap above 1 MB — they do not change the per-satoshi ratio. Here is the schedule.
The M-Bound is fully determined by the halving schedule. Mmax(h) = 1,000,000 / subsidy_sats(h) is a derived, height-dependent ratio — see The source of the cap below. The bound is τ ≤ Mmax(h) · (S + F) — value from subsidy or from fees, the rule does not care which. The table below shows the per-halving Mmax(h) ratio and the subsidy contribution to the bound (the subsidy-backed ceiling, Mmax(h) · S = 1,000,000 bytes). The subsidy-backed ceiling is constant at 1 MB across every halving epoch; what doubles each halving is the per-satoshi budget the rule permits.
| Epoch | Subsidy (BTC) | Mmax(h) (B/sat) | Subsidy-backed ceiling |
|---|---|---|---|
| Post-2024 (current) | 3.125 | 0.0032 | 1 MB |
| Next halving (~2028) | 1.5625 | 0.0064 | 1 MB |
| ~2032 | 0.78125 | 0.0128 | 1 MB |
| ~2036 | 0.390625 | 0.0256 | 1 MB |
| Terminal | 0 | ∞ (F-only) | 0 (F backs every byte) |
What doubles every four years is the per-satoshi budget of the rule. The total bound — Mmax · (S + F) — is unchanged by the halving. This is the structural feature: the rule is subsidy-and-fee-agnostic. It will read the same in the current era, in every halving epoch, and in the terminal era when S = 0. As long as the bytes in the block are paid for — by subsidy, by fees, or by both — the block is valid. What must grow, if throughput is to be maintained, is the fee market; what must not grow, is the persistence cost externalized onto every full node. The M-Bound is the cooling curve of the paper made into a consensus rule, and the cooling curve works whether the value comes from issuance or from fees.
Calibration against history. The table in The source of the cap below shows the empirical M(t) maximum per halving epoch, derived from the mass-value-bound-951k.json.gz dataset. The picture is sharp. Pre-SegWit, the rule held exactly: the largest 2012–2016 block touched the cap at 1.00× Mmax, and the largest 2009–2012 block sat at 0.50× Mmax. Satoshi's 1 MB raw-byte cap was already enforcing the M-Bound; the rule was implicit. Post-SegWit (2017), the rule was progressively violated: 2016–2020 reached 2.40× Mmax, 2020–2024 reached 3.99× Mmax, and the current 2024–2028 era has reached 3.98× Mmax. The witness discount in SegWit allowed raw block bytes to exceed the vbyte cap; the inscription era (2022+) pushed the violation to its current factor. The M-Bound, made explicit, would have rejected every one of those over-cap blocks. The pre-SegWit chain is exactly as it should be; the post-SegWit chain is exactly the attack the M-Bound is designed to make non-viable.
The M-Bound is not a new parameter. The cap Mmax(h) = 1 MB / subsidy_sats(h) is already in Bitcoin's source code, written two different ways. Once you see where, the rule stops being a proposal and becomes a recovery of what the protocol already implied.
Two derivations, both valid, both producing the same number:
Identical formula. Identical number. Different citation. The legacy 1 MB cap and the post-SegWit witness-discounted weight cap both resolve to 1,000,000 vbytes per subsidy-honored block. The M-Bound is the explicit version of what the protocol already implies.
Empirical confirmation from the pre-2016 era: at h=349755, subsidy = 25 BTC = 2.5×109 sats, giving Mmax = 0.0004 bytes/sat. The observed pre-2016 maximum is M = 0.000399, matching the derivation to four significant figures. The protocol was already enforcing this rule; SegWit's witness discount did not change the vbyte accounting, so the implicit cap survived.
Empirical check across every halving epoch, drawn from the 951k-block dataset. Each row shows the subsidy, the derived Mmax, and the largest block the chain actually produced against the cap.
| Era | Subsidy (BTC) | Mmax(h) (bytes/sat) | Empirical max M(t) |
|---|---|---|---|
| 2009–2012 | 50 | 0.0002 | 0.000100 (0.50×, under) |
| 2012–2016 | 25 | 0.0004 | 0.000400 (1.00×, at the cap) ✓ |
| 2016–2020 | 12.5 | 0.0008 | 0.001920 (2.40×, over) |
| 2020–2024 | 6.25 | 0.0016 | 0.006379 (3.99×, over) |
| 2024–2028 (current) | 3.125 | 0.0032 | 0.012735 (3.98×, over) |
The picture is sharp. The 2012–2016 row is the saturation case: the largest pre-SegWit block touched the cap exactly. The 2009–2012 row ran at half the cap (the early chain was small). The 2016–2020, 2020–2024, and 2024–2028 rows violate the derivation, and the violation grows: the M-Bound was real, the protocol enforced it pre-SegWit, and the witness discount in SegWit (2017) plus the inscription era (2022+) have made the rule progressively more violated. The M-Bound, made explicit, would have rejected every one of those over-cap blocks. Empirical data: mass-value-bound-951k.json.gz.
The first article focused on inscriptions and BRC-20 tokens because they are the most visible current instance of the Landauer attack. They are not the only vector. The M-Bound's strength is that it handles all of them by the same mechanism — a byte of block memory is a byte, whether it lives in a witness push, a script tree, a covenant, or a future opcode the protocol hasn't named yet.
Twelve known vectors surveyed against the M-Bound. The rule's response is identical in every case: back the byte with a satoshi of value, or it doesn't enter the block.
| Vector | Mechanism | How the M-Bound handles it |
|---|---|---|
| Inscriptions / BRC-20 | Witness data stuffing | Every witness byte must be backed by a satoshi of value (subsidy or fees). Inscriptions, which minimize fees, fit only as much witness data as the bound allows. |
| Taproot annex | Currently undefined, unlimited data field | Annex bytes are block bytes. Priced at the same rate as everything else. |
| BitVM / BitVM2 | Large Taproot trees with many script leaves; control blocks carry the merkle path | Each control block byte is a block byte. Each script in the tree contributes. The marginal cost scales with tree size. |
| Sidechain headers | Periodic header commitments on-chain (Liquid, Rootstock, etc.) | Headers are small (~80 bytes). Trivially passes the rule. |
| Validity rollups / state commitments | 32-byte state roots posted on-chain; verification off-chain | Trivially passes. |
| Drivechains (BIP-300/301) | Hash-rate escrows and withdrawal transactions | Each withdrawal is a normal transaction. Priced. |
| OP_CAT covenants (proposed) | Recursive covenants with potentially large script sizes | Bytes are bytes. Priced. |
| "Bitstream" / permissionless data uses | Speculative future applications that use Bitcoin as a data layer | Priced. The marginal cost of persistence is what the rule guarantees. |
| Block-weight manipulation via witness discount | Discount on witness bytes in block-weight calculation | The rule uses raw bytes, not weight. The discount does not help. |
| Dust attacks (UTXO bloat) | Many small-value outputs in a block | Dust-heavy blocks have high M(t) because the value moved is small while the bytes are large. Priced. |
| Multi-block inscription split | Spread a single image across many small blocks | Each block must independently satisfy the rule. The attacker pays the per-block data tax N times. Marginal but real. |
The honest list: the M-Bound handles all known vectors economically. The one residual exposure is the multi-block split, which the rule addresses by raising the attacker's marginal cost to N times the per-block data tax. This is not a complete defense — an attacker willing to pay the marginal cost can still split — but it makes the attack proportional to the data stored, which is the correct economic signal. The structural backstop is the per-block rule; future rules can address the edge cases.
Other defenses exist. Each handles part of the problem. None of them is structural — none of them prices memory against value at the protocol level. The M-Bound is not a replacement; it is the layer they were all missing.
A brief survey of the alternatives, and what each one leaves uncovered.
| Defense | Mechanism | Why insufficient |
|---|---|---|
| BIP-110 | Targeted limits on specific data fields (scriptPubKey ≤ 34B, witness pushes ≤ 256B, annex invalid, etc.) | Temporary. Reactive. New opcodes reopen the holes. Patches the latest exploits; doesn't change the underlying accounting. |
| UTXO expiry / storage rent | Periodic rent on UTXOs; abandoned UTXOs are pruned | Prices UTXO state, not block memory. Doesn't address block-weight bloat. A complementary defense, not a substitute. |
| Hard cap on witness bytes per block | witness_bytes ≤ X (a fixed number, not a function of value) | Same form as BIP-110's witness-push limit, but at the block level. Still a byte cap, not a value cap. Self-tightens with subsidy only by accident. |
| Fee market redesign | Two-tier fee market (data fees vs. monetary fees) | Complex. Hard to enforce without consensus changes of similar scope to the M-Bound. May be a future refinement inside the M-Bound framework. |
| Block validation cost cap | Limit the time or memory required to validate a block | Already implicit in consensus rules. Doesn't price persistence — it limits processing cost. Different problem. |
| Per-output size limits | Limit script size, witness size, etc. | Helps with UTXO set bloat, not block weight. Complementary. |
| M-Bound | Mass-to-value ratio capped at consensus level | None — it is the structural rule. New attack vectors are auto-covered because the rule applies to all bytes of all blocks. |
The M-Bound does not displace the other defenses; it completes them. BIP-110 closes known holes today; the M-Bound is the structural backstop that makes new holes non-viable. UTXO rent prices the state that persists; the M-Bound prices the bytes that get there. The two are different objects of accounting, and Bitcoin needs both.
Without the rule, the chart breaks at 2022. With the rule, the break doesn't happen. Here is what the chart looks like in each era when the M-Bound is active.
The shape described below is the empirical reality — see the live chart in The M-Bound above, where you can load any Mass-Value Bound dataset and inspect the per-block M(t) distribution directly.
Under the M-Bound, the post-2022 structural break in the chart described in the first article becomes impossible. A block whose mass-to-value ratio exceeds Mmax(h) is invalid; the bytes cannot be committed to the ledger regardless of how much the miner is willing to forgo in fees to include them. At current subsidy (3.125 BTC), Mmax = 0.0032 bytes/sat; an inscription block of 3 MB with negligible fees gives M ≈ 0.0096 and is rejected.
The projected shape of the chart, with the rule active:
Pre-2022: unchanged. Blocks were well below the cap. The halving-stepped rise of bytes-per-value continues as before, monotonic and predictable.
2022: the structural break that the first article identifies does not occur. Inscription blocks that would have pushed M(t) to 0.05 or 0.1 bytes/sat are rejected. The witness data either pays for itself in fees, or it does not get into a block.
Post-2022 onward: the curve continues to track the halving schedule, but the subsidy contribution to the bound halves each halving. The total bound — Mmax · (S + F) — is unchanged. If the network wants more throughput than subsidy alone covers, fees must rise. If not, throughput falls. The rule does not pick which; it only requires that whatever bytes are committed are paid for, by subsidy or by fees. The cooling curve, which the paper describes as a soft expectation under the natural fee-market response, becomes a hard consensus rule on the mass-to-value ratio.
This is what a structural solution looks like. It does not require a new opcode, a new soft fork per attack vector, or a permanent emergency-brake mentality. It requires one parameter and one check.
The paper expects Bitcoin to cool over time — subsidy falls, fees rise, the system holds its temperature. The expectation is soft: an efficient fee market would do it. The M-Bound makes the expectation hard: a consensus rule that the fee market must satisfy, not merely trend toward.
The paper describes a cooling curve:[3] as block subsidy falls, the fee market is expected to rise in compensation. The block temperature — the ratio of new value inscribed to cumulative supply — is bounded between zero and one, and the system is expected to maintain thermodynamic participation as the subsidy term in the numerator falls toward zero.
The cooling curve is a soft expectation. It is what an efficient fee market would produce. The protocol does not enforce it. If fees do not rise as subsidy falls, the block temperature falls with them, and the system's thermodynamic participation degrades.
The M-Bound is structurally related to the cooling curve but not identical to it. It does not enforce block temperature. It enforces the mass-to-value bound τ ≤ Mmax · (S + F), where value can come from subsidy or from fees. As subsidy falls, fees are the only remaining source. Throughput is preserved if and only if fees rise to compensate. The cooling curve is one of two possible outcomes: either fees rise to maintain throughput, or throughput falls to match the falling subsidy. The rule does not pick which — it remains satisfied either way. It only requires that whatever bytes are committed are paid for, by subsidy or by fees, in the current era, in every halving epoch, and in the terminal era when S = 0.
This is the same architecture, expressed at a different layer. The paper describes the curve as a thermodynamic regularity. The M-Bound translates it into a consensus rule.
The M-Bound does not extend the paper. It realizes it. Six sections of the paper each imply a rule the M-Bound makes explicit. The mapping is short.
The M-Bound is not an external proposal grafted onto the paper's framework. It is a direct realization of claims the paper already makes. A section-by-section mapping:
§1.0 Absolute Boundedness. The paper begins by requiring that every quantity in the system be bounded.[4] The M-Bound adds boundedness to the mass-to-value ratio — the quantity the first article identifies as currently unbounded. This completes the boundedness of the system: bounded supply, bounded block time, bounded memory surface.
§2.1 The satoshi as memory. The paper states: "a satoshi is a minimal claim on memory. To exist, a satoshi must be encoded somewhere in the UTXO set; it must occupy real bytes in Bitcoin's finite state."[5] This is the forward direction: a satoshi → occupies bytes. The M-Bound is the converse: a byte of consensus memory → must be backed by satoshis. The two together form a symmetric correspondence between the value domain and the memory domain.
§2.3 The 1:1 peg. The paper's mapping W · ε(232 · D) → Mt+1 explicitly couples work (D, the difficulty) to memory (M, the new state).[6] The M-Bound extends this coupling: the inscribed value (W) also bounds the physical memory (τ). Every byte of memory now has a thermodynamic anchor in the value-mass, paid at the protocol level.
§7.3 The cooling curve. Already discussed. The M-Bound is the mass-to-value requirement that the cooling curve assumes, made into a consensus rule.
§7.6 Satoshi's Constant. The paper derives ε(t) = EP / C(t), the joules-per-satoshi invariant.[7] The M-Bound is the consensus-level realization of this invariant: every byte of the block's τt has a joule cost, paid in satoshis, enforced at the rule level rather than merely observed in the data.
§7.10 The conservation identity. The paper's identity ΔUblock = Tblock · Hblock couples work to memory to information.[8] The M-Bound realizes the temperature term Tblock = Wt/Ct as a consensus-bounded quantity: the value inscribed in the block bounds the memory it can carry. The conservation identity stops being a measurement; it becomes a rule.
The paper observes a thermodynamic regularity. The M-Bound is the consensus rule that makes the regularity binding.
BIP-110 is the emergency brake. The M-Bound is the road it was installed on. They are not in conflict, not redundant, and not alternatives. They compose.
BIP-110 closes specific, known holes: large scriptPubKeys, oversized witness pushes, the Taproot annex, OP_SUCCESS opcodes, OP_IF/OP_NOTIF in Tapscript. These are the vectors that the Landauer attack has actually used, today, in 2026. The rules are deliberately simple, deliberately minimal, deliberately temporary. The author of BIP-110 is explicit about the tradeoffs: one year, max activation height, no permanent design, no claim of completeness.
BIP-110 closes specific, known holes: large scriptPubKeys, oversized witness pushes, the Taproot annex, OP_SUCCESS opcodes, OP_IF/OP_NOTIF in Tapscript. These are the vectors that the Landauer attack has actually used, today, in 2026. The rules are deliberately simple, deliberately minimal, deliberately temporary. The author of BIP-110 is explicit about the tradeoffs: one year, max activation height, no permanent design, no claim of completeness.
The M-Bound is the permanent design BIP-110 declines to make. It is not a patch; it is a structural rule. It does not name specific attack vectors; it prices memory against value. New vectors — new opcodes, new covenant primitives, new uses of Bitcoin as a data layer — are auto-covered because the rule applies to all bytes of all blocks.
Both should activate. BIP-110 first, because the holes are open and the cost of waiting is real. The M-Bound alongside or shortly after, because the structural rule is the long-term answer. They compose: BIP-110 removes the immediate vectors; the M-Bound ensures the vectors stay removed. Once the M-Bound is active, BIP-110 can be allowed to expire; the structural rule subsumes its work.
The M-Bound is a single new check in the block-acceptance path, derived from existing consensus constants. The cap (Mmax) is not a new parameter; it is a function of MAX_BLOCK_SERIALIZED_SIZE (or equivalently, MAX_BLOCK_WEIGHT / WITNESS_SCALE_FACTOR) and the halving schedule. The rule is permanent. It is inline with the paper. It is the structural rule BIP-110 implies.
The work to write it up as a formal BIP is small. The work to implement it in Bitcoin Core is small. The work to specify the rule — the only thing the network has to agree on — is the choice of citation: MAX_BLOCK_SERIALIZED_SIZE (pre-SegWit) or MAX_BLOCK_WEIGHT / WITNESS_SCALE_FACTOR (post-SegWit). Both resolve to 1,000,000 vbytes per subsidy-honored block; both recover the implicit M-Bound that the protocol already enforced. The work to deploy it as a soft fork is the same machinery BIP-110 itself uses, and BIP-110 is already on the path to activation.
The first article in this series closed: BIP-110 is a year. What is owed is a permanent rule.
The permanent rule is the M-Bound. The network already has the means to deploy it. The cost of deploying it is small. The cost of not deploying it is the continued externalization of the Landauer attack onto every node operator in existence.
What is owed is one parameter, one rule, one deployment.