Removing OP_return limits seems like a huge mistake

[gmaxwell]

I appreciate the honorific, but unless you're in the business of handing out honory degrees I am not a PHD.

- Above certain size (~150bytes) [1], it is claimed it's cheaper to abuse witness exploit so not sure why you're so sure that ppl with malicious intent to embed large jpegs/data will switch to using OP_RETURN.

They won't. I did not intend to suggest otherwise. Did I?   How is it relevant?

- When the actual UTXO bloat exploded like crazy during inscription attack, most Core devs were congratulating their ex coworker from Chaincode (Casey) on exploiting the witness vulnerability.

I don't know anything about this, if it's true, it sounds doubtful to me particularly since I was able to determine that a significant part of the ordinals ecosystem was in fact funded by Calvin Ayre, the same party funding Craig Wright's litigation against developers.

Now you've claims that they're anticipating some usage in more harmful ways(which hasn't happened btw)

There are existent transactions on the network right now shoving data in unspendable outputs, some have been discussed previously in this thread.  I don't think I've made any arguments based on 'anticipating'.

I'm not so sure about your claim of OOB txs atleast for non-std txs. For inscriptions may be but my very first point clearly shows you that relaxing op_return limits doesn't make it cheaper for those inscription txs so they are not going to move there.

You are continuing to debate a point I never made.

Re miners, several of the largest pools will outright accept nonstandard txn and mine them for a payment, this is well documented.  It's not clear to me if you're disagreeing with it or just doubting that it's used often for op_return vs non-standard in other respects.

"It was a limit that made sense at a different time in a different world", explain how are you quantifying that now the system is mature enough and people got educated.

Different time would be one where large miners were not allowing non-standard transactions and not being paid hundreds of millions of dollars for data traffic.  As far as education, I'm not aware of anything people are doing where their goals would be satisfied by just using a commitment, and in fact petertodd reports that OTS now handles an average of 2.1 commitments per second, so that is a significant fraction of the whole chains bandwidth being saved by actually handing commitments the right way.  The goal in originally limiting the size of op_return was to encourage users that could form their usage as a commitment to do so.

How can you claim people are educated, when Core devs themselves said things like use blocksonly

The hyperlink in your post didn't work for me but I dug through the PR and the quote is:

I do not believe this to be in the interest of users of our software. The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like. Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.

Of course, anyone is free to run, or provide, software that relays/keeps/mines whatever they want, but if your goal isn't to have a realistic mempool, you can just as well run in -blocksonly mode. This has significantly greater resource savings, if that is the goal.

I think the comment speaks for itself just fine, there is absolutely nothing ridiculing about it (except towards inscriptions users).  And also, I fail to see how it contributes to a discussion on removing the op_return limit.

even though counter arguments have been also made by people

Where?

who are not just theoreticians but practically running businesses.

Ah, so that's what the false honorific was for.  I am not a "theoretician".   Particularly to this discussion, I *invented* compact blocks, and (with collaborators) *deployed it*, and brought it through numerous in production developments and evolution, so it is galling that you're attempting to dismiss without argument by damning me with faint praise of being a theoretician.


Your post went through numerous points, but none of them appear to make the case that eliminating that particular limit would cause any harm.   To make sure that I'm not missing any, allow me to make another pass on just that point:

- You suggest monkey jpegs won't shift to using OP_RETURN.  I agree.  This is not a reason that removing the op_return limit would be harmful.

- Core devs something with some person something another?   Of no relevance to the op_return limit and not something I know anything about.

- You claim I claim that there is an anticipation of not yet happened more harmful ways.   If so this is still not a reason removing the limit would be harmful.  But as a point of order, users stuffing data in 'fake address' outputs is a current thing, not an anticipated thing.

- You claim Pieter ridiculed users, I think you're mistaken (unless you're complaining that he insulted inscriptions users) but it's also of no relevant to the op_return limit.

- You claim (and I don't dispute though I haven't checked) that there are not that many non-standard op_return transactions being mined.  This is no a reason that removing the limit would be harmful, it is a confirmation of my point that they are being mined.

- You point out that inscriptions bloated the chainstate.  This is not a reason that removing the op_return limit would be harmful (they don't use op_return, but if they did it would reduce chainstate bloat, though I don't expect them to).

- "when Core devs themselves said things like use blocksonly or a bad and shaky claim that we will have utreexo or assumeutreexo in the future"  I have no idea what you're talking about, but again, it does not provide a reason that removing the op_return limit is harmful.

- You've vaguely referred to counter arguments to my point that mismatching relay with mining hurts propagation, which might be somewhat relevant but you haven't specified where so I don't know what you're talking about.  But that said even if my argument on why failing to disable the limit causes harm was in error, this is still not a reason that it would be harmful to disable the limit.

- You attempt to dismiss my credibility on technology I invented *and* deployed, by dismissing me as a theoretician and suggesting that unspecified "practical" people know better.  Yet again, not a reason it would be harmful to disable the limit.

- You suggest communications should improve, complain about moderation not having a good appearance. OK but, at this point you can sing it with me, still no reason removing the limit is harmful.

Have I understood correctly?

[gmaxwell]

thanks for the unfound accusations on my intentions/funding etc. I wish you good luck in your endeavors, that's all I can say at this point  

So you don't think it's appropriate for you to disclose your potential conflicts of interest?  I'm happy to do so, I have no commercial interest in Bitcoin except for the value of my own Bitcoins.

For example, these discussions appear to be utterly mobbed by undisclosed or poorly disclosed employees, investors, and associates of the Ocean Mining pool.  One of them, for example, made a demand of Lopp to disclose his potential conflict of interest (resulting in a temp ban on github which I think you referenced above),  but over and over again I keep finding non-disclosed ocean affiliates/employees/investors, some of which I only recognize because I was asked to invest in it when it was formed.   I can't help but notice that Ocean's exclusive marketing angle seems to be around spam, and so ISTM ocean has a commercial interest in exaggerating any issues related to spam, since they believe they're the cure.

For all the complaints about the development lists requiring polite conduct, it's somewhat amusing to see the vanishing act when I dish it out a bit here.

[gmaxwell]

with 1 bitaxe and 4-5 ASICs,

Thank you for mining!

[RodMor]

I don't know if this helps, but that's the intention, so here are two links that are worth revisiting:

[1] - https://asktom.cf/index.php?topic=195.msg1617#msg1617
[2] - https://asktom.cf/index.php?topic=150405.msg1598258#msg1598258

[Ambatman]

Can you suggest any reason that it shouldn't be done?  I'm waiting to hear an answer that isn't just a rant about shitcoins or spam, none of which is particularly relevant argument against removing the limit.

Okay maybe I over exaggerated the part of becoming Ethereum
But I still believe the concern is valid.
Bitcoin is first a decentralized currency not a general-purpose data store.

Removing the OP RETURN  limit could shift developer and user focus away from financial transactions to incentivize non-monetary applications.


I get that workarounds like Taproot already store data, but removing OP_RETURN limits would incentivize even more non-financial use, risking node centralization and higher fees for regular users.
Not to mention embedding large illegal files (e.g., pirated content) easier, burdening nodes with legal risks.

I'm not saying the above issues don't exist in current system but it's on a lower scale.
Most of the issue of removing the OP_RETURN limit are economical and cultural not really technical perse.

There's always a trade off and I understand the issue of fake outputs
But users were expecting a solution to the ordinals birth last time to protect Bitcoin monetary utility.
Not one that relies solely on the fact that users make use of fake outputs due to limited space.

[gmaxwell]

ut removing OP_RETURN limits would incentivize even more non-financial use

How?

Not to mention embedding large illegal files (e.g., pirated content) easier, burdening nodes with legal risks.

They can do so more cheaply by disguising it as other parts of a transaction, this doesn't change their ability.

But users were expecting a solution to the ordinals birth last time to protect Bitcoin monetary utility.

I'm sure if someone has one which isn't trivially evaded, working in spite of major miners being offered (and accepting) millions to mine them, and somehow can't also be used to impose a state mandated blacklist ... that a lot of people would be very interested.

Especially if the idea somehow doesn't make inscriptions even more valuable and attractive by increasing their scarcity ...  

But even soooo as has been pointed out, this is *independent* of the op_return limit, because removing it wouldn't have any impact on the ordinals/inscriptions stuff.

The whole premise of Bitcoin is to escape a world where your ability to transact could be overridden by some administrator's "judgment call weighing" your rights "against other concerns, or at the behest of his superiors".  So it's no accident that blocking unwanted transactions isn't easy, it's nearly impossible by design.  And if there were some genius way possible to do it, would we want it at the expense of potentially eroding the properties that make bitcoin valuable? "It's a poor atom blaster that won't point both ways"

There used to be a broad understanding that standardness policy was only a gentleman agreement without real force, and that as blocks filled up spam would get managed by the size limits and fees.  Excluding things was always extremely controversial and fraught with drama. I've been one of the most outspoken critics of shoving non-bitcoin data in transactions since probably before some current Bitcoin users were born... and I know this. How did it get forgotten?

[DaCryptoRaccoon]

thanks for the unfound accusations on my intentions/funding etc. I wish you good luck in your endeavors, that's all I can say at this point  

So you don't think it's appropriate for you to disclose your potential conflicts of interest?  I'm happy to do so, I have no commercial interest in Bitcoin except for the value of my own Bitcoins.

For example, these discussions appear to be utterly mobbed by undisclosed or poorly disclosed employees, investors, and associates of the Ocean Mining pool.  One of them, for example, made a demand of Lopp to disclose his potential conflict of interest (resulting in a temp ban on github which I think you referenced above),  but over and over again I keep finding non-disclosed ocean affiliates/employees/investors, some of which I only recognize because I was asked to invest in it when it was formed.   I can't help but notice that Ocean's exclusive marketing angle seems to be around spam, and so ISTM ocean has a commercial interest in exaggerating any issues related to spam, since they believe they're the cure.

For all the complaints about the development lists requiring polite conduct, it's somewhat amusing to see the vanishing act when I dish it out a bit here.

I'm blocked by most people so that defo is not me. 

Luke = Blocked me
Lopp = Blocked me
Todd = Blocked me

Probably some others too.  Seem to be the way they shhhh anyone trying to raise any concerns.

if Liquid can have a side chain why can't we just have a data sidechain? Is ir really that hard keep Bitcoin main chain for UTXO's transactions and money based and have a side chain.  Litecoin runs many side chains no issue.  Why Bitcoin can't just do the same is beyond me.

The overall consensus I fell is users do not want this change to occur, granted they may not be well informed on the matter or understand the nature of the changes as not everyone is a tech guru or coder out there we must keep this in mind. 

Rather than lets have another big fall out over some changes lets find soltutions that fit and work and keep bitcoins core finance.  If you really need or want data do it on a side chain.  Why the need to have the data in the main bitcoin blockchain is beyond me.

BuT BrUh MoNkEy JpEg LoOkS cOoL is not a reason.

[gmaxwell]

If you want to store data, use amazon s3 or other services it's more than a hundred thousand times less expensive to store data forever in S3 than it is to included it in bitcoin at the minimum feerate.

The people cramming jpegs and whatever into the chain are *depending* on it being expensive.  They are trying to profit off seigniorage by creating a rare thing and then selling it to a greater fool, or at least pretending they are doing that while actually engaging in money laundering (where your dirty money account buys jpeg tokens minted by your clean money account).  For either case the limited space and expensive fees are part of the attraction, which is also why the the anti-spam mechanism of it being quite expensive doesn't easily dissuade them.

Perhaps some also do it because it disrupts bitcoin by causing higher fees for users and by creating drama. ::shrugs:: who knows, given that many of the people pushing the stuff are shitcoin promoters and refugees, there are at least a few that do not shed any tears for any trouble it causes Bitcoin.

If they really just wanted to put it in a blockchain there are a thousand existing ones, most with low or effectively no fees.  You can also create a new blockchain in about a day (copying the Bitcoin code, as most have done).  So that just clearly isn't what they want.

Whatever there exact details are there is apparently a metric bucket load of money behind it.  But it's also at least somewhat self limiting, when it's really surged in the past the available funds get depleted.

They aren't using OP_RETURN they won't be using OP_RETURN, they're not particularly relevant to this discussion... but you asked.

BuT BrUh MoNkEy JpEg LoOkS cOoL is not a reason.

Here or among developers you will find some people who defend the practice on the basis that to do otherwise is censorship and antithetical to Bitcoin.   You will find some people who defend it on the basis that we just can't stop it.  You will find people who think it's irrelevant.  Anyone thinking monkey jpegs "look cool" is not likely to be found here and if they show up they will be vastly outnumbered by people who think they're fucking up a good thing and causing a lot of unnecessary drama.   One of the biggest points of confusion that has been created in this discussion is that regular bitcoin core developers like the inscriptions crap.  I can't promise that none do, but the ones I know absolutely do not.  But personally liking something or not is not very relevant.  If you want a way of transferring value based on what someone else likes and approves of, use paypal. 100% monkey jpeg free. If you want money which is secured in a way that was physically impossible for others to screw with use Bitcoin (Warning: May contain nuts).
 
(and depending on what percentage of all this is really just money laundering, perhaps no one is the god damn world thinks monkey jpegs look cool. but I doubt that's true, after all there is a sucker born every minute)

[philipma1957]

No good can come from this.
Feels like another attack on Bitcoin.
Can we just get back to being the money again?

My post directly above yours lists several reasons why failing to remove the limit is bad.  What elements do you disagree with?

So I read your long post.

As I understand it if I am a rich asshole I can pay a large miners say marathon to by pass op_return right now and write anything i want as long as I pay enough.

So right now I could be paying top dollar and tons and tons and tons of encrypted child stuff porn place on the blockchain.

Since no one knows the encryption no one knows every node has illegal data on it right now.

If I remove op_return people could do the same thing cheaper .

So the issue is the blockchain could be loaded with endless amounts of encrypted porn which could be revealed at anytime.

Dumping op_return to no limit makes it easier .

If my logic is wrong and what I say is not possible please let me know.
IF MY LOGIC IS CORRECT PLEASE LET ME KNOW.

it's an easy choice if I am correct.

If I am wrong it is an easy choice.


So please answer me will no limit to op_return make it easier to put in a large encrypted child snuff porn.

I ask because it is quite obvious no one wants to make an easy attack on the block chain.

So please tell me could I mine solo to my own node and upload a huge file with no limit to op_return.


I can get a block mined for under 500k . So could I in theory do this if we stop op_return.

How do we protect the blockchain from and encrypted file with child snuff porn.

My fear is the attack is done and in 4 years when my btc is 1 million a coin the reveal shows there are years and a bad file a month with a different film encrypt.

Do we have a plan for my question if we do than op_return should be open to all miners.

[gmaxwell]

As I understand it if I am a rich asshole I can pay a large miners say marathon to by pass op_return right now and write anything i want as long as I pay enough.

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).

So right now I could be paying top dollar and tons and tons and tons of encrypted child stuff porn place on the blockchain.

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.

If I remove op_return people could do the same thing cheaper .

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)

So the issue is the blockchain could be loaded with endless amounts of encrypted porn which could be revealed at anytime.

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

Dumping op_return to no limit makes it easier.

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.  

How do we protect the blockchain from and encrypted file with child snuff porn.

It seems fundamentally impossible to block, at most it can be 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 stuck 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.  In theory, assuming normality, every illegal piece of data that will ever be exists in the digits of pi... the key is knowing *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.
 

[stwenhao]

while in Bitcoin there is both no means to remove anything (other than pruning) and no authority that could do it

What about chain reorganization?

And 'fake address' outputs can't realistically be blocked.

If some public key is exposed, then it can be required by consensus rules, to be a valid point on secp256k1. And it is possible to make all outputs spendable in theory, if all coins will always land on valid public keys.

If it is in 'fake addresses', then it's not eliminated by pruning and can't be.

If everything is behind some kind of public key, then things can be combined, while removing in-between data, and preserving the final destination of all coins. Also, if things are behind unique public keys, then they can be sorted, which will block a lot of people from storing meaningful data on-chain (especially if everything is finally baked into one huge transaction per block, and nobody can escape sorting by splitting things into separate transactions).

Also, if you have chain X, with chainwork Y, then if consensus rules encourage you to produce a new version of the chain, where the chainwork is bigger, and things are more compressed in the process, then you can achieve UTXO-based Initial Blockchain Download, where every new version is always covered with more Proof of Work, than the previous one.

In general, I think OP_RETURN limits will be finally lifted, that way or another. But the problem with spam will still be there, and it will be more and more urgent, as the blockchain will contain more and more data. Which means, that nodes will evolve in a way, to make things faster, and to process more proofs, that some data chunks are valid, instead of processing the original data. Because in many cases, you know in advance, how coins will be spent in the future, and you can optimize your node, to store only things, which are strictly required, and prune everything else, by simplifying it with proofs, that everything is valid.

For example: if there are some data pushes, which are not enforced by any consensus rules, then you don't have to store all of that data. You can store only the initialization vector of SHA-256, some initial chunks from the beginning, and some last chunks from the end, and for everything in-between, you can just operate on simplified proofs, that things are correct, as long as SHA-256 is not broken.

[d5000]

But even if we thought that making it more expensive for them would be useful it has to be balanced against what it costs.   Having some developer going around playing wack-a-mole blocking stuff that isn't perfectly immitating ordinary transactions is a huge liability.

I wasn't referring here to the heuristic methods the "ordinal blocker" camp was trying to implement e.g. in Bitcoin Knots. I think such methods are ineffective as it could become a cat and mouse game between the Ordinals devs and the Core/Knots devs, and I agree with you about the costs such a "hardcoded" ordinal blocking method would generate. My remark was more general, for example one could think about a size limit that could be applied to Taproot witnesses.

The more I think about it however I guess that finding such methods is next to impossible without significant collateral damage to "financial" use cases and that's not worth it. An extreme example: In the height of the Ordinals discussions, some have mentioned Grin's transaction format, which indeed would make inscriptions very expensive because only a few bytes per transaction can be selected in an "arbitrary" manner. Of course this format makes "useful" scripting (Lightning and friends) very difficult or impossible.

And of course what you write about the economics of the Ordinals "inscribers" is correct, the cost isn't really that important. Winning the attention game is the important thing here (see also below).

From another of your answers I think I'm understanding the intent behind the proposed deletion of the code related to the datacarrier size a bit better, and I may thus be considering switching my stance related to the PR to ACK (still a layman ACK of course, heh).

- Above certain size (~150bytes) [1], it is claimed it's cheaper to abuse witness exploit so not sure why you're so sure that ppl with malicious intent to embed large jpegs/data will switch to using OP_RETURN.

That claim was actually made by me so I'm answering here. It's of course a speculative answer, as everything we can say about the future.

Currently we have three main methods to stuff data into the blockchain: Inscriptions ("witness exploit"), Fake adresses, and OP_RETURN. While the witness exploit is the cheapest, it has the disadvantage that it's a bit complex, above all because you need two transactions (in most cases) to inscribe the NFT (and in the case of BRC-20, which caused the fees to explode in 2023, you even need two transactions per transfer).

For the Ordinals fad, it's not much that can be done, it has already done a (small) bit of harm but is probably fading away, see also the post from gmaxwell I reference above and my answer.

