Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain

[gmaxwell]

Please spare us the AI histrionics.

As pointed out, none of this is new, there is even malware embedded in the chain back in 2011 or 2012.

Nor is 'I can run some obscure RPC manual export commands and _then_ run it through a separate tool (three-- in fact-- jq, sed, and xxd) to decode hex to binary and write it to a file and anger my dumb AV'  new -- no one would do this, but if they would, it's a personal problem and an already existing one. "Doctor, doctor! I bleed when I shoot myself in the head!".

Large op_returns from an attack perspective *cannot be prevented* (without a consensus change which no one has proposed) because the attacker can just use nicehash and rent hashpower, also because major miners *already eliminated the limit*, and one need only directly hand the transaction to their nodes.  The same data, as others have pointed out here can also just be stuffed elsewhere (which is why no one proposes a consensus change).  If there were going to be problems it's very likely they'd already be seen.  If ones crop up later, they'll get fixed.  AV scanning at *worst* trips up a small number of nodes primarily on windows-- we know this because we've seen it before.  That's why some data on disk has been xored for many years-- incrementally where we saw problems, so there is experience on dealing with it.  The system has to be robust against bad data, if it isn't-- that's a bug that needs to be fixed.  Experience suggests that it is already robust, nothing your AI is saying is countering that so far.  Perhaps there are other areas for improvement, if so that's fine but it's not related to any recent changes. Because, repeating, to whatever extent there is a problem it already exists-- and we already know what AV impacts look like when there is a problem and it's a nuisance rather than anything of grave concern.

Otherwise, this is why we have things like P2P encryption which your AI seems to be dumbly unaware of, so for example enterprise firewalls that nuke connections that have 'bad content' or the GFW with "Tiananmen Square massacre" won't isolate nodes... so just give it a break.  I am so tired of inactive aged (and probably purchased) accounts spewing AI nonsense trying to create a false narrative to undermine bitcoin.  You were instantly reported on your first new posts and I should have just nuked you then on the reports.  The only people you're fooling are weak minded and irrelevant.

But hey, I should thank you in one respect:  Every time someone like this shows up arguing these points and people like Luke-jr and his sycophants at ocean mining stay silent at the manipulative falsehoods being uttered on their behalf when they would be best positioned to calm them down it further shows them to be either incompetent or corrupt persons without integrity or care for the health of Bitcoin.

[shinohai]

Please spare us the AI histrionics.

As pointed out, none of this is new, there is even malware embedded in the chain back in 2011 or 2012.

Nor is 'I can run some obscure RPC manual export commands and _then_ run it through a separate tool (three-- in fact-- jq, sed, and xxd) to decode hex to binary and write it to a file and anger my dumb AV'  new -- no one would do this, but if they would, it's a personal problem and an already existing one. "Doctor, doctor! I bleed when I shoot myself in the head!".

Large op_returns from an attack perspective *cannot be prevented* (without a consensus change which no one has proposed) because the attacker can just use nicehash and rent hashpower, also because major miners *already eliminated the limit*, and one need only directly hand the transaction to their nodes.  The same data, as others have pointed out here can also just be stuffed elsewhere (which is why no one proposes a consensus change).  If there were going to be problems it's very likely they'd already be seen.  If ones crop up later, they'll get fixed.  AV scanning at *worst* trips up a small number of nodes primarily on windows-- we know this because we've seen it before.  That's why some data on disk has been xored for many years-- incrementally where we saw problems, so there is experience on dealing with it.  The system has to be robust against bad data, if it isn't-- that's a bug that needs to be fixed.  Experience suggests that it is already robust, nothing your AI is saying is countering that so far.  Perhaps there are other areas for improvement, if so that's fine but it's not related to any recent changes. Because, repeating, to whatever extent there is a problem it already exists-- and we already know what AV impacts look like when there is a problem and it's a nuisance rather than anything of grave concern.

Otherwise, this is why we have things like P2P encryption which your AI seems to be dumbly unaware of, so for example enterprise firewalls that nuke connections that have 'bad content' or the GFW with "Tiananmen Square massacre" won't isolate nodes... so just give it a break.  I am so tired of inactive aged (and probably purchased) accounts spewing AI nonsense trying to create a false narrative to undermine bitcoin.  You were instantly reported on your first new posts and I should have just nuked you then on the reports.  The only people you're fooling are weak minded and irrelevant.

But hey, I should thank you in one respect:  Every time someone like this shows up arguing these points and people like Luke-jr and his sycophants at ocean mining stay silent at the manipulative falsehoods being uttered on their behalf when they would be best positioned to calm them down it further shows them to be either incompetent or corrupt persons without integrity or care for the health of Bitcoin.

This is the finest reply I have read in this thread. The op_return whataboutisms and pearl clutching are getting so tiresome.

[wrapperband0lite]

Thanks, gmaxwell, and thanks, shinohai, for jumping in.

What I hear you saying (in simple terms):
• This is not new. People have put malware or signatures in the chain for years. 
• Exporting blocks and poking them until an AV trips is not a real-world workflow. If someone does that, it is their problem. 
• Bigger OP_RETURN cannot be stopped without a consensus change, and data can go in other places anyway. 
• If this were going to cause trouble, we would have seen it already. At worst a few Windows nodes get annoyed, and XOR on disk helps. 
• P2P encryption keeps dumb firewalls from killing connections. 
• You are skeptical of AI-flavored posts trying to make Bitcoin look bad.

My reply:
• Agree on history. Bytes in the chain are old news. My point is narrower: on v30.0rc1 a common AV flags the block file itself when a ZIP’d signature is embedded via OP_RETURN. That is a specific, repeatable result with scripts anyone can run.

• Exports and plaintext copies are real. Teams export blocks for debugging, research, support, and backup. NAS and backup scanners, CI and email gateways create and scan plaintext copies. I even had a security email bounce because the gateway flagged the artifact. This does not require exotic steps.

• XOR helps at rest, not end to end. Fresh v28+ IBD uses XOR on disk. It does not help when you export, back up, or share data, or when Core reads data to serve it. Many nodes have mixed or non-XOR data.

• Other data paths exist, yes. That does not change this point: making OP_RETURN larger makes it easier and more frequent to drop content AVs already search for (ZIPs, nested archives, multiple signatures). Easier and more frequent means more incidents for operators.

• Not a consensus ask. I am not proposing a consensus rule. I am asking that this operational risk be acknowledged while discussing OP_RETURN policy, because it affects real nodes and backups.

• P2P encryption is unrelated. The repro is about files and exports being scanned at rest or in transit on backup and mail systems, not about in-flight P2P filtering.

Concrete ask 
If this exact operational risk was already considered and accepted, please point to the issue, PR, or mailing list discussion. If not, a short acknowledgement and a tracking reference for v30.0rc1 would close the loop. I am happy for others to run the scripts and post their results.

Thread with scripts and proof (regtest, safe malware test string): 
Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain