From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AB84F898 for ; Tue, 10 Jan 2017 10:04:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F862110 for ; Tue, 10 Jan 2017 10:04:29 +0000 (UTC) Received: from mail-qt0-f179.google.com ([209.85.216.179]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lbaph-1cu9QN3GEV-00lDiW for ; Tue, 10 Jan 2017 11:04:28 +0100 Received: by mail-qt0-f179.google.com with SMTP id v23so160628430qtb.0 for ; Tue, 10 Jan 2017 02:04:28 -0800 (PST) X-Gm-Message-State: AIkVDXKjq1xhCUS/7vRl/Etn/i+YLwKhpfl8U97B6qxNywj+Q+cNqlooO8Ed4L1kPAiOSqqf8TJxyFjZvTbzBA== X-Received: by 10.237.45.195 with SMTP id i61mr1802187qtd.122.1484042667784; Tue, 10 Jan 2017 02:04:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.144.130 with HTTP; Tue, 10 Jan 2017 02:04:27 -0800 (PST) In-Reply-To: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local> References: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local> From: Adam Back Date: Tue, 10 Jan 2017 10:04:27 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Ryan J Martin , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:U0LzP+HJsXe58v6nSKf0DeMYgX3nJ+j+1GyNISs1PwjdwkfC8BC 4xXCsbBVVRycm0Cp013FyE7/Maa4uyWIMiTUngDR6/JRNBD7FB/PJH/+pP3uuFrRUDkWn4D BOcrVO2SFFCQnHCsPpsUT6yTQZt2YfbPvFNaz890oRHqdBMgr8RRb+gMuqWUYtyWM0rbgZ5 BX+I3tfGYN80eWKjlc99w== X-UI-Out-Filterresults: notjunk:1;V01:K0:dZ9j7WnlwX0=:rtSnydXOmFTqtCNvICfjHI j97+nx2YclnpIgUXKpvyt/s7SOn3qflKY5QHvUqBXsdY4p01BK8rFvuBSZcYuI64KzuFOMl6z CgZcxChy2SqXpgUKc/ex1uBC4U7HwhBe2W7TQ+DhnvusnxqXR0Ecf5MHkDod5SFqeqHOJgE5/ FcWTiGfwg0uXDB9fG8EXqDKCy0hSRxfBa/SQRXdT5G3dri4NZU1NBTih6lXGi16N1qR9q+xi2 Y2lNVsATJPEyZtqw+yTRFMwuvv3n4u6RF1WxbNyaj/roU3zSTf1kV8rLd3U9DLqCpgfWQYKCX Y+eCQcnPa1meyahnlznRUiW6IMwsfKC9odSQPTBeyXqdipqxUZtbSovtwHP6GT+m+620eF8PX y9sP1XQpvz+0SRMlrlLMeT/2nfKC58ZjqAO1gYu84PYJCRtep+eeuk2Zl22GKzo8DV1oJgPKk U1jeTZosBxTvg0/2jAo6hY/S4lzhRJI9GRY3U663tAunzXeYcIRwv+DydKihxsDAZpE158WF8 sHAwa6hsabHOL6wl4G0QsaJLb+skzk9oG8wMYpwJk83kV8UZTrWHbMqvE5LBis74C5yhgF6Y7 gaXgGoVDXXWS6qxo9H/a9k9fvNh4j9ecsi5y05i4vPsNrrih1SwXVjQpCuniFjvVFsynJojXL USgTDFqipdXz9dS552I7piV34Ze33Hxpd74lOzuXbncaYOko8ra1UDWaKoehztNMpuy/WaFDW /hgcWqN1bXr1CspV X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP - Block75 - Historical and future projections (t. khan) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 10:04:30 -0000 See discussion on bitcoin-discuss on this topic last few days. People may want to subscribe to that for more free wheeling discussion. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss Adam On 10 January 2017 at 04:14, Ryan J Martin via bitcoin-dev wrote: > The adaptive/automatic block size notion has been around for a while= --- others would be better able to speak to why it hasn't gotten traction. = However my concern with something like that is that it doesn't regard the o= ptimal economic equilibrium for tx fees/size---not that the current limit d= oes either but the concern with an auto-adjusting size limit that ignores t= his would be the potential to create unforeseen externalities for miners/u= sers. Miners may decide it is more profitable to mine very small blocks to = constrict supply and increase marginal fees and with how centralized mining= is, where a dozen pools have 85% hashrate, a couple of pools could do this= . Then on the other side, maybe the prisoner's dilemma would hold and all m= iners would have minrelaytxfee set at zero and users would push the blocks = to larger and larger sizes causing higher and higher latency and network is= sues. > Perhaps something like this could work (I can only speak to the econo= mic side anyway) but it would have to have some solid code that has a socia= l benefit model built in to adjust to an equilibrium that is able to optimi= ze---as in maximizes benefit/minimize cost for both sides via a Marshallian= surplus model--- for each size point. > To be clear, I'm not saying an auto-adjusting limit is unworkable (a= gain only from an economic standpoint), just that it would need to have the= se considerations built in. > > -Ryan J. Martin > > > ________________________________________ > > ------------------------------ > > Message: 2 > Date: Mon, 9 Jan 2017 14:52:31 -0500 > From: "t. khan" > To: Bitcoin Protocol Discussion > > Subject: [bitcoin-dev] BIP - Block75 - Historical and future > projections > Message-ID: > > Content-Type: text/plain; charset=3D"utf-8" > > Using daily average block size over the past year (source: > https://blockchain.info/charts/avg-block-size?daysAverageString=3D14&time= span=3D1year > ), here's how Block75 would have altered max block sizes: > > [image: Inline image 1] > > As of today, the max block size would be 1,135KB. > > Looking forward and using the last year's growth rate as a model: > > [image: Inline image 2] > > This shows the max block size one year from now would be 2,064KB, if > Block75 activated today. > > Of course, this is just an estimate, but even accounting for a substantia= l > increase in transactions in the last quarter of 2017 and changes brought > about by SegWit (hopefully) activating, Block75 alters the max size in su= ch > a way that allows for growth, keeps blocks as small as possible, *and* > maintains transaction fees at a level similar to May/June 2016. > > If anyone has an alternate way to model future behavior, please run it > through the Block75 algorithm. > > Every 2016 blocks, do this: > > new max blocksize =3D x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY)) > > TARGET_CAPACITY =3D 0.75 //Block75's target of keeping blocks 75% full > AVERAGE_CAPACITY =3D average percentage full of the last 2016 blocks, as = a > decimal > x =3D current max block size > > > Thanks, > > - t.k. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Block75 2016.png > Type: image/png > Size: 32088 bytes > Desc: not available > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Block75 2017.png > Type: image/png > Size: 33176 bytes > Desc: not available > URL: > > ------------------------------ > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > End of bitcoin-dev Digest, Vol 20, Issue 21 > ******************************************* > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev