Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3

AceHack commented at 8:01 pm on September 3, 2025: none

This is a significant security issue. I don’t want to allow easily decodable images in my transactions because, by law, I would then be responsible for content moderation. Please save Bitcoin for the little guys like me so we can continue to run a node and home miners legally without fear. I hope nothing immoral or illicit that is easily decodable ever makes it into the actual chain, the miner responsible should be immediately arrested who mined that block. I don’t want to relay this crap either before it makes it into the chain, that is still very dangerous for node runners.

You have the power, please choose correctly.

pinheadmz commented at 8:10 pm on September 3, 2025: member

v29 and all supported previous versions of Bitcoin allow “easily decodeable images” in transaction data, inscriptions proved that. In fact, stuffing data into witness blobs is cheaper than stuffing it in to op_returns. I think this issue should be closed as a duplicate but you can still comment here (or, perhaps more appropriately, on bitcoin.stackexchange.com) if you have additional questions. Please keep in mind the Bitcoin Core issue tracker is reserved for specific implementation issues and feature requests and conversations should stay on topic.

achow101 closed this on Sep 3, 2025

AceHack commented at 8:27 pm on September 3, 2025: none

I will use bitcoin.stackexchange.com, thank you for your kind response, but one triggers advanced AV and one does not; it’s all in one contiguous block, inscriptions is an exploit, not desired behavior.

pinheadmz commented at 8:30 pm on September 3, 2025: member

Witness blobs are also contiguous data. Out of curiosity what is the source of your information?

AceHack commented at 8:37 pm on September 3, 2025: none

It’s my understanding you cannot simply copy the raw bytes from a Bitcoin block or mempool and open them as an image file without using Ordinals-specific software to reassemble them correctly, therefore won’t trip AV. This is not true for the larger op return, that WILL trip AV. I’m trying to look at the code and gather the information myself, I’ve been a developer for 25+ years. I apologize if I get anything wrong. (Also I apologize as I’m being a little vague purposely because of the sensitive nature of this conversation)

pinheadmz commented at 8:55 pm on September 3, 2025: member

There are other types of data stuffing that do require reassembly, like imagine creating a transaction with 100 outputs and each output’s address was a piece of a large blob.

But inscriptions embed data in a witness blob in a single transaction input.

Example: https://mempool.space/tx/64359c5b7e0ab1ad19ad7682bc9e95fd7c25ef85f115cb0fe6d37cce54611111?mode=details

Over 1 kB just in the witness. Contiguous data. See if you can decode the data yourself! Supposedly it is this image:

https://ordinals.com/inscription/64359c5b7e0ab1ad19ad7682bc9e95fd7c25ef85f115cb0fe6d37cce54611111i0

sipa commented at 8:59 pm on September 3, 2025: member

The block data is obfuscated on disk, to avoid AV software triggering on the files.

Policy changes aren’t relevant for this; the transactions can make it into blocks without problems, regardless of what your software allows in its mempool.

AceHack commented at 9:00 pm on September 3, 2025: none

Yes but not in the mempool where windows core isolation scans and others advanced scanning software. Memory is scanned too which is why I don’t want to relay this stuff cause then I have to decode it into memory on my node, my bitcoin node software is not decoding any of that other stuff into something that would trip AV scanning.

sipa commented at 9:03 pm on September 3, 2025: member

If you don’t care about having a useful mempool in your node you can disable it with the -blocksonly setting. But even that won’t prevent your node from downloading, processing, and holding into memory the transaction when it makes it into a block.

pinheadmz commented at 9:04 pm on September 3, 2025: member

The real problem is, you already do relay that stuff. The v30 release won’t affect that. You can choose to run without a mempool in -blocksonly mode. Otherwise, fine-tuning censorship into a system that is censorship-resistant by design is a major technical challenge and we could use your help!

AceHack commented at 9:13 pm on September 3, 2025: none

I disagree, I don’t relay op return larger than 40(43) bytes today, so I absolutely don’t relay “that” stuff. Suppose someone has chosen to hack/exploit data into fake addresses, witness data, and write complicated logic to reassemble that data elsewhere, that is beyond the scope of what I can reasonably control as a node operator and I strongly disagree with. I can’t be held responsible for that. I CAN be held responsible for relaying data that is obviously illicit without any reassembly required other than the Bitcoin node software itself. I won’t be part of that immoral act and I have 15 bitcoin as my life savings and I’m saying that.

