The bitcoin system does not have enough information.
1)It doesn't know the value of bitcoin in the real world.
2) It does not know about the level of technology development.

Therefore, theoretically, it is impossible to come up with an algorithm only within the system that would successfully regulate fees and block size.

You just haven't tried it yet. Everything is known by comparison.

Managing the fee through the block size:
If there are few transactions, the fee is sharply reduced, to cents. If there are a lot of transactions, the fee increases dramatically, up to $10. That is, it can change 100 times. And in a very short time - in a day, 2.
As I wrote above, this is a bad way, because it constantly causes inconvenience to bona fide users.

Minimum fee management:
The fee is set in satoshi and, let's say, changes every 2 weeks. What is a change algorithm is a topic for discussion. Now the price does not change dramatically by 10 times. The recent sharp increase is just a 2-fold increase in 2 weeks.(even in December 2017, the growth was 2-fold in 2 weeks.) It's not that bad. Instead of 10 cents - 20 cents, instead of $ 1 - $ 2 before changing the fee. - not terrible, against the background of the current $10.  
As for hard forks. Since this is adding restrictions, you can theoretically do with a soft fork. Possible, You may need one hard fork.

A blockchain of 10mb. blocks, in which 2.5 million transactions are made every day, will hold less than 10 users? This is so implausible that there is nothing to comment on.

"malicious growth" - As far as I understand, this is filling the blockchain with transactions with zero or very small fee.

There is a very simple and elegant way to solve this problem. You need to enter a minimum fee amount. Transactions with a fee of less than will be invalid. The problem is solved, and solved well. Because it will only affect those who make "malicious" transactions.

The way this is solved now, through the block size limit , is a terrible solution. I do not know if it is possible to come up with a worse solution than this. It does not solve the problem when the block is not complete - "malicious " transactions hit the block. When the blocks are full and there are queues, many good transactions are thrown out along with the "malicious " ones. For example, right now, when the average transaction is $ 10, many transactions with fees of several dollars do not fall into the blocks. Good customers who want to get into the nearest block should play the game "guess the right fee".

If you look at the analogy with your work. For you, the cost of service does not depend on the number of customers at the moment. And the cost of service does not change every second.

“feel” exponential - this is something new in cost estimation.

My computer, bought 5 years ago, processes a new block in less than 1 second. a 10mb block will process less than 10 seconds. And blocks appear once every 10 minutes. The only expense is disk space. At 10MB block - 0.5 TB per year. 2tb. hard disk ~$ 60 and this is for 4 years. The cost per year is $ 15, per month ~ $ 1.2. And now that I make a modest 12 transactions a year, look at the size of the average fee, and estimate how much I have costs due to 1MB. block.

You understand that it is your "concern" for the user that only brings them extra costs.

Even if we take the more expensive option, together hdd ssd. 2tb ssd - ~ $ 240. Divide by 48 months - $ 5 per month. The fee for one transaction per month is about the same level, and I will not pay this fee. That is, I will be at the same level in terms of costs. But in return, I get a 10-fold increase in the Bitcoin system. (10x! , Karl).

You are more careful with your desires. If the Bitcoin Cache develops to the point that users will make 2.5 million transactions a day, and bitcoin will remain at its 350 thousand, then I do not think that this is a a good outcome for Bitcoin..

I understand your moderate position.
I just can't figure out how moderate growth is better than natural growth. After all, your moderate growth implies an artificial restriction of growth. Questions appear. What for? We tell users: some of your transactions are unworthy to get into the blockchain. What do we gain by throwing out some part of the transactions? My answers to these questions are: nothing. Only slowing down the development of Bitcoin.

Unfortunately, this is simply not true. Another statement without proof.
We are discussing raising the block to 10mb here. For this case, there is no problem with the distribution of blocks over the network at the current Internet speed. You do not take into account the growth of Internet speed, as well as the development of technology. I understand you don't know about the Compact block technology.
You were zombified 4 years ago, since then you have not turned on your brain.  

However, users of bitcoin forums constantly use expressions such as"decrease/increase centralization/decentralization". Even bitcoin developers don't hesitate to use these expressions. Although they must have an engineering mindset.
And it's amazing! How can you claim a decrease/increase in some indicator if you do not know how to measure this indicator, if you have not determined how to measure it? This is nonsense.

Again you lie, again you create another strange statement. I do not know anyone on the forum who would like to increase the block despite the technical costs. Why do you invent it?
There is a concept of estimating technical costs. According to my calculations, if the owner of a full node makes an average of one transaction per month, then it is more profitable to keep a full node with a 10mb block and pay cents in the form of a transaction fee than to keep a full node with a 1MB block and pay 5-10$ fee per transaction. Therefore, the statement that when the block is increased, the user's costs will necessarily increase is already incorrect.

If we look at your statement above for pseudo-valid statements:
"on network latency" - unsubstantiated. If you just take the calculator and take the block size of 10mb, you will see that there is no problem with this. But you didn't make any calculations, you don't need to know the truth. You need to refute the possibility of increasing the block by any effort.
"network security" - unsubstantiated.
"costs in the network transfers from the miners to the nodes" - unsubstantiated.

