Removing OP_return limits seems like a huge mistake

[dmatthewstewart]

Concept ACK.

I support removing arbitrary limits on Core.  Sometime, people need to acknowledge that the nature of Bitcoin is to be a permissionless network, where information can be embedded in many forms, and trying to stifle all of them creates more problems than it solves.  For example, the Ordinals could be implemented far more efficiently if certain limits were removed, than by bloating the chain with UTXO dust that will remain unspent forever.

Also, the true reason why people oppose these proposals is because they don't want to see fees skyrocket.  They don't care what's being added in the chain, just as they don't care for every other transaction that is not "data-only".  Opposing the free market from finding innovative and efficient ways to make use of Bitcoin is contrary to the spirit of Bitcoin, and raises concern for the security budget problem.  The more obstacles we place to the way information can be spread, the more we push ourselves towards declining on-chain usage.

But in order for the ones that want to store a lot of info (I consider it spam), they are asking to use my computer to store their information/spam. Nowhere in any instance in society is there a requirement that others may use or abuse your property or use it for reasons you do not want it used.

I haven’t said much over the years because frankly, so many people understand the technical level more than me. But this move pushes us towards centralization. And that is the death spiral. Pretty soon it will require a data center to run core. At that point every small player is priced out of participating. Any chain that allows this always has a high cost and is centralized. Bitcoin will be no different.

I don’t believe I should have to host spam - at a cost nonetheless- in order to use my permissionless money. And just because you can do something, doesn’t mean you should. I can spray paint my car but I don’t want to. Removing this limit means that I have to buy the spray paint for people that want to vandalize my car. I’ve already made the decision that I don’t want my car spray painted. Vandals can go elsewhere and buy their own paint.

[BayAreaCoins]

Could the removal of OP_RETURN be applied to Testnet first and then see how "bad" people can fuck it up there first?

As i stated on earlier page, it just mean people will switch to OP_FALSE OP_IF ... OP_ENDIF inside witness script (this is what Ordinal does). You'll see bloated blockchain since Ordinal need to create 2 on-chain TX to do an operation and spike on UTXO growth if people use it to create token/NFT where the owner representation using an address/UTXO with small amount of Bitcoin.

Should we see this "bloat" on Bitcoin Testnet 4 right now?  I've sent some coins over to try it out hands-on:  https://mempool.space/testnet4/tx/f6de3d16e35e3e1e041d50495cd566192d7f9e8977a3f43c5a347e39b5b3a76b

Edit:  I think I see it, thanks.

[NotATether]

But in order for the ones that want to store a lot of info (I consider it spam), they are asking to use my computer to store their information/spam. Nowhere in any instance in society is there a requirement that others may use or abuse your property or use it for reasons you do not want it used.

I haven’t said much over the years because frankly, so many people understand the technical level more than me. But this move pushes us towards centralization. And that is the death spiral. Pretty soon it will require a data center to run core. At that point every small player is priced out of participating. Any chain that allows this always has a high cost and is centralized. Bitcoin will be no different.

I don’t believe I should have to host spam - at a cost nonetheless- in order to use my permissionless money. And just because you can do something, doesn’t mean you should. I can spray paint my car but I don’t want to. Removing this limit means that I have to buy the spray paint for people that want to vandalize my car. I’ve already made the decision that I don’t want my car spray painted. Vandals can go elsewhere and buy their own paint.

Exactly. There are many layer 2 networks where people can host their data if they really want to. There's no reason to force the entire Bitcoin community to carry data for various shitcoin cash grabs, when things like Taproot Assets literally exist and are begging to be used for this use case. So that will be a Concept NACK from me.

[nutildah]

But in order for the ones that want to store a lot of info (I consider it spam), they are asking to use my computer to store their information/spam. Nowhere in any instance in society is there a requirement that others may use or abuse your property or use it for reasons you do not want it used.

Bitcoin is an opt-in system. Nobody is forcing you to run a bitcoin node. Furthermore, the blockchain is not "your property." You don't really have a right to dictate what it contains, or what it should contain. But if you want to run a node you take part in an implicit agreement to host the blockchain on your computer.

I don’t believe I should have to host spam - at a cost nonetheless- in order to use my permissionless money.

That's the thing: you don't have to. Its a decision you are making on your own accord.

As far as blockchain bloat and the risk of centralization is concerned, I am in 100% agreement with you.

[tvbcof]

This issue seems to me much more about certain fundamental elements of system dynamics (esp, mining) than it is about minor filtering methods which are necessarily (to my way of thinking) under-powered and easily worked around.

As I understand things, this change would more formally open the door for single-transaction blocks.  (Zero-transaction blocks being a thing at times in Bitcoin's history, as, of course, non-filled blocks.)  Am I right about this OP_RETURN change insofar as there would be no coded limits on transaction size and it would only be limited by block size?

Mining pools have always been assumed (for design reasons at least) to be fairly mercenary, and it sounds as though at this point practice is becoming common.  That is to say, out-of-band pay-offs to large miners are becoming more popular?

For various of the on-chain transactions I perform, I would prefer they be processed by non-commercial mining operations (especially in light of the above.)  Assuming some sort of a trustworthy coordination platform, would it be practical to pay minimal or no fee, but instead pay a relatively large sum to an address which would be distributed to the kind of miners which I prefer (e.g., people running bitaxe like devices in their homes and coordinating with processor)?  Are such efforts underway or functional?

[d5000]

But in order for the ones that want to store a lot of info (I consider it spam), they are asking to use my computer to store their information/spam. Nowhere in any instance in society is there a requirement that others may use or abuse your property or use it for reasons you do not want it used.

But, again, you are okay with spam stuffed into fake public keys, like Stampchain? There is no -datacarriersize setting, not even in Knots, that can stop this kind of spam.

I repeat: the removal of OP_RETURN limit does not add additional space for spam. It only offers a significantly less ressource-hungry alternative to store data. If you run a full node, you should love people shifting from fake public keys to OP_RETURN, because you don't need to store the data in the UTXO set and can ignore it.

I really recommend everybody to read the discussion on the developer mailing list, where real technical arguments for and against the change can be found, because I think many of those opposing that change (or any change in policy), are misunderstanding something in that debate. Yes, there are arguments against it too, but imo they're weaker than the arguments in favour.

The most important thing is that there are no additional incentives for spam due to this proposed measure. In other words, spam does not become cheaper.

As I understand things, this change would more formally open the door for single-transaction blocks.  (Zero-transaction blocks being a thing at times in Bitcoin's history, as, of course, non-filled blocks.)  Am I right about this OP_RETURN change insofar as there would be no coded limits on transaction size and it would only be limited by block size?

No, the transaction size standardness limit was not meant to be lifted with this pull request. While there is an idea to later lift also the number of OP_RETURN outputs per transaction, this would not affect the transaction size standardness rule.

[tvbcof]

As I understand things, this change would more formally open the door for single-transaction blocks.  (Zero-transaction blocks being a thing at times in Bitcoin's history, as, of course, non-filled blocks.)  Am I right about this OP_RETURN change insofar as there would be no coded limits on transaction size and it would only be limited by block size?

No, the transaction size standardness limit was not meant to be lifted with this pull request. While there is an idea to later lift also the number of OP_RETURN outputs per transaction, this would not affect the transaction size standardness rule.

What is this standard, where is it defined, and how is it enforced?

The AI associated with a google search on the topic quite clearly communicated (to me) that there are no such limits, but it well could be one of those 'ai hallucinations'.

Edit:  Hold one.  I'm reading the link you provided.  OK, referring to this: https://bitcoin.stackexchange.com/questions/67113/how-does-segwit-reduce-transaction-size-when-the-signature-is-simply-moved-to-a/67115#67115:

Is it the case that there remain basically two size understandings within Bitcoin core at this time and they are at a 1(real)/4(virtual) ratio?

Is it the case that data packed into an OP_RETURN would be valued at the .25 'virtual' ratio (justifiable as their being less strenuous to the system)?

---

Condensing my questions:

Could I pay a mining pool to mine me a block with 3+ MB of contiguous data of my choice and expect it to reside on unprunned blockchains indefinitely?

That is to say, are there hard enforcements on the (seemingly rather generous) transaction size standardness rules, or would someone who had the resources be able to ignore them successfully?

[gmaxwell]

OP_RETURN data, while completely prunable and pruned, gets counted as non-witness data for the purpose of the block's capacity limit.  It would be reasonable for it to count the same as witness data except that doing so would require a hardfork-- so that's why it isn't.

Miners have produced blocks with single huge transactions basically filling the limit of the whole block.  Though that's particularly not related to this subject as you couldn't do that with opreturn.

Is it the case that there remain basically two size understandings within Bitcoin core at this time and they are at a 1(real)/4(virtual) ratio?

I don't think that's generally a reasonable understanding.  Bitcoin core eliminated the block size limit and replaced it with a block weight limit. In terms of weight non-witness bytes count for 4 weight, because (for the most part) they're non-prunable data.   On the basis of Bitcoin's long term resource costs it would have been more reasonable to make that 20x or even higher, but the amount of additional capacity for transactions has a diminishing increase (because on so much of a transaction can be witness data) while the worst case amount of bandwidth needed to relay blocks goes up linearly with it.

If you don't want to store that prunable data, simply don't.  That's the critical difference for prunable data, you can be full participant in the network without storing it long term.
 

[tvbcof]

...

Very useful information.  I have to say thank you for engaging the community which cannot be the most enjoyable use of time.

I bowed out of pretty much all things Bitcoin after the very exhausting blocksize wars and basically just put my confidence in yourself and select others to deal with the seg-wit stuff and other goings-on.  Bitcoin is still around, so hats' off to you guys.  The technicals are frustrating to catch up on due to size/complexity of the system, mis-information, outdated information, understandable differences of opinion, etc, etc.  Understandings are, or course, necessary to have a valid opinion.

[d5000]

What is this standard, where is it defined, and how is it enforced?

"Standardness" are rules you can use to when configuring your node to control some aspects of the transactions or blocks you relay. They're not part of the consensus, so if you configure these settings differently other nodes won't reject your node. So they are not "enforced" in the network. And if a miner mines a block with transactions which do not comply with your standardness settings, your node would process these blocks anyway.

Their main purpose is to give the nodes capabilities to act agains DOS attacks. For example if someone is spamming thousands of transactions to the network with complicated scripts with a lots of calculations to do for nodes, this could make your node go offline (depending on your hardware). You can thus set these transactions as "non standard" and refuse to relay them. Bitcoin Core does have several of these "restrictions" enabled by default. But you can also chose to disable them if you want.

The values afaik are defined in the "policy" file or groups of files of the source code, so before you compile Core you can change them, or use a patch.

The OP_RETURN limit was not set because of a danger of DOS. It was instead set to "nudge" protocols like tokens (e.g. Counterparty or Omni, which were already around in 2014-15) to use the least amount of on-chain data possible. It can't be prevented however that this data is stored in fake public keys which look like a regular transfer of Bitcoins but actually can never be spent. [1] Protocols like Bitcoin Stamps / Stampchain do exactly this. And then the Ordinals wave in 2023 happened, where people learned to stuff data into the witness. In theory you could filter this with standardness rules like Knots does, but the protocol developers may come up with a little change and your filter becomes useless. At least such filters create a lot of maintenance cost for the Bitcoin client development team.

The maximum transaction size is another one of these standardness limits and is independent from the OP_RETURN limit. It's currently 400,000 weight units or normally 100 kBytes (See what gmaxwell wrote). A little less than these 100 kB would be the maximum amount of data the nodes would consider standard for an OP_RETURN output if the OP_RETURN byte limit was removed.

But as you may have read elsewhere and @gmaxwell just posted, in the Ordinals wave some miners didn't care at all about the standardness rules, and mined for example a block with a single transaction with 3,9 MB or so in February (?) 2023.

Could I pay a mining pool to mine me a block with 3+ MB of contiguous data of my choice and expect it to reside on unprunned blockchains indefinitely?

You can do that already now.

That is to say, are there hard enforcements on the (seemingly rather generous) transaction size standardness rules, or would someone who had the resources be able to ignore them successfully?

No, as explained above. Of course the more nodes have enabled a "standardness" restriction, the more difficult it gets for a transaction which doesn't cater to these rules to get mined -- in theory. But financial incentives makes it quite easy to get non-standard transactions mined if you pay a higher fee.

Unfortunately this also creates an incentive for centralization, because it provides big mining pools an additional source of income, hurting the economics of smaller pools and solo miners who are already at a disadvantage. If the big miners have an additional source of income, this indirectly boosts the difficulty (because they can invest in more hardware) and thus makes it more expensive to mine for all miners, but small miners won't have this source of income.

One can say in a simplified manner that the more restrictive the standardness settings are (in comparison to the "hard" consensus limits like the block size), the stronger this centralization effect is. Lifting the limits would thus be an anti-centralization measure. It would hurt the big miners most who charge high fees for non-standard transactions (and that's why it's not surprising that a mining pool representative was against it in the mailing list discussion).


Edit: [1] there is actually a way to require that the keys must create a spendable output, but this still allows to stuff data into these fake public keys, albeit a little bit less. But afaik it would lead to more resource usage for the nodes to control this, so I guess the developer consider it's not worth it.

[tromp]

Edit: [1] there is actually a way to require that the keys must create a spendable output, but this still allows to stuff data into these fake public keys, albeit a little bit less.

Are you talking about public keys with a proof of knowledge of the private key (i.e. a signature) ?
While you can set some output bits by grinding, that would not a little bit less, but MUCH less.

[Wind_FURY]

Asking for my fellow plebs.

For those who don't like dick pics/fart sounds and other "disliked" transactions that are not financial transactions in the blockchain, is there an actual roadmap proposed in how to filter those transactions? Because all I read are "let's vaccinate the blockchain" posts.

[stwenhao]

is there an actual roadmap proposed in how to filter those transactions?

No, there are only some ideas, related to dropping historical data. Which means, that no matter if something is a real payment, or some kind of data push, it can be stripped in a similar way. And then, transaction makers are mostly unaffected, because usually they care only about the final destination of their coins, while data pushers will cry, when they will find out, that less and less nodes are willing to share their pushed data, when they start providing proofs, instead of sharing original data pushes.

In general, when you start a new node, and you synchronize the chain, you don't have to know, that "Alice -> Bob -> Charlie" is what happened. The only thing you have to know, is "Alice -> Charlie", and a proof, that all signatures are valid, and are covered by the heaviest Proof of Work in existence. And then, Bob can locally keep the proof, that he was inside, but nobody else needs that during Initial Blockchain Download (in the same way, as nobody needs all Lightning Network transactions).

And then, if you have just some money-related transactions, it is not a big deal, that Bob will have only some local proofs. It can be even viewed as an advantage, because then, payments can be more private, if all chains of unconfirmed transactions will be simplified every 10 minutes, while charging the same fees as usual. But in case of any spam-related activities, these users wouldn't want to keep their NFTs locally. If they would want to do that, then they would use commitments today. So, they will suffer the most, if that kind of changes will be accepted by the community.

Because all I read are "let's vaccinate the blockchain" posts.

Read about proposals like SwiftSync: https://groups.google.com/g/bitcoindev/c/FpSWUxItXQs

[MeGold666]

Almost every block is full of low quality images:

https://mempool.space/

https://ordiscan.com/blocks

And some people are still arguing that everything is OK. 😄

Filtering transactions by miners equals censorship and I doubt any miner would filter this out when they pay big fees for this junk to be included.

This would need to be fixed at the protocol level to make it impossible - and we all know nothing will be done.
From what I've read on GitHub, there is a solution for it, but people argue it shouldn't be implemented, and every discussion on the topic is eventually closed.

Just look at this shit, there are gigabytes of this junk already and growing.

[ABCbits]

Could the removal of OP_RETURN be applied to Testnet first and then see how "bad" people can fuck it up there first?

As i stated on earlier page, it just mean people will switch to OP_FALSE OP_IF ... OP_ENDIF inside witness script (this is what Ordinal does). You'll see bloated blockchain since Ordinal need to create 2 on-chain TX to do an operation and spike on UTXO growth if people use it to create token/NFT where the owner representation using an address/UTXO with small amount of Bitcoin.

Should we see this "bloat" on Bitcoin Testnet 4 right now?  I've sent some coins over to try it out hands-on:  https://mempool.space/testnet4/tx/f6de3d16e35e3e1e041d50495cd566192d7f9e8977a3f43c5a347e39b5b3a76b

Edit:  I think I see it, thanks.

What exactly are you trying to say? After all, currently you can create Ordinal TX on testnet4.

For various of the on-chain transactions I perform, I would prefer they be processed by non-commercial mining operations (especially in light of the above.)  Assuming some sort of a trustworthy coordination platform, would it be practical to pay minimal or no fee, but instead pay a relatively large sum to an address which would be distributed to the kind of miners which I prefer (e.g., people running bitaxe like devices in their homes and coordinating with processor)?  Are such efforts underway or functional?

I don't think such thing is possible, unless you only share your TX with those non-commercial miners and wait for them to mine a block and include your TX manually. There's also limitation regarding those miner joining mining pool, where AFAIK most of them owned by for-profit company.

This would need to be fixed at the protocol level to make it impossible - and we all know nothing will be done.
From what I've read on GitHub, there is a solution for it, but people argue it shouldn't be implemented, and every discussion on the topic is eventually closed.

Can you share discussion link which makes it impossible, including misuse of address and public key to store arbitrary data?

[stwenhao]

This would need to be fixed at the protocol level to make it impossible

If that's the case, then I wonder, when Monero will fix it: https://mordinals.gitbook.io/handbook/how-does-it-work

Are there any plans to ban Ordinals from Monero?

The only resistant chain I know of is Grin, because users cannot control, how their data pushes will be represented on-chain, so they will be shuffled in the process, which will make them useless.

[tromp]

The only resistant chain I know of is Grin, because users cannot control, how their data pushes will be represented on-chain, so they will be shuffled in the process, which will make them useless.

The reordering of tx outputs and signatures is one reason for spam resistance (item 3. in [1]), but not the main one. Which is the fact that there's very little room for spam to begin with (items 1.,2.,4.)

[1] https://forum.grin.mw/t/ordinals-on-grin/10336/2

[BayAreaCoins]

Could the removal of OP_RETURN be applied to Testnet first and then see how "bad" people can fuck it up there first?

As i stated on earlier page, it just mean people will switch to OP_FALSE OP_IF ... OP_ENDIF inside witness script (this is what Ordinal does). You'll see bloated blockchain since Ordinal need to create 2 on-chain TX to do an operation and spike on UTXO growth if people use it to create token/NFT where the owner representation using an address/UTXO with small amount of Bitcoin.

Should we see this "bloat" on Bitcoin Testnet 4 right now?  I've sent some coins over to try it out hands-on:  https://mempool.space/testnet4/tx/f6de3d16e35e3e1e041d50495cd566192d7f9e8977a3f43c5a347e39b5b3a76b

Edit:  I think I see it, thanks.

What exactly are you trying to say? After all, currently you can create Ordinal TX on testnet4.

Right, like I said, I see it. 

[d5000]

Are you talking about public keys with a proof of knowledge of the private key (i.e. a signature) ?
While you can set some output bits by grinding, that would not a little bit less, but MUCH less.

Seems you're correct, I've re-read the relevant part of the mailing list discussion and here Peter Todd argues that it would make the "fake public keys" approach about 6-7 times more expensive regarding fees. But the downside is that according to another post by Sjors Provoost, here, the sizes of the output scripts would increase "dramatically":

To stop that, you'd have to introduce a rule that only allows spendable public keys to be put on chain. Afaik, the only way to do that is to require a signature. That would dramatically increase the size of all output scripts.

So, to deter spam, we would have more bytes in the blockchain, even in normal "financial" BTC transactions  Basically we would be spamming all the time, only to control that only the "correct" data is published.

(Shower thought: could these signatures perhaps eventually be pruned? Edit: What I mean here - in some altcoins there are "temporary" data fields and transaction types which "expire" at a certain block height so they don't need to be downloaded in the IBD after a certain height has been reached. I guess they are not directly hashed for the tx hash/txid -- otherwise they would always be needed --, but a short hash of it.)

I would not be against such measures if they are well thought out, but making all transactions bigger doesn't look to me that it makes sense.

Ordinals and similar protocols typically come and go like other kinds of fads. They depend on other factors like the current size of the NFT market, and it's possible that NFTs are eventually seen as an outdated concept. I have seen that there are now again more BRC-20 (Ordinals tokens) transactions on the blockchain, but that is probably because they're now using 1 sat/vbyte phases to simply "try out things". Once they see that there's not even profit anymore with that method, also this wave will probably die out.

[tvbcof]

...

For various of the on-chain transactions I perform, I would prefer they be processed by non-commercial mining operations (especially in light of the above.)  Assuming some sort of a trustworthy coordination platform, would it be practical to pay minimal or no fee, but instead pay a relatively large sum to an address which would be distributed to the kind of miners which I prefer (e.g., people running bitaxe like devices in their homes and coordinating with processor)?  Are such efforts underway or functional?

I don't think such thing is possible, unless you only share your TX with those non-commercial miners and wait for them to mine a block and include your TX manually.

I don't see a danger in the transactions being picked up (or mined) by generally dis-favored miners since there is little reason for them to do so, and if they for some reason did, great.

For a lot of (but not all of) the on-chain transactions I perform, it really doesn't matter to me how fast they are mined (within reason.)  Or even if they fail completely in some recoverable way.  It's been a philosophy of mine since the GPU days that profitability is always going to approach zero so, in financial terms, it's as effective and a lot less work to just purchase BTC.  Participating in the system (mining, node operation, etc) would be to me a thing to do as/when the system needs it.  As larger pools take over and engage in practices I don't like, that is the time to get active.

As mentioned, if mining trends toward zero profitability, and one is only competing on such things as energy costs, suplementation from other sources becomes a big or dominant factor in profitability.  It's why they will mine trash into the blockchain so it seems...and such has been predicted since the early days.  The basis for my(*) idea is to do the same form of supplementation and in favor of miners who are doing things I agree.  Esp, being independent and autonomous.  One of them would certainly includes applying filter sets which I agree with.  Call it 'fighting fire with fire'.

From my recent research, it seems like mempool coherence is one of the things which 'core' would like to work toward, and for understandable reasons.  My(*) 'games' (which include increased use of filter sets) would probably fuck that up.  This is lamentable, but in my mind kind of in the same category as the pragmatic arguments they are making about aspects of the OP_RETURN limits.

* I doubt that they are 'my' ideas and they are very basic and obvious even if they are.  It is the case, though, that I have held some of them for a long time, and some of them account for my rather unusual views that it's OK if on-chain fees are super high and there are subtle advantages of having the system be 'inefficient', slow, and unpredictable.

There's also limitation regarding those miner joining mining pool, where AFAIK most of them owned by for-profit company.

For my part, I would tend to prefer to foster solo miners (who maintain their own blockchains and mempools.)  To the extent that they formed a 'pool', it would not really be in the same category as most.  The service itself need not be non-profit.  It would mostly just needs to have high quality transparency to give users and miners the confidence to use it.