Thank you for providing this. Sorry for a late reply, but after looking it seems this directly targets inscriptions and ordinals. ie. this is a cat and mouse game. We can do that and break ordinals and inscriptions... until they change their protocol to just do it a different way. Then devs would have to explicitly update DatacarrierBytes() with another case to catch it. like ad blockers... They work until the ads use a different scheme and the blocker no longer works until the devs implement a new blocker.

It's not a real solution to the problem. This is just whack-a-mole imo.

What’s the real “fix”

A consensus rule that says:

“No witness stack element may exceed X bytes, no witness script may exceed Y bytes, no input may have more than Z stack elements.”

But this requires a hard fork.

Reply to this note

Please Login to reply.

Discussion

The reason spam is addressed in policy and not consensus is so that devs can update it easily to block new types of spam.

👍

You're talking about a new version every couple of weeks still... Nodes don't auto update. The reason this was done in policy is because a hard fork is not achievable.

and it still doesn't work, since it would be easy to get around with librerelay. lots of wasted dev time for nothing.

So you answered the question right?

Spam was under control until the taproot change, and inscriptions in 2023.

IMO-

It was another spam event, which was handled before in Bitcoin history: satoshi dice, colored coins, and counterparty. All blocked by policy filters and SOCIAL DISINCENTIVES

The difference today is the core dev team redefined the documentation and pretended a bug was a feature.

Plebs are now saying enough is enough.

Spam was not "under control" there just wasn't a protocol for spam yet. And it was far more costly before ordinals. On chain activity has decreased substantially.

It's also not feasible. By the time the review process is done they will have circumvented it anyways.