/ 56 / 74041a6827125d7f90fdf8d3125051b369c2d3
74041a6827125d7f90fdf8d3125051b369c2d3
  1  Return-Path: <adam@cypherspace.org>
  2  Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
  3  	[172.17.192.35])
  4  	by mail.linuxfoundation.org (Postfix) with ESMTPS id AB84F898
  5  	for <bitcoin-dev@lists.linuxfoundation.org>;
  6  	Tue, 10 Jan 2017 10:04:30 +0000 (UTC)
  7  X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
  8  Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
  9  	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F862110
 10  	for <bitcoin-dev@lists.linuxfoundation.org>;
 11  	Tue, 10 Jan 2017 10:04:29 +0000 (UTC)
 12  Received: from mail-qt0-f179.google.com ([209.85.216.179]) by
 13  	mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id
 14  	0Lbaph-1cu9QN3GEV-00lDiW for <bitcoin-dev@lists.linuxfoundation.org>;
 15  	Tue, 10 Jan 2017 11:04:28 +0100
 16  Received: by mail-qt0-f179.google.com with SMTP id v23so160628430qtb.0
 17  	for <bitcoin-dev@lists.linuxfoundation.org>;
 18  	Tue, 10 Jan 2017 02:04:28 -0800 (PST)
 19  X-Gm-Message-State: AIkVDXKjq1xhCUS/7vRl/Etn/i+YLwKhpfl8U97B6qxNywj+Q+cNqlooO8Ed4L1kPAiOSqqf8TJxyFjZvTbzBA==
 20  X-Received: by 10.237.45.195 with SMTP id i61mr1802187qtd.122.1484042667784;
 21  	Tue, 10 Jan 2017 02:04:27 -0800 (PST)
 22  MIME-Version: 1.0
 23  Received: by 10.12.144.130 with HTTP; Tue, 10 Jan 2017 02:04:27 -0800 (PST)
 24  In-Reply-To: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local>
 25  References: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local>
 26  From: Adam Back <adam@cypherspace.org>
 27  Date: Tue, 10 Jan 2017 10:04:27 +0000
 28  X-Gmail-Original-Message-ID: <CALqxMTGuSes78WybU7Q_fnPKynEoFCqp_A1vX1xYEq92tg6Qpg@mail.gmail.com>
 29  Message-ID: <CALqxMTGuSes78WybU7Q_fnPKynEoFCqp_A1vX1xYEq92tg6Qpg@mail.gmail.com>
 30  To: Ryan J Martin <rjmarti2@millersville.edu>, 
 31  	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
 32  Content-Type: text/plain; charset=UTF-8
 33  Content-Transfer-Encoding: quoted-printable
 34  X-Provags-ID: V03:K0:U0LzP+HJsXe58v6nSKf0DeMYgX3nJ+j+1GyNISs1PwjdwkfC8BC
 35  	4xXCsbBVVRycm0Cp013FyE7/Maa4uyWIMiTUngDR6/JRNBD7FB/PJH/+pP3uuFrRUDkWn4D
 36  	BOcrVO2SFFCQnHCsPpsUT6yTQZt2YfbPvFNaz890oRHqdBMgr8RRb+gMuqWUYtyWM0rbgZ5
 37  	BX+I3tfGYN80eWKjlc99w==
 38  X-UI-Out-Filterresults: notjunk:1;V01:K0:dZ9j7WnlwX0=:rtSnydXOmFTqtCNvICfjHI
 39  	j97+nx2YclnpIgUXKpvyt/s7SOn3qflKY5QHvUqBXsdY4p01BK8rFvuBSZcYuI64KzuFOMl6z
 40  	CgZcxChy2SqXpgUKc/ex1uBC4U7HwhBe2W7TQ+DhnvusnxqXR0Ecf5MHkDod5SFqeqHOJgE5/
 41  	FcWTiGfwg0uXDB9fG8EXqDKCy0hSRxfBa/SQRXdT5G3dri4NZU1NBTih6lXGi16N1qR9q+xi2
 42  	Y2lNVsATJPEyZtqw+yTRFMwuvv3n4u6RF1WxbNyaj/roU3zSTf1kV8rLd3U9DLqCpgfWQYKCX
 43  	Y+eCQcnPa1meyahnlznRUiW6IMwsfKC9odSQPTBeyXqdipqxUZtbSovtwHP6GT+m+620eF8PX
 44  	y9sP1XQpvz+0SRMlrlLMeT/2nfKC58ZjqAO1gYu84PYJCRtep+eeuk2Zl22GKzo8DV1oJgPKk
 45  	U1jeTZosBxTvg0/2jAo6hY/S4lzhRJI9GRY3U663tAunzXeYcIRwv+DydKihxsDAZpE158WF8
 46  	sHAwa6hsabHOL6wl4G0QsaJLb+skzk9oG8wMYpwJk83kV8UZTrWHbMqvE5LBis74C5yhgF6Y7
 47  	gaXgGoVDXXWS6qxo9H/a9k9fvNh4j9ecsi5y05i4vPsNrrih1SwXVjQpCuniFjvVFsynJojXL
 48  	USgTDFqipdXz9dS552I7piV34Ze33Hxpd74lOzuXbncaYOko8ra1UDWaKoehztNMpuy/WaFDW
 49  	/hgcWqN1bXr1CspV
 50  X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, 
 51  	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
 52  X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
 53  	smtp1.linux-foundation.org
 54  Subject: Re: [bitcoin-dev] BIP - Block75 - Historical and future projections
 55   (t. khan)
 56  X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
 57  X-Mailman-Version: 2.1.12
 58  Precedence: list
 59  List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
 60  List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
 61  	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
 62  List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
 63  List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
 64  List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
 65  List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
 66  	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
 67  X-List-Received-Date: Tue, 10 Jan 2017 10:04:30 -0000
 68  
 69  See discussion on bitcoin-discuss on this topic last few days.  People
 70  may want to subscribe to that for more free wheeling discussion.
 71  
 72  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
 73  
 74  Adam
 75  
 76  On 10 January 2017 at 04:14, Ryan J Martin via bitcoin-dev
 77  <bitcoin-dev@lists.linuxfoundation.org> wrote:
 78  >      The adaptive/automatic block size notion has been around for a while=
 79  --- others would be better able to speak to why it hasn't gotten traction. =
 80  However my concern with something like that is that it doesn't regard the o=
 81  ptimal economic equilibrium for tx fees/size---not that the current limit d=
 82  oes either but the concern with an auto-adjusting size limit that ignores t=
 83  his  would be the potential to create unforeseen externalities for miners/u=
 84  sers. Miners may decide it is more profitable to mine very small blocks to =
 85  constrict supply and increase marginal fees and with how centralized mining=
 86   is, where a dozen pools have 85% hashrate, a couple of pools could do this=
 87  . Then on the other side, maybe the prisoner's dilemma would hold and all m=
 88  iners would have minrelaytxfee set at zero and users would push the blocks =
 89  to larger and larger sizes causing higher and higher latency and network is=
 90  sues.
 91  >     Perhaps something like this could work (I can only speak to the econo=
 92  mic side anyway) but it would have to have some solid code that has a socia=
 93  l benefit model built in to adjust to an equilibrium that is able to optimi=
 94  ze---as in maximizes benefit/minimize cost for both sides via a Marshallian=
 95   surplus model--- for each size point.
 96  >      To be clear, I'm not saying an auto-adjusting limit is unworkable (a=
 97  gain only from an economic standpoint), just that it would need to have the=
 98  se considerations built in.
 99  >