And you say:None of it is “pseudo-statements”.
I've been waiting for this. Pseudo-arguments such as "disk size, processor power, RAM, internet speed, etc." come to an end.
Then there is the main argument of "the increasing centralization (reduction of decentralization)".

So, for newbies. (since there is a tradition to address newbies.). When the arguments "increasing centralization (decreasing decentralization)" appear, then the constructive discussion ends. Because these statements "increasing centralization (decreasing decentralization)" are usually presented as self-sufficient. For some reason, it is considered that it is not necessary to provide any evidence.

If my opponent wanted to confirm his words with evidence, then he should have provided:
1) How it measures the level of centralization (decentralization).
2) What is the level of centralization (decentralization) now, at 1mb block.
3) What is the level of centralization (decentralization) will be if we increase the block, for example, to 10MB.

The only reason I see is the reluctance of most Bitcoin developers (not all) increase the block. I do not know the real reasons for this decision. Because all the arguments that the developers gave in favor of such a decision were unconvincing. For me. The majority of society believed them. (I'm not going to rewrite history )

Just because society chose such a consensus does not mean that it was the right decision. It can also mean that someone is very strong in propaganda and manipulation.
If the arguments against increasing the block were convincing, then they should remain the same now. All you have to do is get them out, dust them off, and give them to the public. The fact is that they were ridiculous, and so they remained.

I wonder how a convincing argument convinced you that the block can't be increased? Maybe a "Chinese firewall"?

For OP.
Your reasoning is correct and based on common sense. If all technologies are improving,then it is necessary and possible to increase the block. There is no reason to freeze the block size.
 
The problem is that the Bitcoin community is mostly zombified. They are sincerely convinced that the block cannot be increased. They have no real reason, but they are convinced of it.
Therefore, they will generate refutations for any proposal to increase the block. They generate such arguments against increasing at a high rate. All of them without proof, just look plausible.
 If you take the time to prove one claim untenable, another will immediately appear. And the number of such pseudo-true statements is not limited.
For example, "spam from miners". This problem is not there, it is just made up. This problem was not present when the blocks were half-empty, this problem is not present when the blocks became full. And there is no evidence of the existence of "spam from miners".

When you doubt the credibility of this argument, there will be arguments in the form of "lack of processor power, RAM, block propagation speed over the network, etc." I emphasize that all these statements are without evidence. And you will have to look for evidence that they are untenable. If you expose these statements, the following will appear: like "increasing the block increases censorship", etc.

How to break through this swamp is not understood.

p/s/ why was the Khaos77 post deleted?

Schnorr signatures will give a theoretical 20%, and in practice 10% increase, block optimization will give 5%. Together, this will give a 25-15% increase. To the existing 10 million users per month, this will add 1.5 -2.5 million. It's a drop in the bucket . I wouldn't use the word "scaling" for this.
For scaling Bitcoin at the moment, there is no alternative but to increase the block.
Increasing the block by 2 times will give 100%, and increasing it by 10 times will give 1000% scaling. At the same time, this does not require any special sacrifices for full-node holders.
According to my calculations, it is enough for me to buy a 2TB hard drive to easily keep a full node with an enlarged block for 5 years. In fact, a increased by 10 times block and a fees worth cents will be more profitable for me than a 1MB block and a fees of 5-10$ for each transaction.

I'm not even sure whether to focus on the 3rd countries. There's something wrong with that. Let's assume that in developed countries we now have 1 billion potential users, of which 10 million can hold a full node with a 10MB block. That is, increasing the block by 10 times can increase the number of users up to 100 million.
But we look at the 3rd countries and decide not to increase, because they will not be able to.. And what it will give us. As there were 10 million users, so there will remain 10 million. Question: What do we get from not increasing it? Who did we do better for?

p/s/ In order to understand that LN will not be able to scale Bitcoin even to 50 million users, it is enough to be able to use a calculator.
And then there are amazing things:
1) The Core team claims otherwise.
2) The Bitcoin community mostly believes them.

What, both of them do not know how to use a calculator?

Increasing the block has nothing to do with resistance to censorship. This is another misconception that occurs in the Bitcoin community.

In order to introduce censorship in the Bitcoin system, it is necessary to introduce censorship for all mining pools. But the resistance of mining pools to censorship does not depend on the block size.
If the main goal is to increase security, and the rest does not matter, then there is a great way to achieve this. Let's make the block size equal to zero. Then all bitcoins will never be lost.

You can, of course, create such a channel and use it in this way, but it will just be an atypical case that will not make a significant difference.
What matters is how the channels will be used by most users.
According to the calculations of LN developers, the average lifetime of the channel will be 3 months. Don't ask me why so much, it's not my calculations.
Now we have the ability to make ~10 million transactions per month. The channel needs 2 transactions-opening and closing. This means that 10 million*3 months /2-> 15 million. That is, there will be 15 million channels. 15 million users if each has an average of one channel, or 7.5 million if the average is 2 channels per user.  And this is if all transactions are set aside for creating and closing LN channels. And since this will not happen, some users will use blockchain transactions for their own purposes, this number can be safely reduced.

