As a pilot, there are some outcomes that are so catastrophic that we build in lots and lots of mitigations so that we don’t EVER encounter them. An example is fuel. Running out of fuel increases the likelihood of a crash to nearly 100%. Meanwhile the actual incidence of fuel related crashes in commercial aviation is very close to 0. The fact that the incidence is close to 0 doesn’t mean we can safely remove fuel reserve requirements, or proper fuel planning processes.
This is how I see the SPAM debate. There are some outcomes (e.g. illegal data in the chain) that are so bad that, even if we haven’t seen it yet, we have to build as many mitigations as possible. If the US government can prosecute the samourai developers despite Section 230, it’s hard to imagine that node operators that knowingly host illegal data would also be immune from prosecution. So we have to build in multiple layers of mitigation to prevent that catastrophe. With Core deciding to open up OP_RETURN to 100k bytes, they’ve taken away one of those mitigations.
For me personally, best case scenario: OP_RETURN goes back to 83 bytes and the inscriptions bug gets fixed.
Barring that, what is the next best mitigation in order to prevent the catastrophic result of illegal data on the chain? Certainly a soft fork is a far worse option. But it might be the next best option.
Still I’d much rather that core come to their senses. If not, that more people run knots - or some other bitcoins that allows for filtering OP_RETURN. Only after both of those fail, would I like to see a soft fork. Because we can’t tolerate the catastrophic result of illegal data on chain.
