<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br><div>Put another way: let’s stop thinking about what the max block size should be and start thinking about how full we want the average block to be regardless of size. Over the last year, we’ve had averages of 75% or higher, so aiming for 75% full seems reasonable, hence naming this concept ‘Block75’.<br></div></div></div></div></blockquote><div><br></div><div>That&#39;s effectively making the blocksize limit completely uncapped and only preventing spikes, and even in the case of spikes it doesn&#39;t differentiate between &#39;real&#39; traffic and low value spam attacks. It suffers from the same fundamental problems as bitcoin unlimited: There are in the end no transaction fees, and inevitably some miners will want to impose some cap on block size for practical purposes, resulting in a fork.</div><div><br></div><div>Difficulty adjustment works because there&#39;s a clear goal of having a certain rate of making new blocks. Without a target to attempt automatic adjustment makes no sense.</div></div></div></div>