path: root/2c/91cdc00dcb4f49e563a68d06a9598ce3dee53e

Return-Path: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 00DD5415
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 00:26:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com
	[209.85.217.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 081CAAB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 00:26:02 +0000 (UTC)
Received: by mail-ua0-f180.google.com with SMTP id 20so51645559uak.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 16:26:02 -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=xK9ThT2KG2eqz6id+3K6yRhEc+CN7jX9ri355S+P0uc=;
	b=tBd1Y4poCi4b+TKF15qiHMF5dP9gFA5i2Nnwrw3Khv/KGr3WMdZLW/YWSaJRfcETJ2
	+LHPayZ/BhyZogp4MWTnua2yA1KCZFPf4zCMo4573VNAnVa3rwlTdKNWpnWdgezDYnRL
	GR8mgTkGwJGWGNOO2+xmagBRXr3Xcvr5x3gYKlCBm3xcBOX5P2Iqola4j4EjksEGwFsB
	xn0/Z0lZwBCW66NCkNP9Abz4sL0/aqdyRBfALmrYwsyn0tP7FiZDiDn+OSNbJrYLwsXG
	nqbkcArMuGW7mOsHVcDIN022Gaog9sUo6GUaMbpQbcP92EbMJ0v9stHFeYE3H7LF411W
	tZhQ==
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=xK9ThT2KG2eqz6id+3K6yRhEc+CN7jX9ri355S+P0uc=;
	b=Md+NiW77yzcF+5TikNB+fDkBT+/f66H9/fQ+4pkR51AP2lS8RTintUkdjYEUoLVPAm
	rSapIGhsj/h3fyhm0t7AZV7urbnyPgkTL4NsXOI2d7T9lPlTqnx9+6cwJ+mhrMsOwtrt
	Uk9e430juvc09QzdWcwLJBpKQt4sZZ6dQ4UnDftC/SvVzPCMyCPBErairU4TZ/gnHN8o
	a7vsoTgDQQuIapf3UHMRjX5pPsct5mG71D9oKbqW2yCn1o2s+XHxPiKBSrHwQDJWW5SP
	09MeCQwOopIgWEztFr5Z6QOOk9aVlsRmGK8SjbThKpGp6+qxswEXuWah6NsPRwsG1hYW
	Hu0w==
X-Gm-Message-State: AKaTC01kc5JWOXdTCWb1flHv+wdcucptRHMdD9dvZnoCLWp0nq5FyaR1hx2TuUIZ4GiOO26UbWxN+2lwJ1Xr2w==
X-Received: by 10.176.86.23 with SMTP id y23mr53764250uaa.88.1481415962142;
	Sat, 10 Dec 2016 16:26:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Sat, 10 Dec 2016 16:26:01 -0800 (PST)
In-Reply-To: <c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
	<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
From: "t. khan" <teekhan42@gmail.com>
Date: Sat, 10 Dec 2016 19:26:01 -0500
Message-ID: <CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
To: s7r@sky-ip.org, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f403045daa66302a0f0543570824
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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: Sun, 11 Dec 2016 00:27:24 +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: Sun, 11 Dec 2016 00:26:04 -0000

--f403045daa66302a0f0543570824
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Miners 'gaming' the Block75 system -
There is no financial incentive for miners to attempt to game the Block75
system. Even if it were attempted and assuming the goal was to create
bigger blocks, the maximum possible increase would be 25% over the previous
block size. And, that size would only last for two weeks before readjusting
down. It would cost them more in transaction fees to stuff the network than
they could ever make up. To game the system, they'd have to game it forever
with no possibility of profit.

Blocks would get too big -
Eventually, blocks would get too big, but only if bandwidth stopped
increasing and the cost of disk space stopped decreasing. Otherwise, the
incremental adjustments made by Block75 (especially in combination with
SegWit) wouldn't break anyone's connection or result in significantly more
orphaned blocks.

The frequent and small adjustments made by Block75 have the added benefit
of being more easily adapted to, both psychologically and technologically,
with regards to miners/node operators.

-t.k

On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> t. khan via bitcoin-dev wrote:
> > BIP Proposal - Managing Bitcoin=E2=80=99s 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=E2=80=99s clear at this point that human beings should not be involv=
ed in the
> > determination of max block size, just as they=E2=80=99re not involved i=
n
> > 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 shoul=
d
> > be adjusted every two weeks (2016 blocks) using a system similar to how
> > difficulty is calculated.
> >
> > Put another way: let=E2=80=99s stop thinking about what the max block s=
ize
> > should be and start thinking about how full we want the average block t=
o
> > be regardless of size. Over the last year, we=E2=80=99ve had averages o=
f 75% or
> > higher, so aiming for 75% full seems reasonable, hence naming this
> > concept =E2=80=98Block75=E2=80=99.
> >
> > 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 =3D 1000000
> > TARGET_CAPACITY =3D 750000
> > AVERAGE_OVER_CAP =3D average block size of last 2016 blocks minus
> > TARGET_CAPACITY
> >
> > To check if a block is valid, =E2=89=A4 (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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">Miners &#39;gaming&#39; the Block75 system -=C2=A0<div>The=
re is no financial incentive for miners to attempt to game the Block75 syst=
em. Even if it were attempted and assuming the goal was to create bigger bl=
ocks, the maximum possible increase would be 25% over the previous block si=
ze. And, that size would only last for two weeks before readjusting down. I=
t would cost them more in transaction fees to stuff the network than they c=
ould ever make up. To game the system, they&#39;d have to game it forever w=
ith no possibility of profit.</div><div><br></div><div>Blocks would get too=
 big -=C2=A0</div><div>Eventually, blocks would get too big, but only if ba=
ndwidth stopped increasing and the cost of disk space stopped decreasing. O=
therwise, the incremental adjustments made by Block75 (especially in combin=
ation with SegWit) wouldn&#39;t break anyone&#39;s connection or result in =
significantly more orphaned blocks.</div><div><br></div><div>The frequent a=
nd small adjustments made by Block75 have the added benefit of being more e=
asily adapted to, both psychologically and technologically, with regards to=
 miners/node operators.</div><div><br></div><div>-t.k</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Dec 10, 2016 at 5:4=
4 AM, s7r via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoun=
dation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cla=
ss=3D"HOEnZb"><div class=3D"h5">t. khan via bitcoin-dev wrote:<br>
&gt; BIP Proposal - Managing Bitcoin=E2=80=99s block size the same way we d=
o<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=E2=80=99s clear at this point that human beings should not be invol=
ved in the<br>
&gt; determination of max block size, just as they=E2=80=99re 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=E2=80=99s 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=E2=80=99ve had averages =
of 75% or<br>
&gt; higher, so aiming for 75% full seems reasonable, hence naming this<br>
&gt; concept =E2=80=98Block75=E2=80=99.<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, =E2=89=A4 (MAX_BLOCK_BASE_SIZE + AVERAGE=
_OVER_CAP)<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>
</div></div>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>
<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></blockquote></div><br></div>

--f403045daa66302a0f0543570824--