Ordinals and Inscriptions

Every previous chapter has treated satoshis as interchangeable. A sat is a sat—1/100,000,000 of a bitcoin, fungible by design. Ordinal theory upends this assumption: by assigning a unique serial number to every satoshi ever mined and tracking transfers via a deterministic first-in-first-out rule, it turns each sat into a distinct, identifiable object.

Inscriptions build on this foundation. Using a Taproot script-path spend (Chapter 13), arbitrary data—images, text, HTML, even programs—can be embedded in the witness of a reveal transaction. The inscription is permanently bound to a specific sat, which can then be transferred, sold, or held like any other UTXO.

This chapter examines both the numbering scheme and the transaction anatomy that makes inscriptions possible.^†

19.1Ordinal Theory: Numbering Every Sat

19.1.1The Assignment Algorithm

Every sat receives a serial number based on the order in which it is mined. The whole algorithm is two short functions — together they answer "given a block height, what are the ordinal numbers of the sats that block minted?" The algorithm is purely interpretive: no consensus rule changes, no extra bytes on chain, no new transaction field. Any node can recompute every ordinal from chain history.

# ── Constants ──────────────────────────────────────────────────────
SATS_PER_BTC     = 100_000_000        # 1 BTC = 10^8 sats
HALVING_INTERVAL = 210_000            # blocks per halving epoch (~4 yrs)
INITIAL_SUBSIDY  = 50 * SATS_PER_BTC  # 5,000,000,000 sats (block 0's reward)

# ── 1. How many sats does block <height> mint? ────────────────────
def subsidy(height):
    halvings = height // HALVING_INTERVAL    # 0 in epoch 0, 1 in epoch 1, ...
    return INITIAL_SUBSIDY >> halvings         # halve `halvings` times (>> 1 ≡ ÷ 2)

# ── 2. What ordinal is the FIRST sat of block <height>? ───────────
def first_ordinal(height):
    total = 0
    for h in range(height):       # sum every prior block's reward
        total += subsidy(h)
    return total                    # picks up where block (height-1) left off

That's it. Five active lines once you strip the comments. Let's actually run it on real heights so the abstraction stops being abstract:

The same data, grouped by halving epoch:

19.1.2Transfer: First-In-First-Out

Once a sat exists, where it ends up after a transaction is also fully determined by a simple rule: FIFO. Stack all the input sats in order (input 0's sats first, then input 1's, then input 2's…), then pour them into the outputs in order until each output is full. Any sats left over after every output is full constitute the fee and are claimed by the miner via the block's coinbase transaction.

Color key: input 0 sats came from input 0 (ordinals 1000–1099); input 1 sats came from input 1 (ordinals 2000–2049). Same color = same source — at a glance you can see which input contributed which slice of each output.

19.1.3Rarity

Bitcoin's periodic events create natural rarity tiers:

A cycle is the period between conjunctions of a halving and a difficulty adjustment (\(6 \times 210,000 = 1,260,000\) blocks, 24 years). The first conjunction has not yet occurred.

19.2The Inscription Envelope

Inscriptions embed data inside a Taproot witness script using a construct called an envelope: an OP_FALSE OP_IF block that is syntactically valid but never executed.

Key design properties:

• No-op semantics. OP_FALSE OP_IF … OP_ENDIF is never entered during script execution. The envelope does not affect the spending condition—it can be combined with any locking script.
• The "ord" marker. The 3-byte string 0x6f7264 (ASCII "ord") disambiguates inscriptions from other uses of envelopes.
• Field tags. Tag 1 = content type (MIME), tag 2 = pointer, tag 3 = parent, tag 5 = metadata, tag 7 = metaprotocol, tag 9 = content encoding, tag 11 (0x0b) = delegate (inscription inherits its content from another inscription). Tag 0 signals the start of the body. Odd-numbered tags are unrecognized-safe; see the Ordinals specification for the full registry.
• 520-byte push limit. Taproot's only restriction on data pushes is that each individual push cannot exceed 520 bytes. Large inscriptions split their content across multiple pushes within the envelope.

19.3The Commit/Reveal Pattern

Inscriptions require a two-phase process because Taproot script-path spends can only be made from existing Taproot outputs. You cannot create and spend a Taproot output in the same transaction.

19.3.1Phase 1: Commit

The commit transaction creates a P2TR output whose internal key or script tree commits to the inscription content. From the outside, this looks like an ordinary Taproot output—nothing reveals the inscription until the output is spent.

19.3.2Phase 2: Reveal

The reveal transaction spends the commit output via script-path (Chapter 13). The witness contains:

1. A signature satisfying the script's spending condition.
2. The tapscript containing the envelope (the full inscription data).
3. The control block (parity byte + internal public key + Merkle proof).

The inscription content becomes visible on-chain only in the reveal transaction's witness—permanently recorded in the blockchain.

19.4Specimen: Inscription #0

The very first Ordinals inscription — a 100×100 pixel skull image — was inscribed by Casey Rodarmor on December 14, 2022 at 20:32 UTC in block 767,430. Two transactions in two blocks: a commit that creates a P2TR output, then a reveal that spends it script-path with the inscription embedded in the witness.

Below is the full reveal-transaction hex — hover any byte for a field tooltip:

The bulk of those 1,040 bytes is a single witness element — the tapscript, witness item 1, which carries both the spending condition and the inscription. Below is its anatomy.

19.4.1The Witness: Three Items

19.4.2Tapscript Anatomy — Color-Coded

The 853-byte tapscript splits into seven distinct regions. Each row below shows the actual hex from this specimen, the opcode interpretation, byte count, and purpose:

Color key: spending condition · envelope no-op · protocol marker · content-type tag · body separator · payload

19.4.3Reading PNG Out of the Witness

Once you have the reveal txid, the procedure to recover the inscribed image from on-chain bytes alone is:

1. Fetch the reveal transaction 6fb976ab…2799 via any of the routes above (bitcoin-cli getrawtransaction, mempool.space, Esplora).
2. Take witness item 1 (the tapscript), 853 bytes.
3. Skip the first 34 bytes (spending condition).
4. Skip 00 63 (envelope open).
5. Skip 03 6f 72 64 (the "ord" marker).
6. Skip 01 01 09 69 6d 61 67 65 2f 70 6e 67 (the content-type tag).
7. Skip 00 (the body separator).
8. For each remaining push, read OP_PUSHDATA2 + length + payload bytes. Concatenate the payloads.
9. Stop at OP_ENDIF.

The concatenated bytes are the literal contents of the PNG file. Save them to inscription_0.png, double-click, see the skull.

19.5Why Taproot Makes This Possible

Inscriptions exploit three properties of the Taproot upgrade that converge to make on-chain data storage economical:

19.5.1The Witness Discount

Witness data is counted at 1 WU per byte (vs. 4 WU per byte for non-witness data). For inscription #0:

Without the witness discount, the same 1,040 bytes would cost \(1,040 \times 4 = 4,160\) WU (1,040 vB)—more than three times the actual cost. The witness discount provides a 69% fee reduction for data-heavy transactions like inscriptions.

19.5.2No Script Size Limit (BIP 342)

Pre-Taproot scripts were limited to 10,000 bytes (the MAX_SCRIPT_SIZE consensus rule). BIP 342 (Tapscript) removed this limit for Taproot script-path spends. The only remaining constraint is the 4,000,000 WU block weight limit—a single inscription can theoretically consume nearly an entire block.

19.5.3Unexecuted Branches Are Valid

Because OP_FALSE OP_IF … OP_ENDIF is never entered during script execution, the data inside the envelope is not subject to script-execution rules (like the stack element size limit for operations). The 520-byte push limit still applies at the serialization level, but arbitrarily large content can be split across multiple pushes.

19.6The Storage Debate

Inscriptions reignited a long-standing argument about what data belongs on the Bitcoin blockchain. The technical reality is more nuanced than either side typically acknowledges.

19.6.1The Seven Layers of Pruning

"Pruning" in Bitcoin is not a single operation — it operates at several distinct layers, each discarding different data with different trade-offs:

The common thread: at each layer, the question is what data can the node discard and still validate fully? Block pruning discards historical evidence. UTXO pruning discards provably dead outputs. Mempool pruning discards low-priority unconfirmed transactions. Utreexo would discard the UTXO set itself. Witness pruning would discard signatures and inscription data. They are all "pruning," but they operate on completely different data structures — and only the first is available as a user setting today.

19.6.2What "Prunable" Actually Means

"Prunable" is used loosely in the Bitcoin community, but it refers to two completely different operations that happen at different layers:

With this distinction, the storage picture becomes more precise:

When gmaxwell says OP_RETURN data is "completely prunable and pruned," he means UTXO-set pruning — the output never enters the expensive in-memory database. The raw bytes still sit in blk*.dat on every archive node's disk. On a pruned node, those bytes eventually disappear when the entire block is deleted — but that's not special to OP_RETURN; every byte in the block goes with it.

The real advantage of OP_RETURN is not that the data vanishes from disk. It's that the data never touches the UTXO set. Block files are cheap sequential storage. The UTXO set is a live database queried on every transaction validation, held in RAM or fast SSD, growing permanently with every unspent output. An OP_RETURN output creates zero burden on this critical resource. A fake P2WSH output creates a permanent entry that every full node on the network must maintain — forever, or until someone "spends" it (which, for a fake script hash, is never).

19.6.3The Costs That Pruning Does Not Eliminate

• Initial sync. A new node must download and validate every block in full — including all witness data — before it can prune anything. A blockchain with 200 GB of inscription witness data means every new node downloads that 200 GB even if it immediately discards it afterward.
• Block space is zero-sum. A block containing a 3.9 MB inscription leaves roughly 100 KB for financial transactions. During that block, every other user pays higher fees.
• Archive nodes cannot prune. Block explorers, Lightning watchtowers, and any service that serves historical blocks must store everything. More witness data means higher infrastructure costs for shared ecosystem infrastructure.
• UTXO dust accumulation. Millions of inscription outputs that are never spent — because the owner lost interest, lost their keys, or the inscription has no market value — bloat the UTXO set permanently. Unlike witness data, UTXO entries cannot be pruned by anyone.

19.6.4The Witness Discount Mismatch

The 75% witness discount (1 WU per witness byte vs. 4 WU per non-witness byte) was designed to incentivize SegWit adoption. The economic rationale: witness data is prunable and does not affect the UTXO set, so it should be cheaper. The discount assumed witness data would consist of signatures (64–73 bytes per input). Inscriptions exploit the same discount to store megabytes of arbitrary content at one-quarter the effective fee rate — an application the discount's designers did not anticipate.

19.6.5Can Node Operators Selectively Prune Inscription Data?

Not with Bitcoin Core's current tools. The -prune flag operates at the block level — it discards entire old blocks after validation, keeping only the most recent blocks (the value is a disk budget in MiB; the 550 minimum keeps roughly a day or two of blocks). There is no option to selectively strip witness data while preserving the rest of the block.

The options available to a node operator are:

1. Full pruned node (-prune=550): Discards block data beyond the disk budget (~1–2 days of blocks at the 550 MiB minimum). Disk usage stays around 5–10 GB. All inscription witness data is eventually deleted — but so is everything else. The node cannot serve historical blocks to peers.
2. Full archive node (default): Keeps every byte ever confirmed — currently 650+ GB and growing. No selective deletion is possible.

There is no middle option in Bitcoin Core. A node operator who wants to validate the full chain and serve blocks to peers, but does not want to store hundreds of gigabytes of inscription images, has no recourse.

19.6.6Could You Build Selective Pruning?

Short answer: not without modifying Bitcoin Core's storage layer or rewriting the entire blockchain on disk. The block-serialization format interleaves witness data inside each transaction (not appended at the end), so removing a witness shifts every byte offset that follows in the file, which invalidates every subsequent block's index entry. The full code-level walk-through — the actual BlockManager::WriteBlock() source, the FlatFilePos index structure, and the two architectures (external post-processor / separate witness files) that could make selective pruning practical — lives in Appendix G.

Appendix G addresses the chain-bytes side of the question (can we delete the data?). The design memo addresses the UTXO-set side (can we make the spending claim expire?). They're sister rabbit holes from the same concern about long-term storage cost.

19.6.7Inscriptions Are Door 2

Chapter 15 introduces the Three Doors framework developed by the BitcoinTalk user d5000 during the 2025 debate over Bitcoin Core 30's OP_RETURN change. The framework ranks on-chain data-embedding methods by how much harm they do to the network: Door 1 is fake public keys (permanent UTXO pollution), Door 2 is Taproot witness embedding (moderate, theoretically prunable, never actually pruned), Door 3 is OP_RETURN (never enters the UTXO set).

Inscriptions are Door 2. An inscription envelope lives in the Taproot script-path witness; the actual reveal output is a normal P2TR UTXO (~43 bytes of UTXO-set weight) that eventually gets spent or sits in limbo. The content itself rides on the witness discount (1 WU per byte instead of 4) and is not counted against any per-tx relay cap — the only brake on inscription size is the 4 MB block weight limit itself.

The key observation from the v30 debate, echoed by Greg Maxwell and d5000, is that Door 2 is architecturally the strangest of the three: its data is theoretically deletable (the coinbase's witness commitment, §14.4.3, proves the witness existed even after the bytes are gone), but no Bitcoin client has ever implemented selective witness pruning. The witness discount was priced on a prunability that was never built. So while inscriptions sound cleaner than OP_RETURN ("it's in the witness, it doesn't hit the UTXO set"), in practice every archive node stores every inscription byte forever. If the goal is truly prunable on-chain data, Door 3 — not the witness — is where it belongs. That is precisely the argument that carried Bitcoin Core 30 across the line.

19.6.8Interrogating the Arguments

The debate around on-chain data storage is full of claims that sound technical but collapse under scrutiny. A rigorous reader should challenge each one:

The honest conclusion: there is no free lunch. Every method of embedding data on-chain has costs. The question is not whether data storage should be prevented (it can't be — the bytes are valid transactions) but which costs are acceptable and who bears them. OP_RETURN imposes the least cost (no UTXO burden, block-file only). Witness inscriptions impose moderate cost (UTXO entry + block-file data). Fake outputs impose the highest cost (permanent UTXO entry + block-file data, with no way to ever remove the UTXO entry). The tooling to prune witness data — the middle option — was never built, despite the witness discount being justified by its theoretical prunability.

19.7Inscription Identity and Transfer

19.7.1Inscription IDs

Each inscription is identified by its reveal transaction's txid and an index:

6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0

The i0 suffix indicates this is the first (index 0) inscription in the reveal transaction. A single transaction can contain multiple inscriptions across its inputs.

19.7.2Ordinal-Aware Transfer

The inscription is bound to the first sat of the reveal transaction's first input. From that point, the sat (and its inscription) follows the FIFO transfer rule through subsequent transactions.

Ordinal-aware wallets must carefully control input/output ordering to avoid accidentally sending an inscribed sat to an unintended recipient—or worse, losing it to fees. A standard (non-ordinal-aware) wallet treats all sats as fungible and may inadvertently relinquish a valuable inscribed sat.

19.8What We Learned

• Ordinal theory assigns a unique serial number to every sat, based on mining order, with FIFO transfer through transactions.
• Inscriptions embed arbitrary data in a Taproot script-path witness using an envelope: OP_FALSE OP_IF … OP_ENDIF.
• The commit/reveal pattern uses two transactions: the commit creates a P2TR output; the reveal spends it via script-path, exposing the inscription.
• Three Taproot properties make inscriptions economical: the witness discount (69% savings), no script size limit (BIP 342), and unexecuted branch validity.
• Inscriptions are identified by txid + index (e.g., ...i0) and are bound to the first sat of the reveal input.
• Inscription #0 was a PNG skull inscribed by Casey Rodarmor in block 767,430 (December 14, 2022).

19.8.1Looking Ahead

Inscriptions use the witness to embed non-fungible content—one inscription per sat. Chapter 20 examines Runes, a protocol that uses OP_RETURN to create fungible tokens on Bitcoin, with an entirely different transaction anatomy.

Exercises

Litmus (L)

1. How are ordinal numbers assigned to satoshis?
2. What does the "ord" marker in an inscription envelope signify?
3. Why does the inscription protocol use a two-phase commit/reveal pattern?
4. What is the maximum size of a single data push in a Taproot script?
5. What happens to sats that are not claimed by any output (i.e., the fee)?

Hands-On (H)

1. Calculate the ordinal number of the first sat mined in block 767,430 (Inscription #0's block). Show your work by epoch.
2. A "Hello, world!" text inscription (13 bytes of content, MIME type text/plain;charset=utf-8) is revealed in a transaction with 82 bytes of non-witness data. Estimate the total witness size and the transaction's weight.
3. In Inscription #0's reveal transaction, the stripped size is 82 bytes and the total size is 1,040 bytes. Verify the weight (1,286 WU) and vsize (322 vB) using the BIP 141 weight formula.

Proofs and Reasoning (P)

1. Explain why OP_FALSE OP_IF … OP_ENDIF is a no-op in Bitcoin Script. Why is this property essential for inscriptions?
2. Why did BIP 342's removal of the 10,000-byte script size limit have a larger practical impact on inscriptions than the witness discount?
3. The ordinal transfer rule is FIFO. Construct a scenario where a 3-input, 2-output transaction results in an inscribed sat ending up in the fee (lost to the miner).

Connections (C)

1. Taproot dependency. Compare the inscription mechanism (Taproot script-path, witness envelope) with the OP_RETURN data embedding from Chapter 15. Why can't inscriptions use OP_RETURN? What are the size and cost tradeoffs?
2. Block weight economics. A 400,000-byte JPEG inscription fills nearly an entire block's witness budget. Calculate its weight and the percentage of the 4,000,000 WU block limit it consumes. What does this imply for other transactions in that block?

Bridge (B)

1. Chapter 20 covers Runes (fungible tokens via OP_RETURN). Compare the on-chain footprint of an inscription (witness data) vs. a Rune etching (OP_RETURN). Which is more efficient per byte of protocol data, and why?
2. Could the inscription envelope format work with pre-Taproot transaction types (e.g., P2WSH)? What consensus or relay-policy constraints would prevent it?

Solutions

L1. Ordinals are assigned sequentially in the order sats are mined. The first sat of the genesis block is ordinal 0. Each block's subsidy adds the next batch. The first sat of block \(h\) has ordinal \(\sum_{i=0}^{h-1} \texttt{subsidy}(i)\).

L2. The "ord" marker (0x6f7264) disambiguates Ordinals inscriptions from other potential uses of the OP_FALSE OP_IF envelope pattern. It is the first push inside the envelope and identifies the protocol.

L3. Taproot script-path spends can only be made from existing Taproot outputs. The commit transaction creates the P2TR output that commits to the script tree containing the inscription. The reveal transaction then spends it, exposing the tapscript (and the embedded data) in the witness. You cannot create and spend a Taproot output in the same transaction.

L4. 520 bytes. This is a Taproot consensus rule inherited from the original script push limit. Larger content is split across multiple pushes within the envelope.

L5. Unclaimed sats (the transaction fee) flow to the coinbase transaction of the block. In ordinal theory, the coinbase has implicit inputs for fees, so these sats are assigned to the miner's coinbase outputs following the standard FIFO rule.

H1. Block 767,430 is in epoch 3 (blocks 630,000–839,999).

The first sat of block 767,430 is ordinal 1,923,393,750,000,000. The 137,430 partial-epoch blocks come from \(767,430 - 630,000\).

H2. The tapscript contains:

• Spending condition: 33 bytes (<pubkey>) + 1 byte (OP_CHECKSIG) = 34 bytes
• Envelope overhead: OP_0(1) + OP_IF(1) + push "ord"(1+3) + push tag 1(1+1) + push MIME(1+24) + OP_0(1) + OP_ENDIF(1) = 35 bytes
• Body: 1 + 13 = 14 bytes (single push, fits in one OP_PUSHBYTES_13)

Tapscript total: \(34 + 35 + 14 = 83\) bytes. Add Schnorr signature (64 bytes) and control block (33 bytes). Witness items with varints: \(1 + 64 + 1 + 83 + 1 + 33 = 183\) bytes. Add witness item count (1 byte) and marker+flag (2 bytes): total transaction \(\approx 82 + 2 + 1 + 183 = 268\) bytes.

Weight: \(82 \times 3 + 268 = 246 + 268 = 514\) WU, or \(\lceil 514/4 \rceil = 129\) vB.

H3. Weight \(= \text{stripped\_size} \times 3 + \text{total\_size} = 82 \times 3 + 1{,}040 = 246 + 1{,}040 = 1{,}286\) WU.

vsize \(= \lceil 1{,}286 / 4 \rceil = \lceil 321.5 \rceil = 322\) vB.

Fee rate: \(322 \div 322 \approx 1\) sat/vB.

P1. In Bitcoin Script, OP_IF pops the top stack element and executes the following code only if the element is nonzero (true). OP_FALSE pushes zero, so OP_IF always takes the "else" branch—which, in the absence of an OP_ELSE, means jumping directly to OP_ENDIF. All data pushes between OP_IF and OP_ENDIF are parsed but never executed. This is essential because inscription data (binary images, HTML, etc.) would cause script failures if executed—they are not valid opcodes or stack elements in an execution context. The envelope ensures the data is recorded on-chain (in the witness) but ignored by the script interpreter.

P2. The witness discount reduces the cost per byte of inscription data by 75% (1 WU vs. 4 WU). But the 10,000-byte script limit would have capped inscription size to 10 KB regardless of cost. BIP 342's removal of this limit changed the maximum possible size from 10 KB to 4 MB (the entire block weight budget). Without the size limit removal, inscriptions would be limited to small text or tiny images. The discount makes large inscriptions affordable; the size limit removal makes them possible.

P3. Suppose Alice holds three UTXOs: input 0 has 5,000 sats (with an inscription on sat 0), input 1 has 3,000 sats, input 2 has 2,000 sats. Total: 10,000 sats. She creates a transaction with output 0 = 4,000 sats and output 1 = 5,500 sats, paying a 500-sat fee.

FIFO assignment: output 0 gets the first 4,000 sats from input 0 (ordinals 0–3,999). Output 1 gets the remaining 1,000 from input 0 (ordinals 4,000–4,999), then 3,000 from input 1, then 1,500 from input 2. The last 500 sats from input 2 are the fee.

The inscription (on sat 0 of input 0) ends up in output 0. Now change the outputs: output 0 = 4,000 sats, output 1 = 5,000 sats, fee = 1,000. If Alice carelessly sets output 0 = 0 sats and output 1 = 9,000 sats, then the first 9,000 sats fill output 1 and the final 1,000 sats (from input 2) are the fee. The inscribed sat (sat 0 of input 0) goes to output 1.

For the sat to be lost to the fee, its position in the combined input stream must exceed the total output value. Put the inscription late in the stream: inputs = [5,000, 3,000, 2,000] with the inscription on sat 1,500 of input 2 — stream position \(5{,}000 + 3{,}000 + 1{,}500 = 9{,}500\). Set output 0 = 4,000 sats and output 1 = 5,000 sats, fee = 1,000. FIFO: output 0 takes positions 0–3,999, output 1 takes 4,000–8,999, and positions 9,000–9,999 — including the inscribed sat at 9,500 — fall into the fee. The ordinal protocol treats fee sats as flowing to the block's coinbase: the inscription now belongs to the miner.

C1. OP_RETURN (Chapter 15) embeds data in a scriptPubKey output, which is non-witness data (4 WU/byte). Maximum: 80 bytes of data. Inscriptions embed data in the witness, which costs 1 WU/byte, and have no practical size limit beyond the block weight.

Tradeoffs: OP_RETURN is 4\(\times\) more expensive per byte but creates a provably unspendable output (no UTXO bloat). Inscriptions are 4\(\times\) cheaper per byte but require a spendable Taproot output, increasing UTXO set pressure. OP_RETURN is limited to 80 bytes; inscriptions can store megabytes. For small metadata (transaction timestamps, proof anchors), OP_RETURN is simpler and cheaper in absolute terms. For large data (images, media), only inscriptions are feasible.

C2. A 400,000-byte JPEG in the witness, with 82 bytes of non-witness data:

Weight \(= 82 \times 3 + (82 + 2 + 400,000 + overhead) \approx 246 + 400,200 \approx 400,446\) WU.

As a fraction of the 4,000,000 WU block limit: \(400,446 / 4,000,000 \approx 10.0\%\). A single large inscription consumes roughly 10% of a block's capacity, leaving 90% for other transactions. A 4 MB inscription (the theoretical maximum) would consume the entire block.

B1. Inscriptions store data in the witness at 1 WU/byte. Rune etchings store protocol data in OP_RETURN outputs at 4 WU/byte. Per byte of protocol data, inscriptions are 4\(\times\) more weight-efficient. However, Rune protocol messages are small (typically \(<\)80 bytes), so the absolute weight difference is modest. Inscriptions are designed for large payloads (images, media); Runes are designed for compact token operations (etch, mint, transfer) where the total data is tiny.

B2. The OP_FALSE OP_IF envelope is syntactically valid in any script context, so it could appear in a P2WSH witness script. However, pre-Taproot scripts have a 10,000-byte MAX_SCRIPT_SIZE consensus limit, capping inscription size to 10 KB. Additionally, P2WSH witness data still receives the SegWit discount (1 WU/byte), but the script size limit makes it impractical for anything beyond small text. BIP 342 (Tapscript) removed this limit specifically for Taproot script-path spends, which is why inscriptions require Taproot.