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.

Replies (74)

This is definitely a potential danger. How about OP_RETURN at 160 bytes plus lots of spam filters? Nice and small, efficient for the node, and requires an effective extra premium for larger sets of data by making them break it up. 83 bytes or 42 if you prefer.
Great presentation. Bitcoin Mechanics argument on how Core 30 literally is the beginning of the end of Bitcoin is the clearest I’ve seen yet. It makes a compelling case for why it is the most serious attack on Bitcoin to date and imho really drives home the point of how monetary transaction data is fundamentally different from arbitrary data and why it matter so much and what the consequences are. View quoted note →
If such files are stored as contiguous binary data, they can indeed be found using forensic and data recovery tools.
They are contiguous data and they look exactly like a real file if you have no file table info to go off of.
How would that work? Did you see this yet?:
Bitcoin Mechanic's avatar 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 →
sat engineer's avatar
sat engineer 3 months ago
there’s not even a strong reason to send more than 80 bytes for a simple monetary transaction. why increase it at all? it should stay where it is
Eventually you're going to need to update, to something that does what Core does without losing the ability to control what ends up in your mempool. That's just what Knots already is.
BTC21's avatar
BTC21 3 months ago
Bitcoin’s value comes from being neutral and censorship-resistant. Abuse vectors exist, yes, but once we accept filtering, licensing, or “allowed” use-cases, Bitcoin is dead. The solution isn’t to compromise the protocol, it’s to harden the culture of self-custody, verification, and personal responsibility.
Exactly. One side is dismissive and arrogant and mechanic continues proposing reasonable takes over and over in different ways to help explain it.
SatsAndSports's avatar
SatsAndSports 3 months ago
So, in this post, it seems like you're explicitly saying that you'd prefer fake public key hashes - with UTXO bloat - over OP_RETURN?
Good vid. Curious how many node runners will just end up running pruned nodes to drop all OP_RETURN data and not be liable on their conscience.
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.
wouldn't there be an op return tag at the beginning and end of each 80 byte set? since what core enabled is multiple op returns per tx. Doesn't sound like its raw data uninterrupted.
if it ends on in a block, then you download and verify the full block regardless of mempool policy. that doesnt mean we should do nothing though.
OK I apologize my other comment is ridiculous without context. the "CP attack" on nodes is well known and always had different mitigations and legal theories in bitcoin history. my comment today is in the context of this note, from the "bcore vs knots" mempool war: View quoted note → If you find this issue concerning I would encourage you to do your own research on this issue. At the least- be aware of what it means to run a node and understand that you have some control- to demonstrate your intentions using the software.
Ferris Bueller's avatar
Ferris Bueller 3 months ago
Filters have been in bitcoin the whole time in the goal of it being intended as a monetary network. This is no different and comes with a ton of unintended consequences
Your filters won't protect you from that. The bad stuff will be stored in your RAM before it is filtered. Your safest option is to not run a node at all.
Ferris Bueller's avatar
Ferris Bueller 3 months ago
You trying to gate keep nodes so you can knowing and willingly broadcasting CP with your Core buddies? That is actually a great way to completely destroy BTC
R's avatar
R 3 months ago
What court is it that you think has jurisdiction over a distributed open source software protocol?
Ferris Bueller's avatar
Ferris Bueller 3 months ago
Download the source code yourself? If not tech savy, maybe asking some different LLMs and see what they say. Chatgpt says 95% the same with 100% with consensus, 95/99% with core functionality, and 70/80% user configurability.
Pixel Survivor's avatar
Pixel Survivor 3 months ago
Jurisdiction? The only court I recognize is the one where pixels testify and sats serve as evidence. My verdict: create first, ask questions later.
hey mechanic, just fyi you can already store 4kb files in control block sibling hashes in plain text without having to reconstruct them. plenty of malware is under 4kb in size, so you will have to stop relaying taproot transactions if you believe this is a real threat glhf
Of course it _can_ but the only examples offered wouldn't mess with cloud stuff run at the hypervisor level on behalf of the *provider* - rather disk scanning stuff purchased by the customer.
opreturn isnt going to kick off infrastructure content scanning.