AceHack commented at 9:21 pm on September 3, 2025: none

Also, this is not censorship, this is individual bottom-up node filtering, the opposite of censorship. Not allowing node runners to filter obvious illicit data or “ban” them from the mempool is the definition of censorship. The 3 update will actively censor the node runners’ ability to filter data they deem illicit without being punished, and features restricted that make home mining impossible, further centralizing mining, which, I guess, is the goal of this update.

sipa commented at 9:33 pm on September 3, 2025: member

Nobody is prevented from anything, as nobody is required to run Bitcoin Core, v30 or otherwise. I realize this may sound snarky, but it is very sincere: Bitcoin’s strength lies in the fact that the network is ultimately defined by what software people choose to run, of their own choice. I obviously disagree with you in this particular case, but I do hope that if ever Bitcoin Core actually ships changes that hurt the network, that you and other users choose to run something else.

As for motivation, see https://bitcoincore.org/en/2025/06/06/relay-statement/. The point is the opposite of centralization: if network nodes refuse to relay transactions with active demand on the network, all it takes is for someone to build infrastructure to relay it to miners directly. And when that happens, (1) it becomes harder for new small miners to enter the business and reap the same rewards, especially anonymously and (2) your node will still be downloading and processing the same transactions, because once they make it into a block, you have no choice to accept them - doing otherwise would amount to forking off into your own currency.

AceHack commented at 9:44 pm on September 3, 2025: none

Sorry, it seems from an outsider’s point of view that you are incorrect in your assessment, and I will not be running Bitcoin Core software and will actively encourage everyone I know to look for alternatives. This may inspire me to create my own. I have a deep background in cryptographic systems and older consensus mechanisms, such as Raft and Paxos, so this is within my area of expertise. Larger miners already have several ways to hurt smaller miners within Bitcoin if they wish; it’s a weakness of the system with large centralized mining pools that this new update will favor. Bitcoin is for money; everything else on-chain is spam and exploits, or we risk breaking what Satoshi gifted humanity. I do hope you are correct and this won’t hurt Bitcoin, but from everything I can gather, it most certainly will.

Someone figured out how to do the “hard” way and hide illicit pictures in transactions, so instead of punishing that bad behavior, we are just gonna say, Hey, everyone, we are making it super easy for illicit pictures now, We thought it was too hard before. This disgusts me, really, and I hope you can live with your morals and refrain from harming the network any further.

AceHack commented at 10:04 pm on September 3, 2025: none

From a small home miner’s perspective, I have two options when using Bitcoin Core.

Participate in mempool, which allows mining, relaying these anonymous P2P elicit images, risking prosecution.
Disable mempool, not allowing me to mine without using someone else’s node, breaking the zero-trust Satoshi’s Bitcoin built.

Therefore, Bitcoin Core as of v3 is no longer for home miners and decentralized mining; it now prefers centralization of miners and caters to their needs over those of home miners.

When this is released it will be a sad day for Bitcoin

AceHack commented at 10:42 pm on September 3, 2025: none

I have five children, four of whom are girls. It makes me angry to think some dumb ex-boyfriend without any effort at all can stick underage pictures of her easily in the OP_RETURN on the blockchain for anyone to see, and it’s there forever, immortalized on the blockchain, and Bitcoin Core can decode it without additional software. I would make it my life’s mission to destroy Bitcoin if that ever happened, even though I currently have immense love for it. I imagine any person who thinks of their family before profit would feel this same way. Get ready for Pandora’s box.

wrapperband commented at 2:09 pm on September 4, 2025: none

Please do not excessively increase op_return size. The coder will be as responsible for miss use as tornado cash developer - and they ended up in prison.

darosior commented at 2:35 pm on September 4, 2025: member

I’d like to point out this concern was already addressed at length here, here and here. Storing illegal content has always been a risk of running Bitcoin, no matter the encoding of the data. The mentioned relay policy change does not materially affect this risk.

glozow commented at 2:43 pm on September 4, 2025: member

The concerns outlined in the issue have been addressed. The discussion is now about open source developers’ responsibility for usage, which is off topic.

A discussion page is available for feedback on moderation around this issue, #33240, #32381, #32359, #32406 etc.

bitcoin locked this on Sep 4, 2025

Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3 #33298