Tx volume-determined block size increases

[Washington Sanchez]

Hi folks,

One of the strongest and understated advantages of BIP101 is the predictable nature of block size increases until 2036. Predictability makes economic calculation easier and gives confidence to all stakeholders. That said, the problem becomes calculating the most appropriate rate of increase in light of the trade-offs to decentralisation and resource consumption we're all familiar with. In contrast, the rate of block size growth in BIP101 may be too slow for any rapid growth over the next 20 years, which may seem ridiculous to us now.

With this in mind, I've been toying with an idea (possible BIP) that I'd like some feedback on:

Block size increases will occur in 2 stages.

1) A scheduled increase in the block size over the next 4 years (January 2016-2020)

2) Algorithmically-governed, limited increases in maximum block size after 2020

Stage 1 ensures that block size increases at a reasonable pace to balance increased transaction volume while allowing infrastructure improvements to occur before Stage 2. In other words, Stage 1 allows for predictable runway to Stage 2, or kicking the can down the road as far as we can see it.

Stage 2 enables the transaction volume to determine the maximum block size similar to increases in the target difficulty for mining.

*Stage 1: Maximum block size schedule*
2016: 2 MB
2017: 4 MB
2018: 8 MB
2019: 16 MB
2020: 32 MB

This schedule reaches a maximum block size of 32 MB by 2020 at a smoother rate of increase compared to BIP100 and BIP101, the former in a theoretically achievable sense.

*Stage 2: Algorthmically-determined maximum block sizes*

- Every 2016 blocks (~2 weeks), the maximum block size will be increased by 25% if the average block size (or some %) exceeds 50% of the (current) max block size.
- The max block size can only ever be increased
- To prevent a mining pool preserving the status quo or raising the limit too quickly, the largest 400 (~20%) and the smallest 400 (~20%) of blocks will not be counted

The approach in last point is up for debate, but some feedback mechanism would be ideal. Also other variables of this proposal may be tweaked.

Regards,
drwasho

[Tom Zander]

On Wednesday 2. September 2015 18.55.27 Washington Sanchez wrote:
> One of the strongest and understated advantages of BIP101 is the predictable
> nature of block size increases until 2036. Predictability makes economic
> calculation easier and gives confidence to all stakeholders. That said, the
> problem becomes calculating the most appropriate rate of increase in light
> of the trade-offs to decentralisation and resource consumption we're all
> familiar with. In contrast, the rate of block size growth in BIP101 may be
> too slow for any rapid growth over the next 20 years, which may seem
> ridiculous to us now.

The maximum block size is not really there to support economic incentives. The
maximum is there to protect the network from overuse or abuse.

The rapid growth we might get doesn't change that our hardware won't allow
Bitcoin to stay widespread if we increase above the BIP101 rates.
I personally think we will end up with a varied set of solutions. Sidechains
being a good example.

I personally find it wrong to make *usage* of Bitcoin determine the maximum
size somehow. The usage already determines the effective block size.

Changing the maximum based on usage misses the point of why the maximum
exists, which is to protect the nodes against being overwhelmed and
effectively centralising the network.


What BIP100 and you are effectively suggesting is that if we turn on more
machines in our house, the fuses should let more power through after a couple
of months. This can only end with the house burning down due to the higher
current causing the wiring to catch fire.
--
Tom Zander

[Washington Sanchez]

The maximum block size is not really there to support economic incentives. The
maximum is there to protect the network from overuse or abuse.

Close. Like the hash rate, the maximum block size is there to balance both the economic incentives against potential abuse. If either consideration were polarized, the block size would be eliminated or permanently constrained.

 

The rapid growth we might get doesn't change that our hardware won't allow
Bitcoin to stay widespread if we increase above the BIP101 rates.
 I personally think we will end up with a varied set of solutions. Sidechains
being a good example.

I don't doubt we'll get a varied set of solutions, which is what I expect to happen in earnest within the next 4-5 years. I consider the BIP101 rates up until 2020 to be perfectly reasonable. Beyond that, it is difficult to predict how technology or Bitcoin will evolve... either Bitcoin will experience unprecedented growth that may outstrip the growth curve of BIP101, or it will dwindle. My hypothesis is that it will be the former, and beyond 2020 we will need a dynamically-adjusting max block size like we have a dynamically-adjusted target difficulty.

 

I personally find it wrong to make *usage* of Bitcoin determine the maximum
size somehow.   The usage already determines the effective block size.

Changing the maximum based on usage misses the point of why the maximum 

exists, which is to protect the nodes against being overwhelmed and
effectively centralising the network.

Like the target difficulty, the max block size absolutely need to be determined according to use...this is the reason we are having a large debate about the block size in the first place! If the number of transactions were so low, there wouldn't be a sense of urgency related to pushing through an increase in the block size via BIP101 etc.

I agree that the maximum guards against certain attacks and I believe my proposal for dynamically-adjusting max block sizes ensure that an increase in the block size is both gentle and the result of a sustained growth in transaction volume.

 

What BIP100 and you are effectively suggesting is that if we turn on more
machines in our house, the fuses should let more power through after a couple
of months. This can only end with the house burning down due to the higher
current causing the wiring to catch fire.

I guess we better starting charting out the hashing target difficulty 20 years into the future then.

I appreciate your feedback.

[Tom Zander]

> Like the hash rate, the maximum block size is there to balance both the economic incentives against potential abuse.

Ehm, no, neither are. Sorry. 

[Dave Scotese]

I think it is a mistake to choose numbers in the interest of economic balance.  The combined efforts of all the economic actors (the free market) will find those numbers instead.  In fact you can't stop that from happening, though you can get in the way, and I think we should avoid that.

However, in order for any system to work, it must limit certain numbers, and the choice should reflect the limits of the system rather than any attempt to establish an economic balance.  The hash rate is NOT limited.  The system can function properly with any hash rate (though higher is better for security - are we going to establish a minimum hash rate?  No.)  It cannot function properly with any block size.

notplato

On Thu, Sep 3, 2015 at 5:52 AM, Tom Zander <t...@thomaszander.se> wrote:

> Like the hash rate, the maximum block size is there to balance both the economic incentives against potential abuse.

Ehm, no, neither are. Sorry. 

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

I like to provide some work at no charge to prove my value. Do you need a techie? 
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto

[Washington Sanchez]

Well it looks like someone tried my approach in BIP106, though I think they're proposal reacts far too late and increases the block size by too much in one hit.