diff options
| author | Erik <erik.fors@startmail.com> | 2015-11-14 16:25:19 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-11-14 15:25:24 +0000 |
| commit | ed8a9c6e2d6b987e908eb566134b977b3799c51c (patch) | |
| tree | 33cc80f25bce6f131e3ef5f636c17966ee8f36fb | |
| parent | dffad3dc20a233dfc516e5119b51ba4c6c098cac (diff) | |
| download | pi-bitcoindev-ed8a9c6e2d6b987e908eb566134b977b3799c51c.tar.gz pi-bitcoindev-ed8a9c6e2d6b987e908eb566134b977b3799c51c.zip | |
Re: [bitcoin-dev] BIP proposal - Max block size
| -rw-r--r-- | 3f/11f918bf389e68e40048d2a3e71c8264f69f78 | 296 |
1 files changed, 296 insertions, 0 deletions
diff --git a/3f/11f918bf389e68e40048d2a3e71c8264f69f78 b/3f/11f918bf389e68e40048d2a3e71c8264f69f78 new file mode 100644 index 000000000..e4bc1e3e2 --- /dev/null +++ b/3f/11f918bf389e68e40048d2a3e71c8264f69f78 @@ -0,0 +1,296 @@ +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;">> On Friday, November 13, 2015 + 1:07:33 PM Erik via bitcoin-dev wrote:<br> + >> Hi devs. I was discussing the BIP proposals concerning + max block size<br> + >> yesterday in the #bitcoin channel. I believe that BIP101 + fully utilized<br> + >> will outperform consumer hardware soon or later and + thereby centralize<br> + >> Bitcoin. I would therefore like to do a different + proposal:<br> + ><br> + > It doesn't look like you've considered BIP103 or newer BIPs? + Especially, I'd <br> + > suggest you look at and work with John Sacco who just the + other day posted a <br> + > BIP draft very similar-looking to yours. My overall + impression of your summary <br> + > is that it is unnecessarily over-complicated and + underspecified. How does the <br> + > 2^(1/2) block size limit actually work? This is not a very + precise number, so <br> + > it seems liable to produce rounding errors in different + implementations. <br> + > Additionally, the miner voting thing seems pointless since + miners can already <br> + > softfork lower limits. It would be beneficial to express the + current <br> + > possibility so full nodes can enforce it, but this would be + expressed as an <br> + > unlimited simple-majority vote to reduce the limit. Probably + it would be ideal <br> + > to separate this off from the hardfork BIP, since it's fairly + tangent to it.<br> + ><br> + > 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-- + |