A different approach to Bitcoin's scalability issues?

[vjudeu]

Using average mempool size is no different than using average difficulty.

It is completely different, because all blocks have to be the same for all miners, so difficulty is based on a situation, where all miners have the same chain, so they get the same difficulty. On the other hand, each node has a different mempool. For example, my node allows accepting and broadcasting free transactions, and they are included only if there is a space for them (if you want to see them, you have to find my node in the wild, and set your node to allow free transactions, because they are sent only to nodes that declare to accept them). So that means my mempool is always bigger, because you can send some free transaction, and it will be later dropped if not picked by other nodes (which is usually the case).

In addition there is no financial incentive for miners to attack blockchain.

Why not? Any miner can create a lot of dust, just to get rid of the competition. For example, some evil miner could use some 256-bit number as a source of entropy, then use that to generate a lot of transactions, moving coins to himself. That miner could always fill the whole mempool, up to the 300 MB default limit. Then, that miner can pretend that its mempool is always full of transactions. But it does not matter, because even if some miner is sending coins to himself, then it can be done at zero cost (also if everything is precomputed, then that miner does not have to store all of that, but only be aware of the correct UTXO set). In this way, a single miner can create a lot of dust, that will take a few kilobytes, but others will process a lot of data, because others will have no idea, which algorithm was used to generate them.

So, there are things that may be profitable from a single miner's perspective, but can be considered harmful from the network's perspective.

[1715283028]

1715283028

[1715283028]

1715283028

[1715283028]

1715283028

[n0nce]

I haven't yet read the replies, but my first thought is that you might be mixing up running a full node and running a miner.
If you come from crypto theory and mostly read papers like the Bitcoin whitepaper itself, you may rightfully assume so, since it was envisioned that people would do both. But today, this is not the case.

This means that a higher hashrate in the network doesn't gain node runners anything, so it makes no sense that they'd need to go buy larger SSDs, while miners are making more profit or something like that (if I understood your proposal correctly like that).

2) The BCH hard fork, happened because it was being claimed that making the block size bigger, would cause a more centralized network, that would be much harder for the regular people to participate in.

This is correct, since regular people (altruistic node operators) who run a low-cost, low-power node (like in my $50 guide) don't want to spend a lot of money on hardware and networking.

So, given that bitcoin uses a self-adapting mechanism that adjusts the block-mining-difficulty in relation to the network's hashing power, why not use a similar mechanism in order to make block size bigger?

Either one of these two options, suggests that the network (by the price of it's coin - aka bitcoin) is profitable enough for people to invest in mining power.

That's the issue: node operators are usually not miners at the same time.

3) It works both upwards and downwards - Meaning, that also when fear or pessimism (or regulations) are causing people to abandon the network, leading to lower hashing rates - the network will adjust the block size back to smaller sizes - making it easier for everyone to mine blocks again.

Here you're speaking about mining blocks, again - while the issue with a larger block size (as you said in my first quote) is that it becomes hard for ordinary people to run a node. That's not due to mining difficulty or anything like this, but due to hardware and networking (infrastructure) costs. Node operators gain nothing in terms of money, from doing it.

This concept is based on one major assumption - in general (not in a specific date or short period of time), more hashing power means one of two things:
     1) More people are joining the network
     2) The same people/mining farms etc. got more power

Yeah, so the issue is that the 'new people joining the network' as miners, aren't the ones running the nodes. That's pretty much it.

[rlirs]

You could validate block difficulty, but how would you validate someone's mempool size? But since you said it doesn't need to be validate it, what would happen if majority miner claim have big mempool or majority miner claim have small mempool?

In addition there is no financial incentive for miners to attack blockchain.

Regarding maximum block size, there are possible financial reason to do it such as,
1. Lower block size could force people to pay more transaction fee.
2. Higher block size could be used to attract investor with PR "Bitcoin now is scalable and can adjust to network condition" which increase Bitcoin price.

1. Lower max block size can have minimum size set to the current Bitcoin block max size so it cannot get worse than what it is now.
2. If it does increase Bitcoin price than I would not complain . If it does not then the incentive to claim big mempool for miners is gone.

In real life different miners would set mempool size to different values, there will be conflicting interests, and in the long run it will be close to what majority of nodes see.
But I am not in favor of increasing max block size as I believe it would affect decentralization. But theoretically it is an interesting topic.

[garlonicon]

Bitcoin now is scalable and can adjust to network condition

Increasing max block size is not what "scaling" means. If you can process M transactions, and it takes N bytes, then processing 1000*M transactions by using 1000*N bytes is not "scaling". It is the simplest "linear growth" and has nothing to do with real scaling. The "real scaling" is called "compression". For example, where you can handle N-of-N multisig by using a single signature, instead of N signatures. Or where you can compress a chain of A->B->C->...->Z transactions into A->Z transaction, that is also scaling. And that is the right direction for the next soft-forks.

If it does not then the incentive to claim big mempool for miners is gone.

I think it is gone. Also because BCH and similar chains did it in a hard-fork way for no reason. They could create 1 GB blocks in a soft-fork way, and we can also do that, if it will turn out that no other way is possible. But as far as I know, there are better ways to scale things, so I think we won't need increasing the block size in the future. Another thing is that the max witness size is just a parameter that any node can set to anything, so from the code perspective, everything is ready, it is just a matter of reaching consensus if needed.

[DooMAD]

Definitely not Segwit2x, but i think you refer to BIP 104, 106 and 107.

And not to forget the truly awful BIP 100, A.K.A. "Just let the miners pick the size.  What could possibly go wrong?"    

Glad that one never gained any traction.    

There was a time where I was an ardent supporter of BIP 106, or at least a somewhat curtailed version of it.  But people pointed out that it would be possible to manipulate or game the system.  As such, it's probably not safe.  If it's a major part of the foundations, it has to be solid.

[n0nce]

Bitcoin now is scalable and can adjust to network condition

Increasing max block size is not what "scaling" means. If you can process M transactions, and it takes N bytes, then processing 1000*M transactions by using 1000*N bytes is not "scaling". It is the simplest "linear growth" and has nothing to do with real scaling. The "real scaling" is called "compression". For example, where you can handle N-of-N multisig by using a single signature, instead of N signatures. Or where you can compress a chain of A->B->C->...->Z transactions into A->Z transaction, that is also scaling. And that is the right direction for the next soft-forks.

I couldn't have put this better! It will go in my list of bookmarks. This is what happens when people throw around words from a field they have no idea about.
It's clear that a block of twice the size has twice the space for transactions; so since the relation between size and transaction count stays the same, nothing was 'scaled'.