Why was the block size not increased?

[pooya87]

For 4 years. Then it halves again. And again. People have this distant figure of "2140" in their head as when the subsidy goes to zero and we can just kick the can down the road and we don't really need to care about fees until then, but in reality most people using bitcoin today are going to live to see the point when the subsidy becomes negligible. It's only going to take 20 years for the block subsidy to fall below 0.1 BTC. Even if we think bitcoin will be $100,000, then you are down to only $10k per block which is around 2-3% of what miners are earning right now per block. And it only goes down from there. Unless you believe bitcoin is going to be worth $10 million or more within in the next 20-30 years, we need a competitive fee market.

That's true but we should discuss that and the options to increase miners revenue when the issue arises in 10-30 years from now. If by then we decided that turning Bitcoin to cloud storage and to increase the fees by a spam attack is the way to go, then so be it. It would be trivial to loosen the policy rules to allow that.

Today and in the near future we don't need that though. And that's why I disagree with bringing up miners revenue at this stage. Price has been rising nicely and even during the drops over the past year or two we still saw hashrate go up which shows miners are not concerned about losing revenue.

[1714286551]

1714286551

[1714286551]

1714286551

[1714286551]

1714286551

[Medusah]

Today and in the near future we don't need that though.

Another one might argue we neither need 519.6 EH/s and that we would be fine with *just* 10 EH/s.  I think the path to dictating what miners need and what need not is a dangerous one.  Also, "censor these unless we need their money" sounds a ridiculously improvised solution to the long-term survival problem.

[philipma1957]

If the block size can be in a way that 1 sat/vbyte transactions can all be processed in the next block, will this not be good?

No, that will be terrible, since the block subsidy is slowly being phased out, leaving security of the chain entirely up to fees.

The capped supply can only work in the long term if a fee market develops based on sustained congestion.

ideally LN for under 500 usd worth of btc.

and  500-1000 your choice of either LN or the chain

lastly 1000 and up the chain.

We are seeing large mining farms push for large fees to prep for this 2024 1/2 ing.

I think they can force fees over 2-3 btc for a long time after the 1/2ing


There are lots of methods to clog the chain. So a summer 2024 block will be

5-6 coins with fees.

The best method is down clock your huge mining farm/pool

Foundry make 48 blocks a day.

If they down clock for 5 days they make 38 blocks a day losing say

 3+1 = 4 coins x 10 blocks  x 5 days comes to 200 coin loss. they save a lot of power with this down clock they also clog the mempool.

9 days in the second part of the 14 day diff adjustment

then over clock for 9 days making say 50 blocks a day for 9 days or 450 blocks.

these blocks have higher fees say  3+2 = 5 1 extra coin for 450 blocks is 450 coin extra.


so 450 - 200 = 250 coins extra every 2 weeks. and save power on the 5 days of down clocking.

No need for ordinals it can be done by the method above.

LN will get pushed hard next 3 months should be fun to watch it all

[mikeywith]

There are good arguments for every point people make about block size; let's break some of them down.

Argument 1: "Increasing block size would lead to centralizing Bitcoin in terms of nodes."

In theory, this holds. The larger the blockchain, the more expensive it is to store the data.

Counter-Argument: This is B.S. Storage drives are pretty cheap. If someone can afford $50 a year for a node, they could afford $60. Storage is only getting cheaper as we move forward.

Argument 2: "Increasing block size would lead to centralizing Bitcoin in terms of mining."

In theory, this holds true as well. The average miner would safely download or propagate a 4MB block but will have a difficult time handling a 40MB block. This means only large miners would survive, leading to centralization.

Counter-Argument: This is B.S. 99% of blocks are found by mining pools that spend thousands of dollars a month on operating nodes across the globe, running on a gigabit fast internet connection. They could handle a 40MB block just as easily as they handle the 4MB block.

Argument 3: "Increasing block size would reduce miners' rewards, leading to less security."

Again, holds true in theory. Miners want people lining up, outbidding each other so they can make the most profit. The more profit to be extracted, the more hash power we can have, and thus, the more secure the blockchain is.

Counter-Argument: This is B.S. Just because you build a small road for a highly populated city doesn't mean you increase toll revenue; you are just forcing poor people to stay off the road. The argument suggests that if blocks were 8MB, there would be 2x more transactions paying 50% the fee, which means cheaper transactions for everyone but the same profit for miners.

Argument 4: "1st rule of programming: If it works, don't touch it."

As a programmer, I confirm this. I look at some messy code I wrote years ago, and I find it so hard to risk the change. The code works, and I know for certain that if I touch it, no matter how careful I am, I could end up breaking things. Core devs did everything they could to increase the block without a hard fork; there may be left some 5-10% optimization, but past that, you are going to need a hard fork. A hard fork is like jumping off an airplane without a parachute, counting on your buddy who is jumping off another plane to come and catch you—you could end up recording the best video of your life, or you could fall on your head and make a 50m deep hole.

Counter-Argument: We had many forks before; this won't be the first one. Let's just do it. Let's save the poor folks who want to pay 1 sat/Vbyte to pay for their Starbucks that tastes like horse shit.


Every argument and counter-argument is valid depending on how you view them. Many people avoid getting into these discussions because many in the crypto community are narcissists and want BTC to be what they want it to be. If you speak for larger blocks, they accuse you of being CW's puppet; if you advocate for smaller blocks, you are now Core's pawn.

So now you need to be realistic with yourself and ask: Why would this change?

Miners are content with people competing to get into the block.
Exchanges are satisfied because there's more incentive to keep your BTC in their custody for cheap internal exchange and transfers, or to exchange your BTC for other coins when making smaller payments.
Most users don't seem bothered; we see people paying 8000 sat/Vbyte when potential fees are 300 sats/Vbyte.
People pay millions to mint some ugly JPEGs, and those who call themselves 'normal users' pay even higher fees than them to transact.
If you think BTC isn't working, then you need some fact-checking. It is working, it's in high demand, and the world doesn't give a damn about the 100 folks who want to set their fees at 1 sat/Vbyte to get into the next block. Sad fact? Indeed. Will it change anything? Hell no.

So, given the above and considering the risks involved in the transition, and the fact that people didn't give up on BTC despite high fees, it would be foolish for anyone to think that a block increase is going to happen anytime soon.

[pooya87]

Today and in the near future we don't need that though.

Another one might argue we neither need 519.6 EH/s and that we would be fine with *just* 10 EH/s.

That argument is not in the same category though. That doesn't even make sense.

Lets look at the hashrate chart, to add some evidence to my arguments before.

The following is the 30-day average hashrate over the past 3 years and the position where I placed the curser at is the time when we reached ATH of about $70k in 2021 and also it is the start of the bear market where price continues falling down to about $15k for about a year.
It is clear that the hashrate has been constantly rising despite the massive drop in price. Even before the reversal starts and we go back above $20k, hashrate has almost doubled!



You can not argue about miners revenue when the price has gotten dumped so much while hashrate has more than tripled in the same period!
If miners were so desperate for revenue, hashrate would have at best stayed the same and at worse dropped. But instead it massively rose.

[garlonicon]

Storage drives are pretty cheap. If someone can afford $50 a year for a node, they could afford $60. Storage is only getting cheaper as we move forward.

It is not about storage. It is about verification time. If you can download 1 GB/s, but you can verify 1 MB/s, then verification is your bottleneck, not storage. Who cares, that you can download the whole blockchain quite fast? Verification time is more important. If you can verify 1 MB/s, then it is fine, because when you verify 600 blocks, then in the same time, one new block is produced.

However, if you have 600 MB blocks, and your verification time is still 1 MB/s, then the time to verify new block is close to the time of making a new block. And then, you have a problem, because if your ratio of verification time to the new block time is too high, then you can reach the point, when you never verify new blocks, even if all of them will be downloaded on your disk.

And yes, I know we will not jump from 1 MB or 4 MB into 600 MB. But every increase means that verification time will be increased.

[mikeywith]

It is not about storage. It is about verification time. I

Hmm i disgree, notice that i mentioned handling and propagating blocks only for miners, because for a non-miner node there is no "rush" to download or verify a block, storage is more important.

But anyway, for a good hardware it takes  about180 seconds to do all of this

- Download  a 2MB block
- Empty some space if need
-Verify all transactions
-deal with the mempool and construct a brand new blocktemplate.

A non-mining node doesn't need much processing for a block, and should be able to process a block size of a few hundred MBs in no time, this is only a sub-issue for miners not all nodes.

[Medusah]

That argument is not in the same category though. That doesn't even make sense.

Not same category, but same spirit.  I act as the sole arbitrator to what miners are permitted to mine and earn.  "Mine as long as you do not exceed x hash rate" is similar to "censor these as long as the network is sustainable". 

You can not argue about miners revenue when the price has gotten dumped so much while hashrate has more than tripled in the same period!

I know that some miners' investment remains profitable, but there are tons of factors that influence the hash rate (let's please ignore them).  You cannot just tell the miners they cannot mine x-type transactions, because you believe they earn "enough" and because you believe these transactions do not belong here (unless the hash rate needs them).

And then, you have a problem, because if your ratio of verification time to the new block time is too high, then you can reach the point, when you never verify new blocks, even if all of them will be downloaded on your disk.

Interesting thought.  So, for instance, someone can attack BSV by simply filling the blocks with more than 600 MB data.  I think their block size is 1 GB, so it is not a very expensive attack. 

(I do not know if anyone still uses that, maybe it is already attacked several times)

[garlonicon]

So, for instance, someone can attack BSV by simply filling the blocks with more than 600 MB data.

It was only an example. If your verification time is instead 10 MB/s, then your upper limit is 6 GB per 10 minutes. So, it really depends on nodes, and their resources. But yes, if you have too big chain (and potentially unlimited), then if your blocks are extremely big, then you exclude weaker nodes, and centralization increases along with the time of checking a single block.

Also, for that reason, UTXO-based model is needed, because then it can be handled faster, than what we have today. But we are not there yet, so it should be implemented first, before any block size will be increased. And also, another loophole is Ordinals: as long as users cannot join their transactions, they cannot compete fairly with such protocols, so if you increase block size, without giving regular users any way of joining their payments, then regular payments will vanish, and Bitcoin will turn into P2P cloud storage.

[ABCbits]

Argument 2: "Increasing block size would lead to centralizing Bitcoin in terms of mining."

In theory, this holds true as well. The average miner would safely download or propagate a 4MB block but will have a difficult time handling a 40MB block. This means only large miners would survive, leading to centralization.

Counter-Argument: This is B.S. 99% of blocks are found by mining pools that spend thousands of dollars a month on operating nodes across the globe, running on a gigabit fast internet connection. They could handle a 40MB block just as easily as they handle the 4MB block.

In addition, block propagation become easier with existence of compact block where node doesn't broadcast whole block since most other node already have TX data on their mempool.

It is not about storage. It is about verification time. I

Hmm i disgree, notice that i mentioned handling and propagating blocks only for miners, because for a non-miner node there is no "rush" to download or verify a block, storage is more important.

But anyway, for a good hardware it takes  about180 seconds to do all of this

- Download  a 2MB block
- Empty some space if need
-Verify all transactions
-deal with the mempool and construct a brand new blocktemplate.

A non-mining node doesn't need much processing for a block, and should be able to process a block size of a few hundred MBs in no time, this is only a sub-issue for miners not all nodes.

But longer verification time means longer time to propagate block to most/all Bitcoin nodes. Pool and miner will waste more time/resource before their node receive newly mined block.

And then, you have a problem, because if your ratio of verification time to the new block time is too high, then you can reach the point, when you never verify new blocks, even if all of them will be downloaded on your disk.

Interesting thought.  So, for instance, someone can attack BSV by simply filling the blocks with more than 600 MB data.  I think their block size is 1 GB, so it is not a very expensive attack. 

(I do not know if anyone still uses that, maybe it is already attacked several times)

I believe in past there was project about inserting weather data to BSV blockchain. There was also 2GB block which mostly contain duplicate dog image.

[stompix]

Counter-Argument: This is B.S. Storage drives are pretty cheap. If someone can afford $50 a year for a node, they could afford $60. Storage is only getting cheaper as we move forward.
~
Counter-Argument: This is B.S. 99% of blocks are found by mining pools that spend thousands of dollars a month on operating nodes across the globe, running on a gigabit fast internet connection. They could handle a 40MB block just as easily as they handle the 4MB block.
~
Counter-Argument: This is B.S. Just because you build a small road for a highly populated city doesn't mean you increase toll revenue; you are just forcing poor people to stay off the road. The argument suggests that if blocks were 8MB, there would be 2x more transactions paying 50% the fee, which means cheaper transactions for everyone but the same profit for miners.

Savage!!!  
Let me add a thing to the first.

So bitcoin node owners were supposed to be bitcoin users too, and by this I mean at least one tx a week, but let's d it one tx a month!
If you're a a master on coin control and you magically can only use one output for all your expenses all year , at the current fees you're going to pay only $30 for a tx, that means $360 a month, which is the price of a 8TB drive.
Let's assume 16MB blocks,  2.3GB a day and you have enough space for 9 years!

As for node propagation and the poor guys living at the end of the remotest village in a fourth word country, how many of those did had internet in 2009?
I got a downlaod Mbps 247.29 upload Mbps 183.21 in a winter resort in the mountains right now to Darwin Australia on a hotel network and people still talk about 4MB propagations in 10 minutes?

How the FUCK (YEAH CAPS) is Doge being able to do this fucking shit in 1 minute?

Sad fact? Indeed. Will it change anything? Hell no.

Yeah, we should start get used to this.

Another point that was not mentioned, but increasing the size of blocks leads to the centralization of the network. If the block sizes are larger than 16 megabytes, then those who can manage full nodes will be limited, and thus the entire network is distributed and not decentralized.

Sorry but this is just ridiculous.
Decentralization will be compromised because hobby node owners can't afford a 2tb dive but at the same time you expect decentralization to happen with our average mining gear being over 3 median wages in like 80% of the countries and with a power draw that would blow most fuses the moment your turn in on in your average Joe apartment?

[garlonicon]

Just because you build a small road for a highly populated city doesn't mean you increase toll revenue; you are just forcing poor people to stay off the road. The argument suggests that if blocks were 8MB, there would be 2x more transactions paying 50% the fee, which means cheaper transactions for everyone but the same profit for miners.

1. If you have no sidechains, then blocks can be only big or small. If you have sidechains, then both networks can co-exist, without increasing 21 million coins limit.
2. Transaction batching is needed. If you have 4 MB witness, it doesn't mean you can process only 4 MB per 10 minutes. You can process much more, but you have to reduce transaction size, and some Input->Output transaction should not belong to a single user, but instead handle thousands of users. Then, the price per user will be cheaper, and the total transaction fee can stay high, because it doesn't matter if you have Alice->Bob transaction paying 0.01 BTC in fees, or if you have thousands of users, behind some transaction of the same size, where everyone pays 1000 satoshis.

We had many forks before; this won't be the first one. Let's just do it. Let's save the poor folks who want to pay 1 sat/Vbyte to pay for their Starbucks that tastes like horse shit.

Good luck. Sidechains were rejected in the current form, so I doubt block size increase will be accepted. But you can try, even some BIPs are ready, just the code has to be adjusted. The next timeline for a hard-fork, which will be hard to avoid, is 2038 year problem (because then, some existing nodes will crash). And after that, probably something like 2106.

Also, good luck at convincing people, that we need more than 4 MB witness. Because even if blocks are full, then still, witness is not. And if some changes like OP_CAT will be activated, then it can open a way to trustlessly handle some additional traffic, without block size increase (because then, OP_CHECKSIG will be able to check every message, not necessarily the current transaction).

[philipma1957]

Block space needs to be limited to ensure bitcoin's long term survival.

Given that the block subsidy is halving every 4 years, it will not be long before the subsidy alone is negligible and certainly not enough to support even a fraction of the current hashrate. At that point, fees have to be sufficient to take over. For fees to be sufficient, block space has to be limited and there needs to be a full mempool and a competitive fee market. If we increase block size so everything can confirm at 1 sat/vbyte, then even for a (let's say) 16 MvB block you are still only talking about fees of 0.16 BTC.

If you want everything to confirm in the next block at tiny fees, then you need some other mechanism to pay miners once the subsidy is insufficient. That means either lifting the cap of 21 million and having constant inflation, or some other mining incentive like merged mining.

Merged mining already exists> I point 6ph of btc miners at viabtc and earn 3 other coins at the same time. the other coins are essentially worthless.

BTC goes against LTC/DOGE

1 block vs 12 blocks

vanishing rewards vs a hybrid of vanishing rewards+ stable rewards.


if you look at the two setups.

btc is far less suited to move small coin values.

One reason is it was the first coin and people have pushed using it for value storage.

It is a shit fit to move little coin value. Great for large coin value.

Tweaking to make it work for small value mya prove to be its undoing.

Or LN could get fully adapted  along with 10 digits not 8 .  Time will tell.

[pooya87]

Not same category, but same spirit.  I act as the sole arbitrator to what miners are permitted to mine and earn.  "Mine as long as you do not exceed x hash rate" is similar to "censor these as long as the network is sustainable". 

They're not in the same spirit either. Hashrate going from 500 to 10 makes bitcoin 100% vulnerable. However, fixing an exploit in the protocol is not going to damage anything, in fact it would get bitcoin's "healthiness" back!

You cannot just tell the miners they cannot mine x-type transactions, because you believe they earn "enough" and because you believe these transactions do not belong here (unless the hash rate needs them).

Maybe you need to check out the policy rules that we've been enforcing for the past decade to see that it is not "me" that is telling miners what to mine and what not to. The whole community has been preventing a large number of exploitable ways malicious people could use to spam Bitcoin, that is of course until this new exploit was found in the protocol which is being abused heavily these days.

BTW I brought up the miners' revenue in response to the claim that miners need that additional revenue from the spam.

[d5000]

In a perfect world, yes, but from what we've seen in recent months this would only lead to larger Ordinals Inscriptions rather than an increased transaction throughput. Maybe someone can correct me if I'm wrong, but if I'm not mistaken the current congestion is largely due to Ordinals, rather than regular transactions.

You're largely correct, while Ordinals transactions are not occupying as much space as some months ago, there was an increase since last weekend, where again some 300.000 transactions per day were BRC-20. In addition, there probably was an increase of "normal payment transactions" too due to seasonal reasons.

There could however be a way to circunvent the problem of space filling by Ordinals and other data-spam transactions: create a special discount for simple payment transactions which only consist of inputs and outputs with the simplest possible P2WPKH script.

Currently we have a two-tier discount scheme due to Segwit:

Tier 1: Segwit witness data (weight in vBytes = weight in bytes)
Tier 2: All other transaction data  (weight in vBytes = 4 * weight in bytes)

We could advance to a three-tier scheme:

Tier 0: Simple payment transactions (weight in vBytes = 0,5 * weight in bytes), i.e. they would have a weight of half of the Segwit witness data*
Tier 1: Other Segwit witness data (weight in vBytes = weight in bytes)
Tier 2: All other transaction data (weight in vBytes = 4 * weight in bytes)

This would have the effect that we would increase the maximum block size to a maximum of 8 MB, but only if it was filled exclusively by Tier 0 data.

Of course that would not be an easy change. In the case of Witness data, there's actually a reason why it got the discount: because in the long run it is cheaper to store, process and transmit this kind of data as Segwit Witnesses are a separate section in transactions and don't clutter the UTXO set. In contrast, the "Simple Payment Transaction discount" would be completely arbitrary, it isn't cheaper to process. It would be a convention to favour this kind of transaction and to make payments cheaper than other contracts.

If there's any problem with that approach please criticise it, after all I'm not really an IT expert.  (A point I've noticed myself is that if implemented that way is that Lightning transaction and sidechain peg-ins/outs for example would not benefit from this discount. They could be included but that would make the measure very complex.)

(An alternative could be to add the Segwit discount to all parts of the transaction if it only contains transaction data payments (edited: previous sentence made no sense ). This would not increase the block size but would fill the 4 MB more often.)

[mikeywith]

Tier 0: Simple payment transactions (weight in vBytes = 0,5 * weight in bytes), i.e. they would have a weight of half of the Segwit witness data*
Tier 1: Other Segwit witness data (weight in vBytes = weight in bytes)
Tier 2: All other transaction data (weight in vBytes = 4 * weight in bytes)

This would be viewed as censorship by many people, you do know that Ordinals are also Segwit transactions, the Segwit upgrade was widely accepted because it gave everyone the same chance, to change your address -- you get the discount, but with this approach, you are not separating Segwit transactions into two groups, one that gets a discount (because some people want that) and others who don't (again, because some people don't them to).

This would be the equivalent of those Ordinals folks asking for a discount for their Segwit transactions only, many people won't welcome that idea, will they?

This also opens the door to other types of transaction-biased discounts, transactions of >x amount should get y discount and the others won't, it's like creating a VIP membership on the blockchain.

Your idea would make perfect sense if what you guys call "not normal" or "spam" was universally agreed upon, which isn't, it seems like there are no more than a few folks here and on Reddit that are mad about these Ordinals, I mean, with all honesty who gets to say "Yes let's change the protocol"?

- Mining pools
- Nodes devs (mainly Core)
- Exchanges
- Wallets

Out of these 4 groups, probably only some Core devs are annoyed, mining pools are certainly happy and don't consider Ordinals spam (ya except for Luke's pool which is a drop in the Ocean 'no pun intended' ), Exchanges are having the best time of their life with all the volume surrounding those shit Ordinals coins, Wallets would be like "What spam" ? lol.

 

In addition, block propagation become easier with existence of compact block where node doesn't broadcast whole block since most other node already have TX data on their mempool.

compact blocks are a part of the relay networks that mining pools use, even with blocks being as small as 4MB large pools don't count on the P2P network to propagate blocks, given the amount of money at stake, they consider the P2P network to be risky, and they operate outside of it to ensure none of them loses half a million $ due to some latency issues every other day.

Mining has changed a lot, it's no more thousands of nerds on their PCs where nobody knows who sent the block, it's now a group of multi-billion $ companies who think of BTC mining as nothing but business, Foundry sends the block hash to Antpool using their private relay protocol, Antpool won't even bother checking shit, just start constructing an empty block while dealing with their mempool, so added verification time isn't going to hurt those pools, and let's be honest, only mining nodes matter here, the other nodes would just set tight till the big boys handle their business and they would always follow the longest blockchain.

So even at a 1GB blocks, it's unlikely that miners would be affected by any means (ya maybe more empty blocks here and there and that's all about it), it's us the average joe who would need to refresh their wallets twice while waiting for transaction confirmation which has already been included 2 minutes ago.

Obviously, small miners/pools who can't get a seat in those private relay networks will have to rely solely on the P2P network, and every % of network delay added is a potential loss for them, in other words, those 2 mins they spend working on a block that has already been solved and passed to other miners, will be a loss for him, a heavy 20% loss in this example, but ya 2 mins is just an extreme example.

But with all honesty, small miners are more likely to vanish due to the difficulty affect caused by large miners growing too large than to face issues with network delays.

Savage!!!  

Fudge!

I'd like to make it clear that those aren't particularly my arguments nor counterarguments. I mean, they have been floating around forever. Just thought I'd sum them up for those interested. And, as I said, every argument and its counter do make sense. I could just argue that I want 0.1MB blocks because I live somewhere way too far and only have access to a 500kbps connection. I want to mine BTC with the same chances that a European person like yourself has. So, raising blocks to 20MB is racial discrimination, which is terrible for Bitcoin. What say you? You may say it's b.s."it is " but many others would find it a perfectly valid argument.

[HeRetiK]

There could however be a way to circunvent the problem of space filling by Ordinals and other data-spam transactions: create a special discount for simple payment transactions which only consist of inputs and outputs with the simplest possible P2WPKH script.

Currently we have a two-tier discount scheme due to Segwit:

Tier 1: Segwit witness data (weight in vBytes = weight in bytes)
Tier 2: All other transaction data  (weight in vBytes = 4 * weight in bytes)

We could advance to a three-tier scheme:

Tier 0: Simple payment transactions (weight in vBytes = 0,5 * weight in bytes), i.e. they would have a weight of half of the Segwit witness data*
Tier 1: Other Segwit witness data (weight in vBytes = weight in bytes)
Tier 2: All other transaction data (weight in vBytes = 4 * weight in bytes)

The main problem I see with this approach is that effectively penalizing smart contracts and similar transactions (such as LN and sidechain related transactions, as you already pointed out), is throwing the baby out with the bath water.

Also the fact that Ordinals inscribers (inscriptors?) appear to be largely fee insensitive would probably make any form of monetary penalty largely ineffective.

[d5000]

This would be viewed as censorship by many people, you do know that Ordinals are also Segwit transactions, the Segwit upgrade was widely accepted because it gave everyone the same chance, to change your address -- you get the discount, but with this approach, you are not separating Segwit transactions into two groups, one that gets a discount (because some people want that) and others who don't (again, because some people don't them to).

Censorship? I don't think so. But it would be of course arbitrary. It would be a bold statement screaming "We want Bitcoin to be a payment coin, not a contract coin nor data cloud storage platform!".

However: Those who use other scripts than those benefitting from the additional discount would not be punished at all. They would even be benefitted partly too, because if "payment-style" transactions have less weight, the weight which is then "liberated" can also be used for things like Ordinals and it's likely that initially they'll pay less fees too. But payment transactions would benefit proportionally much more from such an hypothetical change.

Also, it's not the first time such a "discrimination of a particular user group" happened. When OP_RETURN was introduced it was limited to 80 bytes and to one output per transaction - because the devs thought that larger data storage should be disincentived.

I want to point out however that this "proposal" is only an example for a possible path which could be explored, it's not that myself I would favour such a rule over other possibilities (my own opinion is actually that it's better to concentrate on solutions like sidechains and LN, and in the long term: use a zero-knowledge-based approach to verify the blockchain, which would liberate nodes from the need to store all data). It's to show the theoretical possibility to increase the block size without making data storage-type spam easier. Personally I think it's too difficult to really determine which are "desired" or "undesired" kinds of usage. However: If such a change would be necessary, it could be probably applied via soft fork - I see no technical problem.

This also opens the door to other types of transaction-biased discounts, transactions of >x amount should get y discount and the others won't, it's like creating a VIP membership on the blockchain.

Well first these protocol changes would have to be approved by miners. Miners would probably not necessarily against such a policy: while the average fees would level down a bit, there are more transactions they could fit in a block, so the total fees collected per block could increase. A "VIP club" like the one you describe, in contrast, would not make sense for miners. They don't care about the amounts transacted, they care about the fees.

I get what you probably mean though, it could lead to endless senseless discussions about "desired" and "undesired" use cases. So the best thing would actually if such a discount could be applied to transactions which effectively have a resource-saving function (like Segwit had.)

The main problem I see with this approach is that effectively penalizing smart contracts and similar transactions (such as LN and sidechain related transactions, as you already pointed out), is throwing the baby out with the bath water.

Of course one could include transactions with OP_CSV and multisig, which are required for Lightning, to the list of discounted transaction types. But see my response above to mikeywith: I don't think this approach is ideal.

Also the fact that Ordinals inscribers (inscriptors?) appear to be largely fee insensitive would probably make any form of monetary penalty largely ineffective.

That wasn't the case initially. It was even argued in this thread (and/or other discussions?) that despite of the high transaction count, the fee level stood relatively low (often below 20 sat/vByte) for a long time. IMO it's the bubbles some of the tokens have seen that led to the big fee increase and thus to the sensation that Ordinals users are fee insensitive.

[shield132]

It was a fork but it is an altcoin (shit coin) while bitcoin remain the bitcoin.

Keep in mind that bcash is not a shitcoin because it was a hard fork, neither was it because of Roger Ver, Jihan Wu, etc. Instead Bcash is a shitcoin because it created and change and enforced it without reaching majority support. In Bitcoin when we want to change something (soft or hard fork) we first have to reach a threshold of supporters (almost always +90%) before we can move ahead with that change/fork. If we do anything else (like forking with 10% support) we would be creating an altcoin which would be viewed as a shitcoin.

It was because of Roger Ver and Jihan Wu. They ignored the lack of support for block size increase and still did the fork but that was not the only thing that made Bitcoin Cash trash. They started saying that Bitcoin Cash was the original Bitcoin and not Bitcoin Core. They spread many lies and prioritized Bitcoin Cash on bitcoin.com and r/btc. That's why people started to hate Bitcoin Cash too.

I read the discussion and I agree with your points, but having small sized blocks is neither in favor of bitcoin's long term survival.  

That's right, small block size will kill Bitcoin. No business wants to pay premium to send and receive bitcoin transactions, no individual wants to pay premium to make a bitcoin transaction.

There are good arguments for every point people make about block size; let's break some of them down.

Argument 1: "Increasing block size would lead to centralizing Bitcoin in terms of nodes."

In theory, this holds. The larger the blockchain, the more expensive it is to store the data.

Counter-Argument: This is B.S. Storage drives are pretty cheap. If someone can afford $50 a year for a node, they could afford $60. Storage is only getting cheaper as we move forward.

Large blockchain is not expensive today. Guys, if equipment price was the problem, then gaming wouldn't improve and would stay on the level where GT series of Nvidia GPUs would be enough to play today. We wouldn't also see the same iPhone sold more expensively every year. I bought a PC for $500 in 2014. I bought a new PC for $500 recently. There is a huge difference between capabilities and space that my new PC has compared to old one. By giving this example, I want to say that everyone upgrades there PC at least once in a decade and hardware is not an issue today to blame it for low block size.

[mikeywith]

However: Those who use other scripts than those benefitting from the additional discount would not be punished at all.

It really depends on how you look at it, you may call it a 50% discount or you may call it a 100% tax, being on the "normal transaction" side, it would seem as though you are getting a 50% discount compared to the rest, being on the other side, it would seem that you are paying a 100% tax compared to the rest, if we think of block space as goods sold at the market, at the end of the day, a "normal" person can buy twice as much of those goods with the same money compared to those "weird" people.

However, I agree, censorship is probably not the best word to use here, I suppose it's more of a discrimination.

Miners would probably not necessarily against such a policy: while the average fees would level down a bit, there are more transactions they could fit in a block, so the total fees collected per block could increase. A

This is a "Chicken-and-egg" debate, and has not been solved, and probably never will, simply because there are two side of the same story, the first one is what you described, in other words, more space = more transactions = same or more profit for miners.

The other side suggests a different thing, because you are creating more supply of something, it's most likely the price will go down, and that makes sense because you can't guarantee "demand", you would only speculate the demand will go up, which isn't something you can be sure of, and if demand doesn't increase as much as the demand does, then the overall price of block space will go down enough to bring the overall profit down.

people who support this theory have a very good point, and that is, whoever needs to transact on the blockchain would do so no matter what the fees are, and those who don't want to transact on the blockchain -- they won't even if you bring fees down to near zero.

The above "theory" suggest that the transaction count is limited, so you could just assume that there would be 100 transactions a day no matter what, if there is enough space for all 100 to be included on the same day, you are simply removing the competition/bidding insetnive, whereby if there is only a place for 10 transactions, those 100 transactions would have to outbid one another, raising the profit of the miners.

Keep in mind that in order for profit to be the same for miners in the above example, if you increase the daily block size from 10 to 20, and want to keep the same profit, you would have to increase transaction count by 100%.

So

10 space  > 100 transactions  > profit = 1
20 space  >          ??              > profit = 1
=
20 space  > 200 transactions  > profit = 1

anything short of 200 will make profit < 1.

And it's not guaranteed (actually probably less likely) for transaction count to do 2x just because fees are down 50%, so this side of the "Chicken-and-egg" theory is more favorable to most miners because they can't control demand, they rather control the supply.