Yes, but it would be even more inefficient to use op_return, instead you'd put the same crap in the witness data because witness data uses less of the consensus limits (which are the only limits that matter to miners).

Yes, always could have but it's easier now because miners have infrastructure to allow it.  In the far past you'd have to mine your own block or perhaps talk Wang Chun into doing it with F2pool. ... or you could just split into lots of fake addresses and not even bother with getting a miner's help.

No op_return is already not the cheapest way to do this, sticking it in signatures is. However, if for whatever reason you didn't want to use signatures you can emed the data as fake addresses, it's only a little less efficient and isn't non-standard, has never been non-standard, and couldn't be made non-standard (because it's not distinguishable to someone who doesn't have your key)

Yes, this is true and it is unchanged by op_return limits.

No, it makes no difference to that abuse since you wouldn't use op_return anyways.

If it was the way you thought opinions would likely be very different.  It hopefully will not surprise you to know that Bitcoin developers have cared about this threat all along and really dislike it, and that it has driven much of the efforts to minimize arbitrary data in the chain.  The fact that it's "spam" is too judgemental for most of the rather libertarian early Bitcoin developers at least, but the fact that it could make running a node legally problematic is a concern.  

It seems fundamentally impossible to block, at most it can and isbe made quite expensive (and it is).

The existing countermeasures is the block files and utxo set are encrypted on disk with a key that is unique to each node, so that automated scanning like photo recovery tools, illegal image searching tools, and anti-virus won't turn up anything.  Bitcoin Core also doesn't offer any "random access" to transactions, only whole blocks if you're not pruning-- proposals to add such random access that could turn nodes into image file servers were rejected for explicitly this reason (much to Mike Hearn's outrage). And there is no interface via RPC or GUI to view images or other such data that has been stuffed in, when the data is accessible at all it's only there as hex encoded binary for diagnostics.  These protections have been put in and maintained for years because it was always understood to be a risk of Bitcoin. --- an inscriptions browser would probably be a popular feature even among people who hate inscriptions, but because embedded data may be illegal or just harmful (like scams trying to trick you), it's better to not provide access.

I would hope that a competent legal decision would look at the facts and say that one someone has snuckstuck in illegal data secretly by encoding it into transactions, and you don't even know about it and don't have practical means to access it yourself-- that the illegal thing ought to actually be the access *instructions* rather than the blobs.  This issue isn't unique to Bitcoin someone could secretly encodeIn theory, assuming normality, every illegal data into all mannerpiece of places, advertisementsdata that will ever be exists in news papers, the backgrounddigits of public audio recordings, QR codes on busy city walls, encoded into ebook cover art uploaded to Wikipedia [1]pi.  Illegal data could even be disguised into court documents.... But it is somewhat worse for Bitcoin because in most cases the illegal material could be removed, while in Bitcoin therekey is both no means to remove anything and no authority that could do itknowing *where*.

This issue isn't unique to Bitcoin someone could secretly encode illegal data into all manner of places, advertisements in news papers, the background of public audio recordings, QR codes on busy city walls, encoded into ebook cover art uploaded to Wikipedia [1], or put in youtube videos [2].  Illegal data could even be disguised into court documents.  ... But it is somewhat worse for Bitcoin because in most cases the illegal material could be removed, while in Bitcoin there is both no means to remove anything (other than pruning) and no authority that could do it.

It's all a sucky thing, but it is not changed by OP_RETURN because the data would not be encoded via OP_RETURN and if it were for some it would at least be better than using 'fake address' outputs because OP_RETURN is pruned (meaning you can get the data off your systems by using pruning) and doesn't gunk up the UTXO set.  And 'fake address' outputs can't realistically be blocked.

In the long run this will likely end up before courts and hopefully the outcomes will be good.  Though this risk is also part of the reason that there is interest in UTXO based sync, even through accepting a UTXO set is a radical change in the security model it would mean not having to handled old pruned data that might be unlawful.  (and keep in mind OP_RETURN like witness data is pruned, so if there is any objectionable content we strongly prefer it be in the pruned data.  If it is in 'fake addresses', then it's not eliminated by pruning and can't be.


[1] Fun fact: back before Bitcoin was a thing and I was one of the volunteer sysadmins of Wikpedia I discovered that some clever people were unlawfully sharing ebooks by uploading tiny thumbnails of the cover art with an embedded RAR stuck to the end of the image!  The rar decoder would ignore the jpeg and unpack the book.  Sadly I had to end their fun and games.

[2] Less fun fact, sickos have figured out a way to monetize distributing child porn using youtube.  What they do is put encrypted child porn on mega or other dropbox service, and they they put some weird meaningless AI generated video on youtube which has the password hidden in it spread out so you have to watch the whole video.  They then monetize the youtube video, which they can do since youtube sees nothing wrong with it.  There is a thread on this on kiwifarms, last I checked it people weren't even having success in getting youtube to take the videos down.  Fortunately the phenomenal expense of storing anything in Bitcoin means that it can't be a reasonable replacement for the dropbox service.  The only way that kind of material is going to end up in Bitcoin is an attacker hoping that they'll be able to disrupt bitcoin with it, either directly by dissuading people from running nodes, or creating dispute in the community about how to handle this sort of thing.
 

Yes, but it would be even more inefficient to use op_return, instead you'd put the same crap in the witness data.

Yes, always could have.

No op_return is already not the cheapest way to do this, sticking it in signatures is. However, if for whatever reason you didn't want to use signatures you can emed the data as fake addresses, it's only a little less efficient and isn't non-standard, has never been non-standard, and couldn't be made non-standard (because it's not distinguishable to someone who doesn't have your key)

Yes, this is true and it is unchanged by op_return limits.

No, it makes no difference to that abuse since you wouldn't use op_return anyways.

If it was the way you thought opinions would likely be very different.  It hopefully will not surprise you to know that Bitcoin developers have cared about this threat all along and really dislike it, and that it has driven much of the efforts to minimize arbitrary data in the chain.  The fact that it's "spam" is too judgemental for most of the rather libertarian early Bitcoin developers at least, but the fact that it could make running a node legally problematic is a concern. 

It seems fundamentally impossible to block, at most it can and is quite expensive.

The existing countermeasures is the block files and utxo set are encrypted on disk with a key that is unique to each node, so that automated scanning like photo recovery tools, illegal image searching tools, and anti-virus won't turn up anything.  Bitcoin Core also doesn't offer any "random access" to transactions, only whole blocks if you're not pruning-- proposals to add such random access that could turn nodes into image file servers were rejected for explicitly this reason (much to Mike Hearn's outrage). And there is no interface via RPC or GUI to view images or other such data that has been stuffed in, when the data is accessible at all it's only there as hex encoded binary for diagnostics.  These protections have been put in and maintained for years because it was always understood to be a risk of Bitcoin.

I would hope that a competent legal decision would look at the facts and say that one someone has snuck in illegal data secretly by encoding it into transactions, and you don't even know about it and don't have practical means to access it yourself-- that the illegal thing ought to actually be the access *instructions* rather than the blobs.  This issue isn't unique to Bitcoin someone could secretly encode illegal data into all manner of places, advertisements in news papers, the background of public audio recordings, QR codes on busy city walls, encoded into ebook cover art uploaded to Wikipedia [1].  Illegal data could even be disguised into court documents. ... But it is somewhat worse for Bitcoin because in most cases the illegal material could be removed, while in Bitcoin there is both no means to remove anything and no authority that could do it.

It's all a sucky thing, but it is not changed by OP_RETURN because the data would not be encoded via OP_RETURN and if it were for some it would at least be better than using 'fake address' outputs because OP_RETURN is pruned (meaning you can get the data off your systems by using pruning) and doesn't gunk up the UTXO set.  And 'fake address' outputs can't realistically be blocked.

