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 --]
prev parent 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 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$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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