Not a Knots apologist, though I’ll sound like one with this question. I genuinely don’t understand how the 100kb data storage on-chain is not a legitimate worry.
Like, given enough time someone will push CSAM on-chain. If for no other reason than to see the world burn, or because they’ve opened a huge short on Hyperliquid.
And that would likely lead to a “floor discovery phase”.
What am I not getting?
No one is really arguing that the 100kb is a good idea. But CSAM can already be put on chain regardless. This fork would give someone (Luke) the power to roll back bitcoin.
The entire CSAM argument is retarded.
I am. If you want to put that stuff on chain, at least put it in an unspendable output, so you don't poison the UTXO set
Organized religions are a major threat to bitcoin.
There's a perfect storm coming, with interests of failing nation states aligning with big religion. The existence of both depends on the individuals domination.
consuming agency, infantilizing the population into submission.
Both want two control the flow of information, it's no coincidence the growth in online censorship is being pushed at the same time religion is gaining popularity.
We are being encircled. Bitcoin is the ultimate defense for freedom of speech, because of this it is the ultimate target.
There maybe very few agents of these collectivist forces that understand, but the emergent behavior of the State/Religion, is taking this deadly serious.
Religions will often fight from their righteous, moral high ground. A position most are unaccustomed and uneasy to dealing with.
The cage is being built and most "bitcorners" are helping!
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.
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.
Liar
No one cares about your virtue signal.
The opposition is always part of a conspiracy theory or in this case virtue signaling. This view the commitment to debate is what it needs to bring society a step forward.
you cannot stop spam pubkeys…and those show up in the utxo and cannot be pruned you are incentivizing centralization as ram requirements push minimal hardware setups off the network. The purpose of the op_return is to prevent utxo bloat.
I would rather upgrade my hard drive to handle some stupid monkey jpeg(or run a pruned node) than upgrade my whole machine because you wanted purity. You would rather virtue signal.
Do you see it now? The ram requirements are already making node hardware options more expensive.
I looked that up. From my understanding Bitcoin Core sets the Ram used for the UTXO set to 512MB as a default. The rest is stored on the for example SSD and fetched when needed. If this is the case you argument does not hold up.
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
