Its the year 2141.
The last sat has been mined, but the political struggle for monetary supremacy still rages. China and the EU have both fragmented, and both have struck the free bitcoin communities that rejected their authority with nuclear weapons. The middle east and Southeast Asia are entirely bitcoinized, and the Texan Confederation has allied with the reunified Central American Union, and bitcoin citadels have sprung up throughout the region, but directly north and south are two behemoths that still enslave their populations with CBDCs.
Everyone universally uses the phrase, "rotten to the Core," in a new way - #Bitcoin #Core was rotten, and their betrayal was what gave states the legal pretext to violently attack bitcoiners, which started the chain of events that shattered the world. Everyone knows it didn't have to be this way.
Replies (9)
Kyc poisoned payload incoming in op_return outputs #OperatorBeware
How would that work?
Did you see this yet?:
Bitcoin Mechanic
Old methods of storing evil stuff required obfuscation: they would need to break it up into multiple chunks and reassembly would require specific software and knowledge of what the data is and how to reconstruct and interpret it exactly.
The old formats looked like this:
"Hi, I'm a Bitcoin transaction, here's my first output of 45 outputs - <filepart1>, here's my second output <filepart2>, here's my third output<filepart3>" along with a tonne of other stuff that has to get parsed out when processing the highly obfuscated material. This is thankfully also true of inscriptions.
OP_RETURN however is just a dump for raw, serialized data. It's not the same.
It says the equivalent of "Hi I'm a Bitcoin transaction, here's an unspendable output: <file> end".
This wasn't a problem for tiny OP_RETURNs i.e their current limit of 80 bytes.
If they're permitted to be 100kb, that's where the abuse begins.
And that's the end of plausible deniability.
When the stuff gets processed - which it has to be for your node to verify that they are valid transactions - then you just have a raw, unadulterated file that will trigger primitive antivirus/forensics software to alert the user: "Hi, you have CP on your computer."
You now need a licence to run a Bitcoin node, everyone thinks you're disgusting if you do, and they're not even wrong.
View quoted note →
Damn I just posted on #KyCPoisoning and regulatory entrpment ... but this is the root of it
The suspect data can be deleted, overwritten. Sorry, I only have the header.
I'm pretty sure pruned nodes do this. 80 bytes per block for the whole chain, tx payloads for the UTXOs that are er. Unspent.
The blocks have the integrity data and are the hashed prevblock itself.so, no. You don't need to keep any spam someone will have the full block either way. You personally only need the txs relevant to your wallet.
The whole point of pruning is safe minimization: validate everything, keep UTXOs + headers, drop history you don’t need. That’s fine — it doesn’t weaken the system because archival nodes still exist.
But this OP_RETURN policy change is the opposite: it normalizes unsafe defaults. Instead of minimizing safely, it opens the door to arbitrary payloads and leaves the burden on every validating node. Talking about pruning in this context is a red herring — pruning reduces load after full validation, whereas permissive OP_RETURN just increases attack surface before validation is even done.
Enabling unsafe defaults isn’t optimization. It’s either naïve or malicious.
i'm just pointing out that putting CP on chain doesn't mean everyone who runs it will store CP on their disk. this kind of spam would especially be easy to prune, you could literally just omit all of the spammy transactions from what you store, txs only no data. so, as an attack on bitcoin it would fail to stop people from using bitcoin, because there would be archival nodes elsewhere. and ultimately, the chain is just the headers, the transaction payloads are referred to but you could just prune out the garbage and leave a marker with the tx hash only for calculating the merkle tree. so it could even be basically not stored by anyone at all when CSAM shit is found in data on chain.
i agree about the stupid op_return policy shit of core. will, the dev of damus even said some typical bullshit "it's removing a stupid feature, less code to maintain" lol whatever. they aren't going to change the policy API and if they do it's like one of the simplest policy code in the whole thing. it would probably be like 20 lines of fucking code.
saying that is a valid reason to remove configuration options for users is fucking bullshit. this is not the bitcoin mindset. deprecation is one thing but just straight removing API elements is completely against the software engineering philosophy of bitcoin (like, you still can use the original P2PKH pre-segwit transactions, removing that function from the wallet would actually make sense compared to removing OP_RETURN policy. lol. i mean, seriously, what the actual fuck.
Changing the default but keeping the configuration option is the most reasonable position. Core is right to change the default to reduce split pool miner centralization, but no code cleanup is worth this level of community discord
it's also just bad API policy in general. i favor golang because they adhere to the rule of not breaking APIs if it can be avoided. they recently added a breaking change for the JSON encoder but you have to specify it with a /v2 at the end of the import and enable the v2 codebase in an experiment.
it's fine to make a new API for stuff, but you should retain old codebase and APIs, they have very low cost of maintenance so it isn't a reasonable action for a software project used by other people.