100  > -Ryan J. Martin
101  >
102  >
103  > ________________________________________
104  >
105  > ------------------------------
106  >
107  > Message: 2
108  > Date: Mon, 9 Jan 2017 14:52:31 -0500
109  > From: "t. khan" <teekhan42@gmail.com>
110  > To: Bitcoin Protocol Discussion
111  >         <bitcoin-dev@lists.linuxfoundation.org>
112  > Subject: [bitcoin-dev] BIP - Block75 - Historical and future
113  >         projections
114  > Message-ID:
115  >         <CAGCNRJpSV9zKxhVvqpMVPyFyXco_ABB9a7_ihaDKEKFPQ9v3sw@mail.gmail.c=
116  om>
117  > Content-Type: text/plain; charset=3D"utf-8"
118  >
119  > Using daily average block size over the past year (source:
120  > https://blockchain.info/charts/avg-block-size?daysAverageString=3D14&time=
121  span=3D1year
122  > ), here's how Block75 would have altered max block sizes:
123  >
124  > [image: Inline image 1]
125  >
126  > As of today, the max block size would be 1,135KB.
127  >
128  > Looking forward and using the last year's growth rate as a model:
129  >
130  > [image: Inline image 2]
131  >
132  > This shows the max block size one year from now would be 2,064KB, if
133  > Block75 activated today.
134  >
135  > Of course, this is just an estimate, but even accounting for a substantia=
136  l
137  > increase in transactions in the last quarter of 2017 and changes brought
138  > about by SegWit (hopefully) activating, Block75 alters the max size in su=
139  ch
140  > a way that allows for growth, keeps blocks as small as possible, *and*
141  > maintains transaction fees at a level similar to May/June 2016.
142  >
143  > If anyone has an alternate way to model future behavior, please run it
144  > through the Block75 algorithm.
145  >
146  > Every 2016 blocks, do this:
147  >
148  > new max blocksize =3D x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY))
149  >
150  > TARGET_CAPACITY =3D 0.75    //Block75's target of keeping blocks 75% full
151  > AVERAGE_CAPACITY =3D average percentage full of the last 2016 blocks, as =
152  a
153  > decimal
154  > x =3D current max block size
155  >
156  >
157  > Thanks,
158  >
159  > - t.k.
160  > -------------- next part --------------
161  > An HTML attachment was scrubbed...
162  > URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
163  20170109/b0e0b713/attachment.html>
164  > -------------- next part --------------
165  > A non-text attachment was scrubbed...
166  > Name: Block75 2016.png
167  > Type: image/png
168  > Size: 32088 bytes
169  > Desc: not available
170  > URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
171  20170109/b0e0b713/attachment.png>
172  > -------------- next part --------------
173  > A non-text attachment was scrubbed...
174  > Name: Block75 2017.png
175  > Type: image/png
176  > Size: 33176 bytes
177  > Desc: not available
178  > URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
179  20170109/b0e0b713/attachment-0001.png>
180  >
181  > ------------------------------
182  >
183  > _______________________________________________
184  > bitcoin-dev mailing list
185  > bitcoin-dev@lists.linuxfoundation.org
186  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
187  >
188  >
189  > End of bitcoin-dev Digest, Vol 20, Issue 21
190  > *******************************************
191  > _______________________________________________
192  > bitcoin-dev mailing list
193  > bitcoin-dev@lists.linuxfoundation.org
194  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
195