path: root/0d/df69a643ae061d2ee66a3bd7ba2d80995014a0

Return-Path: <daniele.pinna@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4F4FE826
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 12:23:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com
	[209.85.218.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB95C13B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 12:23:50 +0000 (UTC)
Received: by mail-oi0-f50.google.com with SMTP id b126so45360086oia.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 04:23:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=6Q1yLzlOFPVJL2k4LVuS4PUas4l/ivGVyojdqX/eITo=;
	b=Da7dSA1ATTpzsmBmFMlBsEfXOYxF3Gle/1etI9C0wo17fi0NKde/B1pqsRMKrl9af9
	6C2lu/CLmArFQ2vwpm7dSY3Apl/PDXtSkfyzqLGWP36hK0kghnTY5EewFrBCMsBIv9LA
	3QMmyL2G1yI4lr78vGvqrpWmid1KznDA7pw/04YB+EmVTH6A/aq4fJIaz3JbnIfNKIR2
	XM8H0JlrmpoeYTJXGL0+F+EwFzKOwGVKPHSaU7MIyyMpz1P/YDgyO+jH2v5TNOY8Xvn1
	GDfp+CCpaJTBI4GzfOAs/yCYJusSsdFMy5CjhMKQQq/drhwq0WQ7QiLHgOKm1AeeN0Zx
	QsGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=6Q1yLzlOFPVJL2k4LVuS4PUas4l/ivGVyojdqX/eITo=;
	b=i6rh0KKbpBqucip/x8zDBdGxHcVzfi0O4EpXJfPH09zGe/WAVi5jTsxmGwUkceDvCd
	m0i0e3edbplSEsquCusZ/0vSZTesT5d/Z3ChoG8+uVMuBMp4GWhDyKxW1WAtY/3ucNip
	JwT0Y7pVMFkhNttRCPngLgWo9t7OzfR32j5SEUfEnuSV9aX41DBkRvZoavjxHQJmmJFF
	FymGX5VnvdYISx0kXFqApk8uELmrZrAld7tcyLFfv8nn8KSC2MQzbh6v5JlGqe7LQA3b
	5cgISxKxYmpmrUS55YMQp+Ruu/NX+4g5NNzwKK4dKFiU6QxM5EwueeQ/A68f/xs8/3Gz
	Vufg==
X-Gm-Message-State: AKaTC02vrjOcvp/2GCAQg/R0XLWRqmBlFmR00rRecxp6QtArb7l7UeibT05E6gz78jJmVqiLKI2DRkdi9NJJIQ==
X-Received: by 10.202.188.196 with SMTP id m187mr43911190oif.210.1481372629864;
	Sat, 10 Dec 2016 04:23:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.31.29 with HTTP; Sat, 10 Dec 2016 04:23:49 -0800 (PST)
Received: by 10.157.31.29 with HTTP; Sat, 10 Dec 2016 04:23:49 -0800 (PST)
In-Reply-To: <CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
References: <CAEgR2PEMPo3veqJat7OAps1DzTSNFJmJiRbkFgYKvYfxqdbUiw@mail.gmail.com>
	<CAEgR2PELB1_s+o0Bj4Kj9vS27eoqP7gV_VS_6QHQtTUAOnMORg@mail.gmail.com>
	<CAEgR2PFpGWxngq=fKGi7CC_d+=5YWzWwbEEsQNEifCuHAAPAHw@mail.gmail.com>
	<CAEgR2PHnrsdaBiDgywvE9amK8_yPE_hBo0yYOYwUk4T8n7wnAQ@mail.gmail.com>
	<CAEgR2PEgPkRe76hW0Jj7_Z1EdmmNTpTAOKGm_of2dG=XXUOtnA@mail.gmail.com>
	<CAEgR2PHew+fcJWnAt+t8umcwKu4TkshH=AFJ-8MeYysud2MkBQ@mail.gmail.com>
	<CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Sat, 10 Dec 2016 13:23:49 +0100
Message-ID: <CAEgR2PEvpEwv=a0syn43negEnvGcoQ8LBxKRp4-JpnxCNORJSg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113dc8fc6217d505434cf1e9
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 10 Dec 2016 13:57:42 +0000
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
 (aka Block75)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 12:23:55 -0000

--001a113dc8fc6217d505434cf1e9
Content-Type: text/plain; charset=UTF-8

We have models for estimating the probability that a block is orphaned
given average network bandwidth and block size.

The question is, do we have objective measures of these two quantities?
Couldn't we target an orphan_rate < max_rate?



On Dec 10, 2016 1:01 PM, <bitcoin-dev-request@lists.linuxfoundation.org>
wrote:

Send bitcoin-dev mailing list submissions to
        bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
        bitcoin-dev-request@lists.linuxfoundation.org

You can reach the person managing the list at
        bitcoin-dev-owner@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

   1. Managing block size the same way we do difficulty (aka
      Block75) (t. khan)
   2. Re: Managing block size the same way we do difficulty (aka
      Block75) (s7r)


----------------------------------------------------------------------

Message: 1
Date: Mon, 5 Dec 2016 10:27:32 -0500
From: "t. khan" <teekhan42@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Managing block size the same way we do
        difficulty      (aka Block75)
Message-ID:
        <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

BIP Proposal - Managing Bitcoin?s block size the same way we do difficulty
(aka Block75)

The every two-week adjustment of difficulty has proven to be a reasonably
effective and predictable way of managing how quickly blocks are mined.
Bitcoin needs a reasonably effective and predictable way of managing the
maximum block size.

It?s clear at this point that human beings should not be involved in the
determination of max block size, just as they?re not involved in deciding
the difficulty.

Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
passing the decision to miners/pool operators, the max block size should be
adjusted every two weeks (2016 blocks) using a system similar to how
difficulty is calculated.

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?.

The target capacity over 2016 blocks would be 75%. If the last 2016 blocks
are more than 75% full, add the difference to the max block size. Like this:

MAX_BLOCK_BASE_SIZE = 1000000
TARGET_CAPACITY = 750000
AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
TARGET_CAPACITY

To check if a block is valid, ? (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)

For example, if the last 2016 blocks are 85% full (average block is 850
KB), add 10% to the max block size. The new max block size would be 1,100
KB until the next 2016 blocks are mined, then reset and recalculate. The
1,000,000 byte limit that exists currently would remain, but would
effectively be the minimum max block size.

Another two weeks goes by, the last 2016 blocks are again 85% full, but now
that means they average 935 KB out of the 1,100 KB max block size. This is
93.5% of the 1,000,000 byte limit, so 18.5% would be added to that to make
the new max block size of 1,185 KB.

Another two weeks passes. This time, the average block is 1,050 KB. The new
max block size is calculated to 1,300 KB (as blocks were 105% full, minus
the 75% capacity target, so 30% added to max block size).

Repeat every 2016 blocks, forever.

If Block75 had been applied at the difficulty adjustment on November 18th,
the max block size would have been 1,080KB, as the average block during
that period was 83% full, so 8% is added to the 1,000KB limit. The current
size, after the December 2nd adjustment would be 1,150K.

Block75 would allow the max block size to grow (or shrink) in response to
transaction volume, and does so predictably, reasonably quickly, and in a
method that prevents wild swings in block size or transaction fees. It
attempts to keep blocks at 75% total capacity over each two week period,
the same way difficulty tries to keep blocks mined every ten minutes. It
also keeps blocks as small as possible.

Thoughts?

-t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20161205/c24d6c6d/attachment-0001.html>

------------------------------

Message: 2
Date: Sat, 10 Dec 2016 12:44:31 +0200
From: s7r <s7r@sky-ip.org>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Managing block size the same way we do
        difficulty (aka Block75)
Message-ID: <c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
Content-Type: text/plain; charset="utf-8"

t. khan via bitcoin-dev wrote:
> BIP Proposal - Managing Bitcoin?s block size the same way we do
> difficulty (aka Block75)
>
> The every two-week adjustment of difficulty has proven to be a
> reasonably effective and predictable way of managing how quickly blocks
> are mined. Bitcoin needs a reasonably effective and predictable way of
> managing the maximum block size.
>
> It?s clear at this point that human beings should not be involved in the
> determination of max block size, just as they?re not involved in
> deciding the difficulty.
>
> Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
> passing the decision to miners/pool operators, the max block size should
> be adjusted every two weeks (2016 blocks) using a system similar to how
> difficulty is calculated.
>
> 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?.
>
> The target capacity over 2016 blocks would be 75%. If the last 2016
> blocks are more than 75% full, add the difference to the max block size.
> Like this:
>
> MAX_BLOCK_BASE_SIZE = 1000000
> TARGET_CAPACITY = 750000
> AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
> TARGET_CAPACITY
>
> To check if a block is valid, ? (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
>
> For example, if the last 2016 blocks are 85% full (average block is 850
> KB), add 10% to the max block size. The new max block size would be
> 1,100 KB until the next 2016 blocks are mined, then reset and
> recalculate. The 1,000,000 byte limit that exists currently would
> remain, but would effectively be the minimum max block size.
>
> Another two weeks goes by, the last 2016 blocks are again 85% full, but
> now that means they average 935 KB out of the 1,100 KB max block size.
> This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to
> that to make the new max block size of 1,185 KB.
>
> Another two weeks passes. This time, the average block is 1,050 KB. The
> new max block size is calculated to 1,300 KB (as blocks were 105% full,
> minus the 75% capacity target, so 30% added to max block size).
>
> Repeat every 2016 blocks, forever.
>
> If Block75 had been applied at the difficulty adjustment on November
> 18th, the max block size would have been 1,080KB, as the average block
> during that period was 83% full, so 8% is added to the 1,000KB limit.
> The current size, after the December 2nd adjustment would be 1,150K.
>
> Block75 would allow the max block size to grow (or shrink) in response
> to transaction volume, and does so predictably, reasonably quickly, and
> in a method that prevents wild swings in block size or transaction fees.
> It attempts to keep blocks at 75% total capacity over each two week
> period, the same way difficulty tries to keep blocks mined every ten
> minutes. It also keeps blocks as small as possible.
>
> Thoughts?
>
> -t.k.
>

I like the idea. It is good wrt growing the max. block size
automatically without human action, but the main problem (or question)
is not how to grow this number, it is what number can the network
handle, considering both miners and users. While disk space requirements
might not be a big problem, block propagation time is. The time required
for a block to propagate in the network (or at least to all the miners)
is directly dependent of its size.  If blocks take too much time to
propagate in the network, the orphan rate will increase in unpredictable
ways. For example if the internet speed in China is worse than in
Europe, and miners in China have more than 50% of the hashing power,
blocks mined by European miners might get orphaned.

The system as described can also be gamed, by filling the network with
transactions. Miners have the monetary interest to include as many
transactions as possible in a block in order to collect the fees.
Regardless how you think about it, there has to be a maximum block size
that the network will allow as a consensus rule. Increasing it
dynamically based on transaction volume will reach a point where the
number got big enough that it broke things. Bitcoin, because its
fundamental design, can scale by using offchain solutions.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20161210/c231038d/attachment-0001.sig>

------------------------------

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


End of bitcoin-dev Digest, Vol 19, Issue 4
******************************************

--001a113dc8fc6217d505434cf1e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-size:13.696px;font-=
family:sans-serif">We have models for estimating the probability that a blo=
ck is orphaned given average network bandwidth and block size.=C2=A0</span>=
<br></div><div dir=3D"auto"><span style=3D"font-size:13.696px;font-family:s=
ans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-family:sa=
ns-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_ra=
te?=C2=A0</span><span style=3D"font-size:13.696px;font-family:sans-serif"><=
br></span></div><div dir=3D"auto"><div dir=3D"auto"><br><br><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Dec 10, 2016 1:01 PM,  &lt;<a=
 href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org">bitcoin-dev-=
request@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><b=
lockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Send bitcoin-dev mailing list submissions to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.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>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin=
uxfoundation.org">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a><br=
>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux=
foundation.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>
=C2=A0 =C2=A01. Managing block size the same way we do difficulty (aka<br>
=C2=A0 =C2=A0 =C2=A0 Block75) (t. khan)<br>
=C2=A0 =C2=A02. Re: Managing block size the same way we do difficulty (aka<=
br>
=C2=A0 =C2=A0 =C2=A0 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=3D"mailto:teekhan42@gmail.com">teekha=
n42@gmail.com</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
Subject: [bitcoin-dev] Managing block size the same way we do<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 difficulty=C2=A0 =C2=A0 =C2=A0 (aka Block75)<br=
>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;CAGCNRJqdu7DMC+<wbr>AMR4mYKRAYStRMKVGqbnjtE=
fmzcoeM<wbr>ij5u=3D<a href=3D"mailto:A@mail.gmail.com">A@mail.gmail.com</a>=
&gt;<br>
Content-Type: text/plain; charset=3D&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<b=
r>
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<b=
r>
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<b=
r>
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 =3D 1000000<br>
TARGET_CAPACITY =3D 750000<br>
AVERAGE_OVER_CAP =3D 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<b=
r>
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<b=
r>
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<b=
r>
transaction volume, and does so predictably, reasonably quickly, and in a<b=
r>
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=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20161205/c24d6c6d/attachment-0001.html" rel=3D"noreferrer" targ=
et=3D"_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=3D"mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Managing block size the same way we do<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 difficulty (aka Block75)<br>
Message-ID: &lt;<a href=3D"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=3D&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 block=
s<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 t=
he<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.) o=
r<br>
&gt; passing the decision to miners/pool operators, the max block size shou=
ld<br>
&gt; be adjusted every two weeks (2016 blocks) using a system similar to ho=
w<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% o=
r<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 siz=
e.<br>
&gt; Like this:<br>
&gt;<br>
&gt; MAX_BLOCK_BASE_SIZE =3D 1000000<br>
&gt; TARGET_CAPACITY =3D 750000<br>
&gt; AVERAGE_OVER_CAP =3D 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_CA=
P)<br>
&gt;<br>
&gt; For example, if the last 2016 blocks are 85% full (average block is 85=
0<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, bu=
t<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. Th=
e<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<b=
r>
&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.<b=
r>
&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, an=
d<br>
&gt; in a method that prevents wild swings in block size or transaction fee=
s.<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<b=
r>
&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.=C2=A0 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=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20161210/c231038d/attachment-0001.sig" rel=3D"noreferrer" targe=
t=3D"_blank">http://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<w=
br>attachments/20161210/c231038d/<wbr>attachment-0001.sig</a>&gt;<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_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>

--001a113dc8fc6217d505434cf1e9--