Thread

Mining is centralized. The concern around objectionable content is met with appeals to decentralization of mining - i.e a Bitcoin network that doesn't exist. Until now, what has already been "technically possible" with storing nasty stuff in the chain wasn't. 1. "The" mempool was protected because everyone would filter a sick 100kb OP_RETURN along with *all* OP_RETURNs greater than 83 bytes. 2. The blockchain was protected because the few miners there are in the world would reject directly submitted malicious content. This left one option for sabotage: an attacker mining a CSAM OP_RETURN directly into the chain themselves. Referring to something as impractical as that as "technically possible" is entirely frivolous and it would have been laughable if it had ever happened. An "Unknown" pool finds a block that has a giant 1MB MP4 of something appalling in it? Obvious sabotage that we would universally eschew and I'm confident we would be able to resolve after the fact. Now however the situation has changed. F2Pool solicits this stuff directly from the p2p network and Libre Relay nodes along with Core 30 release candidates are willingly relaying it. There is now an anonymous, p2p network for this attack that's free to access and there is a miner who will oblige it. The combination of the above, in practice, drops the cost from six figures ($$$,$$$) to three ($$$) and makes it possible to do anonymously. But more importantly, the mechanism of the attack makes the resulting content appear to have been endorsed by the network at the policy level rather than come as a result of a circumvention that exploits crude consensus rules. If you still cannot understand the significance of that then you must simply not be aware of the changes that Bitcoin has undergone with all the malicious tweaking of late and the sheer desire there is to take Bitcoin out. Again: The p2p network has protected itself from attack due to sane default mempool policies, while the blockchain has been inaccessible to attackers due to pools not wanting to be on the hook for blocks containing malicious data. Those technically-circumventable factors are now gone and there is no practical limitation to the attack beyond cleaning some coins, and paying a couple hundred bucks in transaction fees to get unacceptable content into the chain. If the network isn't going to protect itself from malicious, consensus-valid activity then the only option left is changing consensus and doing a soft fork to limit OP_RETURNs and perhaps other known types of data carrying. That idea entered the arena on the mailing list on Friday from someone vocally against Knots (@PortlandHODL) and was received positively by the Core devs who responded. Some embellishment was offered by Luke (add additional data carrying types) to which there was not so much response. Without community support a fork fails. It's possible if even the Core 30 proponents are OK with limiting this stuff at the consensus level though that there is community support and thus it could be the way forward. I dislike it because it abandons spam mitigation occurring at the policy level which is where it belongs but the current environment isn't giving us a lot to work with. It is probably appropriate to characterize the fork as defense we never needed against a specific type of attack versus spam mitigation in general which will have to be continue in parallel. Fork?