If someone tells you that using LN and 1MB. block we reach a billion users- don't listen to it. He's either an idiot or he'll cheat you.

The security of using the spv-client can easily be raised to a full-node if you teach the spv-client to work through a wide pool of full-nodes.

But... I think that such functionality is not added because the probability that a miner with more than 25% of the hashrate power will attack the spv-client, creating fake block headers and spending half a million dollars on it, is almost 0. (Attacking the spv client with less hashrate power is pointless - too much time to create blocks). There is no guarantee that such an attack will be successful.

In general, it is time to stop using the expressions "the spv client requires trust", "the spv client is vulnerable", "an attacker can easily deceive the spv client" ,etc as untrue.

If someone wants to prove the opposite, then they must present a real attack scheme for the spv-client, which will be easier than attacking a full-node. Otherwise, it will be just words.

Lack of mining capacity.
Let's fix the fact that a non-mining node cannot deceive the spv client. So I don't have to go back to it.

What does "easy" mean? If the attacker has 10% of the capacity, then he will create 6 blocks in 10 hours. During this time, he will lose more than half a million dollars. At the same time, the spv client should not guess anything. There is no setting that the spv client should work with a single full node. I already wrote above about a well-implemented spv client. So, if the spv client works with a wide pool of full nodes, then this attack loses all meaning.

Note that if a full node only works with such an attacker and no one else, then the attacker can similarly deceive this full node by preparing a fake block chain for it. The only difference is that the blocks should look correct. And this attack does not cost by the fact that the full node checks the block, but by the fact that the full node connects to many full nodes and learns about the existence of other chains.

As you can see, there is not much difference between a full node and spv clients.

So you don't need to check the entire block, you don't need to check transactions. This block contains information that can be used to determine which chain this block belongs to. It is enough to get this information.

What does "significant portion" mean? Now, according to various estimates, from 50-100 thousand users use full nodes. And there are about 10 million users in total. That is, less than 1% of users use. Is this still a "significant portion" or not?
I would like to learn more about the dependence of spv clients on the number of full node users.

To be honest, it is doubtful. Let's take an extreme case, we have 20 miners, there are no non-mining full nodes, all work through the spv client, which are connected to the miners. And spv clients duplicate requests to different miners. How can I cheat the spv client? The only answer I came up with was only having more than 50% of the mining capacity in one hand.
Conclusion, non-mining full nodes do not add much protection.

This information will be located in a block. This block will have a header that only miners can make. And the miners who make this header check the block for correctness. A non-mining full node will not be able to make a header for a block with incorrect information.

This is not enough. To create a fake block header, you need to find the hash of this block with the appropriate hash rate. If you don't have the mining capacity, you can't do it.

If there is no possibility now, it doesn't mean that it can't be done.
If there is information in the blockchain that can be used to determine which of the chains you need, you can always get this information from the full node without downloading the entire chain from the very beginning. A chain of block headers ensures that this information is correct.


To feed the spv client a fake chain of block headers in real time, the attacker must have ~50% of the hashrate power.

If it is known how the block number N in one chain will differ from the block number N in another chain, then what prevents the spv-client from downloading this block and checking it. Downloading a single block once every 5 years does not make it a full node.
If it is very easy to create many fake nodes for spv nodes, what prevents you from creating many fake nodes for full nodes? If the spv client connects to 8 full nodes, and the full node connects to 8 full nodes, then the cost of surrounding them with fake full nodes will be the same. I don't see the benefits of a full node.

If a full node can distinguish between a good chain and a bad one, I see no reason why such functionality cannot be added to the SPV client.
It's only a matter of timely updates, just like for full nodes.

You can also reduce the probability of an attack if the SPV client works with more than one full node and duplicates requests to N full nodes.

Well-implemented spv wallet can only be deceived by an attacker-a miner with a 51% hashrate. As we know, such a miner can also deceive full nodes. In this regard, full nodes have no advantage.
If this is the case the current topic is meaningless. Why fight to increase the number of full nodes?

Unfortunately, you have not shown how the security of the network depends on the number of full nodes.

Are there any studies that show what we get from increasing the number of full nodes?

The functionality seems to be clear. Since the system works smoothly with the current number of full nodes, increasing it will not do anything.

There were complaints about the security of the system. Where we can see what security level is in the current state with the number of ~10 thousand full nodes. What level of security will be at 5 thousand, and what at 20 thousand?

You didn't read the terms very carefully. I'll help you.
"full nodes in the amount that is sufficient for the full operation of all users and the system"-means that there are no problems connecting to network.  And if there are no problems, adding additional nodes does not increase the ability to connect to the network.

Are you suggesting that it is impossible to estimate the number of full nodes that is sufficient for the network to function?
Now we have ~10 thousand full nodes. ~350 thousand transactions are added to the system every day. That is, on average, through each full node the system receives 35 transactions per day, or 1 transaction per 40 minutes.
And you think that 10 thousand full nodes can't handle it, that there may be problems connecting to the network. So, should we still increase the number of full nodes? Seriously?