idk who needs to hear this, but you don't have to update your bitcoin node software. bitcoin node software is backwards compatible and no one can push updates to your node that you do not want.
Discussion
It's been 5 years since I've updated mine.
Then you are opening youself up to DDos attacks, fee management issues, privacy leaks, ect
It's been 5 years, haven't had any of those issues
That’s not how Bitcoin works.
What? Haha
He said you don't know what you're talking about.
RTFM.
If it's in the chain it's on your node
True, but do you need the list of CVEs that would help you understand why that's a bad idea?
What happens when there’s a security vulnerability found that affects 29?
Fixes get backported usually in couple versions back. Again, up to you whether you update your node or not.
100k byte, raw CSAM is still going to end up on your hard drive whether you update on not. Valid transactions.
Propagation path remains scarce if only a few nodes and miners run v30/libre relay nodes. It matters no matter how much you guys push this narrative.
Raw bytes of data (probably incl CSAM) are already on your hard drive, because people have been putting these into witness for years as inscriptions, since these bytes are actually discounted in terms of fees. 
E.g. Transaction: 521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79da - mempool - Bitcoin Explorer https://share.google/yr7OQxAgC6XNThp7w
AFAIK these are “chopped up” into segments or no?
No, check out that transaction. The limits for script witness are currently 4MBs by consensus and 400kBs by standardness.
(Please correct me if I'm wrong, but this is my read of it)
https://bitcoin.stackexchange.com/questions/117594/what-are-bitcoins-transaction-and-script-limits
And if I'm correct, then the whole Knots CSAM argument is just fear mongei, right?
I didn't see anything in your link that told me what I needed in order to see witness data and I've never tried to do it so I used an LLM and this is what it told me I needed to extract the data:
-bitcoin-cli (to dump the raw transaction)
-jq or another parser to extract witness fields
-xxd or Python/Go/Rust to reassemble hex into binary
-Knowledge of file formats / scripting skills
Here is for OP_Return:
- copy / paste hex to binary with one command
One seems harder to get as a normie...
Also, as a knots node, I am not forced to send data I don't want to participate in. If it ends up on the chain anyway, atleast I wasn't complicate in propogating it
The effort is almost the same, for reading OP_RETURN using bitcoin_cli the script would look very similar - i.e. it reads the bytes following "OP_RETURN" (i.e. "6a" in hex), for ordinals/inscriptions the script reads the bytes that follow "ord" (i.e. "6f7264" in hex) and it skips the "4d" bytes every 520 bytes...
Of course people will create viewers like mempool space that make this much easier. Same as they did for the data in witness/inscriptions: https://ordiscan.com/tx/eadfab095bfe5bcfde6024126ef139ac0e98f19dcb4c8fc4e96bfa87cc39141e
The first paragraph doesnt seem very compelling. Im relatively technically compitent and that doesnt seem straight forward yo me but maybe we can agree to disagree there.
The second paragraph however is the most compelling thing I have seen yet. Thank you for sharing that. But this is still a website on the clear net that obviously cant host csam on it. So a normal person running a node couldn't use that website to see csam if it was there. It would then only be easily seen with OP_Return on their node
Am I missing something or do you disagree?
For the first paragraph - The main argument here is for bitcoin node runners - and that assumes that you are running a node. And I think most node runners are comfortable with running bash one-liner.
For the second - When you are running a node you usually also run local explorers connected to your node (e.g. mempool space is built in in most node packages, like Umbrel), in the same way there are ways to run ordinals explorer locally.
The website that I shown is using it's own local bitcoin node to read from and if there is CSAM in inscriptions (nothing is preventing that), then that node also has CSAM and there is a chance that that clearnet website would show it, unless they implemented some strong system to do analysis and filtering of CSAM before it gets displayed.
It's important to note that CSAM is utterly disgusting, but nothing in this discussion seems to be making any difference (or even being related to) to actually preventing child abuse.
I pulled up my mempool instance in start9 and I'm looking at block 913983. I'm looking at the witness data and I do not see 6a or 6f7264 anywhere. The fact that you needed to tell me what too look for I feel like is proving my point haha. The witness data is crazy long and would overwhelm most people. Isnt that because its split up like you are saying every 520 bytes?
I run a start9 so I don't see ordiscan on their registry or community one. I didn't even know there was another one besides mempool.space.
And I mostly agree that is not stopping CSAM or child abuse for that matter. I just dont see why Core decided node runners should be required to relay it and store it on their own computers. Why do they want to give another place to put spam, that I would argue is easier to see for a non tech person? I don't want to facilitate spam because I just want it to be money. I understand the UTXO bloat argument but if the spam is in op_return it would cost more anyway so idk why they would use it unless to make a statement with something explicit or to attack the network.
Do you give any volitity to the idea that if somebody put malware in the OP_Return that it would trigger antivirus on nodes around the network? Especially cloud ones for example? I understand they wouldn't be executable but I'm hearing it could still set them off. Thoughts?
So then is it that the level of effort required to contort that back into a picture is high enough that it’s not a legal problem for node runners? The effort required is (significantly) lower if it’s in opreturn? Vaguely heard about this.
In both cases it's a bash script one-liner to extract the data from the chain. Not really practically different.
Again, someone please correct me if I'm wrong, but this really makes the whole Knots CSAM argument just plain stupid scare tactics...
I think two other commenters here corrected this
Yeah, from the other comment I learned that there is a sequence "4d" inserted every 520 bytes, but the ways to retrieve this data are the same for almost all intents and purposes.
So is the claim that there is a law that specifically defines that image has to be stored in continuous bytes (without any extra bytes inserted) to be considered CSAM?
(correction, the inserted sequence is "4d0208" in most cases, because it includes the length)
This has nothing to do with laws. It is a malware detection issue because of the contiguous state of the data.
The one topic that has been heavily discussed above was CSAM - there it's about laws.
About malware - continuous or not doesn't really have effect here, right? The way how malware is detected is via detecting fingerprints (short byte sequences) that are common to the malware or via heuristic analysis, or via some other tricks (like running the code in sandbox). So if there is malware stored in inscriptions or in op_returns would be detected the same way with probably the same results. But taking a step back - this isn't even a real concern, since node-to-node packets are now encrypted, right? (since BIP 324 is enabled by default in Core)
So what is exactly the argument about malware in this case?
The argument is validation. When validating those bytes are processed in the clear decrypted. (XOR doesn't change this) also, the finger prints for malware detection are more like heuristics. Does this have 1 fingerprint? Yes, check for 2. And so on. (This is obviosly so the antivirus ALSO isn't running those same contiguous bytes through its processor).
As far as CSAM goes I am fairly certain (though I don't dare try it) that if you run those bytes through something as basic as VLC you will get an image. No additional encoding necessary. Meaning you are storimg a raw data file of terrible shit in ram that you could conceivably render with simple image software NOT some inscription decoding taproot wizard shit.
The malware is an attack vector, the CSAM is more or less gross despicable shit. All enabled by 100kb OP_RETURNS easily propagated through the gossip network.
Yeah, see how it uses "OP_PUSHDATA2" over and over again? That makes the data non-contiguous because the there is a byte limit when you push data on the stack. (Or else the script doesn't know where your transaction ends) this is not 100kb CONTIGUOUS data. Meaning it IS chunked up.
Ok, so the main difference is that in witness encoded data you have "4d" inserted every 520 bytes, but it only costs 1/4 of fees?
Well, not exactly. Contiguous bytes that amount to CSAM, or malware in general would cause people who run a VPS node to probably have their VM shut down. That's probably 20% of the node netwprk, including major players like exchanges and mining orgs. THAT is the attack vector. Then the mitigations would be effectively having VPS providers whitelist Malware (which they won't). Having the pushbytes allows the data to be segmented and it won't trip malware detection. Nothing to do with the fees.
You're missing the technical difference in visibility.
Now: Arbitrary data is buried in witness fields, requiring special software to decode and view.
With 4MB OP_RETURN: The data sits plainly in a standard output. Any node parsing the chain can see it without special explorers.
It’s the difference between data being technically present versus being unavoidably visible.
And that's a huge difference. Don't sugarcoat it.
Is core going to parse this automatically? Is there like an image preview in core GUI or something
No, Bitcoin Core won’t parse or preview images, even with 4MB OP_RETURN. But with the larger limit, you could embed big text art or ASCII images right in a transaction, making complex visuals from letters and symbols possible on-chain, way beyond what was doable before. Only actual images/binary would still require extraction to view as pictures; however, it's only logical to expect popular block explorers to quickly add binary extraction features for user convenience.
Okay so you still need special software. It’s all 💩 but as soon as I don’t have to see it and it does not stop me from getting my usual txs mined I don’t care.
As a side note I decided to give knots a try for a few days we’ll see how it goes but so far all good.
Since it’s all 💩 and most of it might not even be mined ever I might as well save myself some bandwidth 😄.
True, but alteast I won't be choosing to relay it and share with others
are you planning on not relaying confirmed blocks at all
Lol cmon man. My mempool and the blockchain aren't the same. I hope you're trolling
I'm not. if you relay confirmed blocks, you relay all different types of arbitrary data that were already embedded in those blocks
Only to maintain consensus. I don't think anybody wants a fork here. I'm just not interested in helping give spammers another place to put their data.
that goalpost wasn't here a minute ago. you were talking about not choosing to relay CSAM
Are you going to help relay it before it gets into a block?
it doesn't help. I'd be saving myself from relaying the data for only 20 minutes. if you really felt like lady law was going to get you, do you think this would help your defense at all?
That's not what I asked. Are you going to choose to store it beforehand and relay it to your peers as node policy?
yes I know, and it's a very stupid question. if you relay blocks at all you are already relaying illegal data. this is a fact. if you are afraid of that you shouldn't run a bitcoin node. you are trying to make this into a thing where you are being safer or more virtuous by pretending valid transactions don't exist for their first 20 minutes, making your node run less efficiently for no benefit, and like I already explained it doesn't matter. you want to have your cake and eat it too.
It is a reasonable question and I don't understand why its hard for you to answer. I would argue all day that we should relay what is necessary to maintain consensus because maintaining this new monetary system is a net benefit to society even if it includes illicit material. I however cannot defend an individuals actions that knownly and purposely decided to store it when there is a perfectly good alernative. Opening ourselves unnecessarily to legal and the court of public opinion for almost no reason is just not a positive and i don't see why we need to put it on the front page when it can atleast stay buried in witness data for now.
This defeatist additude you have is really sad. The btc community (atleast that run a node and use it) isn't that big yet. You can make your voice heard and make a difference if you decide too.
I think it is wrong from a legal perspective and a court of public opinion perspective to differentiate illegal arbitrary data between STAMPS, OP_RETURN, and ordinals. still if large OP_RETURN values bother you so much, you should make a fork of bitcoin where they are invalid in consensus. it doesn't matter what core does and it doesn't matter if lots of people run knots. these transactions are still valid and we must assume that some miner will get them and confirm them because of censorship resistance. you must make them invalid in consensus.
Telling me to fork myself is not an argument haha. If I was driving and I hit somebody who jumped in front of my car because they had headphones in vs. I'm drunk and I hit somebody with my car, would you say its the same thing because the result is same? Or do you think that would be treated different in each perspective?
there is nobody driving a car or drinking alcohol or crossing the street. don't be silly.
you are propagating confirmed blocks, are you not? and you are aware that confirmed blocks contain multiple different types of arbitrary data that are allowed in consensus including STAMPS, OP_RETURN, and witness data. you are aware that all of these methods have been used to store illegal data. yet you intentionally continue to propagate confirmed blocks. you are knowingly and willingly relaying illegal data right now.
Defaults matter
Core 28.1 will be just fine for a good while ☕
Sadly you do get forced to eventually as bugs get fixed. Staying on pre v30 will work for a bit but it's not the solution
What?
What bugfixes are you talking about. Unless there's a fork of some kind, you can happily run your old node for a long time
idk who needs to hear this, but software has bugs, and running unpatched software is generally a bad idea.
Facts 💯 My node, my rules.