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 (5)

Core, whether through omission or commission, through the changes they instituted created ordinals regardless of whether this is #Bitcoin’s reality currently……… I personally do not see ordinals as a positive for Bitcoin given what that has done to the data storage on my full node, perhaps you do. Now we are asked by this group to open things up further in op return? Most reasonable and logical individuals would look at the past, see the track record, and ask what may result of such action………. What’s the impetus for the change if things are currently working fine? Their track record shows that they are not able to anticipate unknowns nor patch them when they occur….…. We are now given V30 which blows open the op return…….. Running a FULL node and keeping the barrier to entry (cost) minimized is in line with #Bitcoin’s ethos…….. Enforcement should be cheap (running a full node), profiting should be expensive (Bitcoin mining)……….. Adding more data to the time chain increases the costs for node operators to run FULL nodes…… I know I personally have to upgrade my set up (memory constraints) due to what ordinals has added to the storage requirements which was caused by Core…… Perhaps you don’t mind this, but I do and I am against unnecessary changes that further bloat the time chain………..
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.