It was proposed for new testnets to make it like that. And I agree with Garlo Nicon, that it is better to not touch the limit, but change the proportions instead, by mining enough coins for developers, before releasing new client for new testnet.

Also, when it comes to OP_RETURN, then there are other limits, which will still make things stable. There is a Script size limit, a transaction size limit, a block size limit, a transaction fee limit, and so on. And when OP_RETURN limit can be trivially bypassed, then it can be lifted, because it does more harm than good.

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.

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.


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.

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.

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.

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.

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.
 

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

You can do that already now.

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.

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.

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.