(Ordinals) BRC-20 needs to be removed

[vjudeu]

How do you convince NFT users to stop using on-chain Bitcoin?

For example by not sharing the data behind historical signatures (which, by the way, leads us to the same model I described above, but just being forced, instead of being voluntary). Bitcoin is a payment system, which means, that pubkey-based functionality should be priority number one. Other use cases are of course possible, and you can create complex scripts, but it should not be the main use case, but just some "fallback" mechanism, intended to resolve conflicts. Which means, that if you have P2TR address, then spending by key is the main functionality, which should cover the majority of all cases, and spending by script is a "rescue mode", which is needed, if something goes wrong. However, if that "emergency path" is deeply confirmed, then it can be safely downgraded into key path again.

Which also means, that if new nodes wouldn't require downloading everything during Initial Blockchain Download, and would downgrade historical data into something like OP_CHECKSIGFROMSTACK, or into other kinds of proofs, then projects like Ordinals could no longer rely on their "huge OP_NOPs" being served by Bitcoin nodes, and would be forced into storing those kinds of data by themselves.

Another thing is transaction joining. If regular payments would be joined, then they could compete with Ordinals and other misuse. Because if you have some "payment-only" transactions, then it is easy to combine signatures, because you just add public keys. However, if you have "data-based" transactions, then compression is harder.

Also, I am not the only one thinking in that way. Another example:

That isn't a use case for *Bitcoin* in that it's something Bitcoin doesn't actually accommodate on a fundamental basis: Bitcoin nodes don't need to store or provide access to historical blocks to operate.  They only do today (to the extent they do, many don't) to aid new nodes coming up securely, but in the future that will be accomplished via other means because transferring terabytes of blockchain to process and throw away whenever someone starts a new node won't be sufficiently viable.

Also note that for example chapter seven from the whitepaper, called "Reclaiming Disk Space" is still not applied on the Initial Blockchain Download stage, which means, that Satoshi's conclusions, expressed as "storage should not be a problem even if the block headers must be kept in memory" are not fulfilled, because you still have to download more data, than "just block headers". And also note, that we can get there gradually, for example by applying "just synchronize signatures-only" first, and see how that approach would be received by the community, before going further.

Also, the current model, where you have to download everything, is one of the reasons, why you cannot increase the size of the block by too much. Because then, you can get beyond verification time, which means, that blocks would be produced faster, than you could verify them. However, if anyone thinks that having bigger blocks is a good idea, then improving Initial Blockchain Download is the first step to get it done (and also other simplifications are needed, to not allow people for uploading videos, which could remove all advantages of higher on-chain transactions per second ratio).

[1714562034]

1714562034

[ABCbits]

~ If Rune users want cheaper transaction fees for their Rune-shitcoins, then USE LIGHTNING!

Or better yet, if they actually want to develop anything and not just scam people they should create a separate and stand alone blockchain and use that to create whatever they want and stop exploiting the Bitcoin protocol

It's worth to remind you already can create NFT/token on LN using either Taproot Assets or RGB protocols. But using sidechain should be better option since you could avoid creating any transaction on Bitcoin blockchain.

That's the "what", not the "how". How do you convince NFT users to stop using on-chain Bitcoin?

IMO it's mostly not technical issue. If they still prefer using Bitcoin to create NFT even though it has slower confirmation time and far higher TX fee, there aren't many other option.

[Wind_FURY]

How do you convince NFT users to stop using on-chain Bitcoin?

For example by not sharing the data behind historical signatures (which, by the way, leads us to the same model I described above, but just being forced, instead of being voluntary). Bitcoin is a payment system,

Don't take it offensively, but let me stop you there. Because of its permissionless nature, the Bitcoin network is not merely a "payment system". "Our" use case doesn't have to be "their" use case. Satoshi may have wanted to design a censorship-resistant "payment network", but it doesn't look like it's its only use case.

That's the "what", not the "how". How do you convince NFT users to stop using on-chain Bitcoin?

IMO it's mostly not technical issue. If they still prefer using Bitcoin to create NFT even though it has slower confirmation time and far higher TX fee, there aren't many other option.

OK, then let's agree to disagree.

[pooya87]

I don't doubt those many ways of shutting this "attack" - according to your opinion - down. I'm asking actually HOW? Those are valid transactions that paid the fees/followed the consensus rules. It's a very dangerous path for the community if shutting it down gets consensus. Because that would start a cycle, in that, another group of people could also complain about some other use case and demand that it should be "shutdown".

I disagree because we're talking about an exploit not "use case" and we've been doing this for always and this is literally the first time the Bitcoin community is showing resistance against fixing an exploit in the protocol! Nobody ever called any of them "censorship" nor where they ever worried about it starting "a dangerous path"!

For example before SegWit soft-fork in 2017 you could exploit the protocol by abusing the dummy stack item in OP_CHECKMULTISIG(VERIFY) ops to inject an arbitrary data to the chain. After the fork, this exploit was patched and such transactions are invalid now. Same with the conditional ops bool that is popped from the stack.
There are also countless examples of how we prevented a lot of different exploits through standard rules that we've already covered a thousand times such as the limits on OP_RETURN outputs.

[Wind_FURY]

I don't doubt those many ways of shutting this "attack" - according to your opinion - down. I'm asking actually HOW? Those are valid transactions that paid the fees/followed the consensus rules. It's a very dangerous path for the community if shutting it down gets consensus. Because that would start a cycle, in that, another group of people could also complain about some other use case and demand that it should be "shutdown".

I disagree because we're talking about an exploit not "use case" and we've been doing this for always and this is literally the first time the Bitcoin community is showing resistance against fixing an exploit in the protocol! Nobody ever called any of them "censorship" nor where they ever worried about it starting "a dangerous path"!

For example before SegWit soft-fork in 2017 you could exploit the protocol by abusing the dummy stack item in OP_CHECKMULTISIG(VERIFY) ops to inject an arbitrary data to the chain. After the fork, this exploit was patched and such transactions are invalid now. Same with the conditional ops bool that is popped from the stack.
There are also countless examples of how we prevented a lot of different exploits through standard rules that we've already covered a thousand times such as the limits on OP_RETURN outputs.

You can call it an "exploit", or a "bug", or something else, but from the network's viewpoint those transactions followed the consensus rules, paid the fees, and miners are also incentivized to include them in their blocks because of that. You can have your opinion about what it is, but that's merely what it is. An Opinion. But if removing the "exploit/bug" gets community consensus through a soft/hard fork, then OK. Fork accepted.

[pooya87]

You can call it an "exploit", or a "bug", or something else, but from the network's viewpoint those transactions followed the consensus rules, paid the fees, and miners are also incentivized to include them in their blocks because of that. You can have your opinion about what it is, but that's merely what it is. An Opinion. But if removing the "exploit/bug" gets community consensus through a soft/hard fork, then OK. Fork accepted.

Being part of the consensus rule doesn't mean something is not a bug or exploitable. Read my two examples again, they were also part of the consensus rules and yet they were bugs in the protocol that could have been exploited.

[DooMAD]

Being part of the consensus rule doesn't mean something is not a bug or exploitable. Read my two examples again, they were also part of the consensus rules and yet they were bugs in the protocol that could have been exploited.

Your premise appears to be that any kind of data storage, unrelated to transactional data, isn't a valid use of Bitcoin.  But I'm not convinced developers see things in such black and white terms.  I've certainly seen some developer discussion relating to the standardisation of data storage, but I don't see any particular push to restrict it completely.  Perhaps the patches you're referring to weren't the correct format in which devs were looking to support data storage. 

Is it possible you might be working under the assumption that devs want to prevent data storage because they made those particular changes?  If so, I think you might be misinterpreting what they were looking to achieve.

[Wind_FURY]

You can call it an "exploit", or a "bug", or something else, but from the network's viewpoint those transactions followed the consensus rules, paid the fees, and miners are also incentivized to include them in their blocks because of that. You can have your opinion about what it is, but that's merely what it is. An Opinion. But if removing the "exploit/bug" gets community consensus through a soft/hard fork, then OK. Fork accepted.

Being part of the consensus rule doesn't mean something is not a bug or exploitable. Read my two examples again, they were also part of the consensus rules and yet they were bugs in the protocol that could have been exploited.

But from the viewpoint of the network, if a transaction paid for the fees and followed the consensus rules then those transactions are technically valid, and they will be included in the blocks. You can have an opinion on what to call it. It's an "exploit" according to your opinion? OK, but for dick pic/fart sound collectors, their usage of the blockchain is merely something you don't approve of.

[Cricktor]

There's the clear inequity under current rules that one byte of data in an OP_RETURN output is worth 4WU and one byte in witness data as exploited by inscriptions is only 1WU. If you want data on the blockchain to be treated equally, current rules simply don't do it and I consider this a fault/bug and/or ongoing exploit.

I'm not so much following discussions of Core devs, but frankly, my perception is a disturbing unwillingness to tackle this weight unit inequity.

I don't need to like what's "inscribed" to the blockchain, it's not my business to judge or censor. Bitcoin is not made to judge or censor.

[vjudeu]

There's the clear inequity under current rules that one byte of data in an OP_RETURN output is worth 4WU and one byte in witness data as exploited by inscriptions is only 1WU.

Guess what: on the mailing list, there was a topic about exactly this issue, and it was continued on Delving Bitcoin: https://delvingbitcoin.org/t/bug-spammers-get-bitcoin-blockspace-at-discounted-price-lets-fix-it/327

But I think it won't be fixed, because of that line of thinking:

The byte size of transactions in the P2P protocol is an artifact of the encoding scheme used. It does matter, because it directly correlates with bandwidth and disk usage for non-pruned nodes, but if we really cared about the impact these had we could easily adopt more efficient encodings for transactions on the network or on disk that encodes some parts of transactions more compactly. If we would do that, the consensus rules (ignoring witness discount) would still count transaction sizes by their old encoding, which would then not correspond to anything physical at all. Would you then still say 1 byte = 1 byte?

And in general, I agree with that statement, but I also agree, that in the current model, not all bytes are counted properly. For example: there is an incentive to send coins into P2WPKH, but spend by key from P2TR. However, if you count the total on-chain footprint of P2WPKH, and compare it with P2TR with key-path spending, then P2WPKH is cheaper to send to, but it takes more on-chain bytes (and the cost is just moved to the recipient, so it is cheaper for the sender).

Also, if we would optimize things, and represent them on-chain differently, for example by saving raw public keys, and just using a single byte to indicate, that "this should use old DER encoding", and "this pubkey is wrapped in P2SH", then the whole chain could probably be much smaller, than it currently is. However, as compression is a no-fork, it can be always applied, so the only problem is standardizing the data, so then you can rely on other nodes, getting exactly the same results, and compressing data with the same algorithms. So, it is all about making "ZIP format for blockchain data": it is easier to send ZIP file, if you can unzip them in the same way on both computers. The same is true for historical blockchain data (and of course, some custom algorithm would be more effective, than just zipping it, because it could take into account, that you have to compress for example secp256k1 points, so it could efficiently use for example x-only-pubkeys, without having to build a weird auto-generated "dictionary" for that).

I've certainly seen some developer discussion relating to the standardisation of data storage, but I don't see any particular push to restrict it completely.

Well, if you want to simplify the current model, then standardisation is the first step in the right direction. And then, if you have for example some widely-deployed model, where you have a huge table of all public keys, which appeared on-chain, then you can generalize it, switch to a different model (utreexo), or view the scripting language from a different perspective: https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682

So, I guess that it could be restricted, if the network will be abused too much, but people are currently focused on things, which needs to be done, no matter if you want to restrict it, or not. Because simply "the status quo" is the default, so if you work on a change, that does not require touching consensus, then it can be easily merged. But if you work on some serious soft-fork instead, then you may end up with some working code, that simply won't be merged. And of course, writing some code, which is not consensus-critical is still needed, and is often required as a dependency to your soft-fork (you need to have standardized data compression, to compress and decompress the chain reliably, and to "undo your pruning" if needed).

[pooya87]

Being part of the consensus rule doesn't mean something is not a bug or exploitable. Read my two examples again, they were also part of the consensus rules and yet they were bugs in the protocol that could have been exploited.

Your premise appears to be that any kind of data storage, unrelated to transactional data, isn't a valid use of Bitcoin.  But I'm not convinced developers see things in such black and white terms.  I've certainly seen some developer discussion relating to the standardisation of data storage, but I don't see any particular push to restrict it completely.  Perhaps the patches you're referring to weren't the correct format in which devs were looking to support data storage. 

Is it possible you might be working under the assumption that devs want to prevent data storage because they made those particular changes?  If so, I think you might be misinterpreting what they were looking to achieve.

My examples were about "exploits" and fixing them more than being about data storage. But I agree that in Bitcoin we are slightly "flexible" when it comes to data storage (but not that much). For example we already have OP_RETURN that is used for data storage and is the standard way but it is a limited way that is acceptable.

Keep in mind that bottom is that Bitcoin is not a cloud storage, it is a payment system.

[larry_vw_1955]

Keep in mind that bottom is that Bitcoin is not a cloud storage, it is a payment system.

well, all i can say about that is bitcoin is going to be LEFT BEHIND if it clings to some type of small block sizes when consumer hard drives end up being 250 TB in size.

Hard drives aren't dead yet as Seagate demos new multi-layer 3D magnetic tech with potential for 240TB capacities
https://www.pcgamer.com/hardware/graphics-cards/hard-drives-arent-dead-yet-as-seagate-demos-new-multi-layer-3d-magnetic-tech-with-potential-for-240tb-capacities/

How would bitcoin continue to justify itself with only 400mb per year when people have 240TB hard drives? I just don't think it could. Adapt or die.

[pooya87]

Keep in mind that bottom is that Bitcoin is not a cloud storage, it is a payment system.

well, all i can say about that is bitcoin is going to be LEFT BEHIND if it clings to some type of small block sizes when consumer hard drives end up being 250 TB in size.

That's a completely different topic.
Regardless of what Bitcoin's block capacity is, whether it is 1 byte or 1 terabyte, Bitcoin should continue staying as a payment system and not a cloud storage.

[Wind_FURY]

There's the clear inequity under current rules that one byte of data in an OP_RETURN output is worth 4WU and one byte in witness data as exploited by inscriptions is only 1WU. If you want data on the blockchain to be treated equally, current rules simply don't do it and I consider this a fault/bug and/or ongoing exploit.

But from the viewpoint of the Ordinals/soon Runes users, if they have paid the fees and they're transactions are following the consensus rules, are they truly "exploiting" the system? It's not their fault it's there. They're merely using it because the system allows them to. Plus if it wasn't Casey Rodarmor, it would be another developer that would use this "hack/bug" and make something from it.

I'm not so much following discussions of Core devs, but frankly, my perception is a disturbing unwillingness to tackle this weight unit inequity.

I believe that they should be careful. It might start a hash war again.

I don't need to like what's "inscribed" to the blockchain, it's not my business to judge or censor. Bitcoin is not made to judge or censor.

I don't like it too, it's making on-transactions a little more expensive to use for plebs like us. But what can we do? Literally ANYONE can use Bitcoin the way it allows us to if we pay the fees and follow the consensus rules.

[vjudeu]

But from the viewpoint of the Ordinals/soon Runes users, if they have paid the fees and they're transactions are following the consensus rules, are they truly "exploiting" the system?

Yes. In the same way, you could try to copy-paste the whole chain from some altcoin into Bitcoin, by using "a coin in a coin" scheme. Or copy-paste all posts from bitcointalk and put it into Bitcoin transactions. Or even abandon GitHub, and copy-paste all commits behind "OP_SHA1 <commitHash> OP_EQUALVERIFY <developerPublicKey> OP_CHECKSIG". The purpose of Bitcoin is not to be "the global chain for every use case". As Satoshi said:

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

And then he also continues:

Bitcoin and BitDNS can be used separately.  Users shouldn't have to download all of both to use one or the other.  BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.

So, if other use cases would use some separate chains for that data, it could be fine. They could build some honest, valuable protocol out of that. But the problem is, that they just decided not to, and abuse the Bitcoin network instead.

And yet another sentence, from the same post:

The networks need to have separate fates.  BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.

Which means, that if you put all of those additional features on separate chains, then Bitcoin can still stay "easy for lots of users and small devices", and just take a role of "a notarization chain", providing Proof of Work to timestamp all other chains. But if you put "everything on Bitcoin" instead, then guess what: the current limits will take down existing payments. Because it is always a choice: confirm this payment, or this Ordinal. Which means, that if you allow using and abusing Bitcoin for everything else than the payment system, then it may stop being useful for payments, and lose its utility.

[Cricktor]

How would bitcoin continue to justify itself with only 400mb per year when people have 240TB hard drives? I just don't think it could. Adapt or die.

400MB per year is not the growth rate of Bitcoin's blockchain. A conservative estimate with approx. 1.5MB per block gives you a growth of roughly 2016 blocks per two weeks times 26 (for a year) times 1.5MB which equals 78,624MB per year, thus somewhere in the ballpark of 80GB growth per year at minimum.

I wonder where you got this 400MB figure from...

And those 240TB harddrives are still vaporware. Try an Initial Blockchain Download and node sync on a mechanical harddrive, it's a real fun^{not so much for the drive}. You can keep the irony if you detect it.

But from the viewpoint of the Ordinals/soon Runes users, if they have paid the fees and they're transactions are following the consensus rules, are they truly "exploiting" the system? It's not their fault it's there. They're merely using it because the system allows them to. Plus if it wasn't Casey Rodarmor, it would be another developer that would use this "hack/bug" and make something from it.

I'm not sure if I get it right, so excuse if I confuse consensus rules with something else. My standpoint is: it's a flaw in consensus rules to allow arbitrary sized witness data for an input in a transaction. There's likely no real need for this. It's an oversight which is now exploited. Can it be fixed easily without having weird or problematic side-effects. I don't know, that's a bit over my technical Bitcoin expertise.

I don't care who exploits it for whatever reason. The inscription shitheads and shit-token on Bitcoin blockchain morons exploit it and abuse the blockchain for storage of bullshit data. They don'c care about Bitcoin, period!

Sure, I'm exaggerating that it's bullshit of whatever flavor in my personal opinion. I don't expect anybody to agree on this with me. I'm free to have my own opinion and defend it.

I believe that they should be careful. It might start a hash war again.

Did you rather meant a blocksize war? I believe, yes, because I can't make up anything related to hash power with this topic.

I don't like it too, it's making on-transactions a little more expensive to use for plebs like us. But what can we do? Literally ANYONE can use Bitcoin the way it allows us to if we pay the fees and follow the consensus rules.

We can debate the magnitude of "more expensive" fees, but that's not what I dislike in particular. More adoption and more transactions would also fill up the mempool and make it more expensive for you and me. That's the fee market and I have no valid point to complain about it if more adoption and "normal" transaction volume were the reason for  mempool clogs.

OP_RETURN data costs 4WU per byte. I wouldn't be happy if people start to use it excessivly but at least they'd have to pay a fair fee for it. And it's limited in size for a reason. Someone who wants to pay for it could use as many OP_RETURN outputs in his transaction(s) as this someone feels (s)he needs to. Would I like it? Certainly no. But I'm pretty much sure, it wouldn't be exploited in the extend we see with the inscription shit.

This superfluous data burdens every archival node and because of arbitrary size within the limits of max. blocksize any exploiter can cram in data that could become a problem with law. OP_RETURN is somewhat similar but you have the 80 bytes limit, even if used in multiples, you have a segmentation of problematic data like pictures or movies that collide with law.
I hope that such a forced segmentation wouldn't allow to say there's a whole problematic picture, intact in it's entirety in the blockchain. (Yes, I'm aware that such things were attempted in the past or maybe also in the presence. Stupid data abusers...)

