Removing OP_return limits seems like a huge mistake

[j2002ba2]

It just occurred to me: Removing the limit opens up bitcoin network for cheap DOS attacks.

Instead of lengthy rants, please show how the network will be attacked, and what would prevent disruptions from happening.

[headingnorth]

Nodes act as Bitcoin's security guards by spotting and blocking invalid activity.
They reject blocks that create unauthorized bitcoin or include double-spent transactions.
With thousands of nodes performing these checks independently, attackers can't slip malicious transactions past the network.

Likewise the purpose of spam filters is to give node runners the freedom of choice of accepting or rejecting any transaction.

Spam filters that prevent abuse of the blockchain as a store of random data have been part of Bitcoin Core since day 1,
and that’s for a good reason. Redeclaring Bitcoin to be an ‘arbitrary data storage’ and redefining spam filters as ‘censorship’
is one of the most Orwellian things I have ever heard. Removing one's choice and calling it freedom is the definition of Orwellian.
You could use such twisted logic to allow anything on bitcoin including double-spend and other malicious transactions.
Because not to do so would be "censorship."

Freedom doesn't mean you can do whatever you want without any rules or laws. Bitcoin is a rules-based protocol and the rules exist
for a reason. If someone gives you permission to spray graffiti on their house then that is their choice. The keyword being CHOICE.
I should not be FORCED into letting someone spray paint graffiti on my house or place of business against my will.
Worse, you don't even know what is being spray-painted until after the fact. It could be monkey jpegs or child porn.

Do these sovereign citizen idiots consider laws against child porn to be unwarranted censorship?

Likewise I should not be FORCED to accept whatever transactions that a handful of devs unilaterally decides to force me to accept through my own private (node) hardware, whether I like it or not. That would mark the beginning of the end for bitcoin decentralization when a handful of devs gets to unilaterally dictate and decide something over the objection of the community. A very slippery slope that sets a terrible precedent.

[stwenhao]

Instead of lengthy rants, please show how the network will be attacked

If OP_RETURN will be unlimited, then some nodes will enforce the limits, and others will not (because upgrading takes some time). Which means, that by sending 100 kvB transactions, which will contain huge OP_RETURNs, some nodes could receive a lot of transactions, which will never be confirmed.

Removing the limit opens up bitcoin network for cheap DOS attacks.

The same is true for every change, which can lift some limits. For example: if you change minimal fees from 1 sat/vB into 0.5 sat/vB (it can be done without recompiling the client), then some nodes can be easily flooded with cheap transactions, which will never be confirmed.

And the same is true for some block explorers, which ignore the locktime field in transactions: you can easily spam them with a lot of transactions, timelocked into 2035, and they will think, that they will have 30% chances of being confirmed in the next block.

[scottmsul]

For example, these discussions appear to be utterly mobbed by undisclosed or poorly disclosed employees, investors, and associates of the Ocean Mining pool.

The points you're making seem quite valid to me, I'm curious though what's going on with Ocean? Why would they care about an OP_RETURN relay limit?

[teatwo]

Bitcoin is already designed to handle it, it's one of the reasons that there is and must be some block capacity limit.

That is my question. Isn't the "free market" in a 4MB blockspace a miniature garden that only works within certain boundaries?

If it is connected to an external economy and profits and losses are calculated in total with the external market, economic rationality only in the miniature garden will not work. Ordinals did not stop because of economic inefficiency in the miniature garden, but just because the external economy's NFT market died. What should be noted is that when the external economy (NFT market) was alive, it was minted with exorbitant fees in the miniature garden. This is because even if you pay high fees in the blockspace, you still make a profit in total with the external economy.

If oracles and scripts would evolve and more sustainable "goods" than NFTs would be mounted, the blocks might continue to be filled with those goods.

But I don't know whether that is a problem though.

P.S. I posted a similar discussion here, but then I remembered this so I multi-posted it.
https://stacker.news/items/971211

[gmaxwell]

It just occurred to me: Removing the limit opens up bitcoin network for cheap DOS attacks.

How so?  I believe I've explained pretty comprehensively why that shouldn't be the case:  The attacker can just create non-op_return outputs, and those are even more expensive to process for the network because they go into the utxo set.

[bogdanbaydyuk]

Thank you for your position gmaxwell — your arguments are more technically sound, and they convinced me that removing the limits is necessary.

[Hueristic]

Thank you for your position gmaxwell — your arguments are more technically sound, and they convinced me that removing the limits is necessary.

How about you sum those arguments up for us.

[jaybny]

I spent a lot of time supporting the limited size when it was first introduced and received an inordinate amount of abuse over it.  It was a limit that made sense at a different time in a different world and was successful in educating people about commitments.

This entire OP_RETURN proposal was a result of a potentially new valid use of proofs where simple commitments are not enough. Seems like 144bytes are needed for these proofs.

By upgrading the OP_RETURN limit from 80 to say 160 - we stick with the ethos that legitimate use of bitcoin may contain commitment/proof data.

Removing the limits all together for no reasons other than "they can do it anyways", creates a negative game theory incentive. Where "honest actors", those that do want to follow the social consensus and ethos of bitcoin as p2p money vs a data availability layer, now have the green light, that the social consensus of bitcoin is to use it as an immutable database.

but that smacks of appointing people to adjudicate over one application vs another

subject matter expert consensus and basic computer science can adjudicate between the commitment data utility and the data availability utility. This is exactly how we came up with the 40 then 80 byte limit.  and we should do this again. 

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.

bitcoin core should continue to hold the line and educate and lead on valid use cases for L2s. It turns out intent matters in the long run. Signaling a capitulation to anti-patterns, like inefficient protocols storing unnecessary data on-chain for badly designed protocols, will have negative consequences.

This leaves us with the data availability use case of ordinals. Which turns out will be naturally priced out in the face of p2p money transactions, if we can ever scale and bring back full blocks of actual money transactions, as the economic value of each money transaction increases the relative fees decrease.  

This leaves us with p2p money and data commitments/proofs tied to L2 monetary transaction scaling solutions, using valid software patterns that minimize space needed on-chain.

In general, all protocols should want to limit the byte size. Only the data availability protocols can't compete here.
 

[gmaxwell]

subject matter expert consensus and basic computer science can adjudicate between the commitment data utility and the data availability utility. This is exactly how we came up with the 40 then 80 byte limit.  and we should do this again.  

That was in a climate where miners were not allowing direct submission to bypass these restrictions.  In my view that fact is what shifts the limit from being no longer necessary but of no significant harm to somewhat harmful.

Subject matter expert understanding was broadly always that this sort of limit was an unstable equilibrium that wouldn't be sustained as mining transitioned from being subsidy driven towards being fee driven.

In 2014 public bitcoin understanding was often far less sophisticated than today, people often wanted to stuff data in where they would be better off according to their _own goals_ if they included a hash (or using OTS, if it had existed) or doing something else entirely.  And there was far less understanding about the downsides and potential harms of (ab)using the Bitcoin system as 'data storage'.  Back then when I was defending the limitation on online people were so mad about it they were making threats of violence against me and in many discussions I stood alone in defending limiting it.  The world is very different now.  There are also plenty of less expensive alternatives for many things people wanted to stuff data in for, ifps, nostr, other blockchains.  What remains today are things where people do rationally judge that they benefit from putting the data in bitcoin, so much so that they are willing to do so at significant expense and that is much harder to dissuade.

And the concept of generally appointing people to judge how others are using Bitcoin is repulsive to the premise that Satoshi set out for the system-- Bitcoin shouldn't have and doesn't need "experts" passing judgement on other people's ability to transact.  Fortunately, Satoshi designed a system where the ability to do so is fairly limited and fragile: for better or worse.   There isn't such thing as a freedom that doesn't have its negatives.  And the fact that the ability to filter stuff that is willing to pay is limited in Bitcoin is among them.  Moreover, data embedding can hide as indistinguishable from other uses -- in particular by shoving their data as fake addresses in outputs, which is hardly any worse for the embedder, but much worse for Bitcoin and just not blockable through any amount of expert judgement short of stuff like only allowing Bitcoin to be sent to approved, whitelisted, kyced, addresses! So sure, we can say that stuffing in outside data isn't a restriction on people's freedom to actually transact, but as far as we know there is no way to eliminate the ability to (ab)use bitcoin for outside data that is willing to pay which isn't equally (in)effective against transactions.

Please don't mistake this point as an argument that "blocking monkey jpegs is CeNSoRShIP!".  While I wouldn't *completely* dismiss the merits of that argument, it's weak at best and entirely not my point:   My point is that any tool that DOES block monkey jpegs would be no less effectual for some state mandated blacklist.  The fact that filtering has limited effectiveness is *good news*, and we would be very foolish to muddy the waters by playing an extended game of wack-a-mole that gives anyone any ideas, that writes out a roadmap for actually censoring transactions to whatever extent they can be,  or which sticks bitcoin developers or miners in a position of being punished for failing to implement or make effective some form of censorship that various powerful entities demand.  Even though such actual censorship would ultimately be ineffectual that doesn't mean it couldn't cause tremendous harm.

In general, all protocols should want to limit the byte size.

And all have a significant incentive to do so that can't be escaped, in that the resources available are limited and that there is enough traffic to create meaningful fees.  This is something that was far less that case at the time this non-standardness policy was initially set, in fact the minimum feerate has increased by a factor of 171 in real terms since then.  Blocks at the time contained only an average of 16% of their limit and so there was no market produced level of fees-- absent non-consensus rules it would have cost literally nothing to stuff in lots of trash.  Today blocks are consistently full capacity.

When the limit was established Bitcoin wouldn't even have block file pruning for another year, so you couldn't even participate without keeping every piece of junk shoved in the chain on your drive.  Today there are options designed and more or less implemented (though not included in Bitcoin Core) that let people bring up a node without ever downloading historical prunable data at all.  So functional capacity limits moderate the data storage (ab)use and ultimately the answer may be to just not care about it at all because you're not storing it and you don't have to download the past stuff to bring up a node.  Obviously not validating every bit of history has its own cost (though there are ZKP proposals that might even eliminate those but they're still very theoretical), it is an *actual* solution to much of the data embedding harms and it's one that doesn't require building ineffectual censorware or get mooted by the embedders disguising their data.

[traincarswreck]

The reason these debates aren't real, aren't sincere, and are full of vitriol and silliness is because everyone is trying to avoid the question: Whats bitcoin's optimal use case?

Whats the goal gents? What are we trying to do here? 

Ur conman talking about a means...to an undefined ends.  Because defining the ends defines the means. 

Thus the bitcoin community is a sybil attack.  Let me in the dialogue...I'll show you the conmen.

[spoil][/spoil]

[z]

I firmly believe that simpler is better. I Removing OP_return limits is definitely a huge mistake.
I hope to return to common sense and return to the most important core functions.

[d5000]

Some interesting arguments have been brought up in the discussion. Let's see:

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![..]
After that "fix" you'll have 2 problems!

As I've already written before, "fixing what's being exploited", is simply not possible. If you filter / block use cases like Ordinals you would direct the same spam into potentially more harmful mechanics.

But let me explain why I don't believe that the OP_RETURN limit lift would cause additional trouble, so there are no "two problems".

As gmaxwell already wrote those who exploit Taproot via Ordinals usually do that with a profit expectation. The market these people are addressing is however limited. There is only X demand for NFTs on the Bitcoin blockchain (a sub-market of the bigger NFT market).

Thus there will be most likely no additional market being created only by liberating OP_RETURN (see also below to my answer to @jaybny). But there is a positive effect: demand from this market could be directed significantly more into the OP_RETURN "channel" instead of the Taproot and "fake address" channels. And I think most of us here agree that OP_RETURN is the least harmful "channel" of these three.

the fact that nodes do not have a say in what they relay.

I'm also a bit in conflict with this part of the PR, even if I (as I wrote above) also understand the arguments in favour of removing that possibility mentioned by @gmaxwell.

I also want to point out that if the datacarriersize parameter is removed, then the incentive to use alternative implementations like Knots could increase. This would create additional complexity: Now both versions are in conflict regarding a relatively minor issue like standardness. But in the future it's possible that alternative implementations, encouraged by increased use, could move towards protocol changes, like the reduction of block size to something like 150 kB proposed by the Knots main developer.

In addition, mixing both changes may help the "conspiracy" camp (those who think the Core devs are corrupt and are doing this because some Big Evil Company or Malicious Attacker is bribing them).

Regarding this issue I'm moving more towards NACK again. Technically I think the removal of the parameter makes sense for the reasons gmaxwell mentioned, but socially it could have unintended negative consequences. For me, both issues should be at least separated cleanly: "lifting the limit for standardness" and "letting nodes decide how much arbitrary data per tx they relay".

Removing the limits all together for no reasons other than "they can do it anyways", creates a negative game theory incentive. Where "honest actors", those that do want to follow the social consensus and ethos of bitcoin as p2p money vs a data availability layer, now have the green light, that the social consensus of bitcoin is to use it as an immutable database.

While I think your argument is interesting, I think it's highly speculative.

First, we can't assume that "everything what is possible with Bitcoin is covered by the social consensus". Now, for example, the Taproot witness "exploit" is also possible, and there is no consensus to limit it, so according to your assumption, the "social consensus" is that it is "allowed" and "legitimate". Even if hundreds of pages of discussions in this forum and elsewhere speak otherwise.

Thus I think the removal of the limit would instead generate a "message" like: "social consensus is that OP_RETURN is the least harmful of the three methods to include arbitrary data on chain, so if you want to include them, this is at least not more limited than the other two." (it isn't even the "preferred" method, due to the witness discount one can assume that the preferred metod is still Taproot).

Second, what I wrote above about the limited market for NFTs and tokens would also affect the game theory for additional protocols which may be developed on top of OP_RETURN. If there is no additional demand, then the "social consensus" doesn't really matter, because nobody would waste fees for additional data transactions (be it with NFTs, tokens or whatever). Imo thus there is no additional incentive for the development of data-heavy protocols because other methods exist anyway.

[takuma sato]

That should be the point of Bitcoin Core, remain the Core, stick to the basics, and do not add any complexity in the name of innovation.

By that metric, that's what the PR does. It removes more complex code than it adds.


I don't understand why everyone is flaming us for someone who doesn't frequently contribute to Core opening a PR advocating for a change they'd like to see. Just because there is a PR doesn't mean that it's a good idea or that will be merged.

Well even if you don't use Core you are still going to suffer the impact of whatever Core does. Say im running Knots now as my full node, im still going to complain about things Core does that I think are not good for BTC, because Core is a main part of the network as it stands, so even if I run Knots, if Core screws up along the way, the price is the same for everyone involved in running nodes irrespective of what software you are running. As far as removing lines of code, im not an expert to start talking about the code itself, but I understand game theory. If we remove all code that was added with segwit and beyond and just put 128MB blocks or whatever, you would have simpler code, but a bloated blockchain the moment someone wants to exploit it.

[OgNasty]

Obviously removing OP_return limits is a bad idea, but I don’t think Blockstream left the community many other options. After backstabbing miners by not living up to promises made in the New York agreement and instead crippling Bitcoin, toxic maxis thought they were untouchable. It seems chasing away those who wanted to grow the Bitcoin ecosystem bought them a few years, but they’re seemingly now being overwhelmed with people sick of their idiotic approach to scaling Bitcoin. Is removing OP_return limits a bad idea? Yes. Is this exactly what core developers deserve? Also yes. Until they actively push to raise the blocksize limit to 2mb and fulfill their 2017 obligation that was made in a compromise to get segwit activated, I cannot respect the Blockstream team or anything they do.

[philipma1957]

Look As I person that still mines high fee blocks are very desirable to me.

But as a person running a full unpruned node I do not want to be charged with distributing

illegal data.

It seems to me that as much as I read this I need to not run the node as I can not be assured that the node does not carry criminal data and there is no plan in action to stop that issue if it explodes in our faces in a few epochs or is that 1/2ings.

So if un limited op_return will raise block fees and keeping current limits keeps fees lower I have to go with larger or unlimited op_return.

It looks like I can not run a node anymore for my own legal safety.


Am I looking at this wrong?

Yes I am miner biased. but I do not see BTC as a p2p money system as hodl turned it into a store of wealth.


Wish I was in the hodl camp years ago oh well

[gmaxwell]

I firmly believe that simpler is better. I Removing OP_return limits is definitely a huge mistake.

Simpler is better ... so removing complexity from the bitcoin codebase is a huge mistake?  ?

by not living up to promises made in the New York agreement [...] and fulfill their 2017 obligation that was made

(added hyperlink)

Hi Og, I made an agreement with another forum poster that you would give me all your assets.  Of course, your participation was expressly and explicitly excluded from our negotiation, but none the less you have obligations and aren't living up to them right now. Pay up!  I'll let you keep a cardboard box to sleep in, and if you're nice a swamp cooler. I'm sure you wouldn't want to fail to live up to your obligations.  

But as a person running a full unpruned node I do not want to be charged with distributing
illegal data.

That risk sucks but it exists today and isn't changed by alterations to opreturn filtering on nodes.

You can mitigate the risk by setting "prune=1" in your bitcoin.conf.  This won't actually prune any blocks, but will behave to the outside world as if you have-- so it won't serve any historic blocks more than about two days old.  You can also make sure your block files are new enough that they're encrypted so that scanning tools won't flag anything in them.

It's important to keep some perspective:  No one has ever gotten in trouble with this and it's only one of many fringe theoretical risks.  Life just has risks--  someone could relay a north korean transaction through your node and authorities could potentially try blaming you for it or just come to seize your node to try to get logs to determine the transaction's origin.  Also very not likely.  You could be sued for patent infringement by Craig Wright's co-scammer business partners as they've repeatedly claimed Bitcoin violates their patents the fact that they're full of shit doesn't mean that they couldn't cause you bankrupting levels of legal expenses.

But if you don't run your own node maybe you're the last straw that otherwise would have helped hold back a bad consensus change.

Basically if you're going to commit yourself to worrying then there is no end to it.   The best you can do is be aware of more significant risks, mitigate what you can affordably mitigate and deal with problems as they arise.  Only the dead are invulnerable to risk.

I can not be assured that the node does not carry criminal data and there is no plan in action to stop that issue

It's not that there is no plan, it's that it's a fundamental issue that appears to be largely unsolvable.  It also isn't unique to bitcoin-- anyone who publishes anything could accidentally transmit illegal data that someone snuck in, even if they were engaging in editorial oversight.

Beyond the block file and utxo set encryption bitcoind/bitcoin-qt doesn't provide any facilities to decode/display these embedded things, quite intentionally, to avoid any argument that the node operator meaningfully had access.  Also the P2P protocol got encryption a while back, though I worry that drama adverse behavior is delaying developers doing the right thing and offering an option to only use encrypted connections.  I have a patch available that I made for a friend if you want one, it's required no revisions to apply cleanly for more than a year now.

There are also ideas like assumeutxo which will allow people to bring up a full node without validating (thus downloading) the far past that would help.  Though of course this comes with a security tradeoff in that you only have 'assumevalid' like security of the part you didn't validate... but it's another way Bitcoin has worked on mitigating risk from illegal content.

I'm also a bit in conflict with this part of the PR, even if I (as I wrote above) also understand the arguments in favour of removing that possibility mentioned by @gmaxwell.
I also want to point out that if the datacarriersize parameter is removed, then the incentive to use alternative implementations like Knots could increase. This would create additional complexity: Now both versions are in conflict regarding a relatively minor issue like standardness. But in the future it's possible that alternative implementations, encouraged by increased use, could move towards protocol changes, like the reduction of block size to something like 150 kB proposed by the Knots main developer.

There are two PRs, one which leaves a setting but unlimits it by default.  Of course, most people 'following' the debate don't even know that...

It's less advanced in development in part because its a somewhat harder change.  I'm not really that opinionated on leaving a useless option in, though because of the character of the response I do lean towards removing it: Removing it is simpler, results in less complexity.  Perhaps less good reasons, conceding to an attack driven by misinformation or collateral concerns creates ongoing risk.  For people who intentionally have exaggerated the issue a concession just amplifies their social clout.  Some people running some other version isn't inherently bad, and if they're doing it because they've been bamboozled then the solution is education. If they're doing it because they're so angry at other uses that they'd harm bitcoin in order to harm the other uses, I'd rather they go off and do their own thing and not distort future development priorities with future unreasonable demands.

Also running another version is overkill for this, this is exactly the kind of small change that it ought to be easy to carry a local patch for.  The ecosystem would be better off if more people felt comfortable doing that.  True, I believe this is a silly and unhelpful thing to carry a local patch for.. but if it causes people to learn how and not be afraid of it, then that sounds like a winning outcome to me.

It's extremely easy to drum up or even outright fake public outrage... more sybil vulnerable than even P2P.  If developers are going to be diverted from what they think is best via that kind of attack, then that is a really serious and concerning vulnerability.  That doesn't mean they shouldn't listen-- they should, but all that should matter is good arguments that go directly to the issue in question, and not unfocused outrage or abusing the subject as a proxy issue.

[tvbcof]

Seems to me that people who wish to leverage the Bitcoin blockchain for various pet data projects would/could/should just peg out to a dedicated sidechain.  Unlike in earlier days (back before the earth stopped cooling) such technologies have been developed, and are working pretty well as best I can see.

Seems to me that a dedicated  sidechain would be a better choice than the Bitcoin blockchain since it wouldn't be being spammed by BTC transactions and there is a lot of unrelated cruft which could be left behind.

At first blush, somehow 'needing' to crud up the BTC blockchain seems more like an attack than a legitimate solution to a real problem.  Where is my thinking wrong here?

[ABCbits]

But as a person running a full unpruned node I do not want to be charged with distributing

illegal data.

Such illegal data already embedded into Bitcoin blockchain far before Ordinals exist. We better hope government keep being sensible, since you can't access such data without additional software which enable parsing, listing and searching such data.

Seems to me that people who wish to leverage the Bitcoin blockchain for various pet data projects would/could/should just peg out to a dedicated sidechain.  Unlike in earlier days (back before the earth stopped cooling) such technologies have been developed, and are working pretty well as best I can see.

Seems to me that a dedicated  sidechain would be a better choice than the Bitcoin blockchain since it wouldn't be being spammed by BTC transactions and there is a lot of unrelated cruft which could be left behind.

At first blush, somehow 'needing' to crud up the BTC blockchain seems more like an attack than a legitimate solution to a real problem.  Where is my thinking wrong here?

Sidechain and other L2 already exist far before Ordinals created. But almost no one use it despite both Liquid network and Rootstock have smart contract capability and developer behind it promote it support NFT/token. I also have seen Ordinals supporters say they only want to use Ordinals since their arbitrary data guaranteed to be immutable.

[pooya87]

As I've already written before, "fixing what's being exploited", is simply not possible. If you filter / block use cases like Ordinals you would direct the same spam into potentially more harmful mechanics.

Sadly I somewhat agree with this, which is what I've warned about before; and it's only because the core devs didn't act when they should have acted!
If they had fixed the exploit in a patch shortly after the Ordinals Attack was introduced, it would not have grown so much to "fester" and establish a market. After all before this attack began we weren't seeing people spamming or using "other more harmful mechanics" to inject arbitrary data into the chain at large scale. So preventing it would have never led to it either.

But I still don't see how encouraging people to inject arbitrary data of any size and without limit into bitcoin blockchain which would be treating it like cloud storage is a good idea. It sounds like a disaster not a solution.

As gmaxwell already wrote those who exploit Taproot via Ordinals usually do that with a profit expectation.
demand from this market could be directed significantly more into the OP_RETURN "channel" instead of the Taproot and "fake address" channels.

They are indeed driven by profit, and to make profit from the garbage they create they'd look to minimize their costs. Even more so during the mempool congestion times where fee rates shoot up significantly. Using the exploit to inject their large date into witness is significantly cheaper compared to using OP_RETURN. I doubt they can be directed to using it instead.

And like I always say bitcoin is not a cloud storage, so we should make it harder for them to use it as such not easier (ie. removing OP_RETURN limit).