Why was the block size not increased?

[d5000]

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.

Yes, but compared to the current policy, it's not correct to call it a "tax" or "discrimination", because nothing would have been changed and these transactions are even favoured because blocks would be, on the whole, emptier. And if the blocks are not full, like it was the case many times even in 2022/early 2023 before Ordinals came up, then there is no tax at all.

With the other part of your post, you are correct - it's possible that fee income goes down if demand is not high enough. To avoid this, in the block size debate models for a flexible block size were proposed, where the maximum weight is adjusted by demand or there are incentives to miners to adjust the blocksize carefully if needed. Monero (which was already mentioned in this thread) is an example how such a policy could look like. In contrast to Monero, however, Bitcoin needs slightly stricter parameters, because of Monero's tail supply which ensures they get rewards infinitely, so the necessity of a fee market isn't that pronounced on XMR.

So you could combine the "payment transaction discount" with a "flexible blocksize" policy. In this case, if the minimum max size is set too low, then the contract/Ordinals transactions could pay a "tax" indeed even compared to today. I think it would make sense, if such a change was decided, to ensure the minimum max block size is never lower than the current 4 vMB.

Anyway, such a policy is, again, meant as a possibility if there is general consensus in the community of the need for a block size increase, and that would be decided only if demand justifies it. Simply: instead of moving max block size "straight" to 8 MB, one could change the weight formula in a way simple payment transactions take less weight and pay half the fees.

Even if the current fee situation is a bit annoying, in my opinion we have not reached the point, and my hope is we'll never need it due to sidechains/LN improvements.

[1714239279]

1714239279

[1714239279]

1714239279

[1714239279]

1714239279

[philipma1957]

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.

Yes, but compared to the current policy, it's not correct to call it a "tax" or "discrimination", because nothing would have been changed and these transactions are even favoured because blocks would be, on the whole, emptier. And if the blocks are not full, like it was the case many times even in 2022/early 2023 before Ordinals came up, then there is no tax at all.

With the other part of your post, you are correct - it's possible that fee income goes down if demand is not high enough. To avoid this, in the block size debate models for a flexible block size were proposed, where the maximum weight is adjusted by demand or there are incentives to miners to adjust the blocksize carefully if needed. Monero (which was already mentioned in this thread) is an example how such a policy could look like. In contrast to Monero, however, Bitcoin needs slightly stricter parameters, because of Monero's tail supply which ensures they get rewards infinitely, so the necessity of a fee market isn't that pronounced on XMR.

So you could combine the "payment transaction discount" with a "flexible blocksize" policy. In this case, if the minimum max size is set too low, then the contract/Ordinals transactions could pay a "tax" indeed even compared to today. I think it would make sense, if such a change was decided, to ensure the minimum max block size is never lower than the current 4 vMB.

Anyway, such a policy is, again, meant as a possibility if there is general consensus in the commuity of the need for a block size increase, and that would be decided only if demand justifies it. Simply: instead of moving max block size "straight" to 8 MB, one could change the weight formula in a way simple payment transactions pay half the fees.

Even if the current fee situation is a bit annoying, in my opinion we have not reached the point, and my hope is we'll never need it due to sidechains/LN improvements.

Yeah LN is viable for smaller sends.  You do not even need to maintain a node to do it.

Let's say you have 1 btc .  Keep the whole 1.0 btc in a safe storage place and open an account with an LN exchange.  Kraken does LN put 0 btc in just do KYC and put in 200 or 300 cash. Maybe 500 cash.  Buy some BTC with the cash.  You can then use kraken's LN wallet at no cost other than the 0.00000014 fee to do the send.

SO far I tested Nicehash and kraken both are kyc and I have about $500 worth of btc in them.  They work pretty good for LN .

Yeah I have $500 or $600 worth of btc not in my full control.  I can live with this.

[suzanne5223]

