public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Washington Sanchez <washington.sanchez@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion
Date: Wed, 9 Sep 2015 23:10:43 +1000	[thread overview]
Message-ID: <CAG0bcYybcBADdPs6uUoZjmCcPzpjduyv6znSaTD-cJeLA78n1Q@mail.gmail.com> (raw)
In-Reply-To: <CAG0bcYyQT-B6xoL3DpLQgvZfkqrmbajscFgywPhUsPF71XwVBA@mail.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 --]

      reply	other threads:[~2015-09-09 13:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08  7:45 [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion Washington Sanchez
2015-09-08  8:49 ` Btc Drak
2015-09-08 12:28   ` Ivan Brightly
2015-09-08 13:13     ` Adam Back
2015-09-08 13:52       ` Ivan Brightly
2015-09-08 14:02       ` Washington Sanchez
2015-09-08 14:18         ` Adam Back
2015-09-08 15:10           ` Washington Sanchez
2015-09-08 16:46             ` Andrew Johnson
2015-09-08 17:04             ` Gavin Andresen
2015-09-08 23:11               ` Washington Sanchez
2015-09-09 13:10                 ` Washington Sanchez [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAG0bcYybcBADdPs6uUoZjmCcPzpjduyv6znSaTD-cJeLA78n1Q@mail.gmail.com \
    --to=washington.sanchez@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox