The Current State of the Blockchain
Bitcoin, in its current state, cannot act as a major transaction network. Because blocks are current limited to be 1 MB in size, Bitcoin is limited to handle roughly 7 transactions per second. In comparison, thousands of credit card transactions happen per second across the world. Despite its declining price, Bitcoin’s usage has been growing- the average block size has doubled in the past 6 months. If this rate of growth continues, Bitcoin will reach its limits within a year. Once every block begins to reach maximum capacity, fees will begin rising rapidly as people wishing to have their transaction included in a block will be competing with each other.
Why The Block Size is Limited, And the Developer’s Perspective on the Issue
The block size is limited to prevent a bad miner from creating a massive block that everyone would be forced to download. Hypothetically, if the cap didn’t exist, a miner could create a 100 GB block that everyone had to download, and continue doing so to destroy Bitcoin by making the blockchain too large for everyone to store, and transmit.
Raising the block size limit is considered to be something that will eventually become necessary; however, developers wish to wait as long as possible. They believe that because the blockchain must fork to make the change, it isn’t worth the struggle when Bitcoin is doing fine right now.
At this point, a blockchain fork would require getting the approval of most of the major businesses in the industry, such as Bitpay, Coinbase, Bitstamp, and other merchant services/exchanges. If the majority of people disagreed on a fork, it could be disastrous to Bitcoin as it would effectively be split in two, and people would disagree on whose money is on the “real chain”.
By waiting longer, we’re effectively waiting until it becomes a problem. And with all forks, it requires planning and time. You can’t fork well in a day; ideally its best to announce it months ahead of time, put it on the testnet, and then implement it several months later, with the fork happening months after people have a chance to update wallets, at a specific block. If we wait until Bitcoin grinds to a halt due to the blockchain reaching its limits, it would take a long time for the problem to be resolved. As a result, trust in Bitcoin may be lost, and it would be a lot harder to recover.
The refusal to do anything about an issue until it becomes a problem is not an uncommon thing for humans to do. People neglect making backups until they lose their data, businesses often ignore certain aspects of security until being hacked, airline security was lax until 9/11 happened. But it most certainly foolish to not prevent things before they happen, and it is crucial that we plan ahead for Bitcoin’s future.
The Problem With Simply Raising The Limit
If we raise the limit, it’s possible that we may need to raise it again in the future. Each time we fork, it causes inconveniences to businesses and users, as they must update their software and wallets to reflect the change, and it must be approved by both the general public and the majority of businesses. It’s also risky, as a glitch could occur on the actual chain that for some reason doesn’t happen on the Testnet. At the same time, if we raise the limit so much such that it never needs to be raised again, we risk the blockchain getting flooded with spam transactions, making it very hard to store the Blockchain on an average hard drive, or transmit it on average cable/DSL.
Because of these factors, agreeing on a number is hard. Hypothetically, one exchange may believe a 10 MB cap is the best for Bitcoin right now. At the same time, another exchange may believe a 100 MB limit is best for the future of Bitcoin. These disagreements may lead to controversy, and creates a risk of a fork not going smoothly at all.
The Proposed Solution
Instead of choosing a specific limit for the size of the block, the block size limit should scale based on a formula that takes into account how big the blocks have been. The maximum size should never reduce, only increase.
An idea for the algorithm used for the calculation of the maximum block size in pseudo-code might be as follows:
if(average size of last 4096 blocks*4>maxblocksize && median size of last 4096 blocks *8>maxblocksize)
maxblocksize=(average size of last 4096 blocks*4)
The maximum block size would be recalculated every 4096 blocks, much like the difficulty is recalculated every 2 weeks.
This is more of just showing the idea than proposing an actual formula, I’m sure a better one could be created. The logic behind this formula is to ensure both the median and average are higher. If just the average is used, the block size may increase when it isn’t needed just because of a few spam blocks every cycle. By checking the median, it ensures that there are legitimate blocks that are reaching that size. The only way the median would be a faulty indicator of what is needed would be if spamming miners controlled more than 50% of the blocks, but at that point, greater problems would exist. The median is likely harder to reach the same number as the average, due to smaller miners capping their blocks, which bigger miners compensate for. As a result, the median threshold is more lenient.
In Plain English:
If 4 times the average of the last 4096 block is greater than the current maximum block size, and 8 times the median of the last 4096 blocks is greater than the current maximum block size, then increase the maximum blocksize to 4 times the average of the last 4096 blocks.
Basically, you’re allowing room for 4 times what’s actually being used, and recalculating every month.
What it Accomplishes
Because there is always a limit, the block size limit can only do so much as Quadruple once a month, preventing rapid change. In some months, it may not go up at all due to usage not increasing. This formula allows the network limit to grow as much as 400% monthly. In theory, the 4 can be replaced with the variable scaleFactor, and a more appropriate number could be decided by the developers.
This solution would still prevent a bad miner grabbing hold of a couple blocks and creating a block too big, as it would be denied by the network. A few blocks created at the new maximum size won’t cause any issues due to checking the median. This change allows lets Bitcoin scale infinitely as long as infrastructure supports it, which means we won’t need to fork for this reason any time in the future.
Regarding Technology Limitations
One of the largest criticisms of this model is that technology and infrastructure may not be able to keep up. While server-grade hardware and fiber connections set up between thousands of companies can easily support thousands of transactions per second on the Bitcoin network, the average user would not be able to handle all of the bandwidth, or store the entire blockchain if Bitcoin ever reached this magnititude. Making sure running a full node remains viable to the average person is of great importance to some people, so that needs to be taken into consideration.
One way to meet this goal would be to limit the speed at which the maximum size is increased, in another calculation. Perhaps, for example, the growth is limited to 10% per month at maximum. The calculation proposed earlier will be done, however if the new value exceeds 110% of the previous block size value, it will be set to 110% of the last value, so that the increase is only 10%(or whatever value is deemed appropriate). If It doesn’t exceed 110% of the last value, but is greater than 100%, then the cap will be increased to the value calculated.
This is just yet another idea for consideration, that those who believe the ability for anyone to run a full node may prefer. Limiting Bitcoin to allow for full nodes to be run by anyone would prevent it from becoming a mainstream payment network if technology doesn’t advance. However, ensuring anyone can run a full node helps decentralization by increasing the amount of nodes. Limiting the growth to 10% per month while adapting this model would help Bitcoin to grow as a Niche payment network and protocol, but with this limit, it would not be capable of growing to become as large as credit cards or other payment technologies.
Tips are welcome at :1DHtQMNbXubz83ofw3G2y34xYcCrLskjot