Sorry for the long post ...
TLDR: +1 for dynamic block size. I hope it is not too late for the
right changeA dynamic algorithm can not magically instantiate the needed resources.
It doesn't need to! If properly implemented it will be the other way around (see below {1})
The reason I feel OP's proposal is beautiful is because it requires users to fill up nodes with high Tx volumes and then miners to fill up blocks from mempool.
Exactly, what should be used here:
{1}
- Hard limit size - calculated by some algorithm for the entire network (see below {2})
- Client limit size - configured from the client (miner full node) based on it's hardware and bandwidth limitations or other preferences
Each node may set it's own limit of how big blocks it will send to the network, but should accept blocks up to the
Hard limitI hate to rain on the parade, but full blocks are an essential feature going into the future. Any proposal that tries to avoid ever having full blocks also must address how transaction fees are going to replace inflation as it diminishes.
If not, then there will be no funding for the highly redundant network that exists now, and it will necessarily atrophy to a handful of nodes; Being hardly less subject to coercion, malpractice, and discrimination than our financial system today.
This is probably where consensus will be hardly achieved if it should be hard coded and not dynamic - cheaper transactions or bigger fees? Some want the first others the send and the truth is in the middle after both sides make some compromise, so it should also be kept in mind when planning the dynamic algorithm.
What I may suggest for the calculation of the
Hard limit is:
{2}
When calculating the new target difficulty, do the same for the block size.
- Get the average size of the last 4000 nonempty blocks = AvgSize
- Set the new block size to 150% of AvgSize, but not more than twice bigger/lower than previous block size
How it is expected to work:
The Hard limit is kept at 66% with 1 month moving average on each diff change.
BUT it depends on the Soft limit chosen from the miners, so:
- If the bandwidth is an issue (as it is for the most private pools and those in China) - they will send smaller blocks and thus Vote for the preferred size with their work
- If there is a need for much bigger blocks, but the current status of the hardware (CPU or HDD) does not allow that - no increase will take place, because the clients won't send bigger blocks than configured
- If there are not enough transactions to make bigger blocks - the size will be reduced
EDIT: An option in the mining software to ignore blocks above Soft limit gives the control switch in each miner's hands in addition to the pools
EDIT 2: If you take a look at the
average block size chart you will see that the current average size is far from the 1MB limit, if you ignore the stupid stress tests during the last month or two and even then the average is around 80%, so 2/3 (66% full) block size is a good target IMHO