path: root/3f/11f918bf389e68e40048d2a3e71c8264f69f78

Return-Path: <erik.fors@startmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5DCE28EB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 Nov 2015 15:25:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from smx-7fb.smtp.startmail.com (smx-7fb.smtp.startmail.com
	[37.153.204.247])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3024F160
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 Nov 2015 15:25:23 +0000 (UTC)
Received: from smx-8a9.int1.startmail.com (smx-8a9.int1.startmail.com
	[10.1.137.139])
	by smx-7fb.smtp.startmail.com (Postfix) with ESMTPS id 9AFA197699;
	Sat, 14 Nov 2015 16:25:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=startmail.com;
	s=dkim; t=1447514720;
	bh=GTTsV9KQr94bkbAwz53DEFGOLEQWa4SMAIcfIzZdj9w=;
	h=Subject:To:References:From:Cc:Date:In-Reply-To:From;
	b=FQuNhslnSATKd63kMa3ohhkIkH+NnNWL/L5X0AviBGF1sCxYxNQ3i1McNJBV+LaCH
	cfMyZEpmb5KC3IutQA1WE9QO0eMdkcoNzfjWY66tBnUXPA6urGXMkWzh6bGp3qUC49
	mjzGvYUz1U2ESSQJFd9w3BIOfIT2l0TSMfBWVBJojOgqOXQAtVVv7cYoRKKPTYuDR8
	E2EvPdKtYoAACZRiAPhyu+3qBqgzL+d5YU3SH5Kp/spb7oCU0IaL9iaK0uuzC7rulJ
	6abot8AeX3MEgyaml39I1aXNhFV3TYj9qS8NcRfwMQzstYVwpOcg05KNS4TFXHJ/st
	fra8VJ8rOhnXw==
To: bitcoin-dev@lists.linuxfoundation.org
References: <5645E095.4050704@startmail.com>
	<201511131937.03430.luke@dashjr.org>
From: Erik <erik.fors@startmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5647525F.40801@startmail.com>
Date: Sat, 14 Nov 2015 16:25:19 +0100
Mime-Version: 1.0
In-Reply-To: <201511131937.03430.luke@dashjr.org>
Content-Type: multipart/alternative;
	boundary="------------070007050809000304080205"
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RP_MATCHES_RCVD autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP proposal - Max 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: Sat, 14 Nov 2015 15:25:24 -0000

This is a multi-part message in MIME format.
--------------070007050809000304080205
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've seen two different BIP103's and choose to not write about it
because risk of ambiguity. One of them are proposing a linear growth and
the other one is proposing an exponential growth. The all-linear growth
is an option that will not work well in the future because the growth
will be too slow soon or later. The exponential growth assumes that the
technology will rise in a certain growth, which may be too slow or too
fast in accordance to the technical evolution. None of the BIP103
proposals will actually handle an unexpected future case.

BIP105 has another feature not mentioned in my proposal that is to place
a vote requires a cost as a difficulty increase. I do not think it's a
good option since it will make users refrain from voting to "earn" a
difficulty lowering. The votes are the (yet) only soft way I see to let
the blockchain know if it should allow growing faster or slower. I also
don't see a benefit of having the opportunity to lower the block max
size in comparison to the risks involved with that. Then it proposes a
limit to how much it can increase at all which will need a new hard fork
when we need to increase the limits of the proposal.

I don't see how John Sacco's BIP proposal is similar to this one since
there is no voting mechanism to make the increase dynamic. Also John
proposes that the size will double at each halving instead of each
difficulty retarget. This could, in contrary to increase the fees by
making larger spaces in the blocks, decrease the fees because of that
the fee required to enter the next block will be lowered. Also it
proposes a hard limit at 32 MB which, again, need a new hard fork later.

The formula I've provided isn't actually complicated. The 2^(1/2...)
formula creates a number in the interval 1 to 2. The formula can tell if
the block max size every second year shall double or be the same based
on the last 6 month of votes. Because i believe there should always be
an increase to secure a stable growth of the network, there is also a
linear formula that the growth cannot be lower than. If the 2^(1/2...)
formula gives a lower increase than the linear value for the next
retarget, then the linear value should be used instead.

There will not be a rounding error since the implementation shall floor
the value to a whole byte. The next size should be calculated on that
value. Also, if the block max size is included in the retarget block,
there would be an extra correcting method to uncertain clients. The
formula isn't very different in complexity from the difficulty retarget
formula and will still need the last recalculated value to be computed.

One of the benefits of using an exponential formula is that it could
easily be fit for any arbitrary block period by changing the divisor. I
personally think the two week interval will be smooth enough.

Erik

Den 2015-11-13 kl. 20:37, skrev Luke Dashjr:
> On Friday, November 13, 2015 1:07:33 PM Erik via bitcoin-dev wrote:
>> Hi devs. I was discussing the BIP proposals concerning max block size
>> yesterday in the #bitcoin channel. I believe that BIP101 fully utilize=
d
>> will outperform consumer hardware soon or later and thereby centralize=

>> Bitcoin. I would therefore like to do a different proposal:
>
> It doesn't look like you've considered BIP103 or newer BIPs?
Especially, I'd
> suggest you look at and work with John Sacco who just the other day
posted a
> BIP draft very similar-looking to yours. My overall impression of your
summary
> is that it is unnecessarily over-complicated and underspecified. How
does the
> 2^(1/2) block size limit actually work? This is not a very precise
number, so
> it seems liable to produce rounding errors in different implementations=
=2E
> Additionally, the miner voting thing seems pointless since miners can
already
> softfork lower limits. It would be beneficial to express the current
> possibility so full nodes can enforce it, but this would be expressed
as an
> unlimited simple-majority vote to reduce the limit. Probably it would
be ideal
> to separate this off from the hardfork BIP, since it's fairly tangent
to it.
>
> Luke

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJWR1JfAAoJEJ51csApon2o1zkP/1Ik/VjakUII+2iXvPB+DSJ6
cekIC4A8zlgltSmFyE74IuQBlV/5LumNMCzXoKUaDRuKSedlyh1mUrt8hPFfISfr
yvIeWmXUQhd7s34mTTc9mBvz/TDuxuNYAFe1FYQhNzuV3GaLTysBAXScY5rGIkHf
hdgxG3mPtzaqse1I5e+3jpwlPUYpLn/0A2nmF0iXCoOv1LnTvrlV3thP8Fp/YMt3
iLsiWFQFf1jpA4mDoCC/G5bfYiqvFbtXdOKKZC12Dp3hTZZCzJ21FQ6+o/v4BT7y
MfW9kl3aWf3VSxbkvHppIrX1+HqDwTsn5u9kNcbYn8xBMRpFXFddFnsg/v6ai++L
mev+kIUrXvvDqvRSfQYmHIUKCwo+tzXbHcumydxBp412TOKW5bT1CmCRYMOvY/+C
45VWBj6foUYG/kq3QISm+lptVDQlESlAizHdWNkc9HJpKZG3VkNmmxEEXm3o7J07
LbBQ7bR2MELE6lP2Z3ImTXxZe0ZBdjyjDDV3qsIGK9D7LCK31KE70ZIueE3bePmR
9xWBfzKbm6Y3cQ6+4E8p8US7woVs9LGWXzLdKQyKEoiDx16bF7SOGvSyYcnOPsNu
O7lVpGh8Pezb0ZLEx5UnM5ONm35PzmzAT9Ng2iMEhche3AQS4s/b+wVWpyclQ62e
X4UVSr2O1mbfI9CmCPfI
=3DqcA8
-----END PGP SIGNATURE-----


