From: Ryan J Martin <rjmarti2@millersville.edu>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: 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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [bitcoin-dev] BIP - Block75 - Historical and future projections
	(t. khan)
Precedence: list

     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" <teekhan42@gmail.com>=0A=
To: Bitcoin Protocol Discussion=0A=
        <bitcoin-dev@lists.linuxfoundation.org>=0A=
Subject: [bitcoin-dev] BIP - Block75 - Historical and future=0A=
        projections=0A=
Message-ID:=0A=
        <CAGCNRJpSV9zKxhVvqpMVPyFyXco_ABB9a7_ihaDKEKFPQ9v3sw@mail.gmail.com=
>=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&timesp=
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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20=
170109/b0e0b713/attachment.html>=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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20=
170109/b0e0b713/attachment.png>=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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20=
170109/b0e0b713/attachment-0001.png>=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=