In the long run this will likely end up before courts and hopefully the outcomes will be good.  Though this risk is also part of the reason that there is interest in UTXO based sync, even through accepting a UTXO set is a radical change in the security model it would mean not having to handled old pruned data that might be unlawful.  (and keep in mind OP_RETURN like witness data is pruned, so if there is any objectionable content we strongly prefer it be in the pruned data.  If it is in 'fake addresses', then it's not eliminated by pruning and can't be.


[1] Fun fact: back before Bitcoin was a thing and I was one of the volunteer sysadmins of Wikpedia I discovered that some clever people were unlawfully sharing ebooks by uploading tiny thumbnails of the cover art with an embedded RAR stuck to the end of the image!  The rar decoder would ignore the jpeg and unpack the book.  Sadly I had to end their fun and games.

Yes, but it would be even more inefficient to use op_return, instead you'd put the same crap in the witness data.

Yes, always could have.

No op_return is already not the cheapest way to do this, sticking it in signatures is. However, if for whatever reason you didn't want to use signatures you can emed the data as fake addresses, it's only a little less efficient and isn't non-standard, has never been non-standard, and couldn't be made non-standard (because it's not distinguishable to someone who doesn't have your key)

Yes, this is true and it is unchanged by op_return limits.

No, it makes no difference to that abuse since you wouldn't use op_return anyways.

If it was the way you thought opinions would likely be very different.

It seems fundamentally impossible to block, at most it can and is quite expensive.

The existing countermeasures is the block files and utxo set are encrypted on disk with a key that is unique to each node, so that automated scanning like photo recovery tools, illegal image searching tools, and anti-virus won't turn up anything.  Bitcoin Core also doesn't offer any "random access" to transactions, only whole blocks if you're not pruning-- proposals to add such random access that could turn nodes into image file servers were rejected for explicitly this reason (much to Mike Hearn's outrage). And there is no interface via RPC or GUI to view images or other such data that has been stuffed in, when the data is accessible at all it's only there as hex encoded binary for diagnostics.  These protections have been put in and maintained for years because it was always understood to be a risk of Bitcoin.

I would hope that a competent legal decision would look at the facts and say that one someone has snuck in illegal data secretly by encoding it into transactions, and you don't even know about it and don't have practical means to access it yourself-- that the illegal thing ought to actually be the access *instructions* rather than the blobs.  This issue isn't unique to Bitcoin someone could secretly encode illegal data into all manner of places, advertisements in news papers, the background of public audio recordings, QR codes on busy city walls, encoded into ebook cover art uploaded to Wikipedia [1].  Illegal data could even be disguised into court documents. ... But it is somewhat worse for Bitcoin because in most cases the illegal material could be removed, while in Bitcoin there is both no means to remove anything and no authority that could do it.

It's all a sucky thing, but it is not changed by OP_RETURN because the data would not be encoded via OP_RETURN and if it were for some it would at least be better than using 'fake address' outputs because OP_RETURN is pruned (meaning you can get the data off your systems by using pruning) and doesn't gunk up the UTXO set.  And 'fake address' outputs can't realistically be blocked.

In the long run this will likely end up before courts and hopefully the outcomes will be good.  Though this risk is also part of the reason that there is interest in UTXO based sync, even through accepting a UTXO set is a radical change in the security model it would mean not having to handled old pruned data that might be unlawful.  (and keep in mind OP_RETURN like witness data is pruned, so if there is any objectionable content we strongly prefer it be in the pruned data.  If it is in 'fake addresses', then it's not eliminated by pruning and can't be.


[1] Fun fact: back before Bitcoin was a thing and I was one of the volunteer sysadmins of Wikpedia I discovered that some clever people were unlawfully sharing ebooks by uploading tiny thumbnails of the cover art with an embedded RAR stuck to the end of the image!  The rar decoder would ignore the jpeg and unpack the book.  Sadly I had to end their fun and games.