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 92503905 for ; Tue, 10 Jan 2017 04:27:56 +0000 (UTC) X-Greylist: delayed 00:12:56 by SQLgrey-1.7.6 Received: from outgoing.millersville.edu (outgoing.millersville.edu [166.66.86.75]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E07E9142 for ; Tue, 10 Jan 2017 04:27:55 +0000 (UTC) X-ASG-Debug-ID: 1484021696-0793ff17814fbd0001-D3WCip Received: from HUBCAS2.muad.local (outlook.muad.local [166.66.87.94]) by outgoing.millersville.edu with ESMTP id UjVzAy4G7tdbc7zW for ; Mon, 09 Jan 2017 23:14:56 -0500 (EST) X-Barracuda-Envelope-From: rjmarti2@millersville.edu X-Barracuda-Effective-Source-IP: outlook.muad.local[166.66.87.94] X-Barracuda-Apparent-Source-IP: 166.66.87.94 Received: from STUDMAIL1.muad.local ([2002:a642:56b8::a642:56b8]) by HUBCAS2.muad.local ([2002:a642:575e::a642:575e]) with mapi id 14.03.0301.000; Mon, 9 Jan 2017 23:14:55 -0500 From: Ryan J Martin To: "bitcoin-dev@lists.linuxfoundation.org" Thread-Topic: BIP - Block75 - Historical and future projections (t. khan) X-ASG-Orig-Subj: re: BIP - Block75 - Historical and future projections (t. khan) Thread-Index: AQHSau1Mc14p5vsaYEm3Tnr0rjlsgQ== Date: Tue, 10 Jan 2017 04:14:55 +0000 Message-ID: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.207.55.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: outlook.muad.local[166.66.87.94] X-Barracuda-Start-Time: 1484021696 X-Barracuda-URL: https://166.66.86.75:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 4122 X-Virus-Scanned: by bsmtpd at millersville.edu X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=4.5 KILL_LEVEL=1000.0 tests=INFO_TLD, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35668 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 INFO_TLD URI: Contains an URL in the INFO top-level domain 0.00 MAILTO_TO_SPAM_ADDR Includes a link to a likely spammer email X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 10 Jan 2017 06:45:12 +0000 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 04:27:56 -0000 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. Ho= wever my concern with something like that is that it doesn't regard the opt= imal economic equilibrium for tx fees/size---not that the current limit doe= s either but the concern with an auto-adjusting size limit that ignores thi= s would be the potential to create unforeseen externalities for miners/use= rs. Miners may decide it is more profitable to mine very small blocks to co= nstrict supply and increase marginal fees and with how centralized mining i= s, 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 min= ers would have minrelaytxfee set at zero and users would push the blocks to= larger and larger sizes causing higher and higher latency and network issu= es. =0A= Perhaps something like this could work (I can only speak to the economi= c side anyway) but it would have to have some solid code that has a social = benefit model built in to adjust to an equilibrium that is able to optimize= ---as in maximizes benefit/minimize cost for both sides via a Marshallian s= urplus model--- for each size point. =0A= To be clear, I'm not saying an auto-adjusting limit is unworkable (aga= in only from an economic standpoint), just that it would need to have these= considerations built in. =0A= =0A= -Ryan J. Martin=0A= =0A= =0A= ________________________________________=0A= =0A= ------------------------------=0A= =0A= Message: 2=0A= Date: Mon, 9 Jan 2017 14:52:31 -0500=0A= From: "t. khan" =0A= To: Bitcoin Protocol Discussion=0A= =0A= Subject: [bitcoin-dev] BIP - Block75 - Historical and future=0A= projections=0A= Message-ID:=0A= =0A= Content-Type: text/plain; charset=3D"utf-8"=0A= =0A= Using daily average block size over the past year (source:=0A= https://blockchain.info/charts/avg-block-size?daysAverageString=3D14×p= an=3D1year=0A= ), here's how Block75 would have altered max block sizes:=0A= =0A= [image: Inline image 1]=0A= =0A= As of today, the max block size would be 1,135KB.=0A= =0A= Looking forward and using the last year's growth rate as a model:=0A= =0A= [image: Inline image 2]=0A= =0A= This shows the max block size one year from now would be 2,064KB, if=0A= Block75 activated today.=0A= =0A= Of course, this is just an estimate, but even accounting for a substantial= =0A= increase in transactions in the last quarter of 2017 and changes brought=0A= about by SegWit (hopefully) activating, Block75 alters the max size in such= =0A= a way that allows for growth, keeps blocks as small as possible, *and*=0A= maintains transaction fees at a level similar to May/June 2016.=0A= =0A= If anyone has an alternate way to model future behavior, please run it=0A= through the Block75 algorithm.=0A= =0A= Every 2016 blocks, do this:=0A= =0A= new max blocksize =3D x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY))=0A= =0A= TARGET_CAPACITY =3D 0.75 //Block75's target of keeping blocks 75% full= =0A= AVERAGE_CAPACITY =3D average percentage full of the last 2016 blocks, as a= =0A= decimal=0A= x =3D current max block size=0A= =0A= =0A= Thanks,=0A= =0A= - t.k.=0A= -------------- next part --------------=0A= An HTML attachment was scrubbed...=0A= URL: =0A= -------------- next part --------------=0A= A non-text attachment was scrubbed...=0A= Name: Block75 2016.png=0A= Type: image/png=0A= Size: 32088 bytes=0A= Desc: not available=0A= URL: =0A= -------------- next part --------------=0A= A non-text attachment was scrubbed...=0A= Name: Block75 2017.png=0A= Type: image/png=0A= Size: 33176 bytes=0A= Desc: not available=0A= URL: =0A= =0A= ------------------------------=0A= =0A= _______________________________________________=0A= bitcoin-dev mailing list=0A= bitcoin-dev@lists.linuxfoundation.org=0A= https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=0A= =0A= =0A= End of bitcoin-dev Digest, Vol 20, Issue 21=0A= *******************************************=0A=