path: root/d4/fd7f1bbdc5cccd8cb121e446616858c46b4f72

Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2B1077D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Mar 2016 18:48:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com
	[209.85.213.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 731C513D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Mar 2016 18:48:16 +0000 (UTC)
Received: by mail-vk0-f46.google.com with SMTP id e6so99306491vkh.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Mar 2016 11:48:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc; 
	bh=JuadOQc526gvmYGw+8e6d3qexz/sDlNx/SnJD/9/cwE=;
	b=OCqynT3fEbzTjW+ImqvQKH1Tv20Y59e/41cbv3F+wEhOufxcWnGa3iNkYhoOhVzwQ6
	1kFd8E3uFFha0dBjvPYjV7E1o4TMFYZrOox8ACv/EatstwJ0p5c8GF7qe2MJVryxfZM0
	KVRWdprZ6YLLbRZfug+bPSLOg3N8fus+r4AbUJYiVkXVScbMAm8ZdPPq3ZvUX5BlbzJX
	T2+NbAsAEbCzjdSAH3BksgGKGDoJ+/KDXxsEvz5KwIWb7t+yco+cCsfbEm1xRZED8cj/
	yIvWefJw8WwFjiX5/NV5SbI728vlZbSwWCnvMsS93SBOPHW0XrBou/Zn2G5JR59/C1Wj
	zweQ==
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:date
	:message-id:subject:from:cc;
	bh=JuadOQc526gvmYGw+8e6d3qexz/sDlNx/SnJD/9/cwE=;
	b=QA0YH+UIZsvvDQorASZu99W6HOGrAWjGyU/fg2RtuTvH+x6dkmGgmhnATcndGvhva2
	IBT+tATlvYFwFtDA4q8+yqifbQ7yCJxw12RyBWluEEmryte6Uo2mnR4V4koj31zn7w7B
	n8QrApPiUaOhrmoor17oCj9rYnwc/Rk/c01czqB/aZZ2atZGw0XaaOUjd8Qus6dcFwen
	fC4nShpgvipnBbnge1bliE3SGYYPu4vSmaAulYq4kfpDQWXNSW4VTO1SYhNbm2xK4PMM
	QB5Z4AAWBfCKsj1RSmeckVNuA5SqGCv+Bqx2Y3nTi7irBPBw4wxvld24Kn1cfoPTGFRg
	rH7w==
X-Gm-Message-State: AD7BkJKTOq7oYyWx0179wU8+RBEgkVwFaEmdLXiUgsTqQdTUDcJMdEk7ImSrAz2/WXmcWhFgDu1AlbzYRp9bOw==
MIME-Version: 1.0
X-Received: by 10.31.150.215 with SMTP id y206mr7841320vkd.63.1458931695754;
	Fri, 25 Mar 2016 11:48:15 -0700 (PDT)
Received: by 10.176.2.108 with HTTP; Fri, 25 Mar 2016 11:48:15 -0700 (PDT)
In-Reply-To: <CAO1Z-eMxRfM8O+uTFbK0rb-zuL0KKLgYFJex35Rk8UJgGYd4RA@mail.gmail.com>
References: <CAO1Z-eMxRfM8O+uTFbK0rb-zuL0KKLgYFJex35Rk8UJgGYd4RA@mail.gmail.com>
Date: Fri, 25 Mar 2016 18:48:15 +0000
Message-ID: <CAE-z3OUZ-dehQKsCA1ZNHr=vmc7hE0-ZL6rTNx3Rms0p2kcGmA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1140fdd87a21da052ee401e7
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
	RCVD_IN_DNSWL_LOW 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: Fri, 25 Mar 2016 18:55:37 +0000
Subject: Re: [bitcoin-dev] Proposed BIP: Maximum block size consensus rule
 based on median block size (adaptive block size)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 25 Mar 2016 18:48:17 -0000

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

I think you will have a hard time getting something related to block size
accepted in the current climate.

Using floating point calculations in consensus code is a bad idea.  The
standard practice is to use very large integers to fake it.  That has the
advantage that it is exact.  You don't even need to do this here.

Your get median function could just as easily use an array of integers.
You are dividing by 2.0 and then getting casting it to int after using a
floor function.  The standard integer divide by 2 does that automatically.

The median function is sufficiently defined that I don't think you need the
exact function (especially if you use integers).

Since the block size has to be an integer, even if the size was
1,234,567.5, the limit would still be 1,234,567.

It would likely help to gain acceptance if you added a 2nd limiter to the
growth rate.  For example, you could make it so that the size isn't allowed
to more than double every year.  This is similar to the 1MB limit on the
lower end.  A 45 day doubling time (granted subject to miner veto) is
likely unacceptable.  Miners could spam max size blocks by filling them
with transactions created for that purpose.

The graphs likely understate the growth rate, since the 1MB limit
inherently restricts things to 1MB.

On Fri, Mar 25, 2016 at 5:27 PM, Chris Kleeschulte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The following draft BIP proposes changing the MAX_BLOCK_SIZE consensus
> rule to be a function of the median block size over the last 12,960 blocks
> (about three months) multiplied by 2 and calculated when a block is
> connected to the blockchain.
>
> Motivation:
>
> The purpose of this consensus rule change is to allow the maximum block
> size to increase or decrease based on actual network usage. A block size
> limit, as discussed here, prevents certain types of denial of service
> attacks on the Bitcoin network, however a fixed limit does not allow the
> capacity of the network to increase as advancements in scaling are
> realized.  By adjusting the limit based on the sizes of blocks in the
> recent past, the throughput of the network can adjust to changes in user
> demand and scaling related technology advancements while still being
> protected from denial of service attacks.
>
>
> Full proposal here:
>
> https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki
>
> I look forward to your consideration.
>
> thank you,
> --
> Chris Kleeschulte
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div><div><div><div><div>I think you will have a hard time=
 getting something related to block size accepted in the current climate.<b=
r><br></div>Using floating point calculations in consensus code is a bad id=
ea.=C2=A0 The standard practice is to use very large integers to fake it.=
=C2=A0 That has the advantage that it is exact.=C2=A0 You don&#39;t even ne=
ed to do this here.<br><br></div>Your get median function could just as eas=
ily use an array of integers.=C2=A0 You are dividing by 2.0 and then gettin=
g casting it to int after using a floor function.=C2=A0 The standard intege=
r divide by 2 does that automatically.<br><br></div>The median function is =
sufficiently defined that I don&#39;t think you need the exact function (es=
pecially if you use integers).=C2=A0 <br><br>Since the block size has to be=
 an integer, even if the size was 1,234,567.5, the limit would still be 1,2=
34,567.<br><br></div>It would likely help to gain acceptance if you added a=
 2nd limiter to the growth rate.=C2=A0 For example, you could make it so th=
at the size isn&#39;t allowed to more than double every year.=C2=A0 This is=
 similar to the 1MB limit on the lower end.=C2=A0 A 45 day doubling time (g=
ranted subject to miner veto) is likely unacceptable.=C2=A0 Miners could sp=
am max size blocks by filling them with transactions created for that purpo=
se.<br><br></div>The graphs likely understate the growth rate, since the 1M=
B limit inherently restricts things to 1MB.<br></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Fri, Mar 25, 2016 at 5:27 PM, Chris =
Kleeschulte via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">The following draft BIP proposes changing the MAX_BLOCK_SIZE con=
sensus rule to be a function of the median block size over the last 12,960 =
blocks (about three months) multiplied by 2 and calculated when a block is =
connected to the blockchain.<div><br></div><div>Motivation:</div><div><br><=
/div><div>The purpose of this consensus rule change is to allow the maximum=
 block size to increase or decrease based on actual network usage. A block =
size limit, as discussed here, prevents certain types of denial of service =
attacks on the Bitcoin network, however a fixed limit does not allow the ca=
pacity of the network to increase as advancements in scaling are realized.=
=C2=A0 By adjusting the limit based on the sizes of blocks in the recent pa=
st, the throughput of the network can adjust to changes in user demand and =
scaling related technology advancements while still being protected from de=
nial of service attacks.</div><div><br></div><div><br></div><div>Full propo=
sal here:</div><div><br></div><div><a href=3D"https://github.com/bitpay/bip=
s/blob/master/bip-adaptiveblocksize.mediawiki" target=3D"_blank">https://gi=
thub.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki</a><br></d=
iv><div><br></div><div>I look forward to your consideration.</div><div><br>=
</div><div>thank you,</div><span class=3D"HOEnZb"><font color=3D"#888888"><=
div>-- <br><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=
=3D"ltr">Chris Kleeschulte<br><br></div></div></div></div></div>
</div></font></span></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a1140fdd87a21da052ee401e7--