Satoshi and others once discussed the increase in block size limit here but I believe the reason why the increase in the block size of Bitcoin was not welcome is because of the security the limited block size provided for the BTC network and it is better to accept disadvantage that comes with a limited block than accept the disadvantages that come with an increase of the BTC block.

[mikeywith]

flexible block size were proposed, where the maximum weight is adjusted by demand or there are incentives to miners to adjust the blocksize carefully if needed.

This would be better than treating transactions differently, in my opinion. However, it has to be implemented similarly to how XMR does it. Raising the block size would result in a reduction in the block subsidy; otherwise, whatever the max cap is will always be activated by greedy miners. This would lead to larger pools absorbing all available well-paying transactions, leaving smaller transactions with almost nothing.

If we have three pools—A (45%), B (45%), and C (10%)—block C, with the current protocol, is almost always guaranteed to mine 10% of the transactions. So, if there are 100 transactions paying 0.1BTC each, and each block can only take 10 of them, it would, on average, make 1 BTC out of that. However, if pools A and B can increase the limit from 10 to 15, pool C (which only finds 1 in 10 blocks) will be left with nothing but dust. The current way relies solely on luck; a small miner may hit a 5 BTC fee block, whereas large miners who find twice as many blocks may not get 5 BTC combined.

In other words, as of now, potential rewards from fees are based more on "luck and market conditions" than your hashrate. The other model will shift that, making it more about your hashrate and leaving little room for luck.

However, looking at Suzanne5223's comment above this one, if you read what user Kiba wrote right below Satoshi's post, he said:

"If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow."

Reading this 13 years later, it certainly makes a whole lot of sense; it's pretty difficult to do now.

@philipma1957

I agree that leaving a small amount of BTC for emergency cases like this in somebody else's custody may not be a bad idea. My only issue is with the KYC part; I know many people are okay with KYC-ing themselves, but I try to avoid that as much as I possibly can.

[philipma1957]

flexible block size were proposed, where the maximum weight is adjusted by demand or there are incentives to miners to adjust the blocksize carefully if needed.

This would be better than treating transactions differently, in my opinion. However, it has to be implemented similarly to how XMR does it. Raising the block size would result in a reduction in the block subsidy; otherwise, whatever the max cap is will always be activated by greedy miners. This would lead to larger pools absorbing all available well-paying transactions, leaving smaller transactions with almost nothing.

If we have three pools—A (45%), B (45%), and C (10%)—block C, with the current protocol, is almost always guaranteed to mine 10% of the transactions. So, if there are 100 transactions paying 0.1BTC each, and each block can only take 10 of them, it would, on average, make 1 BTC out of that. However, if pools A and B can increase the limit from 10 to 15, pool C (which only finds 1 in 10 blocks) will be left with nothing but dust. The current way relies solely on luck; a small miner may hit a 5 BTC fee block, whereas large miners who find twice as many blocks may not get 5 BTC combined.

In other words, as of now, potential rewards from fees are based more on "luck and market conditions" than your hashrate. The other model will shift that, making it more about your hashrate and leaving little room for luck.

However, looking at Suzanne5223's comment above this one, if you read what user Kiba wrote right below Satoshi's post, he said:

"If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow."

Reading this 13 years later, it certainly makes a whole lot of sense; it's pretty difficult to do now.

@philipma1957

I agree that leaving a small amount of BTC for emergency cases like this in somebody else's custody may not be a bad idea. My only issue is with the KYC part; I know many people are okay with KYC-ing themselves, but I try to avoid that as much as I possibly can.

If you live in the USA they fucking own you

yeah real free.

free to pay

fed income tax ----------- fuck with this possible jail time and likely lose my pension while in jail
state income tax --------- "      "       "      "         "     "
trump import tax --------- "      "      "       "        "     " not sure what penalties for this one.
local town property tax. --- take my home if I don't pay
county property tax. ------  take my home       "
state property tax. --------  take my home       "

I am so KYC'd it is a Joke.

[ABCbits]

flexible block size were proposed, where the maximum weight is adjusted by demand or there are incentives to miners to adjust the blocksize carefully if needed.

This would be better than treating transactions differently, in my opinion. However, it has to be implemented similarly to how XMR does it. Raising the block size would result in a reduction in the block subsidy; otherwise, whatever the max cap is will always be activated by greedy miners. This would lead to larger pools absorbing all available well-paying transactions, leaving smaller transactions with almost nothing.

--snip--

How about BIP 104, 106 and 107? Although personally i'd rather avoid dynamic block size altogether since there's concern it could be manipulated by miner who decide which and how much transaction included on their mined block.

[garlonicon]

Although personally i'd rather avoid dynamic block size altogether since there's concern it could be manipulated by miner who decide which and how much transaction included on their mined block.

Not only that. There is an attack, that could lead to fast verification for the attackers, and extremely slow verification for everyone else.

1. You pick some random, and secure seed.
2. You generate a lot of addresses (deterministically, from your HD wallet).
3. You generate deterministic transactions (yes, it is possible).
4. You include a lot of self-transfer, only to increase block size, according to consensus rules.

And then, you know, that all of your self-transfers are valid. More than that: you can recreate them on the fly, just by knowing the master public key. Which means, you, and your network, can easily validate a lot of your own self-transfers, and mark them automatically as valid. While the rest of the network has to check that, or risk mining an invalid block.

Then, your strategy is simple: always fill the whole block with your dummy transactions, no matter what.

1. It doesn't affect miners, but only competing mining pools (and their block verification time) or other full nodes.
2. It doesn't affect your network, because by knowing master public key, your nodes can skip those transactions as valid.
3. It forces high fees all the time, because even if blocks will be full, then your self-transfer will always fill the remaining space, and make some fee market.
4. It centralizes the network, because if blocks are bigger and bigger, then only your nodes can know upfront, which transactions are fake, and can be skipped as valid. Everyone else waste time on your dummy transaction verification.

[ABCbits]

Although personally i'd rather avoid dynamic block size altogether since there's concern it could be manipulated by miner who decide which and how much transaction included on their mined block.

Not only that. There is an attack, that could lead to fast verification for the attackers, and extremely slow verification for everyone else.

--snip--

It's also worth to mention miner/pool might offer premium service where they include non-standard transaction. For example, Luxor include almost 4MB NFT on their block[1] where it's available on their professional service category[2].

--snip--

Then, your strategy is simple: always fill the whole block with your dummy transactions, no matter what.

1. It doesn't affect miners, but only competing mining pools (and their block verification time) or other full nodes.
2. It doesn't affect your network, because by knowing master public key, your nodes can skip those transactions as valid.
3. It forces high fees all the time, because even if blocks will be full, then your self-transfer will always fill the remaining space, and make some fee market.
4. It centralizes the network, because if blocks are bigger and bigger, then only your nodes can know upfront, which transactions are fake, and can be skipped as valid. Everyone else waste time on your dummy transaction verification.

But there's downside where overall block propagation is slower since compact block can't be used due to most node doesn't have your transaction on it's mempool.

[1] https://www.coindesk.com/tech/2023/02/02/giant-bitcoin-taproot-wizard-nft-minted-in-collaboration-with-luxor-mining-pool/
[2] https://docs.luxor.tech/ordinalhub/faq

[ecdsa123]

This advanced attack method described by garlonicon has serious and far-reaching consequences for the cryptocurrency ecosystem.

Let's analyze it in more detail:

Step 1: At the beginning, the attacker selects a random and secure seed – the foundation upon which all subsequent actions will be based. Easy Step!

Step 2: The attacker then generates multiple addresses deterministically using an HD wallet (hierarchical deterministic). This crucial step allows all generated addresses to be associated with the specific seed. - Important STEP!

Step 3: Next, the attacker creates transactions deterministically, which is feasible to achieve. The essence of these transactions is to generate self-transfers, meaning transferring funds from one address to another owned by the attacker. However, in practice, the purpose of the attack is not to transfer funds but to increase the size of transaction blocks according to consensus rules. - Problem for network!

The key aspect of this attack method is the understanding that all self-transfers are considered valid by the attacker. Moreover, the attacker can seamlessly reproduce and replicate these transactions by using the main public key. This means that the attacker and their network can quickly verify many self-transfers and automatically consider them valid. In the meantime, the rest of the network must individually verify each self-transfer to avoid mining an invalid block.

The attacker's strategy is simple: always fill entire blocks with their own transactions, regardless of other factors such as transaction fees or genuine network needs.

The implications of this attack are:

1. Primarily, this attack affects mining pools and other full nodes. It is important to understand that the bigger the block with a large number of self-transfers, the more time and resources are required for other nodes to verify such a block. This gives the attacker a time advantage in the block verification process, leading to a slowdown and decreased efficiency for competing mining pools.

2. It is worth noting that network self-defense is almost impossible in this case. The attacker possesses exclusive knowledge of which transactions are fraudulent, allowing their nodes to skip these transactions and consider them valid using the main public key. Meanwhile, the rest of the network, lacking this knowledge, must allocate time and resources to verify each transaction, including the fraudulent ones, reducing block verification efficiency.

3. This attack also leads to high transaction fees. Even if blocks are filled with legitimate transactions, the attacker's self-transfers will always occupy the remaining space, creating a market for transaction fees. In other words, if you want your transactions to be processed quickly, you will have to pay a high fee. This phenomenon can promote network centralization, favoring the attacker.

4. Finally, this attack contributes to network centralization because only the attacker and their nodes can identify fraudulent transactions in advance and skip them as valid. All other nodes must spend time and resources to verify transactions, including the fraudulent ones, which undermines the balance among network participants.

In summary, this advanced attack method allows the attacker to prioritize their own transactions, providing a significant advantage in transaction verification speed and legitimacy compared to other network participants. At the same time, it has negative implications for network decentralization and the fairness of participants, as the attacker controls the verification process and manipulates the fee market. Effective defensive mechanisms are necessary to prevent such attacks on cryptocurrency networks.

[BlackHatCoiner]

3. It forces high fees all the time, because even if blocks will be full, then your self-transfer will always fill the remaining space, and make some fee market.

Doesn't that mean that the attacker has to frequently pay high fees to sustain this attack? Moreover, why does "wasting time on dummy transactions" centralizes the network, and why do we call it "wasted time" since they are regular transactions, just like any other honest nodes would either way verify.

1. Primarily, this attack affects mining pools and other full nodes. It is important to understand that the bigger the block with a large number of self-transfers, the more time and resources are required for other nodes to verify such a block. This gives the attacker a time advantage in the block verification process, leading to a slowdown and decreased efficiency for competing mining pools.

That is probably answering my second question. May I suppose that this particular attack influences the network by orders of magnitude more when the block size limit is dynamical?

(Also, am I talking to a chat bot?)

[ecdsa123]

3. It forces high fees all the time, because even if blocks will be full, then your self-transfer will always fill the remaining space, and make some fee market.

Doesn't that mean that the attacker has to frequently pay high fees to sustain this attack? Moreover, why does "wasting time on dummy transactions" centralizes the network, and why do we call it "wasted time" since they are regular transactions, just like any other honest nodes would either way verify.

1. Primarily, this attack affects mining pools and other full nodes. It is important to understand that the bigger the block with a large number of self-transfers, the more time and resources are required for other nodes to verify such a block. This gives the attacker a time advantage in the block verification process, leading to a slowdown and decreased efficiency for competing mining pools.

That is probably answering my second question. May I suppose that this particular attack influences the network by orders of magnitude more when the block size limit is dynamical?

(Also, am I talking to a chat bot?)

No @BlackHatCoiner , i'm using translator  from my born language:). - I Hope it is not Illegal on this forum?

According your question : in 90% yes, but it is not necesary that it must be dynamical.

[so98nn]

Block size is in a sense still increased, well that depends on your definition. Blocks are definitely bigger than 1MB right now.

The most important period to look at would be the block size debate a few years back. One camp thinks that a hard and fast block size increase is the solution.Then again, how much should we really increase the block size? Can it ever be sustainable? The point about a unsustainable block size increase would be that we would reach a limit where only large entities can run Bitcoin nodes, delay across transaction propagation, etc. Big blocks takes longer to propagate, and stale rates would increase. I argue that this point is largely invalid, if you consider propagation speeds of the modern network as well as the inter connectivity of miners.

The other thinks that having second layer scaling as a solution would be the way going forward. Having lightning network was the key thing that made people think that the adoption would skyrocket once adopted and thereby reducing congestion on layer one. Well, it hasn't been extremely effective though adoption is definitely going up.

There are tons of supporters of both sides and they all have their concerns and their vision to what Bitcoin really is. If you want the actual answer, then it boils down a lot more to politics rather than what we can or cannot do.

There should have been a 4-year upgrade in terms of block size incrimination in a similar fashion to how network difficulty rises with time. What I mean is, that Satoshi was able to identify the supply and demand issue earlier through its halving event. However, they did not consider the scaling of block sizes or maybe they never thought that Bitcoin would go to such a high level anytime soon.

So I am not sure if this is technically valid or not, but there should have been an algorithm that automatically increases the size of the block every 4 years or whatever period is feasible to make it happen. Let's say that would be a block-size event in a similar way we have a Halving event. As a result over time, we don't need to fork Bitcoin and create more shit coins as a result.

I know I may not be close to the solution because there could be whole new realm of coding behind this, but at some point we definitely need to think about the solution whether its hardest or simplest, that wont matter.

[ranochigo]

There should have been a 4-year upgrade in terms of block size incrimination in a similar fashion to how network difficulty rises with time. What I mean is, that Satoshi was able to identify the supply and demand issue earlier through its halving event. However, they did not consider the scaling of block sizes or maybe they never thought that Bitcoin would go to such a high level anytime soon.

Difficulty doesn't rise with time, there is a negative correlation. It was identified and also a pressing issue, but we never reached a conclusion on the following:

So I am not sure if this is technically valid or not, but there should have been an algorithm that automatically increases the size of the block every 4 years or whatever period is feasible to make it happen. Let's say that would be a block-size event in a similar way we have a Halving event. As a result over time, we don't need to fork Bitcoin and create more shit coins as a result.

We couldn't reach a consensus on when we should increase block size, how we should increase the block size and by how much should we increase the block size. Of course, we could have a simple algorithm but the scenario where the demand can't reach the expected level would make it disastrous for the eco-system and it would be difficult to reverse. Furthermore, Moore's law is likely not going to hold forever and storage density would stagnant somewhere for a while in the near future.

I know I may not be close to the solution because there could be whole new realm of coding behind this, but at some point we definitely need to think about the solution whether its hardest or simplest, that wont matter.

We have, there are quite a few viable solutions but the overall impact to Bitcoin and the economy differs with each solution. The difficulty is not with coming up with the solution but rather which solution makes the most sense and coming to a consensus with it.

[Dump3er]

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.

As simple as that sentence sounds, you have phrased this straight to the point and I haven't been thinking about it that way yet. But of course, this is quite simple economics and yet you nailed it in a very sophisticated way saying that we essentially need "sustained congestion".

Now a lot of people may shrug for a moment as temporary congestion is already giving most of us headaches, but with decreasing block subsidy, sustained congestion is what we want to keep the network secure.

There are some things I don't understand though.

These ordinals inscriptions, what are the fees those users are paying in order to get their ordinals inscribed? And who are these users because a quick search returned that the formula to inscribe is

Content size ÷ 4 * fee rate

