Bitcoin Ordinals Explained (And Why Bitcoiners Are Split)
An Ordinals inscription is a file stored inside the witness data of a Bitcoin transaction, attached by convention to one specific satoshi. Two ideas are stacked on top of each other: ordinal theory, which numbers individual satoshis so they can be told apart, and inscriptions, which staple arbitrary data to one of them. Neither required a change to Bitcoin's rules.
That last sentence is the whole argument in miniature. One camp reads it as proof the system is flexible enough to carry uses its designers never imagined. The other reads it as proof a limit that should have existed did not. Both camps contain people who understand the protocol very well, and dismissing either as ignorant is the fastest way to misunderstand the fight.
How does an inscription actually get on chain?
Two transactions, because Taproot script-path spends can only be made from outputs that already exist.
The commit transaction creates a Taproot output whose script tree contains the inscription. At this point nothing is visible. A block explorer shows a perfectly ordinary bc1p payment, because that is exactly what it is. The tree is hidden inside the tweaked key, which is the property that makes Taproot useful for everything else too.
The reveal transaction then spends that output using the script path. Spending by the script path means publishing the leaf you used, and the leaf is the file. The data lands in the witness, permanently, in front of everybody.
The envelope itself is the elegant part. It opens with OP_FALSE OP_IF, which is a conditional that can never be true, so the script interpreter skips everything between there and the matching OP_ENDIF. The data is inert. It occupies space and is never executed, which is what makes it storage rather than a program.
What does ordinal theory have to do with it?
Strictly speaking, nothing. They are separable ideas that shipped together.
Ordinal theory numbers every satoshi in the order it was mined, then follows it through transactions first in, first out. The first satoshi of the first input becomes the first satoshi of the first output, and so on until the inputs run out. That gives every one of the roughly two quadrillion satoshis a stable serial number.
The consequence people find strange is that some satoshis then become collectible: the first sat of a block, sats mined by Satoshi-era miners, sats from a halving block. None of this is enforced by anything. It is two or more people agreeing to treat a number as meaningful, which is a description that either sounds absurd or sounds like every collectibles market in history, depending on your priors.
Casey Rodarmor's ord software has been published since 2022, with release 0.4.0 landing on 20 January 2023. Inscriptions reached the wider Bitcoin world within weeks: by 8 February 2023 Bitcoin Optech was reporting "vigorous ongoing discussion" about a new project storing data in Taproot inputs. Development has not slowed, and version 0.27.1 was published on 29 March 2026.
Why did this become possible only after 2021?
Because of two specific limits that tapscript removed, plus one economic fact that predates it.
BIP-342 states, in the resource limits section, that "the maximum script size of 10000 bytes does not apply" to tapscript and that "the maximum non-push opcodes limit of 201 per script does not apply." Script size became bounded only by the block weight limit. The 520-byte cap on individual stack elements stayed, which is why a large inscription is split across many pushes rather than one, but that is a formatting inconvenience rather than a barrier.
The economic fact is the SegWit witness discount from 2017: witness bytes are billed at one weight unit each rather than four. Data in the witness is therefore about a quarter the price of data in a transaction output. Put those together and Taproot script-path spends became the cheapest place on Bitcoin to store bulk data.
| Method | Cost per byte | Bloats the UTXO set? | Size limit |
|---|---|---|---|
| Taproot witness (inscriptions) | 1 weight unit | No, witness data is prunable | Block weight only |
| OP_RETURN | 4 weight units | No, provably unspendable | 100,000 bytes by relay policy since Core v30 |
| Fake public keys in outputs | 4 weight units | Yes, permanently | None, and this is the problem |
| Multisig output stuffing | 4 weight units | Yes, permanently | None |
What did they do to fees?
Something genuinely dramatic, twice, and then it faded. We read these numbers straight from each block's own coinbase output rather than taking them from a chart.
On 7 May 2023, at the peak of the BRC-20 token rush, block 788695 paid its miner 6.70 BTC in fees against a subsidy of 6.25. Fee revenue exceeded the subsidy, which had essentially never happened in a sustained way before. On 20 April 2024, block 840000 combined the halving with the launch of the Runes protocol and paid 37.63 BTC in fees, against a subsidy that had just dropped to 3.125.
Then it stopped. Block 960127, mined on 29 July 2026, paid 0.0094 BTC in fees. Across twelve blocks we sampled between 20 and 29 July 2026, fees ran from 0.0070 to 0.0803 BTC, averaging about 0.025. The halving block earned its miner roughly four thousand times more in fees than a typical block does today.
Both camps cite these numbers, and both readings are defensible. Bitcoin's security budget has to migrate from the subsidy to fees before roughly 2140, and 788695 is the only real-world demonstration that a fee market can carry that load. It is also true that during those weeks ordinary payments were priced out, and that a person trying to move small amounts found the network briefly unusable. Our guide to fees and the mempool covers how to survive a period like that.
Why are Bitcoiners split?
Because the disagreement is about what Bitcoin is for, and no amount of technical clarification settles that.
The case that this is spam. Luke Dashjr, a long-time Bitcoin Core contributor, argued in December 2023 that inscriptions exploit a vulnerability: Bitcoin Core has since 2013 let node operators cap the size of extra data they relay through -datacarriersize, and inscriptions get around that cap by disguising data as program code. The position was formalised as CVE-2023-50428, published 9 December 2023, whose description reads that "datacarrier size limits can be bypassed by obfuscating data as code (e.g., with OP_FALSE OP_IF), as exploited in the wild by Inscriptions in 2022 and 2023." The underlying claim is that a limit which node operators were told they controlled turned out not to be a limit at all.
| Block | Date | Fees to miner | Subsidy then | What was happening |
|---|---|---|---|---|
| 782000 | 22 Mar 2023 | 0.3851 BTC | 6.25 BTC | Inscriptions live but still niche |
| 788695 | 7 May 2023 | 6.7007 BTC | 6.25 BTC | BRC-20 rush. Fees beat the subsidy |
| 840000 | 20 Apr 2024 | 37.6256 BTC | 3.125 BTC | Halving block, Runes launch |
| 960127 | 29 Jul 2026 | 0.0094 BTC | 3.125 BTC | An ordinary Wednesday |
The case that this is legitimate. Andrew Poelstra's response, recorded in Bitcoin Optech's newsletter in February 2023, was that "there is no effective way to prevent data storage," and that adding restrictions to prevent unwanted data in witnesses "would undermine advantages discussed during taproot's design." Push data out of witnesses and it reappears somewhere worse, most likely in outputs that every node must keep in the UTXO set forever. The stronger form of the argument: fees are the mechanism Bitcoin uses to allocate block space, inscribers paid those fees, and a transaction that follows every rule and pays the market rate is not an attack just because you dislike its contents.
Underneath both positions sits a question neither side can answer with a measurement: what is block space for? If Bitcoin is a payment network, then filling blocks with pictures is a misuse that happens to be permitted, and the right response is to make it less convenient. If Bitcoin is a neutral ledger that sells space to whoever pays, then the fee is the entire test and objecting to the contents is asking miners to become editors. Those are not competing readings of the software. They are competing readings of the project.
It is worth noticing how each side's strongest argument is uncomfortable for it. The spam camp wants a limit enforced, but any limit strong enough to work is a consensus rule, and adding consensus rules about content is the thing Bitcoin is supposed to be bad at. The legitimacy camp says the fee market decides, which is a fine principle right up until the fee market decides that ordinary payments are the marginal use and prices them out for a month, as it did in May 2023.
The CVE record itself contains the neatest summary of the standoff, in an official dispute note: "although this is a vulnerability from the perspective of the Bitcoin Knots project, some others consider it 'not a bug.'"
| Question | The spam case | The legitimacy case |
|---|---|---|
| Is it an exploit? | It bypasses a limit operators were told they had | It uses documented rules exactly as specified |
| Who decides what block space is for? | A payment network should carry payments | Whoever pays the fee. That is the mechanism |
| What about the cost to node runners? | Every node stores it forever, at their expense | Witness data is prunable. Output stuffing is not |
| What if you filter it? | Knots gives operators back the control they lost | Filtering relocates data, and usually somewhere worse |
| The fee spikes | Priced ordinary users out of their own network | The first real proof fees can replace the subsidy |
| Long term | Sets a precedent that any limit can be routed around | Demonstrates credible neutrality under pressure |
Why the OP_RETURN fight followed
The argument mutated rather than ended. Bitcoin Core 30.0, released on 10 October 2025, raised the default -datacarriersize from 83 bytes to 100,000, and permitted multiple data-carrier outputs per transaction for relay and mining. The release notes describe the new default as one that "effectively uncaps the limit," while keeping the option available for anyone who wants the old behaviour with -datacarriersize=83.
The reasoning is the Poelstra argument applied: if people are going to store data regardless, the honest response is to make the prunable, provably-unspendable route the cheapest one, rather than pretending a policy knob is a rule. The objection is that raising a limit in response to people evading it is a strange kind of surrender, and that node operators who wanted the old default now find themselves choosing between Core and Bitcoin Knots on the basis of policy rather than correctness.
Whether that change did anything is measurable, so we measured it rather than speculating.
Whatever else the policy change did, the traffic it permits is now a substantial fraction of what Bitcoin blocks contain. Both camps can read that chart as vindication, which by now should feel familiar. Data moved to the prunable, provably unspendable place instead of the permanent one, exactly as the Core reasoning predicted. It also moved in enormous volume, exactly as the critics predicted.
What this means if you just hold Bitcoin
Very little, most of the time, with three exceptions worth knowing.
Fee spikes are the real exposure. If a mania restarts, moving coins gets expensive quickly. The defence is not to hold a lot of small outputs you will need to consolidate at short notice, and to do routine housekeeping when the mempool is quiet rather than when it is not.
Do not accidentally spend a valuable satoshi. If you hold inscriptions, ordinary wallets do not know they exist and will happily spend the sat carrying one as change. This is a genuine way people have lost things, and it needs ordinals-aware software rather than care.
Your node stores it. The chain is bigger than it would otherwise be, and if you run a full node you are carrying the cost. Pruning removes the witness data you no longer need, which is precisely the asymmetry the legitimacy case rests on.
What has not happened, despite years of predictions in both directions, is anything structural. There has been no chain split over this and no consensus change to stop it. The rules that make inscriptions possible are the same rules that make multisig cheap and private, and unpicking one would unpick the other. That constraint is real, and it is why the argument keeps being had rather than settled.
The uncomfortable thought for both sides: the mechanism that allowed this is the same mechanism that guarantees nobody gets to decide what a valid Bitcoin transaction is allowed to mean. If you find that reassuring when it protects a transaction you approve of, you are stuck with it when it protects one you do not. That is not a bug in the argument. It is the argument.
Related on BTCLinks
Sources
- Ordinals documentation: Inscriptions. Source of the commit and reveal structure, the envelope script quoted in the diagram, the statement that inscriptions are stored in taproot script-path spend scripts, and the 520-byte data push limit. Verified 2026-07-29.
- BIP-342: Validation of Taproot Scripts. Source of both quoted resource-limit removals, the 10,000-byte script size limit and the 201 non-push opcode limit, and confirmation that the 520-byte stack element limit remains. Verified 2026-07-29.
- NVD: CVE-2023-50428. Published 9 December 2023, CVSS 5.3 medium. Source of the quoted description and of the dispute note about the Bitcoin Knots perspective. Verified 2026-07-29.
- Bitcoin Optech Newsletter #237, 8 February 2023. Source of the Andrew Poelstra quotes on the impossibility of preventing data storage and on undermining Taproot's design advantages. Verified 2026-07-29.
- Bitcoin Core 30.0 release notes, 10 October 2025. Source of the datacarriersize increase to 100,000 bytes, the "effectively uncaps the limit" phrasing, and the change permitting multiple OP_RETURN outputs for relay and mining. Verified 2026-07-29.
- Blockstream Esplora API. All fee figures computed from each block's coinbase transaction: block 782000 paid 0.3851 BTC, block 788695 paid 6.7007 BTC, block 840000 paid 37.6256 BTC, block 960127 paid 0.0094 BTC. Output-type counts taken from a full tally of every transaction in blocks 958807, 959407 and 960127. Collected 2026-07-29.
- ord releases. Version 0.27.1 published 29 March 2026, confirming active development. Verified 2026-07-29.
Some links are affiliate links. As an Amazon Associate we earn from qualifying purchases. Not financial advice.