Another issue is the bloating of the UTXO set by idiots who like to send dust or more to the genesis block's coinbase or rather the derived P2PKH address of the P2PK coinbase public key or other "Patoshi" blocks. But that's another, entirely different topic, though it shows to some extend that many people simply don't care to look at the whole picture and consequences for all of us.

Sorry for the rant but such sort of asocial ego-centric <choose your own fitting curse word> narrow-bubbled beings piss me off from time to time.

[Wind_FURY]

But from the viewpoint of the Ordinals/soon Runes users, if they have paid the fees and they're transactions are following the consensus rules, are they truly "exploiting" the system?

Yes. In the same way, you could try to copy-paste the whole chain from some altcoin into Bitcoin, by using "a coin in a coin" scheme. Or copy-paste all posts from bitcointalk and put it into Bitcoin transactions. Or even abandon GitHub, and copy-paste all commits behind "OP_SHA1 <commitHash> OP_EQUALVERIFY <developerPublicKey> OP_CHECKSIG". The purpose of Bitcoin is not to be "the global chain for every use case".

Ser, I'm confused because none of what you have just said make sense. What matters is the protocol as is right NOW. Bitcoin is still a decentralized, permissionless, censorship-resistant protocol isn't it? If the Core developers propose a "fix" for the "bug", it would need to go through the proper process, unless UASF.

As Satoshi said:

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

And then he also continues:

Bitcoin and BitDNS can be used separately.  Users shouldn't have to download all of both to use one or the other.  BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.

So, if other use cases would use some separate chains for that data, it could be fine. They could build some honest, valuable protocol out of that. But the problem is, that they just decided not to, and abuse the Bitcoin network instead.

And yet another sentence, from the same post:

The networks need to have separate fates.  BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.

Which means, that if you put all of those additional features on separate chains, then Bitcoin can still stay "easy for lots of users and small devices", and just take a role of "a notarization chain", providing Proof of Work to timestamp all other chains. But if you put "everything on Bitcoin" instead, then guess what: the current limits will take down existing payments. Because it is always a choice: confirm this payment, or this Ordinal. Which means, that if you allow using and abusing Bitcoin for everything else than the payment system, then it may stop being useful for payments, and lose its utility.

I'm not saying Satoshi is wrong, plus currently there are solutions being built/have been built, but it's irrelevant because if users want to inscribe/etch digital artifacts in the blockchain, and if they are willing to pay for the fees/follow the consensus rules, then who could stop them?

[ABCbits]

Try an Initial Blockchain Download and node sync on a mechanical harddrive, it's a real fun^{not so much for the drive}. You can keep the irony if you detect it.

It's generality true. But if you allocate enough RAM for all UTXO, then it's boring.

[larry_vw_1955]

That's a completely different topic.
Regardless of what Bitcoin's block capacity is, whether it is 1 byte or 1 terabyte, Bitcoin should continue staying as a payment system and not a cloud storage.

just imagine the day when everyone has 50TB hdds (yes that day is going to come) and bitcoin is only using 80GB per year. that seems like a serious problem but maybe no one else thinks so.

400MB per year is not the growth rate of Bitcoin's blockchain. A conservative estimate with approx. 1.5MB per block gives you a growth of roughly 2016 blocks per two weeks times 26 (for a year) times 1.5MB which equals 78,624MB per year, thus somewhere in the ballpark of 80GB growth per year at minimum.

I wonder where you got this 400MB figure from...

my mistake.

And those 240TB harddrives are still vaporware.

apparently there is a working prototype. not good enough for you? but expect to open up that wallet when they come to market. unless you're willing to wait for 10 years for prices to come down...

Try an Initial Blockchain Download and node sync on a mechanical harddrive, it's a real fun^{not so much for the drive}. You can keep the irony if you detect it.

no thanks. i'm not interested in downloading 450GB and then having to keep it in sync all the time. you're welcome. 

[vjudeu]

i'm not interested in downloading 450GB and then having to keep it in sync all the time.

This part is strange: many people want bigger blocks, but they don't want to run their own nodes to handle all of that traffic. Why? If you are the one who wants big blocks, then you should also be the one, who runs your node 24/7, and shows everyone: "See? I can handle that without any problems!". I wonder, what is the reason behind willing to increase the maximum block size, and not willing to participate in the costs of doing so. And the same is true for Ordinals: people want to use existing network (like Bitcoin), and put their data here, instead of maintaining their own chain, and participating honestly in all costs of storing additional data, on their own chain.

Also, if you would try running your own node with increased limits, and perform some testing, then you would know, that "downloading 450GB" is not the biggest problem. Storing it on your server is a bigger issue (because bandwidth is usually sufficient, but you need to rent additional disks), and verification is even bigger problem (because then you also need to rent more CPUs). And then, you would also know, that Initial Blockchain Download can currently take something around a week (it depends on your hardware), and if you increase the size of the block, then you could have a situation, which you can see on some altcoins: you can take some CPU-mineable altcoin, and download their chain very quickly, because it takes for example 10 GB, but verification time is something like a month.

But if you allocate enough RAM for all UTXO, then it's boring.

Currently, the size of the whole UTXO set is not limited by consensus rules, but I guess some people really want to abuse that, and force developers to introduce some limits there.