[bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

Hi everyone,

I know many of us feel that the last thing the Bitcoin community needs is
another BIP related to the block size, but after a lot of reading and
commenting, I'd like to throw this idea out there.

I've already written it up as a BIP and would like some constructive
feedback/suggestions/alternatives related to some of the variables in my
specification:


Dynamic limit to the block size
=======================

The goal is to dynamically increase the maximum block size conservatively,
but allow meaningful relief to transaction volume pressure in response to
true market demand. The specification follows:

- Every 4032 blocks (~4 weeks), the maximum block size will be increased by
10% *IF* a minimum of 2000 blocks has a size >= 60% of the maximum block
size at that time
  + This calculates to theoretically 13 increases per year
- The maximum block size can only ever be increased, not decreased

For example, if this rule were to be instituted January 1st 2016, with a
present maximum block size 1 MB, the limit would be increased to 1.1 MB on
January 29th 2016. The theoretical maximum block size at the end of 2016
would be ~3.45 MB, assuming all 13 increases are triggered.

As the maximum block size rises, so the cost of artificially triggering an
increase in the maximum block size.


Regards,
Wash


-------------------------------------------
*Dr Washington Y. Sanchez <http://onename.com/drwasho>*
Co-founder, OB1 <http://ob1.io>
Core developer of OpenBazaar <https://openbazaar.org>
@drwasho <https://twitter.com/drwasho>

[-- Attachment #2: Type: text/html, Size: 2160 bytes --]

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Btc Drak]

> but allow meaningful relief to transaction volume pressure in response to true market demand

If blocksize can only increase then it's like a market that only goes
up which is unrealistic. Transaction will volume ebb and flow
significantly. Some people have been looking at transaction volume
charts over time and all they can see is an exponential curve which
they think will go on forever, yet nothing goes up forever and it will
go through significant trend cycles (like everything does). If you
dont want to hurt the fee market, the blocksize has to be elastic and
allow contraction as well as expansion.

On Tue, Sep 8, 2015 at 8:45 AM, Washington Sanchez via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi everyone,
>
> I know many of us feel that the last thing the Bitcoin community needs is
> another BIP related to the block size, but after a lot of reading and
> commenting, I'd like to throw this idea out there.
>
> I've already written it up as a BIP and would like some constructive
> feedback/suggestions/alternatives related to some of the variables in my
> specification:
>
>
> Dynamic limit to the block size
> =======================
>
> The goal is to dynamically increase the maximum block size conservatively,
> but allow meaningful relief to transaction volume pressure in response to
> true market demand. The specification follows:
>
> - Every 4032 blocks (~4 weeks), the maximum block size will be increased by
> 10% *IF* a minimum of 2000 blocks has a size >= 60% of the maximum block
> size at that time
>   + This calculates to theoretically 13 increases per year
> - The maximum block size can only ever be increased, not decreased
>
> For example, if this rule were to be instituted January 1st 2016, with a
> present maximum block size 1 MB, the limit would be increased to 1.1 MB on
> January 29th 2016. The theoretical maximum block size at the end of 2016
> would be ~3.45 MB, assuming all 13 increases are triggered.
>
> As the maximum block size rises, so the cost of artificially triggering an
> increase in the maximum block size.
>
>
> Regards,
> Wash
>
>
> -------------------------------------------
> Dr Washington Y. Sanchez
> Co-founder, OB1
> Core developer of OpenBazaar
> @drwasho
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Ivan Brightly]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

This is true, but miners already control block size through soft caps.
Miners are fully capable of producing smaller blocks regardless of the max
block limit, with or without collusion. Arguably, there is no need to ever
reduce the max block size unless technology advances for some reason
reverse course - aka, WW3 takes a toll on the internet and the average
bandwidth available halves. The likelihood of significant technology
contraction in the near future seems rather unlikely and is more broadly
problematic for society than bitcoin specifically.

The only reason for reducing the max block limit other than technology
availability is if you think that this is what will produce the fee market,
which is back to an economic discussion - not a technology scaling
discussion.

