The Spam Chronicles A red thread from SegWit through Taproot to Ordinals/Inscriptions is a story about how the problem emerged, why OP_RETURN is barely relevant, and where missing policy responses made things worse. Since 2017, SegWit has set the rules of the game. It was introduced to eliminate transaction malleability and to fit more transactions into each block. SegWit moved signatures and script data into the witness and introduced a new accounting system (“block weight”). A byte in the non-witness part counts as four weight units, while a witness byte counts as just one—roughly a 75% discount. That made SegWit attractive (and made Lightning practical), but it also laid the economic groundwork: witness bytes are the cheapest bytes. In 2021, Taproot arrived as a soft fork—with Schnorr signatures and MAST, but most importantly Tapscript, a modernized script environment. Tapscript relaxed several old guards: the classic ~10 KB script size limit no longer applies, and the old “201 non-push opcodes” limit vanished. In practice, a Tapscript’s size is now only indirectly bounded by block weight. One important thing stayed: the 520-byte limit per stack element. But by using many ≤520-byte pushes, you can add up to very large overall witness payloads—still discounted by SegWit. This combination—more “shelf space” plus cheaper bytes—created the technical breeding ground for what came next. From late 2022 onward, the “envelope” trick became popular: scripts stash data in a never-executed Taproot branch, typically OP_FALSE OP_IF … <data> … OP_ENDIF. That branch is not executed, but the bytes are visible in the witness. External indexers like ord read the structure, treat the bytes as an “inscription,” and attach them to Satos (Ordinals). For Bitcoin’s consensus and validation, these are simply valid spends with heavy witness payload—cheap, because witness. This bypass pattern was later captured in a security note (CVE-2023-50428): the historic datacarriersize policy, which limits OP_RETURN, is circumvented by disguising data as “code” inside an unreachable branch. That’s why the OP_RETURN debate misses the point. OP_RETURN was always a small, standardized data outlet—and that’s exactly what -datacarriersize limits. Ordinals/Inscriptions, however, do not use OP_RETURN at all; they use witness/Tapscript. You can argue about making OP_RETURN 40, 80, or 4 MB—but the cheapest and most flexible path remains the witness. So OP_RETURN is not an honest solution to the observed data growth. The fact that some developers publicly discussed loosening or removing the 80-byte standard limit for OP_RETURN (Core 30, targeted for October 2025) illustrates the wrong front line: it doesn’t address the witness path where the big payloads actually enter. What should have been done instead—without changing consensus, purely via relay/mempool policy? Bitcoin Core already uses standardness rules (guidelines for what nodes will relay). That’s exactly where early, explicit action could have helped: treat unreachable witness branches as data carriers and cap them per input/transaction; add size ceilings for Tapscript and witness bytes in standardness; and—if desired—mark the envelope pattern as non-standard. Alternative builds and third-party patches (e.g., Ordisrespector) already do this: they detect typical inscription patterns and don’t relay them. That proves policy works—it just needs broad adoption (ideally by pools, too) so the economics flip. The lack of a timely response in Core’s default mempool—i.e., the absence of a clear witness-side policy—made the situation worse. The cheap path remained untouched, while the OP_RETURN discussion signaled to many that the actual gap might not be seen as a problem at all. Documents reflect this tension: the CVE explicitly notes that some consider it “not a bug,” even as the concrete bypass (obfuscating data as code via OP_FALSE OP_IF) is well documented. The result was a stalemate: while many node operators and alternative clients filtered, the default stayed permissive—and the economics of witness did the rest. Put the chronology together and a clear picture emerges: SegWit introduced the witness discount and fixed malleability—for good technical and economic reasons. Taproot/Tapscript deliberately relaxed old script limits to enable more flexible spend paths—also a valid goal. Unintentionally, the combination created a cheap, high-volume data path. When it became clear in 2022/23 that this path was being used for arbitrary data, a decisive policy response on the witness side could have dampened the wave. Instead, the debate shifted to OP_RETURN—a sideshow that doesn’t touch the material problem. The lesson is unglamorous but clear: if you want to curb non-monetary usage, you must act where the economics live—in the witness. That means standardness limits for Tapscript/witness, clear rules for unreachable branches, and—if desired—pattern filters for common inscription envelopes. Anything else, especially cosmetic tweaks to OP_RETURN, will crash against block weight discount and just open a door for new additional non-monetary uses, even malisious ones.