path: root/88/2fd090f939ee8b826b54ec6cbf45e5490f09db

Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C1D7949
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 12:05:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CE022E3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 12:05:24 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id a197so9012463wmd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 04:05:24 -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=fOdX7tWxOXXyVAtbvDyfMj9sE7DjzhrY7HSSTEzUNiM=;
	b=Xea79CjPlpodrEDj1Dq8dKLSql0LuhQ6KNOwIKhLsOm5dERDkYXIofgKjuDhxg4LiK
	vBc23O+L8gY6ljtCmS5k0Sv4Cu35BdtYFC7SPym1Ph6Xf5uc77nCPpF7h9IDuo5zhuxI
	WghkgbVj5iRAh12ZNu+FA8A5h6L1cnx9yj4q94xQrnYWjI2TatK+Ibr/nE4GRy0NM4BX
	cA7Vb9/Ku5i8aHHUedCiEG/PrxzRD5e4ShQYWDpPysFH9gYkrCdg8ZmQtWtXqH2rbu8r
	2rH/bTB4apNlxNN1uIFirJZ0pUUmdfjFRbrYLDL26Q0Q5U/SuKpzlBB5j67loMCW4Ncw
	M9kQ==
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=fOdX7tWxOXXyVAtbvDyfMj9sE7DjzhrY7HSSTEzUNiM=;
	b=nByLAHz85A2VXDTpnSrst0dozdzD0/o23RggHKoWTYS6owwO+sMVs7dXPHmMwgWRef
	f45nkXGTIJYPPBnCcIKrLHRAb5KoFQ/52172qs/1HvOXaG3OveUt3qdlvIXthA4fgqOB
	Ra4tdAmJO17iw/TORhETo0Xw2bXtiIimkUrpGWoGnQAUMiLRqn5oyMudPj9CCGPZZaDL
	88k7UlP/F5oLhveTwLI+8vSC9Aj7DiJS1EWosdj6C37xtbRQT0VqRJq+ofQilcmEY2Rp
	UZdlyLYNHYdk4u3IyMUKK4a8BEYRSmhcWWCGuPBjVp8OAGHvqNroVqAcsAPZcDztvLrT
	U4pQ==
X-Gm-Message-State: AKaTC01ZuOJiyCTj/0VemPOSFkZO6DpW9YTMBfu3bAxX9HH3xIrkLsf1+UzM8RK1AP6scqoKibQ3GNNr7r7d9Q==
X-Received: by 10.28.25.134 with SMTP id 128mr10107446wmz.37.1481371523379;
	Sat, 10 Dec 2016 04:05:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.63.66 with HTTP; Sat, 10 Dec 2016 04:05:22 -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: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Sat, 10 Dec 2016 13:05:22 +0100
Message-ID: <CAFMkqK9v6OkNd04FvfMfk+1zYtvZwm0dgx8L=J0ehn0iuyVVoA@mail.gmail.com>
To: s7r@sky-ip.org, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114d46b86e7b2105434cafd4
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham 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:30 +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:05:26 -0000

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

> While disk space requirements might not be a big problem, block
propagation time is

Is block propagation time really still a problem? Compact blocks and FIBRE
should help here.

> Bitcoin, because its fundamental design, can scale by using offchain
solutions.

I agree.
However, I believe that on-chain scaling will be needed regardless of which
off-chain solution gains popularity.

2016-12-10 11:44 GMT+01:00 s7r via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

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

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

<div dir=3D"ltr"><div><div><div>&gt; While disk space requirements might no=
t be a big problem, block propagation time is<br><br></div>Is block propaga=
tion time really still a problem? Compact blocks and FIBRE should help here=
.<br><br>&gt; Bitcoin, because its fundamental design, can scale by using o=
ffchain solutions.<br></div><br></div>I agree.<br>However, I believe that o=
n-chain scaling will be needed regardless of which off-chain solution gains=
 popularity.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">2016-12-10 11:44 GMT+01:00 s7r via bitcoin-dev <span dir=3D"ltr">&lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">t. khan via bitcoin-d=
ev 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>

--001a114d46b86e7b2105434cafd4--