Topic: Why was the block size not increased? (Read 773 times)

TBH, sir the inscriptions are just the bubbles, the inscription wave was crazy but their actual production is zero, and those who are minting these inscriptions are really not well aware of the DEFI ecosystems and Bitcoin network they are just seeking some temporary profits Rather than deploying a full fledge business.

In simple there's nothing need to be worried about for the overhyped bubble of the inscriptions they are going to be dead sooner they we are expecting.

that is the good thing about this

year ——————-rewards————-——- fees
2009/2012         50 >>>>>>>>>> under 0.1
2012/2016.         25.                        under 0.05-0.1
2016/2020.        12.5.                      0.1-2.0
2020/2024.          6.25.                    0.2-5.0
2024/2028.          3.125.                  1.0-6.0.  seems possible


the major pools (foundry) are black box and not transparent.n you need 20ph+ to join them

foundry can down clock to crowd the mempool then over clock to grab extra higher fee blocks which they helped to create by down clocking.


in 2024 the reward penalty for a block lost due to downclocking becomes ½ so right now it costs 250k in rewards for blocks lost trying to clog the chain. april that cost drops to 125k a bargin

should be real interesting after this ½ ing.

It is not forbidden, but it seems like I'm chatting with GPT. (Also, don't bold entire sentences, it is not readable)

But reward doesn't halve. Subsidy does. There is no correlation between the block size and the subsidy. The reward decreases on the long term, but that's because of the mere assumption that the transaction fees will be less than the current subsidy. The current wave of Ordinal transactions shows that the network can pretty much survive by transaction fees alone, and we're years before it is adopted in a mass scale.

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.

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.

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

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

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

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.

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.

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:

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.


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


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

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.

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

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.

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.

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.

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?)

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.

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


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

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.

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.

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.

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:

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.

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.

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.

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.

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.



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.

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.

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.

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.

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.

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

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.

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.

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.

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.

 

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.


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.

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

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!

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.

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.

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.

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

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?


Yeah, we should start get used to this.


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?

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.


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.


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.

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.

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


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


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)

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.

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.

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.

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.

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

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.

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.

You can also have a blockchain that prevents arbitrary data (aka spam) by design rather than by banning: https://bitcointalksearch.org/topic/m.61782921

I know people are going to hate this, but I think this tradeoff of sacrificing a "little" decentralization for a lot of economic relief is worth it.  Sure, there will be full blocks, and sure that is not the solution to scaling.  But I would consider it a necessary step to move towards it, in a flexible manner.

There would still be Ordinals.  And maybe in even worse shape, like small videos instead of images.  But the cost per byte would have decreased by orders of magnitude and an attacker (like Ordinal users) would have to pay a lot more to maintain this congestion.  (I consider Ordinal users an attacker for the sake of simplicity, I do not believe they have bad intentions)

Having been around to experience the whole ordeal, I feel that sentence doesn't really do it justice, heh.  Suffice to say there was a great deal more nuance and complexity involved.  The short version is that (almost) everyone agreed that more throughput was required, but couldn't agree on the best way to achieve it.  Some wanted a small increase and the option to explore off-chain ideas, some wanted larger on-chain increases, while others wanted a mix of the two.  It's also worth noting that Bitmain announced a hardfork of their own, but never went through with it.  There was a lot going on at the time.

---

At the time, during the "civil war", we naturally didn't have this power of hindsight to know for sure what would happen, but thankfully this is the mindset that prevailed.



Well said.  

Anyone proposing placing restrictions on the varieties of transactions that are permitted is missing the point of all this, I feel.  There are other projects catering to that kind of approach.  If you have a centralised ledger, you can easily prevent stuff like ordinals.  All you have to do is completely surrender all your freedom and treat transactions in the exact same way banks do.  What a bargain!  

But we don't have a centralised ledger here and we value our freedom (or, at least, some of us do), which is why we call such projects altcoins.  People can go and play with those if they like banning stuff.

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.

In addition to the low fees on most altcoins because the blocks are mined empty and there is no congestion on the network, the real challenge is to maintain low fees and full blocks, which is what is happening now in Bitcoin.

