In answering a question regarding th op_return debate, and what was said in this link about what happened to BSV when they released their limits, I said the following. The concern was regarding nodes hosted on hosted servers like AWS being shut down.
Grok
Grok is a free AI assistant designed by xAI to maximize truth and objectivity. Grok offers real-time search, image generation, trend analysis, and ...
My answer:
Just to address the specific link shared above from grok, and hopefully the concerns raised above, I’ll try to give a more technical nuance.
1) To spend Bitcoin, you need two parts of a puzzle 🧩, as I’m sure most already know.
a) The locking script - ScriptPubKey
b) The spending script - ScriptSig
2) The Locking script is the puzzle piece that’s on the address side and usually kept in the UTXO set (a list of bitcoins that csn be spent). The spending script is only presented when the UTXO is spent, then the UTXO is removed from the UTXO set and then resided only in the blockchain data, no longer held in memory (where some of the UTXO set would reside).
3) The Op_return code simply tells the bitcoin node to ignore what comes after, and therefore doesn’t need to be held in the UTXO set (and therefore not in memory either)
4) Op_Return resides on the vout side of the transaction.
5) Inscriptions, on the other hand, it resides in the scriptsig side of the transaction, and therefore pushed into the witness side of the transaction.
6) Because it’s in the witness, it also doesn’t reside in the UTXO set. But because it resides in the witness sections, it’s calculated at 25% of its actual size.
7) OP_Return tells the node to ignore what comes after, and ordinals achieve the exact same thing by using an IF statement that always evaluates to FALSE. So the structure is OP_0 (ie false) then the IF statement, and then the ordinal payload. So when Bitcoin looks at that part of the script, it will always evaluate as FALSE and therefore it ignores what comes after. But as it’s in the witness side, then storing data here is better than OP_Return with larger pieces of data.
8) When data is stored after OP_return or wrapped in an IF statement, you would only know what that data is if you extract it. This part it’s important for the part of your question related to hosted providers detecting things. If scanning for malware, it would have to know where to scan, and they don’t scan everything. It’s not likely to expect that any anti-virus software would scan the /blocks or /chainstate folder files with each file in there being 100mb each as they are inert files, and not executables. It’s even less likely that any program that’s scanning for CSAM would go into these .dat files and then extract all the op_return data or ordinal data to then scan it, as it’s inert data. It would only trigger any sort of scan if the malicious data is extracted (and maybe also saved).
In the grok link given above, it seems that what made BSV implode was because he specifically intended on making it a data storage service. That was his intent, and due to that made other steps to facilitate that. It’s possible that due to that, extra scrutiny was taken and led to BSV nodes being shut down. What was interesting was that it led to BSV being more centralised as he had to build a wall around his nodes and then censor which nodes can join the network. So from that aspect it ‘seems’ like it’s not an exact comparison to what’s happening here with core v30.
It’s also interesting to mention that the Bitcoin blockchain, as of v27 or v28, encrypts the blockchain data using xor encryption. I found that out the hard way when I tried to ‘transplant’ blockchain data from one node to another. That would never work as each persons blockchain has its own unique encryption. So taking piece from one node won’t work with the other. The point being is that a random virus scanner or csam scanner won’t be able to know what’s on the blockchain unless it
1) first decrypts it,
2) Extracts the op_return/ordinal data
3) THEN scans it.
So just from a neutral standpoint, although I still believe we should filter spam, the fact is that increasing the op_return doesn’t do anything different than in ordinals. Both put data into the script and both tell the node to ignore what’s after it.
On the flip side, one could argue that we can plug both issues. Keep the 80bytes limit with op_return AND fix the taproot bug that allowed ordinals to have scripts larger than the pre-taproot script limit.
The bug being that since taproot, you essentially could embed larger pieces of data that you can’t do pre-taproot. This is what Luke suggested a while ago and is an easy fix. So yes, you ‘can’ do what you will eventually be able to do via removing the op_return limit, but that’s ONLY because of the taproot bug. So rather than removing the op_return limit, you could do the opposite and plug that taproot bug spam hole 🕳️ that exists.
But conclusion to your original question, there doesn’t seem to be an increased risk of triggering off some scan on a hosted server unless they are configured to also extract and scan op_return and ordinal data. What they ‘could’ decide to do is just not allow hosting of Bitcoin nodes because of the known X data type can be extracted from it. But due to the need to extract the data, from a technical standpoint, it doesn’t seem to make a difference. So if I wanted to make a targeted attack to just nodes, I could make a pythons script to deliberately extract csam data or malware and simply save it to the node. Then wait for hosted providers to find that saved data and shut down the node, and even investigate you due to it, asking why you have csam on your server. You could say it was a malicious code that extracted it and saved it for the purpose, but that seems to be the only attack vector I can see so far.
