Quote from: kingcolex on February 11, 2020, 09:45:05 PM

Quote from: squatter on February 11, 2020, 08:44:02 PM

Quote from: kingcolex on February 11, 2020, 12:42:48 AM

My idea has been something like this a single patch that solves the blocksize issue permanently, X number of full blocks in a row = .1 mb blocksize increase.

Adaptive block size increases like this are easily gamed. An attacker intent on bloating block sizes can simply flood the network with transactions. The attack will actually become cheaper over time as block size increases, which makes it especially dangerous.

Then we use an adaptive increase with a limit, instead of just an increase to 8mb it would be the limit, this would slow things down until their is the demand and nodes and can adapt if they have storage related issues, rather than the flip of a switch, if games by miners once they let up the blocksize would regress naturally to the true limit.

It wouldn't regress because the attack gets cheaper and cheaper to mount over time.

Even outside of an explicit attack scenario, consistently full blocks is the natural state of the network. Whatever incremental limits you put on block size, blocks will become filled shortly afterwards.

So, raising the block size in this manner is a classic "tragedy of the commons" scenario. Block space = highly distributed, permanent storage. It is a very valuable commodity, and users will naturally want to obtain it at the lowest possible price. By allowing demand for transactions to solely determine block size, we would therefore create an endless race towards zero fees and larger block sizes. There would be no built-in check on blockchain growth.

Monero was able to solve this problem by implementing two properties: 1) A penalty function for oversized blocks which lowers the mining reward, and 2) a tail emission. This cannot be implemented in Bitcoin unless users are willing to remove the hard cap on supply.