<div dir="auto"><div dir="auto"><span style="font-size:13.696px;font-family:sans-serif">We have models for estimating the probability that a block is orphaned given average network bandwidth and block size. </span><br></div><div dir="auto"><span style="font-size:13.696px;font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif;font-size:13.696px">The question is, do we have objective measures of these two quantities? Couldn&#39;t we target an orphan_rate &lt; max_rate? </span><span style="font-size:13.696px;font-family:sans-serif"><br></span></div><div dir="auto"><div dir="auto"><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Dec 10, 2016 1:01 PM,  &lt;<a href="mailto:bitcoin-dev-request@lists.linuxfoundation.org">bitcoin-dev-request@lists.linuxfoundation.org</a>&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send bitcoin-dev mailing list submissions to<br>
        <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
        <a href="mailto:bitcoin-dev-request@lists.linuxfoundation.org">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:bitcoin-dev-owner@lists.linuxfoundation.org">bitcoin-dev-owner@lists.<wbr>linuxfoundation.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of bitcoin-dev digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
   1. Managing block size the same way we do difficulty (aka<br>
      Block75) (t. khan)<br>
   2. Re: Managing block size the same way we do difficulty (aka<br>
      Block75) (s7r)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Mon, 5 Dec 2016 10:27:32 -0500<br>
From: &quot;t. khan&quot; &lt;<a href="mailto:teekhan42@gmail.com">teekhan42@gmail.com</a>&gt;<br>
To: <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
Subject: [bitcoin-dev] Managing block size the same way we do<br>
        difficulty      (aka Block75)<br>
Message-ID:<br>
        &lt;CAGCNRJqdu7DMC+<wbr>AMR4mYKRAYStRMKVGqbnjtEfmzcoeM<wbr>ij5u=<a href="mailto:A@mail.gmail.com">A@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;utf-8&quot;<br>
<br>
BIP Proposal - Managing Bitcoin?s block size the same way we do difficulty<br>
(aka Block75)<br>
<br>
The every two-week adjustment of difficulty has proven to be a reasonably<br>
effective and predictable way of managing how quickly blocks are mined.<br>
Bitcoin needs a reasonably effective and predictable way of managing the<br>
maximum block size.<br>
<br>
It?s clear at this point that human beings should not be involved in the<br>
determination of max block size, just as they?re not involved in deciding<br>
the difficulty.<br>
<br>
Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or<br>
passing the decision to miners/pool operators, the max block size should be<br>
adjusted every two weeks (2016 blocks) using a system similar to how<br>
difficulty is calculated.<br>
<br>
Put another way: let?s stop thinking about what the max block size should<br>
be and start thinking about how full we want the average block to be<br>
regardless of size. Over the last year, we?ve had averages of 75% or<br>
higher, so aiming for 75% full seems reasonable, hence naming this concept<br>
?Block75?.<br>
<br>
The target capacity over 2016 blocks would be 75%. If the last 2016 blocks<br>
are more than 75% full, add the difference to the max block size. Like this:<br>
<br>
MAX_BLOCK_BASE_SIZE = 1000000<br>
TARGET_CAPACITY = 750000<br>
AVERAGE_OVER_CAP = average block size of last 2016 blocks minus<br>
TARGET_CAPACITY<br>
<br>
To check if a block is valid, ? (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)<br>
<br>
For example, if the last 2016 blocks are 85% full (average block is 850<br>
KB), add 10% to the max block size. The new max block size would be 1,100<br>
KB until the next 2016 blocks are mined, then reset and recalculate. The<br>
1,000,000 byte limit that exists currently would remain, but would<br>
effectively be the minimum max block size.<br>
<br>
Another two weeks goes by, the last 2016 blocks are again 85% full, but now<br>
that means they average 935 KB out of the 1,100 KB max block size. This is<br>
93.5% of the 1,000,000 byte limit, so 18.5% would be added to that to make<br>
the new max block size of 1,185 KB.<br>
<br>
Another two weeks passes. This time, the average block is 1,050 KB. The new<br>
max block size is calculated to 1,300 KB (as blocks were 105% full, minus<br>
the 75% capacity target, so 30% added to max block size).<br>
<br>
Repeat every 2016 blocks, forever.<br>
<br>
If Block75 had been applied at the difficulty adjustment on November 18th,<br>
the max block size would have been 1,080KB, as the average block during<br>
that period was 83% full, so 8% is added to the 1,000KB limit. The current<br>
size, after the December 2nd adjustment would be 1,150K.<br>
<br>
Block75 would allow the max block size to grow (or shrink) in response to<br>
transaction volume, and does so predictably, reasonably quickly, and in a<br>
method that prevents wild swings in block size or transaction fees. It<br>
attempts to keep blocks at 75% total capacity over each two week period,<br>
the same way difficulty tries to keep blocks mined every ten minutes. It<br>
also keeps blocks as small as possible.<br>
<br>
Thoughts?<br>
<br>
-t.k.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161205/c24d6c6d/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>attachments/20161205/c24d6c6d/<wbr>attachment-0001.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 10 Dec 2016 12:44:31 +0200<br>
From: s7r &lt;<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>&gt;<br>
To: <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Managing block size the same way we do<br>
        difficulty (aka Block75)<br>
