<p dir="ltr">I would support a dynamic block size increase as outlined. I have a few questions though.</p>
<p dir="ltr">Is scaling by average block size the best and easiest method, why not scale by transactions confirmed instead? Anyone can write and relay a transaction, and those are what we want to scale for, why not measure it directly?</p>
<p dir="ltr">I would prefer changes every 2016 blocks, it is a well known change and a reasonable time period for planning on changes. Two weeks is plenty fast, especially at a 50% rate increase, in a few months the block size could be dramatically larger. </p>
<p dir="ltr">Daily change to size seems confusing especially considering that max block size will be dipping up and down. Also if something breaks trying to fix it in a day seems problematic. The hard fork database size difference error comes to mind. Finally daily 50% increases could quickly crowd out smaller nodes if changes happen too quickly to adapt for.<br><br><br><br><br><br></p>
<p dir="ltr">&gt; Date: Thu, 28 May 2015 11:53:41 -0400<br>
&gt; From: Gavin Andresen &lt;<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>&gt;<br>
&gt; Subject: <br>
&gt; To: Matt Whitlock &lt;<a href="mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a>&gt;<br>
&gt; Cc: Bitcoin Dev &lt;<a href="mailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>&gt;<br>
&gt; Message-ID:<br>
&gt;         &lt;<a href="mailto:CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com">CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com</a>&gt;<br>
&gt; Content-Type: text/plain; charset=&quot;utf-8&quot;<br>
&gt;<br>
&gt; On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock &lt;<a href="mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Between all the flames on this list, several ideas were raised that did<br>
&gt; &gt; not get much attention. I hereby resubmit these ideas for consideration and<br>
&gt; &gt; discussion.<br>
&gt; &gt;<br>
&gt; &gt; - Perhaps the hard block size limit should be a function of the actual<br>
&gt; &gt; block sizes over some trailing sampling period. For example, take the<br>
&gt; &gt; median block size among the most recent 2016 blocks and multiply it by 1.5.<br>
&gt; &gt; This allows Bitcoin to scale up gradually and organically, rather than<br>
&gt; &gt; having human beings guessing at what is an appropriate limit.<br>
&gt; &gt;<br>
&gt;<br>
&gt; A lot of people like this idea, or something like it. It is nice and<br>
&gt; simple, which is really important for consensus-critical code.<br>
&gt;<br>
&gt; With this rule in place, I believe there would be more &quot;fee pressure&quot;<br>
&gt; (miners would be creating smaller blocks) today. I created a couple of<br>
&gt; histograms of block sizes to infer what policy miners are ACTUALLY<br>
&gt; following today with respect to block size:<br>
&gt;<br>
&gt; Last 1,000 blocks:<br>
&gt;   <a href="http://bitcoincore.org/~gavin/sizes_last1000.html">http://bitcoincore.org/~gavin/sizes_last1000.html</a><br>
&gt;<br>
&gt; Notice a big spike at 750K -- the default size for Bitcoin Core.<br>
&gt; This graph might be misleading, because transaction volume or fees might<br>
&gt; not be high enough over the last few days to fill blocks to whatever limit<br>
&gt; miners are willing to mine.<br>
&gt;<br>
&gt; So I graphed a time when (according to <a href="http://statoshi.info">statoshi.info</a>) there WERE a lot of<br>
&gt; transactions waiting to be confirmed:<br>
&gt;    <a href="http://bitcoincore.org/~gavin/sizes_357511.html">http://bitcoincore.org/~gavin/sizes_357511.html</a><br>
&gt;<br>
&gt; That might also be misleading, because it is possible there were a lot of<br>
&gt; transactions waiting to be confirmed because miners who choose to create<br>
&gt; small blocks got lucky and found more blocks than normal.  In fact, it<br>
&gt; looks like that is what happened: more smaller-than-normal blocks were<br>
&gt; found, and the memory pool backed up.<br>
&gt;<br>
&gt; So: what if we had a dynamic maximum size limit based on recent history?<br>
&gt;<br>
&gt; The average block size is about 400K, so a 1.5x rule would make the max<br>
&gt; block size 600K; miners would definitely be squeezing out transactions /<br>
&gt; putting pressure to increase transaction fees. Even a 2x rule (implying<br>
&gt; 800K max blocks) would, today, be squeezing out transactions / putting<br>
&gt; pressure to increase fees.<br>
&gt;<br>
&gt; Using a median size instead of an average means the size can increase or<br>
&gt; decrease more quickly. For example, imagine the rule is &quot;median of last<br>
&gt; 2016 blocks&quot; and 49% of miners are producing 0-size blocks and 51% are<br>
&gt; producing max-size blocks. The median is max-size, so the 51% have total<br>
&gt; control over making blocks bigger.  Swap the roles, and the median is<br>
&gt; min-size.<br>
&gt;<br>
&gt; Because of that, I think using an average is better-- it means the max size<br>
&gt; will change (up or down) more slowly.<br>
&gt;<br>
&gt; I also think 2016 blocks is too long, because transaction volumes change<br>
&gt; quicker than that. An average over 144 blocks (last 24 hours) would be<br>
&gt; better able to handle increased transaction volume around major holidays,<br>
&gt; and would also be able to react more quickly if an economically irrational<br>
&gt; attacker attempted to flood the network with fee-paying transactions.<br>
&gt;<br>
&gt; So my straw-man proposal would be:  max size 2x average size over last 144<br>
&gt; blocks, calculated at every block.<br>
&gt;<br>
&gt; There are a couple of other changes I&#39;d pair with that consensus change:<br>
&gt;<br>
&gt; + Make the default mining policy for Bitcoin Core neutral-- have its target<br>
&gt; block size be the average size, so miners that don&#39;t care will &quot;go along<br>
&gt; with the people who do care.&quot;<br>
&gt;<br>
&gt; + Use something like Greg&#39;s formula for size instead of bytes-on-the-wire,<br>
&gt; to discourage bloating the UTXO set.<br>
&gt;<br>
&gt;<br>
&gt; ---------<br>
&gt;<br>
&gt; When I&#39;ve proposed (privately, to the other core committers) some dynamic<br>
&gt; algorithm the objection has been &quot;but that gives miners complete control<br>
&gt; over the max block size.&quot;<br>
&gt;<br>
&gt; I think that worry is unjustified right now-- certainly, until we have<br>
&gt; size-independent new block propagation there is an incentive for miners to<br>
&gt; keep their blocks small, and we see miners creating small blocks even when<br>
&gt; there are fee-paying transactions waiting to be confirmed.<br>
&gt;<br>
&gt; I don&#39;t even think it will be a problem if/when we do have size-independent<br>
&gt; new block propagation, because I think the combination of the random timing<br>
&gt; of block-finding plus a dynamic limit as described above will create a<br>
&gt; healthy system.<br>
&gt;<br>
&gt; If I&#39;m wrong, then it seems to me the miners will have a very strong<br>
&gt; incentive to, collectively, impose whatever rules are necessary (maybe a<br>
&gt; soft-fork to put a hard cap on block size) to make the system healthy again.<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; --<br>
&gt; Gavin Andresen<br>
&gt; -------------- next part --------------<br>
&gt; An HTML attachment was scrubbed...<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; ------------------------------------------------------------------------------<br>
&gt;<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
&gt; <a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
&gt;<br>
&gt;<br>
&gt; End of Bitcoin-development Digest, Vol 48, Issue 122<br>
&gt; ****************************************************<br>
</p>