path: root/f0/22e1136938b11e99096e99afad7c4d0ae099ed

Return-Path: <washington.sanchez@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7192A2A00
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Sep 2015 13:10:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
	[209.85.223.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 549E9152
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Sep 2015 13:10:44 +0000 (UTC)
Received: by ioiz6 with SMTP id z6so20975889ioi.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 09 Sep 2015 06:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=6MM+P24xCquL+IqcFUb+UH41Ek/ABR/7gw7sBRTwKFI=;
	b=el7T1LyvN4gi90qDhF5926Wqafzow88w6ZotHa4fYAMRFN8xB1X/bRFgyfMPM6j1ZX
	unVJKDoyE0fzFzy5HV9ZYFTt/VUA1rLF7vkTcbk5n32F8G59yDdnheDs21q9voXcNOy2
	oQBbSrpLMuv5m8TchqFelWdIZDMaX8Q029LyTmPi+AQNHS3H617TISrqYmLHzCZuP4wm
	rT58cMOgxMrh9GWGYt2TwGWmh2KNtVj48dVQt0AfbBFiEAe92HJUe54T0TSm8xbKqUOc
	mQ97CMhgQYApblI0oxQ6wc+ghfSPA8OhyzVyk2o7acPPqQQSC0Rm6qyiITiTiPGEfkLz
	29Wg==
MIME-Version: 1.0
X-Received: by 10.107.165.140 with SMTP id o134mr18724894ioe.29.1441804243587; 
	Wed, 09 Sep 2015 06:10:43 -0700 (PDT)
Received: by 10.107.178.12 with HTTP; Wed, 9 Sep 2015 06:10:43 -0700 (PDT)
In-Reply-To: <CAG0bcYyQT-B6xoL3DpLQgvZfkqrmbajscFgywPhUsPF71XwVBA@mail.gmail.com>
References: <CAG0bcYzzg4yeQvd27PZu5Fqv1ULS3cKeQHaRZ2zPcM3OASw1cg@mail.gmail.com>
	<CADJgMztJx1cBFhNOwMgBHJGPmBNPqsTdQbCCjFBmDBSBfTMMUg@mail.gmail.com>
	<CAAre=yRawFU_WMdE+ReemscYD33ez1PF6VhU2FmWo2fAEcw_Xw@mail.gmail.com>
	<CALqxMTERUFEFgJ4quz2dWLRw9fD3DkBp-6RO4cuvdBGV2MSyhw@mail.gmail.com>
	<CAG0bcYzBCsg9xNLGmu4S=PEPjtbd2iBLH52ryswbkRM23OqquA@mail.gmail.com>
	<CALqxMTFQhFusR5jkEMvRdxDVLZPzWSW5hUHpXoON-K-+xJjpNA@mail.gmail.com>
	<CAG0bcYw=k_z82buUQ_kApmPgSenNy6FEsdXotLaS4Gn-kZbrKg@mail.gmail.com>
	<CABsx9T1a5kbtw=SQrdXyp32LF7gA9LMShPMYEefP4arb6SQcHw@mail.gmail.com>
	<CAG0bcYyQT-B6xoL3DpLQgvZfkqrmbajscFgywPhUsPF71XwVBA@mail.gmail.com>
Date: Wed, 9 Sep 2015 23:10:43 +1000
Message-ID: <CAG0bcYybcBADdPs6uUoZjmCcPzpjduyv6znSaTD-cJeLA78n1Q@mail.gmail.com>
From: Washington Sanchez <washington.sanchez@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1141fb90c66589051f5035d2
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft
	discussion
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2015 18:24:31 -0000

--001a1141fb90c66589051f5035d2
Content-Type: text/plain; charset=UTF-8

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>

--001a1141fb90c66589051f5035d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Errata + clarity (in bold):<blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><ul style=3D"f=
ont-size:12.8px"><li style=3D"margin-left:15px">So in my proposal, if 2000+=
 <b>blocks </b>have a size &gt;=3D 60% <b>of the current limit</b>, this is=
 an indication that real transaction volume has increased and we&#39;re app=
roaching a time where block could be filled to capacity without an increase=
. The block size increase, 10%, is triggered.</li></ul></blockquote></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Sep 9, 201=
5 at 9:11 AM, Washington Sanchez <span dir=3D"ltr">&lt;<a href=3D"mailto:wa=
shington.sanchez@gmail.com" target=3D"_blank">washington.sanchez@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><s=
pan class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><span style=3D"font-size:12.8px">If you wan=
t me to take your proposal seriously, you need to justify why 60% full is a=
 good answer</span><br></blockquote><div><br></div></span>Sure thing Gavin.=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><span style=3D"font-size:12.8px">If you wan=
t blocks to be at least 60% full...</span></blockquote><div><br></div><div>=
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<br><ul><li>The idea of this parameter =
is set a <i>triggering level</i> for an increase in the block size=C2=A0</l=
i><li>The triggering level is the point where a reasonable medium-term tren=
d can be observed. That trend is an increase in the transaction volume that=
, left unchecked, would fill up blocks.</li><li>Determining the appropriate=
 triggering level is difficult, and it consists of 3 parameters:</li><ol><l=
i>Evaluation period</li><ul><li><i>Period of time where you check to see if=
 the conditions to trigger a raise the block size are true=C2=A0</i></li><l=
i>Ideally you want an increase to occur in response to a real increase of t=
ransaction volume from the market, and not some short term spam attack.</li=
><li>Too short, spam attacks can be used to trigger multiple increases (at =
least early on). Too long, the block size doesn&#39;t increase fast enough =
to transaction demand.</li><li>I selected a period of=C2=A0<u>4032 blocks</=
u><br></li></ul><li>Capacity</li><ul><li><i>The capacity level that a major=
ity of blocks would=C2=A0demonstrate in order to trigger a block size incre=
ase</i></li><li>The capacity level, in tandem with the evaluation period an=
d threshold level, needs to reflect an underlying trend towards filling blo=
cks.</li><li>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.</li><li>I selected a capacity level of <u>60%</u>.</li></ul><li>Thresho=
ld</li><ul><li><i>The number of blocks during the evaluation period that ar=
e above the capacity level in order to trigger a block size increase.</i></=
li><li>If blocks are getting larger than 60% over a 4032 block period, how =
many reflect a market-driven increase transaction volume?</li><li>If the th=
reshold is too low, increases could be triggered artificially or prematurel=
y. 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&#39;t resp=
ond fast enough to a real increase in transaction volume.</li><li>I selecte=
d a threshold of <u>2000 blocks or ~50%</u>.</li></ul></ol><li>So in my pro=
posal, if 2000+ nodes have a block size &gt;=3D 60%, this is an indication =
that real transaction volume has increased and we&#39;re approaching a time=
 where block could be filled to capacity without an increase. The block siz=
e increase, 10%, is triggered.</li></ul>A centralized decision, presumably =
by Satoshi, was made on the parameters that alter the target difficulty, ra=
ther 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 b=
elieve 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 go=
od way to do that.<br></div><div><br></div><div><u>Some additional calculat=
ions</u>=C2=A0</div><div><br></div><div>Block sizes for each year are=C2=A0=
<b>theoretical maximums</b> if ALL trigger points are activated in my propo=
sal (unlikely, but anyway).</div><div>These calculations assume zero transa=
ctions are taken off-chain by third party processors or the LN, and no effi=
ciency improvements.</div><div><div><ul><li>2015</li><ul><li>1 MB/block</li=
><li>2 tps (conservative factor, also carried on below)</li><li>0.17 millio=
n tx/day</li></ul><li>2016</li><ul><li>3.45 MB/block</li><li>7 tps</li><li>=
0.6 million tx/day=C2=A0</li></ul><li>2017</li><ul><li>12 MB/block</li><li>=
24 tps</li><li>2 million tx/day=C2=A0</li></ul><li>2018</li><ul><li>41 MB/b=
lock</li><li>82 tps</li><li>7 million tx/day</li></ul><li>2019</li><ul><li>=
142 MB/block</li><li>284 tps</li><li>25 million tx/day</li></ul><li>2020</l=
i><ul><li>490 MB/block</li><li>980 tps</li><li>85 million tx/day</li></ul><=
/ul></div><div>By way of comparison, Alipay (payment processor for the Alib=
aba Group&#39;s ecosystem) processes 30 million escrow transactions per day=
. This gives us at least 4-5 years to reach the present day transaction pro=
cessing capacity of 1 corporation... in reality it will take a little longe=
r 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 in=
frastructure to be significantly improved (and anything else this ecosystem=
 can come up with).</div><div><br></div><div>(let me know if any of these c=
alculations are off)</div><div><br></div></div></div>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div>-----=
--------------------------------------</div><div><b><a href=3D"http://onena=
me.com/drwasho" target=3D"_blank">Dr Washington Y. Sanchez</a></b></div><di=
v>Co-founder, <a href=3D"http://ob1.io" target=3D"_blank">OB1</a></div><div=
>Core developer of <a href=3D"https://openbazaar.org" target=3D"_blank">Ope=
nBazaar</a></div><div><a href=3D"https://twitter.com/drwasho" target=3D"_bl=
ank">@drwasho</a></div></div><div><br></div></div></div></div></div>
</div>

--001a1141fb90c66589051f5035d2--