I don't disagree with this at all. As I've said repeatedly through this whole saga, I think the correct approach here is to work on scaling, and not to arbitrarily ban certain transactions in order to allow other transactions to be processed more cheaply. I have no doubt that increasing the effective block size at some point will be part of that solution, but it cannot be the only solution for the reasons discussed above. Just ramping up the block size by a couple of orders of magnitude destroys bitcoin's long term security and completely centralizes the system, as has happened with shitcoins like BSV.

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. 

In the recent 144 blocks, according to mempool.space, the average transaction fee is ~$30.  This might (over)sustain miners' incentive (and network security), but not the on-chain usability.  I hope we all agree on the part that paying $30 is an outrageous amount (only for median size!). 

We have invested in protecting ourselves from 51% attacks, but I do not see anyone referring to "clogging up the network" as a potential attack vector as well.  Rising the block size by a factor of x, would make it x times more expensive to clog up the network and make the currency practically unusable on-chain. 

FWIW few pools already perform merge mining, but the income is extremely small since Bitcoin sidechain isn't popular.


That's good question, although there's no definitive answer. While i believe increasing block size should consider technological growth and cost to build and run full node, although it's hard to determine the lower limit. For example, should Raspberry Pi 5 (with SSD & 8GB) able to run full node?

I agree with having a competitive fee market, and we should absolutely not allow free lunch but there is of course, several considerations. The fee market right now is largely elastic, users mostly don't care if the fees are high because a good proportion of them can delay their transactions for a later date - at least for the average Joe who are trying to use Bitcoin as a daily functional currency. If Bitcoin were to try to break into the mainstream and be more integrated into our society, I expect more settlements to take place on second layer but there has to be a capacity increase to accommodate for the first layer as well. Fee market would become less elastic as time goes by; certain groups wants their transactions to be confirmed with a certainty in a set timeframe and thereby paying more, certain groups are okay with some delay.

With regards to block size, if we were to increase the block size, say 2-3 times, I would think that there would be times where transactions paying 1 sat/vbyte can be confirmed, and there would be times where it would require substantially more. The fluctuation in fees and the vast increase in the number of transactions can potentially offset the security concerns that may exist. Of course, increment has to be done on the premise where the security tradeoff from the drop in the number of nodes and propagation delay is acceptable.

If we were to keep the fee market overly competitive, ie. $20 for a single transaction, it can dissuade people from using Bitcoin as a currency when there are multiple other payment methods as well.

We don't use that limit. The upper limit is now 4 MB on disk, although in reality most blocks are around 2 MB.

Monero uses dynamic block sizes, and so fees remain low at all times. However, Monero has a tail emission of 0.6 XMR per block for ever more.

Economically speaking, both achieve the same thing - users pay miners. The difference is whether the user making the transaction pays the miner directly (Bitcoin) or whether every user pays the miner via a very small amount of inflation (Monero). Either way, you need some way to fund miners or the chain becomes insecure.

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.

---

I do think that block size will increase again, probably multiple times, but we can't just jump to the initial suggestion of having blocks large enough to let every transaction process at 1 sat/vbyte without greatly decreasing the future security of the network.

Block size was increased but by using a soft fork instead of a hard fork. Bcash is also like a lot of other copycat coins that were created and its creation was not because of the fork or lack of it.

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 depends on why the mempool was congested.
If it is because adoption has grown and more people are using bitcoin, then your assumption is correct. By increasing "capacity" the congestion would go away.
But if it is congested because of a spam attack (like this days with Ordinals scam) then increasing the capacity will only make things worse because it would make it cheaper and easier for the attackers to fill the blocks and create another congestion.

Important thing to remember is that before the Ordinals attack we didn't have any severe and lasting  congestion.

Yes it would be. And I strongly disagree with those who say congestion should exist to help miners due to block subsidy going down. Because even after the upcoming halving the miners would still be paid about $135k per block they find at the current price. This is enough incentive so that they don't need to rely on fees.

The real questions are: by how much and when?
We should always keep increasing the capacity, in my opinion. The adoption is increasing and people need to be able to use Bitcoin (BTW more capacity means more txs and more fees which addresses the concern regarding block subsidy) and there needs to be enough block space for that "additional adoption".
But it shouldn't be that big to push us toward centralization where less and less number of people run full nodes.