On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > but allow meaningful relief to transaction volume pressure in response
> to true market demand
>
> If blocksize can only increase then it's like a market that only goes
> up which is unrealistic. Transaction will volume ebb and flow
> significantly. Some people have been looking at transaction volume
> charts over time and all they can see is an exponential curve which
> they think will go on forever, yet nothing goes up forever and it will
> go through significant trend cycles (like everything does). If you
> dont want to hurt the fee market, the blocksize has to be elastic and
> allow contraction as well as expansion.
>

[-- Attachment #2: Type: text/html, Size: 1956 bytes --]

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Adam Back]

The maximum block-size is one that can be filled at zero-cost by
miners, and so allows some kinds of amplification of selfish-mining
related attacks.

Adam


On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This is true, but miners already control block size through soft caps.
> Miners are fully capable of producing smaller blocks regardless of the max
> block limit, with or without collusion. Arguably, there is no need to ever
> reduce the max block size unless technology advances for some reason reverse
> course - aka, WW3 takes a toll on the internet and the average bandwidth
> available halves. The likelihood of significant technology contraction in
> the near future seems rather unlikely and is more broadly problematic for
> society than bitcoin specifically.
>
> The only reason for reducing the max block limit other than technology
> availability is if you think that this is what will produce the fee market,
> which is back to an economic discussion - not a technology scaling
> discussion.
>
> On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > but allow meaningful relief to transaction volume pressure in response
>> > to true market demand
>>
>> If blocksize can only increase then it's like a market that only goes
>> up which is unrealistic. Transaction will volume ebb and flow
>> significantly. Some people have been looking at transaction volume
>> charts over time and all they can see is an exponential curve which
>> they think will go on forever, yet nothing goes up forever and it will
>> go through significant trend cycles (like everything does). If you
>> dont want to hurt the fee market, the blocksize has to be elastic and
>> allow contraction as well as expansion.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Ivan Brightly]

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]

Agreed. For this reason, the scaling BIPs which don't allow for easy gaming
such as BIP101, your proposal or Pieter's are preferable for their
predictability and simplicity. Changing the fundamental rules for Bitcoin
is supposed to be hard - why give this power up to a subsection of the
ecosystem in order to make it easier to change or game?

On Tue, Sep 8, 2015 at 9:13 AM, Adam Back <adam@cypherspace.org> wrote:

> The maximum block-size is one that can be filled at zero-cost by
> miners, and so allows some kinds of amplification of selfish-mining
> related attacks.
>
> Adam
>
>
> On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > This is true, but miners already control block size through soft caps.
> > Miners are fully capable of producing smaller blocks regardless of the
> max
> > block limit, with or without collusion. Arguably, there is no need to
> ever
> > reduce the max block size unless technology advances for some reason
> reverse
> > course - aka, WW3 takes a toll on the internet and the average bandwidth
> > available halves. The likelihood of significant technology contraction in
> > the near future seems rather unlikely and is more broadly problematic for
> > society than bitcoin specifically.
> >
> > The only reason for reducing the max block limit other than technology
> > availability is if you think that this is what will produce the fee
> market,
> > which is back to an economic discussion - not a technology scaling
> > discussion.
> >
> > On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> > but allow meaningful relief to transaction volume pressure in response
> >> > to true market demand
> >>
> >> If blocksize can only increase then it's like a market that only goes
> >> up which is unrealistic. Transaction will volume ebb and flow
> >> significantly. Some people have been looking at transaction volume
> >> charts over time and all they can see is an exponential curve which
> >> they think will go on forever, yet nothing goes up forever and it will
> >> go through significant trend cycles (like everything does). If you
> >> dont want to hurt the fee market, the blocksize has to be elastic and
> >> allow contraction as well as expansion.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

[-- Attachment #2: Type: text/html, Size: 3408 bytes --]

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez]

[-- Attachment #1: Type: text/plain, Size: 3656 bytes --]

>
> The maximum block-size is one that can be filled at zero-cost by
> miners, and so allows some kinds of amplification of selfish-mining
> related attacks


A selfish mining attack would have to be performed for at least 2000 blocks
over a period of 4 weeks in order to achieve a meager 10% increase in the
block size.

If there goal is to simply drive up fees to gain acceptance into the block,
we're in exactly the same position we are in today (as in nothing stops a
miner from doing this).
If the goal is to increase the block size to push out smaller miners,
they'll have to perform this attack over the course of years and destroy
any economic incentives they have for mining in the first place.

 why give this power up to a subsection of the ecosystem in order to make
> it easier to change or game


Well this same could be said for developers trying to predict what the
appropriate block size should be over the next 20 years... it's a hallmark
to a group of bankers trying to predict the appropriate interest rate for
the entire economy. Just as it is impossible to predict the appropriate
hash rate to secure the network, so it goes for the block size. Both need
to adjust dynamically to the scale/adoption of the network.

On Tue, Sep 8, 2015 at 11:13 PM, Adam Back <adam@cypherspace.org> wrote:

> The maximum block-size is one that can be filled at zero-cost by
> miners, and so allows some kinds of amplification of selfish-mining
> related attacks.
>
> Adam
>
>
> On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > This is true, but miners already control block size through soft caps.
> > Miners are fully capable of producing smaller blocks regardless of the
> max
> > block limit, with or without collusion. Arguably, there is no need to
> ever
> > reduce the max block size unless technology advances for some reason
> reverse
> > course - aka, WW3 takes a toll on the internet and the average bandwidth
> > available halves. The likelihood of significant technology contraction in
> > the near future seems rather unlikely and is more broadly problematic for
> > society than bitcoin specifically.
> >
> > The only reason for reducing the max block limit other than technology
> > availability is if you think that this is what will produce the fee
> market,
> > which is back to an economic discussion - not a technology scaling
> > discussion.
> >
> > On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> > but allow meaningful relief to transaction volume pressure in response
> >> > to true market demand
> >>
> >> If blocksize can only increase then it's like a market that only goes
> >> up which is unrealistic. Transaction will volume ebb and flow
> >> significantly. Some people have been looking at transaction volume
> >> charts over time and all they can see is an exponential curve which
> >> they think will go on forever, yet nothing goes up forever and it will
> >> go through significant trend cycles (like everything does). If you
> >> dont want to hurt the fee market, the blocksize has to be elastic and
> >> allow contraction as well as expansion.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>



-- 
-------------------------------------------
*Dr Washington Y. Sanchez <http://onename.com/drwasho>*
Co-founder, OB1 <http://ob1.io>
Core developer of OpenBazaar <https://openbazaar.org>
@drwasho <https://twitter.com/drwasho>

[-- Attachment #2: Type: text/html, Size: 5596 bytes --]

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Adam Back]

> A selfish mining attack would have to be performed for at least 2000 blocks over a period of 4 weeks in order to achieve a meager 10% increase in the block size.

You seem to be analysing a different attack - I mean that if someone
has enough hashrate to do a selfish mining attack, then setting up a
system that has no means to reduce block-size risks that at a point
where there is excess block-size they can use that free transaction
space to amplify selfish mining instead of collecting transaction
fees.

Adam

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

1) It's not really clear to me how that would work, but assuming it does
then it will go into a basket of attacks that are possible but unlikely due
to the economic disincentives to do so.

2) That said, is the Achilles heal of this proposal the lack of a mechanism
to lower the block size?

3) Let me put it another way, I've read that both Gavin and yourself are
favorable to a dynamic limit on the block size. In your view, what is
missing from this proposal, or what variables should be adjusted, to get
the rules to a place where you and other Core developers would seriously
consider it?

On Wed, Sep 9, 2015 at 12:18 AM, Adam Back <adam@cypherspace.org> wrote:

> > A selfish mining attack would have to be performed for at least 2000
> blocks over a period of 4 weeks in order to achieve a meager 10% increase
> in the block size.
>
> You seem to be analysing a different attack - I mean that if someone
> has enough hashrate to do a selfish mining attack, then setting up a
> system that has no means to reduce block-size risks that at a point
> where there is excess block-size they can use that free transaction
> space to amplify selfish mining instead of collecting transaction
> fees.
>
> Adam
>



-- 
-------------------------------------------
*Dr Washington Y. Sanchez <http://onename.com/drwasho>*
Co-founder, OB1 <http://ob1.io>
Core developer of OpenBazaar <https://openbazaar.org>
@drwasho <https://twitter.com/drwasho>

