No worries, and it's a good question.
First, at least according to The Guardian iirc, there's already CSAM on chain, and forking it at a blockheight in the future won't remove that. So if the argument is that anyone storing this data on their computer will be liable in a court of law, then that ship has already sailed or the chain needs to be rolled back to ~2017.
Second, embedding CSAM on-chain was already possible before the op-return increase, which was reasoned to be included to disincentivize other forms of data storage that are more harmful to the network, such as by bloating the UTXO set.
Third and most importantly, this proposed legal theory simply does not hold up in the face of anyone familiar with the law. Bitcoin nodes (and bitoin miners) are at least by US regulators largely understood to be facilitating communication, and communication providers are not liable for the content they relay or host.
Interestingly, holding communications providers liable for the content they host was a large part of the original cryptowars. If that theory had pertained, the internet would simply not exist as nobody would be willing to build services with such a risk attached, as Google, Facebook, Microsoft, Amazon, etc would routinely lose Billions to hosting CSAM.
Hope that helps.
Login to reply
Replies (3)
There is a difference using workarounds or loopholes to force arbitrary data into the blockchain or to make it possible per default as core v30 is doing. This isn’t the right signal. Run Knots or do not update to v30 is what I would suggest.
My node can delete op_return data that I don't care about. That's the cool thing.
The third point is written as if fact but it’s not. Applying certainty in the face of uncertainty isn’t wise. The country is littered with case law where lawyers would’ve been certain that constitutional law would side with them. Forging an unnecessary risk that adds no value and nobody wants or needs is not smart risk management. I do realize that this last line could be applied to both sides of the argument. The rational thing is for core to roll back the op_return limit to something that users actually care about. Real users. Not devs tinkertoying around with crap nobody cares about and is unlikely to ever gain any adoption