Message-ID: &lt;<a href="mailto:c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org">c318f76d-0904-2e1b-453b-<wbr>60179f8209bb@sky-ip.org</a>&gt;<br>
Content-Type: text/plain; charset=&quot;utf-8&quot;<br>
<br>
t. khan via bitcoin-dev wrote:<br>
&gt; BIP Proposal - Managing Bitcoin?s block size the same way we do<br>
&gt; difficulty (aka Block75)<br>
&gt;<br>
&gt; The every two-week adjustment of difficulty has proven to be a<br>
&gt; reasonably effective and predictable way of managing how quickly blocks<br>
&gt; are mined. Bitcoin needs a reasonably effective and predictable way of<br>
&gt; managing the maximum block size.<br>
&gt;<br>
&gt; It?s clear at this point that human beings should not be involved in the<br>
&gt; determination of max block size, just as they?re not involved in<br>
&gt; deciding the difficulty.<br>
&gt;<br>
&gt; Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or<br>
&gt; passing the decision to miners/pool operators, the max block size should<br>
&gt; be adjusted every two weeks (2016 blocks) using a system similar to how<br>
&gt; difficulty is calculated.<br>
&gt;<br>
&gt; Put another way: let?s stop thinking about what the max block size<br>
&gt; should be and start thinking about how full we want the average block to<br>
&gt; be regardless of size. Over the last year, we?ve had averages of 75% or<br>
&gt; higher, so aiming for 75% full seems reasonable, hence naming this<br>
&gt; concept ?Block75?.<br>
&gt;<br>
&gt; The target capacity over 2016 blocks would be 75%. If the last 2016<br>
&gt; blocks are more than 75% full, add the difference to the max block size.<br>
&gt; Like this:<br>
&gt;<br>
&gt; MAX_BLOCK_BASE_SIZE = 1000000<br>
&gt; TARGET_CAPACITY = 750000<br>
&gt; AVERAGE_OVER_CAP = average block size of last 2016 blocks minus<br>
&gt; TARGET_CAPACITY<br>
&gt;<br>
&gt; To check if a block is valid, ? (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)<br>
&gt;<br>
&gt; For example, if the last 2016 blocks are 85% full (average block is 850<br>
&gt; KB), add 10% to the max block size. The new max block size would be<br>
&gt; 1,100 KB until the next 2016 blocks are mined, then reset and<br>
&gt; recalculate. The 1,000,000 byte limit that exists currently would<br>
&gt; remain, but would effectively be the minimum max block size.<br>
&gt;<br>
&gt; Another two weeks goes by, the last 2016 blocks are again 85% full, but<br>
&gt; now that means they average 935 KB out of the 1,100 KB max block size.<br>
&gt; This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to<br>
&gt; that to make the new max block size of 1,185 KB.<br>
&gt;<br>
&gt; Another two weeks passes. This time, the average block is 1,050 KB. The<br>
&gt; new max block size is calculated to 1,300 KB (as blocks were 105% full,<br>
&gt; minus the 75% capacity target, so 30% added to max block size).<br>
&gt;<br>
&gt; Repeat every 2016 blocks, forever.<br>
&gt;<br>
&gt; If Block75 had been applied at the difficulty adjustment on November<br>
&gt; 18th, the max block size would have been 1,080KB, as the average block<br>
&gt; during that period was 83% full, so 8% is added to the 1,000KB limit.<br>
&gt; The current size, after the December 2nd adjustment would be 1,150K.<br>
&gt;<br>
&gt; Block75 would allow the max block size to grow (or shrink) in response<br>
&gt; to transaction volume, and does so predictably, reasonably quickly, and<br>
&gt; in a method that prevents wild swings in block size or transaction fees.<br>
&gt; It attempts to keep blocks at 75% total capacity over each two week<br>
&gt; period, the same way difficulty tries to keep blocks mined every ten<br>
&gt; minutes. It also keeps blocks as small as possible.<br>
&gt;<br>
&gt; Thoughts?<br>
&gt;<br>
&gt; -t.k.<br>
&gt;<br>
<br>
I like the idea. It is good wrt growing the max. block size<br>
automatically without human action, but the main problem (or question)<br>
is not how to grow this number, it is what number can the network<br>
handle, considering both miners and users. While disk space requirements<br>
might not be a big problem, block propagation time is. The time required<br>
for a block to propagate in the network (or at least to all the miners)<br>
is directly dependent of its size.  If blocks take too much time to<br>
propagate in the network, the orphan rate will increase in unpredictable<br>
ways. For example if the internet speed in China is worse than in<br>
Europe, and miners in China have more than 50% of the hashing power,<br>
blocks mined by European miners might get orphaned.<br>
<br>
The system as described can also be gamed, by filling the network with<br>
transactions. Miners have the monetary interest to include as many<br>
transactions as possible in a block in order to collect the fees.<br>
Regardless how you think about it, there has to be a maximum block size<br>
that the network will allow as a consensus rule. Increasing it<br>
dynamically based on transaction volume will reach a point where the<br>
number got big enough that it broke things. Bitcoin, because its<br>
fundamental design, can scale by using offchain solutions.<br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 488 bytes<br>
Desc: OpenPGP digital signature<br>
URL: &lt;<a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/c231038d/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>attachments/20161210/c231038d/<wbr>attachment-0001.sig</a>&gt;<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
<br>
End of bitcoin-dev Digest, Vol 19, Issue 4<br>
******************************<wbr>************<br>
</blockquote></div><br></div></div></div></div>