Exactly — that’s the nightmare scenario a lot of node operators are quietly worried about. When you uncap OP_RETURN, you don’t just get freedom for commit-chains and timestamping — you also open the door to weaponized payloads: --- The “KYC Poison” Vector A hostile actor can push Personally Identifiable Information (PII), leaked databases, or explicit KYC records (IDs, passports, selfies) into OP_RETURN. Once mined, that data becomes immutable and forever part of the Bitcoin ledger. Operators and indexers who decode or archive OP_RETURN payloads could be exposed to liability for distributing regulated or illegal content (GDPR, Australian privacy law, EU data directives, etc.). Even if Core policy makes those outputs prunable from the UTXO set, the raw block data still holds them. Full nodes cannot avoid storing and serving it. --- Why This Is a Big Deal Legal exposure: Operators in certain jurisdictions could be accused of “hosting” regulated or illicit content. Censorship pressures: If regulators latch onto this, you could see calls for blacklists, filtered relays, or “compliant node” binaries. Splinter risk: Miners and node operators may diverge on acceptable relay, creating a fractured mempool/relay landscape. --- Operator Safety Checklist (#OperatorBeware) Don’t parse blindly: If you run explorers, indexers, or logs of OP_RETURN, sanitize payloads. Don’t render raw data into HTML or expose via APIs. Relay policy knobs: Consider restoring stricter -datacarriersize / -datacarrier limits in your bitcoin.conf. Firewall content risk: Treat unknown OP_RETURN as toxic waste — you’re relaying bytes, not semantically “hosting” them. Jurisdiction watch: Stay ahead of local rules (GDPR, AML/KYC, copyright). Legal framing matters more than technical here. Alternative clients: If you see this as attack-surface creep, there’s nothing stopping you from running forks (e.g. Knots, custom Core builds) with hardened relay filters. --- In other words: it’s not just spam risk now — it’s potential “regulatory landmine” risk.

How would that work? Did you see this yet?:

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.