--------------070007050809000304080205
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    -----BEGIN PGP SIGNED MESSAGE-----<br>
    Hash: SHA1<br>
    <br>
    <br>
    I've seen two different BIP103's and choose to not write about it
    because risk of ambiguity. One of them are proposing a linear growth
    and the other one is proposing an exponential growth. The all-linear
    growth is an option that will not work well in the future because
    the growth will be too slow soon or later. The exponential growth
    assumes that the technology will rise in a certain growth, which may
    be too slow or too fast in accordance to the technical evolution.
    None of the BIP103 proposals will actually handle an unexpected
    future case.<br>
    <br>
    BIP105 has another feature not mentioned in my proposal that is to
    place a vote requires a cost as a difficulty increase. I do not
    think it's a good option since it will make users refrain from
    voting to "earn" a difficulty lowering. The votes are the (yet) only
    soft way I see to let the blockchain know if it should allow growing
    faster or slower. I also don't see a benefit of having the
    opportunity to lower the block max size in comparison to the risks
    involved with that. Then it proposes a limit to how much it can
    increase at all which will need a new hard fork when we need to
    increase the limits of the proposal.<br>
    <br>
    I don't see how John Sacco's BIP proposal is similar to this one
    since there is no voting mechanism to make the increase dynamic.
    Also John proposes that the size will double at each halving instead
    of each difficulty retarget. This could, in contrary to increase the
    fees by making larger spaces in the blocks, decrease the fees
    because of that the fee required to enter the next block will be
    lowered. Also it proposes a hard limit at 32 MB which, again, need a
    new hard fork later.<br>
    <br>
    The formula I've provided isn't actually complicated. The 2^(1/2...)
    formula creates a number in the interval 1 to 2. The formula can
    tell if the block max size every second year shall double or be the
    same based on the last 6 month of votes. Because i believe there
    should always be an increase to secure a stable growth of the
    network, there is also a linear formula that the growth cannot be
    lower than. If the 2^(1/2...) formula gives a lower increase than
    the linear value for the next retarget, then the linear value should
    be used instead.<br>
    <br>
    There will not be a rounding error since the implementation shall
    floor the value to a whole byte. The next size should be calculated
    on that value. Also, if the block max size is included in the
    retarget block, there would be an extra correcting method to
    uncertain clients. The formula isn't very different in complexity
    from the difficulty retarget formula and will still need the last
    recalculated value to be computed.<br>
    <br>
    One of the benefits of using an exponential formula is that it could
    easily be fit for any arbitrary block period by changing the
    divisor. I personally think the two week interval will be smooth
    enough.<br>
    <br>
    Erik<br>
    <br>
    Den 2015-11-13 kl. 20:37, skrev Luke Dashjr:<br>
    <span style="white-space: pre;">&gt; On Friday, November 13, 2015
      1:07:33 PM Erik via bitcoin-dev wrote:<br>
      &gt;&gt; Hi devs. I was discussing the BIP proposals concerning
      max block size<br>
      &gt;&gt; yesterday in the #bitcoin channel. I believe that BIP101
      fully utilized<br>
      &gt;&gt; will outperform consumer hardware soon or later and
      thereby centralize<br>
      &gt;&gt; Bitcoin. I would therefore like to do a different
      proposal:<br>
      &gt;<br>
      &gt; It doesn't look like you've considered BIP103 or newer BIPs?
      Especially, I'd <br>
      &gt; suggest you look at and work with John Sacco who just the
      other day posted a <br>
      &gt; BIP draft very similar-looking to yours. My overall
      impression of your summary <br>
      &gt; is that it is unnecessarily over-complicated and
      underspecified. How does the <br>
      &gt; 2^(1/2) block size limit actually work? This is not a very
      precise number, so <br>
      &gt; it seems liable to produce rounding errors in different
      implementations. <br>
      &gt; Additionally, the miner voting thing seems pointless since
      miners can already <br>
      &gt; softfork lower limits. It would be beneficial to express the
      current <br>
      &gt; possibility so full nodes can enforce it, but this would be
      expressed as an <br>
      &gt; unlimited simple-majority vote to reduce the limit. Probably
      it would be ideal <br>
      &gt; to separate this off from the hardfork BIP, since it's fairly
      tangent to it.<br>
      &gt;<br>
      &gt; Luke</span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----<br>
    Version: GnuPG v2.0.22 (GNU/Linux)<br>
    <br>
    iQIcBAEBAgAGBQJWR1JfAAoJEJ51csApon2o1zkP/1Ik/VjakUII+2iXvPB+DSJ6<br>
    cekIC4A8zlgltSmFyE74IuQBlV/5LumNMCzXoKUaDRuKSedlyh1mUrt8hPFfISfr<br>
    yvIeWmXUQhd7s34mTTc9mBvz/TDuxuNYAFe1FYQhNzuV3GaLTysBAXScY5rGIkHf<br>
    hdgxG3mPtzaqse1I5e+3jpwlPUYpLn/0A2nmF0iXCoOv1LnTvrlV3thP8Fp/YMt3<br>
    iLsiWFQFf1jpA4mDoCC/G5bfYiqvFbtXdOKKZC12Dp3hTZZCzJ21FQ6+o/v4BT7y<br>
    MfW9kl3aWf3VSxbkvHppIrX1+HqDwTsn5u9kNcbYn8xBMRpFXFddFnsg/v6ai++L<br>
    mev+kIUrXvvDqvRSfQYmHIUKCwo+tzXbHcumydxBp412TOKW5bT1CmCRYMOvY/+C<br>
    45VWBj6foUYG/kq3QISm+lptVDQlESlAizHdWNkc9HJpKZG3VkNmmxEEXm3o7J07<br>
    LbBQ7bR2MELE6lP2Z3ImTXxZe0ZBdjyjDDV3qsIGK9D7LCK31KE70ZIueE3bePmR<br>
    9xWBfzKbm6Y3cQ6+4E8p8US7woVs9LGWXzLdKQyKEoiDx16bF7SOGvSyYcnOPsNu<br>
    O7lVpGh8Pezb0ZLEx5UnM5ONm35PzmzAT9Ng2iMEhche3AQS4s/b+wVWpyclQ62e<br>
    X4UVSr2O1mbfI9CmCPfI<br>
    =qcA8<br>
    -----END PGP SIGNATURE-----<br>
    <br>
  </body>
</html>

--------------070007050809000304080205--