I've been away from development for a long time, so it's likely I'm out of sync and it's possible I'm confused--- I only looked into the discussions around this stuff when I learned about who's been funding the BRC-20 floods, and my interest is mostly limited to figuring how it plans into the overall attacks on Bitcoin developers by these parties. That said, XKCD-386 applies
and I can at least offer some historical context.
Funny how they almost completely left me out of the drama considering that Luke was replying to my message.
I don't think that's an accident. Luke (like a dozen other current&former developers; including me) is being sued for billions of dollars with an allegation that we specifically and no one else control the Bitcoin network, and so we're obligated to institute a backdoor for Wright wright to "recover" billions of dollars worth of Bitcoin where he claims to have lost the keys. You're not (currently!) on the list of defendants, and so bringing up you would actually undermine their argument that having opinions on blocking the spam was evidence of that control.
if we close off this vector, these nutcases will just find another vector to continue their spam such as OP_RETURN or Segwit v1 witness data compacted properly in binary, scriptsigs in legacy addresses which have a dummy P2PKH script followed by compact BRC-20 OP_PUSHDATAs and so on. We can't possibly disable all such vectors as some require a hardfork.
Not just a hardfork, it seems to be fundamentally *impossible* even with a hardfork: because attackers could just burn capacity with chains of transactions that look nearly indistinguishable (as they actually did in 2016/2017-- some of the flooding attacks are only obvious with retrospective blockchain analysis).
I'm mindful of the point
pooya87 has made in another thread here that part of the attack is enlisting idiots to participate, which can actually be dampened by standardness rules to inhibit specific forms of spam. I think he's right but I don't think it matters, the enlistment is only a small constant factor on the attack cost. Sure-- the attacker will use enlistment to lower their costs and/or prolong their attack some if they can, but if they can't enlist they'll still attack.
There has been some more blatant attempted enlistment on reddit that the r/bitcoin mods have been pretty good about nuking. E.g. posts claiming that "taproot" has an inflation bug that user can exploit by making a lot of transactions... their inability to get away with *that* kind of enlistment hasn't stopped the attack. The attackers are just going to use whatever is available to attack, but removing those things won't stop the attack unless the things being removed are the only ways to accomplish it. And to the extent that the attack is *specifically* to drive fees up, the actual structure of how they do it is completely irrelevant to the attacker, so blocking any particular one won't work.
I think its also absolutely guaranteed that anyone that successfully deploys standardness rules to inhibit this attack is going to be saddled with hundreds of thousands of dollars in legal fees defending lawsuits--- either because they get sucked into the "you must backdoor bitcoin for me" litigation somehow or because proxy entities will claim that blocking their spam destroyed their oh-so-legitimate business which was goona make billions. It's happened before, see "United American Corp vs Amaury Sechet, Shamma Chancellor, and Jason Cox"-- bcash developers were sued by some shell company because they added a checkpoint that blocked a reorg attack Wright was threatening to perform on social media. They defeated the lawsuit and the shell just declared bankruptcy and vanished, but even though they won they took on large costs that can't be recovered (cause the entity just vanished).
It's also the case that any specific spam filtering can't really stop enlistment.. like these BRC-20 transactions could be encoded in a way that makes it extremely difficult to filter them (as they only embed <90 bytes or so), they aren't now but that's because the attack is just really lazy. It would at best be a bunch of wack-a-mole, and particularly hard to the extent that there exists any earnest usage at all (even if it's just a tiny fraction of a percent)-- since those earnest users will be useful fools for the attackers in opposing the bandaids.
If it was clear that it would work then the costs of trying it might be justifiable, but if it'll just delay or shift the form of the attack? ::meh:: I mean, feel free to put your own neck out, but I think that would be a pyrrhic victory. I'm sure that in some attacks people would expose themselves to personal bankruptcy to defend even a non-guaranteed defense, but "an attacker is bankrupting themselves making fees elevated" is probably just not one of them. Though anyone who disagrees is free to try!
All that said, I do think that the overall trend ... really since 2013 or 2014 has been to avoid having standardness restrictions except where it's needed to preserve the ability to introduce new features or protect hard-to-fix soft spots (like script opcodes that took too much time to execute relative to their weight usage). Part of the motivation behind that trend is that filtering this or that structure doesn't actually prevent attacks since attackers will do whatever works, but part of it was also that additional standardness rules could be deployed as needed. That's made harder by attackers pretending to be legitimate usage in enlistment attacks, which I think was probably expected in the past but perhaps under estimated-- what wasn't anticipated is that they could use any action in defense as a viable way to attack the defenders with lawsuits. So in that sense you could say there may have been some oversight, but I don't know if the loss of "fix the spam with policy" as a tool is all that meaningful, given the broader point that the attack can just change shape.
I haven't even gone into the fact that standardness is a really weak protection since it doesn't apply to miners, who absolutely are known to mine non-standard txn for pay... the whole ethereum MEV dark forest with an endless supply of incentive incompatible smart contracts has also made dishonest conduct (in the sense of violating the unenforced protocol to maximize income) a norm for any part of that industry that has touched the ethereum ecosystem.
Enlistment can also be combated with communication and, in fact, communication is both necessary and sufficient since you can't deploy or preserve a stanardness rule against an attack without justifying it. The tricky part is that if people make a big deal arguing against something they validate it as something important and give it free press so you have to be careful that you don't help it, but actually acting against with technical measures is probably a zillion times worse.
But here I don't know that a lot of communication is needed because I've seen very little evidence of significant enlistment, the enlistment mostly seems to be a cover.
