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 09:11:49 +1000 [thread overview]
Message-ID: <CAG0bcYyQT-B6xoL3DpLQgvZfkqrmbajscFgywPhUsPF71XwVBA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T1a5kbtw=SQrdXyp32LF7gA9LMShPMYEefP4arb6SQcHw@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2015-09-08 23:11 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 [this message]
2015-09-09 13:10 ` Washington Sanchez
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=CAG0bcYyQT-B6xoL3DpLQgvZfkqrmbajscFgywPhUsPF71XwVBA@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