[-- Attachment #2: Type: text/html, Size: 2232 bytes --]

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Andrew Johnson]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

I rather like this idea, I like that we're taking block scaling back to a
technical method rather than political.  BIP100 is frightening to me as it
gives a disproportionate amount of power to the miners, who can already
control their own blocksize with a soft cap.  It also seems silly to worry
about a selfish mining attack if you're going to institute a miner vote
that an entity with that much hashrate can noticeably influence anyway.

101 is better but is still attempting to make a guess as to technological
progression quite far into the future.  And then when we do finally hit 8GB
we will need yet another hard fork if we need to go bigger(or we may need
to do it earlier if the increase schedule isn't aggressive enough).  And
who knows how large the ecosystem may be at that time, a hard fork may be
an undertaking of truly epic proportions due to the sheer number of devices
and embedded firmware that operates on the block chain.

I've done no math on this(posting from mobile) but something similar to
this would be reasonable, I think.  Unbounded growth, as Adam points out,
is also undesirable.

Every 4032 blocks (~4 weeks), the maximum block size will be decreased by
10% *IF* a minimum of 2500 blocks has a size <= 40% of the maximum block
size at that time.

This requires a larger threshold to be crossed to move downwards, that way
we hopefully aren't oscillating back and forth constantly.  I'll try to do
some blockchain research sometime this week and either back my plucked from
the air numbers or change them.

Andrew Johnson
On Sep 8, 2015 10:11 AM, "Washington Sanchez via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> 1) It's not really clear to me how that would work, but assuming it does
> then it will go into a basket of attacks that are possible but unlikely due
> to the economic disincentives to do so.
>
> 2) That said, is the Achilles heal of this proposal the lack of a
> mechanism to lower the block size?
>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
> consider it?
>
> On Wed, Sep 9, 2015 at 12:18 AM, Adam Back <adam@cypherspace.org> wrote:
>
>> > A selfish mining attack would have to be performed for at least 2000
>> blocks over a period of 4 weeks in order to achieve a meager 10% increase
>> in the block size.
>>
>> You seem to be analysing a different attack - I mean that if someone
>> has enough hashrate to do a selfish mining attack, then setting up a
>> system that has no means to reduce block-size risks that at a point
>> where there is excess block-size they can use that free transaction
>> space to amplify selfish mining instead of collecting transaction
>> fees.
>>
>> Adam
>>
>
>
>
> --
> -------------------------------------------
> *Dr Washington Y. Sanchez <http://onename.com/drwasho>*
> Co-founder, OB1 <http://ob1.io>
> Core developer of OpenBazaar <https://openbazaar.org>
> @drwasho <https://twitter.com/drwasho>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4600 bytes --]

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
> consider it?
>

I'm not clear on what problem(s) you're trying to solve.

If you want blocks to be at least 60% full, then just specify a simple rule
like "maximum block size is 1.0/0.6 = 1.666 times the average block size
over the last N blocks (applied at every block or every 2016 blocks or
whatever, details don't really matter)".

If you want an upper limit on growth, then just implement a simple rule
like "Absolute maximum block size is 1 megabyte in 2016, 3.45 megabytes in
2017, and increases by a maximum of 3.45 times every year."

If you want me to take your proposal seriously, you need to justify why 60%
full is a good answer (and why we need a centralized decision on how full
blocks "should" be), and why 3.45 times-per-year is a good answer for
maximum growth (and, again, why we need a centralized decision on that).

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1605 bytes --]

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez]