Pools are already as centralized as it is, increment in block size probably decreases their profit margins but it wouldn't mean that they won't be able to run a node. After all, server costs are always going down and increase in block size doesn't mean that they suddenly won't be able to run a node. Most people are also not willing to run nodes anymore, and if you steadily increase the block size, I suspect the impact would be less than expected.

The key issue here is that even with Segwit, we are still facing outrageous fees, and that the network seems to be stagnant after having Segwit. There is also another issue about a hard fork and if the community is willing to adopt it.
They will, but that isn't something that you can deal with. If they have the money, then the fee mechanism acts as a regulator for them to incur larger costs with more spam. However, if you can increase the block size to alleviate the on-chain situation while promoting off-chain growth, then I don't see why not?

In 20 years time we might be at this point, after the 2044 halving the block subsidy fee will be 0.1 bitcoin, even though the bitcoin price might have increased. But this simply means that we don’t have to wait till bitcoin is mined before miners starts depend only on fees.


I think we already have a change from the 2009 size although practically the size is still 1MB for one block but the implementation of Segwit in 2017 has theoretically made it seems like an upgrade to 4MB per block for all segwit transactions.

Imagine a 100k of transactions is been included in a single block, then this will greatly affect the decentralization of bitcoin, numerous number of transactions that’s can be batched to one separately because the fee is low and this will mean a bigger block size which in turn results into high cost of individuals running a node as the cost to store data will be expensive and also will push out pools with smaller power (hashrate) out of the network and then the network will be centralized to only the big mining nodes which some of them have started censoring transactions already.

Also even if the block size are increased wouldn’t the shittokns like ORDI and STATs continue to spam the network? Decentralization is the major concern whenever the issue of block size increment is discussed, there is no way it wouldn’t be affected.

I understand others who have their interest in mining and related business and want transaction fees to be increased but I don't understand those who are regular users and vote against it. I'll be frank and say that another problem is, what block size is the good size? Accepted by everyone? Some argue it's 4MB, some argue it's 1GB Some ridiculous answers don't make any sense but it's still a good question.

Block space needs to be limited but not in a way that we don't update the limit that was set a decade ago. It's not 2009 anymore. There is a huge difference between demand that we had in 2009 and what we have in 2023. We can't function with 2009's settings. Can someone imagine working today, doing programming/visual stuff with 2009's computer?
I think that flexible block size, i.e. block size increases and decreases according to number of transactions, that means, if there is a 100K transaction, block next block includes 5% of them, then 5% of what's left and so on. At the same time upcoming transactions are added too. If number of transactions decrease, so will the block size, that means that there will still be a competition to get transaction included in the next block and fees won't be as low as 1 sat/vByte. But is this possible to implement in Bitcoin? Ich habe keine Ahnung (I have no idea).

By the way, yesterday, miners were collecting more reward from fees than from blocks alone.

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.

Bitcoin Cash is built on lies. Roger Ver and other people are calling Bitcoin Cash a real, original Bitcoin and ignore our OG Bitcoin Core. Roger Ver owns Bitcoin.com, reddit.com/r/btc and these lies that were spread via his website, led many people to buy this Fake Bitcoin and led to many loses because people were sending BCH to BTC and BTC to BCH.

I think that we aren't increasing Bitcoin block size because not everyone agrees with that and we will have to make a hard fork and leave our absolutely original Bitcoin. Btw I think that we need to increase block size because times change, demand changes, we need to adapt and be a leader cryptocurrency with less limitations.

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.

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.

Paul Sztorc wrote an article called Measuring Decentralization in 2015 that explains why small, cheap nodes are essential to decentralization. Increasing the blocksize only works on a layer two, because you don’t have to store the entire blockchain.

https://www.truthcoin.info/blog/measuring-decentralization/

Scaling Bitcoin with sidechains:

https://www.truthcoin.info/blog/thunder/

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.

All I heard was that the block size was not increased and this led to the creation of Bitcoin Cash. It was a fork but it is an altcoin (shit coin) while bitcoin remain the bitcoin.

But I am thinking recently that if the block size is increased, more transactions can be processed and the mempool will not be congested. 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?

If the block size is increased, what is its disadvantage to bitcoin network and miners?