However, the creators of future fads would have these three methods to select from. Maybe if OP_RETURN limits are in place, they would instead try to create a fad based on a Stampchain-like protocol. Fads also have often to be novel to work, so they would probably try to dismiss Ordinals as something old and outdated. With OP_RETURN limits lifted, in contrast, it's at least possible the fad creators could prefer this method, even selling it as "blockchain friendly", for example (because it can be pruned).

Maybe there is also an indirect effect which could make spam levels decrease if OP_RETURN limits are lifted: new protocols trying to benefit from this change could emerge, and they would enter into competition with Ordinals and Stampchain-style "fake address" methods. That could generate "noise" in the NFT community, i.e. there would not be longer a dominating method which captures all the attention as it was the case in 2023 with Ordinals. Such a situation could be compared with the situation in 2013-15 when the first NFT/token protocols on Bitcoin were implemented, there were several systems in competition (Mastercoin/Omni and Counterparty, mainly); none of them "won" the "battle" decisively, and eventually they both faded away, at least none of them created any significant congestion or fee spike.

The Ordinals fad imo however was as successful as it was not because the Taproot method was cheaper than Counterparty and other older methods, but because they were able to sell it as an "unique" or "best" method to store data on the Bitcoin chain. I think many of the BRC-20 folks really believed that this was the first and best method to implement ERC-20 style tokens on Bitcoin, when it's in fact one of the most inefficient mechanics and even the older methods are better in many ways.

[philipma1957]

my fear is I run a full node no pruning

and am I enabling and encrypted illegal file by doing it.

I also know an anti btc person would want to load the chain for years with a lot of highly illegal data.

Thus making the fix very very expensive once the issue is exposed.

to me if op_return changes do not make it cheaper or easier  do then I do not see a danger.

BTC has a longer term issue of miners continuing to mine blocks when they op to 0.39

btc
a
block

which is only 2036.

I will await  the changes to op_return and see if they hurt or if others are correct.

[Hueristic]

I will await  the changes to op_return and see if they hurt or if others are correct.

From my understanding it will hurt the little miners, but I'm sure all the banks will be running nodes when that happens.

[gmaxwell]

while in Bitcoin there is both no means to remove anything (other than pruning) and no authority that could do it

What about chain reorganization?

Gonna evict whatever N months of mining it took to recognize a problem?  If that's possible might as well give up on Bitcoin.

And 'fake address' outputs can't realistically be blocked.

If some public key is exposed, then it can be required by consensus rules, to be a valid point on secp256k1. And it is possible to make all outputs spendable in theory, if all coins will always land on valid public keys.

That would reduce reduce the attackers ability to embed data by one bit per 32 bytes.

If it is in 'fake addresses', then it's not eliminated by pruning and can't be.

If everything is behind some kind of public key, then things can be combined, while removing in-between data, and preserving the final destination of all coins. Also, if things are behind unique public keys, then they can be sorted, which will block a lot of people from storing meaningful data on-chain (especially if everything is finally baked into one huge transaction per block, and nobody can escape sorting by splitting things into separate transactions).

You cannot non-interactively combine other people's ECC public keys.  For sorting, that could reduce the capacity by log2(n) bits per output (e.g. the cost that is require to encode a hidden counter in the encoded data.

You could imagine some radical redesign of Bitcoin that takes away virtually all of the flexibility Satoshi provided, switches crypto to something aggregtatable etc.  But come on, that's basically replacing Bitcoin with another currency and if you want that you can already use another currency today.

Also if you're cool with throwing away the history the sort of assumetxo stuff gets there without hobbling bitcoin's functionality.  It does have security implications but so does aggregatable crypto, or taking a away scripting.. after all, scripting is what lets bitcoin users consensually do fancy stuff without using trusted third parties.

Currently we have three main methods to stuff data into the blockchain: Inscriptions ("witness exploit"), Fake adresses, and OP_RETURN. While the witness exploit is the cheapest,

It's also important to keep in mind what problem you're solving.   Lets imagine that it were possible to keep the data out of witnesses (it's not but lets imagine)--  the embedder now has to pay more.  But did they particularly care how much they were paying?  No, or they wouldn't use Bitcoin at all.  Most of the time the users are upset about the embedding they're upset because of the impact they have on fees-- but excluded from the witness they have 4x the impact on fees! Maybe their traffic levels go down a bit but they have to go down 4x just to be back where they were in terms of fee impact.  I think because people fall into a combative mindset of viewing them as an enemy they start thinking in terms of how much they hurt their opponent, but hurting the opponent isn't the same as helping everyone else.   Worse, evicted from the witnesses the cost difference for the spammer from using prunable op_return vs some unprunable output embedding is small, at the latter has less further blocking potential.  So you go from spam but at least it's prunable, to spam with 4x the fees impact and maybe it's not even prunable.  Maybe the total bytes sent are somewhat less, but was that ever anyone's issue?

It's like one could also "solve" spam by reducing the block capacity a lot-- if it's reduced to zero no spam at all.  But even if it is just reduced a lot then obviously the amount of spam is reduced too.   But that just seems vindictive to me-- in the sense of "this hurts you and that's all that matters, I don't care how much it hurts me".  The thing that got most users up in arms is that spam increases fees and cutting capacity is like a giving the spammer that reduced space for free, forever, in terms of increased fees.

So it would reduce the amount of illegal content they could put in, but I think mostly only a few developers have ever really been concerned there, and that attack doesn't need large amounts in total in any case.  So it's not like bitcoin with 150vkb blocks as luke-jr argues for would be immune to a very wealthy attacker that wants to put some unlawful stuff in the chain to make node operators worry they'll get in trouble.  But in any case as I say I don't think that concern is what has animated people.

And then we get to the argument that at least some of the embedders are potentially just trying to disrupt bitcoin, that they're actually malicious.  Well then countermeasures would be even less effective for them, if the want to spent lots of money to drive up fees they can also do so with txn that no one would say are not legitimate transactions.  And to their extent that their goal is stuff like creating drama or getting the public to abuse long standing developers that they can't buy off-- well they're winning on that respect right now, aren't they?

[pooya87]

So let me get this straight from a historical perspective.

One day some people decide to store garbage on bitcoin's immutable blockchain but since nodes don't relay their garbage filled tx, they start abusing the protocol by creating fake standard outputs like P2PK to inject their garbage which creates UTXO bloat.
To solve that, OP_RETURN is standardized to encourage them to stop their abuse and instead use OP_RETURN which has always been limited ever since.

Then SegWit/Taproot are added which introduced a vulnerability that the spammers abused in the Ordinals Attack and started injecting arbitrary size garbage which created UTXO bloat.
Now instead of solving that by fixing what's being exploited, they want to remove the OP_RETURN standard limit entirely to try and encourage the abusers to use what could be more expensive!

This is what happens when you don't know the cause of a problem. Like going to emergency room for appendicitis but they remove your kidney instead. After that "fix" you'll have 2 problems!

And as I said before in this topic the biggest problem here is similar to the issue we had with Ordinals Attack, it is the fact that nodes do not have a say in what they relay. A handful of developers decide! That's moving toward centralization.

[gmaxwell]

And as I said before in this topic the biggest problem here is similar to the issue we had with Ordinals Attack, it is the fact that nodes do not have a say in what they relay. A handful of developers decide! That's moving toward centralization.

Miners are ignoring standardness rules, what "developers decide" does *not* limit the junk getting included.  Efforts have been made to convince these miners otherwise, but surprise the like the hundreds of millions of dollars in fees they've gotten by mining what people pay them to mine.   Bitcoin is designed from the get go to be censorship resistant and the result of this is that no one gets to decide how other people can use Bitcoin generally, because of this filtering stuff is generally a losing proposition.  ... and if there were a way to make it effective then it would just be a mechanism that could equally used to impose government blacklists or similar.

But ordinals whatever doesn't have anything to do with the topic at hand, it won't be changed by this.   Instead, there is some traffic stuffing data in outputs its not possible to stop that.  Instead, it could be opreturn which would at least keep it prunable.  But even if op_return were worse, though I don't see how, the limit is ineffectual for anyone willing to pass the transactions directly to miners (promoting centeralization along the way and encouraging miners to bypass standardness).

So there is a limit. It doesn't stop people. It does encourage more harmful encodings that cannot be blocked.  And because there is a gap between what miners mine and what nodes relay this hurts Bitcoin's decentralization by encouraging direct miner relationships and slowing block propagation (which benefits large miners over small ones).  So the limit is no longer useful and causes some harms-- why shouldn't it be removed?

The fact that you also hold that not enough is being done about jpeg spam isn't relevant to this particular question, since op_return limits are not something the jpeg spammers care about or will care about.  The subjects are related because the miners ignoring standardness for ordinals is also why nothing was done there-- because it appears nothing could be and an attempt would be both ineffectual and would just give ammo to parties that want to deploy actual censorship on Bitcoin.

[mindrust]

So let me get this straight from a historical perspective.

One day some people decide to store garbage on bitcoin's immutable blockchain but since nodes don't relay their garbage filled tx, they start abusing the protocol by creating fake standard outputs like P2PK to inject their garbage which creates UTXO bloat.
To solve that, OP_RETURN is standardized to encourage them to stop their abuse and instead use OP_RETURN which has always been limited ever since.

Then SegWit/Taproot are added which introduced a vulnerability that the spammers abused in the Ordinals Attack and started injecting arbitrary size garbage which created UTXO bloat.
Now instead of solving that by fixing what's being exploited, they want to remove the OP_RETURN standard limit entirely to try and encourage the abusers to use what could be more expensive!

This is what happens when you don't know the cause of a problem. Like going to emergency room for appendicitis but they remove your kidney instead. After that "fix" you'll have 2 problems!

And as I said before in this topic the biggest problem here is similar to the issue we had with Ordinals Attack, it is the fact that nodes do not have a say in what they relay. A handful of developers decide! That's moving toward centralization.

Nice analogy.

> one step forward :

-Doctor please help I have so much pain! I can’t live like this no more! Do something!

*Doctor pulls gun

No patient, no pain.

[pooya87]

Miners are ignoring standardness rules, what "developers decide" does *not* limit the junk getting included. 

It does because the bulk of the spam takes place by regular users who use their regular wallets to broadcast their spam tx to regular nodes that would then decide whether to relay them or not. When the nodes reject nonstandard transactions, they won't be relayed to reach miners and the bulk of spammers will not go through the backchannels to contact miners to mine their nonstandard not-relayed transactions.
That's not to mention that the backchannels would cost the spammers a lot more money since they'd have to incentivize the miner (grease their palm) compared to having it relayed normally as standard tx. This can act as another abuse preventive measure.

We can see that clearly by analyzing the chain and seeing that for example the standard rule on OP_RETURN size does indeed work. https://blockchair.com/bitcoin/outputs?s=time(desc)&q=type(nulldata)#f=recipient,type,time
If it were anything else, we should have seen large number of nonstandard transactions being included in blocks every day.

P.S. I also don't fully agree with the statement of "miners ignore standard rules". They don't really modify their code that much due to being too concerned about having their block rejected. Here is an example of how miners were too scared to include a nonstandard tx (a simple SegWit with uncompressed pubkey which was perfectly valid) with a big reward in their block.
The reason why an attack like Ordinals work is because it was never nonstandard to begin with.

[Ambatman]

They can do so more cheaply by disguising it as other parts of a transaction, this doesn't change their ability.

Now this is the issue. Removing the limit doesn't close the back door in using fake outputs.
It only discourages honest users that are doing it because of cost.
I doubt any would use OP_RETURN to embed illicit files since it can be pruned, OP_RETURN low cost could still enable encrypted abuse.
But fake output and taproot would still be used for privacy and it's functionality(Ordinals embed NFT data in Taproot witness data, not OP_RETURN, for inscription logic, and would likely continue regardless of the limit).
It doesn't really stop individuals from engaging in what they were in the past.
Just opened the door and left the window open without any new defence.