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

[Washington Sanchez <washington.sanchez@gmail.com>]

[-- 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 --]