In the link, the example used is a foto of a cat with size 20kb. Long story short, the price is

5,000*fee rate

For everyone here who wants to do the maths, blockchair.com gives an estimate for the recommended fee (I know there are more precise sources, but for the sake of simplicity), which at the time of this writing is

104 satoshi per byte, equating to

5,000*104 sats = 520,000 sats to inscribe a 20kb kitty into the BTC blockchain.

My final question: who the heck is flooding the network with ordinals when it is so freaking expensive to do that? What part am I missing or not understanding?


As a conclusion, I think sustained congestion while keeping the network safe and functional (in the sense as it was originally intended) rather implies that the solution would be second layers. I say "rather" because I might overestimating the point that with increased block size, the number of ordinal inscription will increase forever. But someone has to pay for that, which is why I ask who these someones are that can afford expensive inscriptions?

A bit of a wall of text, but would appreciate if you guys here would enlighten me, correct me, provide your opinions.

[ABCbits]

3. It forces high fees all the time, because even if blocks will be full, then your self-transfer will always fill the remaining space, and make some fee market.

Doesn't that mean that the attacker has to frequently pay high fees to sustain this attack? Moreover, why does "wasting time on dummy transactions" centralizes the network, and why do we call it "wasted time" since they are regular transactions, just like any other honest nodes would either way verify.

You can avoid paying high fees if you never broadcast those transaction. Although with website such as https://mempool.space/ it's trivial to detect that.

There should have been a 4-year upgrade in terms of block size incrimination in a similar fashion to how network difficulty rises with time.

Difficulty doesn't always rise, see https://blockchair.com/bitcoin/charts/difficulty.

What I mean is, that Satoshi was able to identify the supply and demand issue earlier through its halving event. However, they did not consider the scaling of block sizes or maybe they never thought that Bitcoin would go to such a high level anytime soon.

Yeah, Satoshi isn't perfect human being. Satoshi also seems fail to predict about specialization of mining hardware and pools.

[stompix]

5,000*104 sats = 520,000 sats to inscribe a 20kb kitty into the BTC blockchain.
My final question: who the heck is flooding the network with ordinals when it is so freaking expensive to do that? What part am I missing or not understanding?

Remember cryptokitties?
Somebody paid  225 ETH (at that time $100k) now $400k for a cat that is now.worthless!
Same for the ape NFT, 819 ETH at that time around 3 million!
A guy spend 2 million in a mobile game in 4 years
Logan Paul paid 5 million for a pokemon card.
Somebody paid $100k for card with Mark Zuckerberg.

We are 8 billion on this damn planet and we have trillions in out pockets put together, $200 is nothing, that sum will be nearly invisible if you look at what thrash the worlds throw money at! Speaking of thrash, here is a 1800 bag:

[Dump3er]

5,000*104 sats = 520,000 sats to inscribe a 20kb kitty into the BTC blockchain.
My final question: who the heck is flooding the network with ordinals when it is so freaking expensive to do that? What part am I missing or not understanding?

Remember cryptokitties?
Somebody paid  225 ETH (at that time $100k) now $400k for a cat that is now.worthless!
Same for the ape NFT, 819 ETH at that time around 3 million!
A guy spend 2 million in a mobile game in 4 years
Logan Paul paid 5 million for a pokemon card.
Somebody paid $100k for card with Mark Zuckerberg.

We are 8 billion on this damn planet and we have trillions in out pockets put together, $200 is nothing, that sum will be nearly invisible if you look at what thrash the worlds throw money at! Speaking of thrash, here is a 1800 bag:

Yes I am well aware of the cryptokitties madness, but I haven't been following up on that stuff and I have no idea whether any of those kitties is still worth something. I am also aware of some of those transactions you mentioned, but those really have manipulative character and can't be verified either. Whether Logan Paul paid 5 million for a pokemon card (while he was already holding 5 more of them and then offered them for sale, 2.5 million each), or whether he didn't, I doubt we can verify that.

But inscribing ordinals cost money and that can be verified. The term "attack" was used or growing demand for IP purposes as some said, whatever it is. My question was really pointing towards the "who?" and the "why?". If it is an attack, it would be a costly attack if someone wants to provoke sustained congestion to the detriment of the ordinary user. If ordinals are predominantly spammed and consume the majority of the block size, this attack would cost millions per day.

[satscraper]

Increased block size would embolden spammers who are trying to  piggyback off of Bitcoin  success and utilize its brand to popularize their junk (kin to ordinals and other stuff) via below-the-line marketing.

In my view, the solution to  mempool littering might be the fee - if spammers want to broadcast non-standard taproot transactions  then developers must force them to pay hundredfold or even thousandfold fee compared to ordinary transaction.

[Synchronice]

If you live in the USA they fucking own you
yeah real free.
free to pay

fed income tax ----------- fuck with this possible jail time and likely lose my pension while in jail
state income tax --------- "      "       "      "         "     "
trump import tax --------- "      "      "       "        "     " not sure what penalties for this one.
local town property tax. --- take my home if I don't pay
county property tax. ------  take my home       "
state property tax. --------  take my home       "

I am so KYC'd it is a Joke.

I cut some spaces in your post. In Germany we pay up to 45% tax. If you have a good, I would say, normal salary and are single, be prepared to give 40% of your income to your government. The situation is pretty much the same in many EU countries.

According your question : in 90% yes, but it is not necesary that it must be dynamical.

Pretty impressive that you managed to get so many merits by using a translator alone on English speaking boards.

We couldn't reach a consensus on when we should increase block size, how we should increase the block size and by how much should we increase the block size. Of course, we could have a simple algorithm but the scenario where the demand can't reach the expected level would make it disastrous for the eco-system and it would be difficult to reverse. Furthermore, Moore's law is likely not going to hold forever and storage density would stagnant somewhere for a while in the near future.

Reward halves, block size doubles. I think this would be a good solution! Was this even discussed before?

5,000*104 sats = 520,000 sats to inscribe a 20kb kitty into the BTC blockchain.
My final question: who the heck is flooding the network with ordinals when it is so freaking expensive to do that? What part am I missing or not understanding?

Remember cryptokitties?
Somebody paid  225 ETH (at that time $100k) now $400k for a cat that is now.worthless!
Same for the ape NFT, 819 ETH at that time around 3 million!
A guy spend 2 million in a mobile game in 4 years
Logan Paul paid 5 million for a pokemon card.
Somebody paid $100k for card with Mark Zuckerberg.

We are 8 billion on this damn planet and we have trillions in out pockets put together, $200 is nothing, that sum will be nearly invisible if you look at what thrash the worlds throw money at! Speaking of thrash, here is a 1800 bag:

It's brings some tears to think that people who do hard jobs, like working in warehouses, get a basic salary and their boss will yell if they ask for salary increase but their boss might feel fine to pay millions of dollars in 20kb jpeg file that is a piece of trash. By the way, what are chances of getting hundreds of thousands of dollars or millions by making a pixelated NFT? It won't be hard to create a pixelated garbage in Paint Or I'll bother with Photoshop

[ranochigo]

Reward halves, block size doubles. I think this would be a good solution! Was this even discussed before?

Nope, that would have a negative impact on the overall economy. By the 10th halving, you would have a block size of 1GB. That might or might not work depending on how technology progresses and if we really want to pursue layer 1 scaling for the long term. Having a long period of time between halving, and essentially a shock by having the block size doubling can't be good for Bitcoin. Congestion would either never appear in that 4 year period or will be prevalent from the on-start.

Reward halving has nothing to do with transaction volume. Instead, we have to focus on the factors affecting the transaction volume, which can be in the form of adoption rates, prices, market trends and they're hardly quantifiable. Hence why it is difficult to answer the questions in my post.