Thread

If Core neglected to update spam filters and refuses to fix the vulnerability, that sounds like the Core development consensus chose not to restrict it. Whether through action or inaction, that became Bitcoin’s reality post Taproot. On Satoshi’s filters: can you point to specific examples where Satoshi rejected transactions based on content type rather than structural validity? I want to understand the historical precedent you’re citing. On Core 30 and Taproot: if they’re unrelated, what specifically is Core 30 changing that enables the threat you’re warning about? On “each user decides” agreed. But there’s a difference between individual nodes filtering their own mempools versus advocating that filtering should be the standard. Your post isn’t just “here’s what I’m doing”, it’s “everyone should do this NOW.” That’s attempting to establish collective filtering as the norm, not individual choice.

Replies (3)

The specific Satoshi filter is that prior to OP_RETURN, data of an unknown content type was rejected from being relayed (i.e. filtered). However, a transaction sent directly to a miner with data of an unknown content type could still be mined... the miner could even call the output an "OP_RETURN" (or any other op code unknown to anyone else) if he wanted to. The difference is, when all the other nodes validate a block containing a transaction with an op code that it doesn't recognize, it just assumes it's unspendable - which was convenient for the introduction of OP_RETURN (also unspendable) since it didn't change node behavior vis a vis block validation (and thus, no chain-split) The net result of OP_RETURN was to allow data of unknown content type to be relayed; and consequently, way more likely to get minded - then when it was previous being 'filtered' (i.e. 'picky') from being relayed in the first place.