On Twitter, apparently it's supposed to be a tree, or two people holding hands.

Here, it can only look like one thing...

Get a job moron

Indeed, we can definitely go lower than 0.1 sat/vbyte!

I thought increasing the op return limit allowed covenants.

“we are going to try to damage your projects and companies if you do not parrot our exact opinion”

pretty lame, hope this doesn’t hurt my twitter engagement

You need to read about subjetive value sir...

You can't consider spam a gif, a image, a video or even a book.

Rules are clear.

If you want to upload ANY data to Bitcoin. You need to pay the price.

The question isn’t whether the heuristic is simple or complex. It’s who decides what’s monetary vs non monetary data. OP_RETURN limits made sense when they were consensus rules everyone agreed to. Post Taproot, inscription data pays full freight in fees and follows consensus rules.

The “arbitrary data burden” argument cuts both ways: if someone pays market rate for block space, that’s the fee market working. Configurable filters are fine for individual nodes, but marketing them as “spam protection”implies some uses are more

legitimate than others.

Bitcoin’s neutrality is its superpower. Once we encode “this data is worthy, that data isn’t” into standard policy, we’re making subjective calls about what belongs on a permissionless ledger.

The core insight here cuts through all the noise: you can’t out clever thermodynamics. Every spam filter without cost becomes a centralization vector. Whether it’s Google’s servers deciding you’re human or some council deciding what “legitimate”Bitcoin usage looks like. The genius of fees isn’t that they’re perfect, it’s that they’re the only decentralized solution to the spam problem that doesn’t require asking permission from anyone. Either pay in energy or pay in trust. Pick one.

Fork your mother if you want fork.

enjoy your shitcoin fork retard

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 … … 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.

No. Fees are fundamentally different from other filters. You know this.

Ok, what is going on here? Up almost 6% in 48h? Even I have a hard time believing this is organic adoption (hope I’m wrong). Or did the core devs provoked plebs more than usual on Twitter? What am I missing? If this is organic and not a Sybil, this is YUGE!

Um, I’m not sure you distinguished what nostr:nprofile1qqsvfr3f7p95stxqrjslnmuvsmhcxxxqt8swjdfjx5tz7zq0yms5cygpzfmhxue69uhk7enxvd5xz6tw9ec82cspz4mhxue69uhk2er9dchxummnw3ezumrpdejql4w2ex said, from a repost of someone else’s thoughts.

Someone has no idea how computers work 😂😂😂

"to nearly 12 GB"

and yet, my core rpi node uses less than 2GB of RAM. i can't take this position seriously - knots claims to be the defender of rpi nodes, but from what i have seen, *only knots* uses 12GB of RAM. i'm sure there's some optimizations going on in core, but at the end of the day it's an irrelevant detail.

knots is the problem, not the solution

bye bye;