MIME-Version: 1.0
In-Reply-To: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local>
References: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local>
From: Adam Back <adam@cypherspace.org>
Date: Tue, 10 Jan 2017 10:04:27 +0000
Message-ID: <CALqxMTGuSes78WybU7Q_fnPKynEoFCqp_A1vX1xYEq92tg6Qpg@mail.gmail.com>
To: Ryan J Martin <rjmarti2@millersville.edu>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] BIP - Block75 - Historical and future projections
 (t. khan)
Precedence: list

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
<bitcoin-dev@lists.linuxfoundation.org> 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" <teekhan42@gmail.com>
> To: Bitcoin Protocol Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: [bitcoin-dev] BIP - Block75 - Historical and future
>         projections
> Message-ID:
>         <CAGCNRJpSV9zKxhVvqpMVPyFyXco_ABB9a7_ihaDKEKFPQ9v3sw@mail.gmail.c=
om>
> 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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20170109/b0e0b713/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Block75 2016.png
> Type: image/png
> Size: 32088 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20170109/b0e0b713/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Block75 2017.png
> Type: image/png
> Size: 33176 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20170109/b0e0b713/attachment-0001.png>
>
> ------------------------------
>
> _______________________________________________
> 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