[-- Attachment #1: Type: text/plain, Size: 4701 bytes --]

>
> If you want me to take your proposal seriously, you need to justify why
> 60% full is a good answer
>

Sure thing Gavin.

If you want blocks to be at least 60% full...


First off, I do not want blocks to be at least 60% full, so let me try and
explain where I got this number from

   - The idea of this parameter is set a *triggering level* for an increase
   in the block size
   - The triggering level is the point where a reasonable medium-term trend
   can be observed. That trend is an increase in the transaction volume that,
   left unchecked, would fill up blocks.
   - Determining the appropriate triggering level is difficult, and it
   consists of 3 parameters:
      1. Evaluation period
         - *Period of time where you check to see if the conditions to
         trigger a raise the block size are true *
         - Ideally you want an increase to occur in response to a real
         increase of transaction volume from the market, and not some
short term
         spam attack.
         - Too short, spam attacks can be used to trigger multiple
         increases (at least early on). Too long, the block size
doesn't increase
         fast enough to transaction demand.
         - I selected a period of *4032 blocks*
         2. Capacity
         - *The capacity level that a majority of blocks would demonstrate
         in order to trigger a block size increase*
         - The capacity level, in tandem with the evaluation period and
         threshold level, needs to reflect an underlying trend towards filling
         blocks.
         - If the capacity level is too low, block size increases can be
         triggered prematurely. If the capacity level is too high, the
network could
         be unnecessarily jammed with the transactions before an
increase can kick
         in.
         - I selected a capacity level of *60%*.
      3. Threshold
         - *The number of blocks during the evaluation period that are
         above the capacity level in order to trigger a block size increase.*
         - If blocks are getting larger than 60% over a 4032 block period,
         how many reflect a market-driven increase transaction volume?
         - If the threshold is too low, increases could be triggered
         artificially or prematurely. If the threshold is too high,
the easier it
         gets for 1-2 mining pools to prevent any increases in the
block size or the
         block size doesn't respond fast enough to a real increase in
transaction
         volume.
         - I selected a threshold of *2000 blocks or ~50%*.
      - So in my proposal, if 2000+ nodes have a block size >= 60%, this is
   an indication that real transaction volume has increased and we're
   approaching a time where block could be filled to capacity without an
   increase. The block size increase, 10%, is triggered.

A centralized decision, presumably by Satoshi, was made on the parameters
that alter the target difficulty, rather than attempt to forecast hash
rates based on his CPU power. He allowed the system to scale to a level
where real market demand would take it. I believe the same approach should
be replicated for the block size. The trick of course is settling on the
right variables. I hope this proposal is a good way to do that.

*Some additional calculations*

Block sizes for each year are *theoretical maximums* if ALL trigger points
are activated in my proposal (unlikely, but anyway).
These calculations assume zero transactions are taken off-chain by third
party processors or the LN, and no efficiency improvements.

   - 2015
      - 1 MB/block
      - 2 tps (conservative factor, also carried on below)
      - 0.17 million tx/day
   - 2016
      - 3.45 MB/block
      - 7 tps
      - 0.6 million tx/day
   - 2017
      - 12 MB/block
      - 24 tps
      - 2 million tx/day
   - 2018
      - 41 MB/block
      - 82 tps
      - 7 million tx/day
   - 2019
      - 142 MB/block
      - 284 tps
      - 25 million tx/day
   - 2020
      - 490 MB/block
      - 980 tps
      - 85 million tx/day

By way of comparison, Alipay (payment processor for the Alibaba Group's
ecosystem) processes 30 million escrow transactions per day. This gives us
at least 4-5 years to reach the present day transaction processing capacity
of 1 corporation... in reality it will take a little longer as I doubt all
block size triggers will be activated. This also gives us at least 4-5
years to develop efficiency improvements within the protocol, develop the
LN to take many of these transactions off-chain, and network infrastructure
to be significantly improved (and anything else this ecosystem can come up
with).

(let me know if any of these calculations are off)

[-- Attachment #2: Type: text/html, Size: 5327 bytes --]

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez]

[-- Attachment #1: Type: text/plain, Size: 5559 bytes --]

Errata + clarity (in bold):
>
>
>    - So in my proposal, if 2000+ *blocks *have a size >= 60% *of the
>    current limit*, this is an indication that real transaction volume has
>    increased and we're approaching a time where block could be filled to
>    capacity without an increase. The block size increase, 10%, is triggered.
>
>
On Wed, Sep 9, 2015 at 9:11 AM, Washington Sanchez <
washington.sanchez@gmail.com> wrote:

> If you want me to take your proposal seriously, you need to justify why
>> 60% full is a good answer
>>
>
> Sure thing Gavin.
>
> If you want blocks to be at least 60% full...
>
>
> First off, I do not want blocks to be at least 60% full, so let me try and
> explain where I got this number from
>
>    - The idea of this parameter is set a *triggering level* for an
>    increase in the block size
>    - The triggering level is the point where a reasonable medium-term
>    trend can be observed. That trend is an increase in the transaction volume
>    that, left unchecked, would fill up blocks.
>    - Determining the appropriate triggering level is difficult, and it
>    consists of 3 parameters:
>       1. Evaluation period
>          - *Period of time where you check to see if the conditions to
>          trigger a raise the block size are true *
>          - Ideally you want an increase to occur in response to a real
>          increase of transaction volume from the market, and not some short term
>          spam attack.
>          - Too short, spam attacks can be used to trigger multiple
>          increases (at least early on). Too long, the block size doesn't increase
>          fast enough to transaction demand.
>          - I selected a period of *4032 blocks*
>          2. Capacity
>          - *The capacity level that a majority of blocks
>          would demonstrate in order to trigger a block size increase*
>          - The capacity level, in tandem with the evaluation period and
>          threshold level, needs to reflect an underlying trend towards filling
>          blocks.
>          - If the capacity level is too low, block size increases can be
>          triggered prematurely. If the capacity level is too high, the network could
>          be unnecessarily jammed with the transactions before an increase can kick
>          in.
>          - I selected a capacity level of *60%*.
>       3. Threshold
>          - *The number of blocks during the evaluation period that are
>          above the capacity level in order to trigger a block size increase.*
>          - If blocks are getting larger than 60% over a 4032 block
>          period, how many reflect a market-driven increase transaction volume?
>          - If the threshold is too low, increases could be triggered
>          artificially or prematurely. If the threshold is too high, the easier it
>          gets for 1-2 mining pools to prevent any increases in the block size or the
>          block size doesn't respond fast enough to a real increase in transaction
>          volume.
>          - I selected a threshold of *2000 blocks or ~50%*.
>       - So in my proposal, if 2000+ nodes have a block size >= 60%, this
>    is an indication that real transaction volume has increased and we're
>    approaching a time where block could be filled to capacity without an
>    increase. The block size increase, 10%, is triggered.
>
> A centralized decision, presumably by Satoshi, was made on the parameters
> that alter the target difficulty, rather than attempt to forecast hash
> rates based on his CPU power. He allowed the system to scale to a level
> where real market demand would take it. I believe the same approach should
> be replicated for the block size. The trick of course is settling on the
> right variables. I hope this proposal is a good way to do that.
>
> *Some additional calculations*
>
> Block sizes for each year are *theoretical maximums* if ALL trigger
> points are activated in my proposal (unlikely, but anyway).
> These calculations assume zero transactions are taken off-chain by third
> party processors or the LN, and no efficiency improvements.
>
>    - 2015
>       - 1 MB/block
>       - 2 tps (conservative factor, also carried on below)
>       - 0.17 million tx/day
>    - 2016
>       - 3.45 MB/block
>       - 7 tps
>       - 0.6 million tx/day
>    - 2017
>       - 12 MB/block
>       - 24 tps
>       - 2 million tx/day
>    - 2018
>       - 41 MB/block
>       - 82 tps
>       - 7 million tx/day
>    - 2019
>       - 142 MB/block
>       - 284 tps
>       - 25 million tx/day
>    - 2020
>       - 490 MB/block
>       - 980 tps
>       - 85 million tx/day
>
> By way of comparison, Alipay (payment processor for the Alibaba Group's
> ecosystem) processes 30 million escrow transactions per day. This gives us
> at least 4-5 years to reach the present day transaction processing capacity
> of 1 corporation... in reality it will take a little longer as I doubt all
> block size triggers will be activated. This also gives us at least 4-5
> years to develop efficiency improvements within the protocol, develop the
> LN to take many of these transactions off-chain, and network infrastructure
> to be significantly improved (and anything else this ecosystem can come up
> with).
>
> (let me know if any of these calculations are off)
>
>


-- 
-------------------------------------------
*Dr Washington Y. Sanchez <http://onename.com/drwasho>*
Co-founder, OB1 <http://ob1.io>
Core developer of OpenBazaar <https://openbazaar.org>
@drwasho <https://twitter.com/drwasho>

[-- Attachment #2: Type: text/html, Size: 6856 bytes --]