diff options
| author | Btc Drak <btcdrak@gmail.com> | 2015-08-17 11:51:26 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-17 10:51:48 +0000 |
| commit | 036390ab5f58927998b5840a4d739dbdcdbf1c0b (patch) | |
| tree | 814361149dc8a68755495b220180d8dd7531996f /5b | |
| parent | 86b7d75028bb7404feafad8a7e27667bf6afdf42 (diff) | |
| download | pi-bitcoindev-036390ab5f58927998b5840a4d739dbdcdbf1c0b.tar.gz pi-bitcoindev-036390ab5f58927998b5840a4d739dbdcdbf1c0b.zip | |
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Diffstat (limited to '5b')
| -rw-r--r-- | 5b/ab114c473199b548be5285270c174fc0e2a8f7 | 229 |
1 files changed, 229 insertions, 0 deletions
diff --git a/5b/ab114c473199b548be5285270c174fc0e2a8f7 b/5b/ab114c473199b548be5285270c174fc0e2a8f7 new file mode 100644 index 000000000..6a83f233b --- /dev/null +++ b/5b/ab114c473199b548be5285270c174fc0e2a8f7 @@ -0,0 +1,229 @@ +Return-Path: <btcdrak@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 6EF0E259 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 17 Aug 2015 10:51:48 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com + [209.85.160.176]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8976E8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 17 Aug 2015 10:51:46 +0000 (UTC) +Received: by ykdt205 with SMTP id t205so122418067ykd.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 17 Aug 2015 03:51:46 -0700 (PDT) +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 + :cc:content-type; + bh=tKTE0LSQoFuFbdXmrnY10wrpWPMvPoJubWAetibu0A8=; + b=ifcqggvRB8fK8/khkEOi/Ra117B2zXUHjR7S1QhiRh/7cVDTUN4xNRqMShlJHyzCJd + lbJ4s7mML4BrgdnkDDYEuP0nNRgJpqTakvyjJAfvqDBQZ8EHVofMyf3bwNQbuhOCqzIu + HJvrPWGpC6WIVE/Ec0HAugUAyY+iShF6oHqcGn8kEiMDZm9AKa1aTPdNv+5Cq5+QCKXj + AYarflnGiTDDSdQeMpio4E9RoJvnQhgbt1PugoJdxWI+kH7p5sMK8Rerb5P+65rk6Q/g + fScJ0t9xlr8EZTxHB4/fmgjW37ppMcYSP1nLVg293BYsdVcH+IjqA2XsKX/F8H53H5BC + /5PA== +X-Received: by 10.13.254.1 with SMTP id o1mr682569ywf.88.1439808705871; Mon, + 17 Aug 2015 03:51:45 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.37.94.132 with HTTP; Mon, 17 Aug 2015 03:51:26 -0700 (PDT) +In-Reply-To: <55D1B077.6070208@gmail.com> +References: <CAED3CWjfWAC-6=5P8OWx-1eP6Dq52K=c1L5B7h6fjGb71e-STw@mail.gmail.com> + <55D1B077.6070208@gmail.com> +From: Btc Drak <btcdrak@gmail.com> +Date: Mon, 17 Aug 2015 11:51:26 +0100 +Message-ID: <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=vVyw@mail.gmail.com> +To: Patrick Strateman <patrick.strateman@gmail.com> +Content-Type: multipart/alternative; boundary=94eb2c0809f4754534051d7f96b4 +X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, + HK_RANDOM_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10, + 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 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap +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: Mon, 17 Aug 2015 10:51:48 -0000 + +--94eb2c0809f4754534051d7f96b4 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: +> Nobody is going to click that... + +I guess I am nobody. Here's a copy of the text:- + +*Dynamically Controlled Bitcoin Block Size Max Cap +<http://upalc.com/maxblocksize.php>* + +*Assumption*: This article is for those, who already understand the bitcoin +protocol and aware of the block size controversy. Details of the problem +statement can be found in BIP 100 +<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>. +Satoshi's opinion regarding block size can be found here +<https://bitcointalk.org/index.php?topic=3D1347.msg15366#msg15366>. I will = +be +directly going into the solution without explaining the problem in details. + + +*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016 +block each full node does a calculation to find the next target. We will do +just another calculation here. Nodes will also calculate what % of blocks +in the last difficulty period is higher than 90% of the maximum block size, +which is 1 MB for now. If it is found that more than 90% blocks in the last +difficulty period is higher than 90% of the maximum block size, then double +the maximum block size. If not, then calculate what % of blocks in the last +difficulty period is less than 50% of the maximum block size. If it is +higher than 90%, then half the maximum block size. If none of the above +condition satisfies, keep the maximum block size as it is. + +Please note that, while calculating the % of blocks, it is better to take +into account the first 2000 of the 2016, than the whole of 2016. This helps +to avoid the calculation mistake if some of the last few blocks get +orphaned. + + +*Reasoning*: This solution is derived directly from the indication of the +problem. If transaction volume increases, then we will naturally see bigger +blocks. On the contrary, if there are not enough transaction volume, but +maximum block size is high, then only few blocks may sweep the mempool. +Hence, if block size is itself taken into consideration, then maximum block +size can most rationally be derived. Moreover, this solution not only +increases, but also decreases the maximum block size, just like difficulty. + + +*Other Solutions of this Problem*:- + +Making Decentralized Economic Policy +<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by +Jeff Garzik + +Elastic block cap with rollover penalties +<https://bitcointalk.org/index.php?topic=3D1078521> =E2=80=93 by Meni Rosen= +feld + +Increase maximum block size +<https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by Gavin +Andresen + +Block size following technological growth +<https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille + +The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments +<https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon & +Thaddeus Dryja + + +Please share your opinion regarding this solution below. For mail +communication, feel free to write me at bitcoin [at] upalc.com. + + +> On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote: +> +> I have tried to solve the maximum block size debate, depending on the +> previous block size calculation. +> +> Requesting for comment - http://upalc.com/maxblocksize.php +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--94eb2c0809f4754534051d7f96b4 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bi= +tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc= +oin-dev@lists.linuxfoundation.org</a>> wrote:<br>> Nobody is going to= + click that...<br><br>I guess I am nobody. Here's a copy of the text:-<= +br><br><div align=3D"center" style=3D"color:rgb(0,0,0);font-family:'Tim= +es New Roman';font-size:medium"><font size=3D"4"><strong><a href=3D"htt= +p://upalc.com/maxblocksize.php">Dynamically Controlled Bitcoin Block Size M= +ax Cap</a></strong>=C2=A0<br></font></div><br style=3D"color:rgb(0,0,0);fon= +t-family:'Times New Roman';font-size:medium"><table width=3D"600" a= +lign=3D"center" style=3D"font-family:'Times New Roman'"><tbody><tr>= +<td width=3D"90%"><p align=3D"justify"><b>Assumption</b>: This article is f= +or those, who already understand the bitcoin protocol and aware of the bloc= +k size controversy. Details of the problem statement can be found in=C2=A0<= +a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf"= + target=3D"_blank">BIP 100</a>. Satoshi's opinion regarding block size = +can be found=C2=A0<a href=3D"https://bitcointalk.org/index.php?topic=3D1347= +.msg15366#msg15366" target=3D"_blank">here</a>. I will be directly going in= +to the solution without explaining the problem in details.<br><br><br><b>So= +lution</b>: Difficulty changes at every 2016 block, i.e. at every 2016 bloc= +k each full node does a calculation to find the next target. We will do jus= +t another calculation here. Nodes will also calculate what % of blocks in t= +he last difficulty period is higher than 90% of the maximum block size, whi= +ch is 1 MB for now. If it is found that more than 90% blocks in the last di= +fficulty period is higher than 90% of the maximum block size, then double t= +he maximum block size. If not, then calculate what % of blocks in the last = +difficulty period is less than 50% of the maximum block size. If it is high= +er than 90%, then half the maximum block size. If none of the above conditi= +on satisfies, keep the maximum block size as it is.<br><br>Please note that= +, while calculating the % of blocks, it is better to take into account the = +first 2000 of the 2016, than the whole of 2016. This helps to avoid the cal= +culation mistake if some of the last few blocks get orphaned.<br><br><br><b= +>Reasoning</b>: This solution is derived directly from the indication of th= +e problem. If transaction volume increases, then we will naturally see bigg= +er blocks. On the contrary, if there are not enough transaction volume, but= + maximum block size is high, then only few blocks may sweep the mempool. He= +nce, if block size is itself taken into consideration, then maximum block s= +ize can most rationally be derived. Moreover, this solution not only increa= +ses, but also decreases the maximum block size, just like difficulty.<br><b= +r><br><b>Other Solutions of this Problem</b>:-<br><br><a href=3D"http://gtf= +.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf" target=3D"_blank">M= +aking Decentralized Economic Policy</a>=C2=A0- by Jeff Garzik<br><br><a hre= +f=3D"https://bitcointalk.org/index.php?topic=3D1078521" target=3D"_blank">E= +lastic block cap with rollover penalties</a>=C2=A0=E2=80=93 by Meni Rosenfe= +ld<br><br><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0101.m= +ediawiki" target=3D"_blank">Increase maximum block size</a>=C2=A0- by Gavin= + Andresen<br><br><a href=3D"https://gist.github.com/sipa/c65665fc360ca7a176= +a6" target=3D"_blank">Block size following technological growth</a>=C2=A0- = +by Pieter Wuille=C2=A0<br><br><a href=3D"https://lightning.network/lightnin= +g-network-paper.pdf" target=3D"_blank">The Bitcoin Lightning Network: Scala= +ble Off-Chain Instant Payments</a>=C2=A0- by Joseph Poon & Thaddeus Dry= +ja=C2=A0<br><br><br>Please share your opinion regarding this solution below= +. For mail communication, feel free to write me at bitcoin [at] <a href=3D"= +http://upalc.com">upalc.com</a>.</p></td></tr></tbody></table><br><br>> = +On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:<br>><br>= +> I have tried to solve the maximum block size debate, depending on the<= +br>> previous block size calculation.<br>><br>> Requesting for com= +ment - <a href=3D"http://upalc.com/maxblocksize.php">http://upalc.com/maxbl= +ocksize.php</a><br>><br>><br>> ___________________________________= +____________<br>> bitcoin-dev mailing list<br>> <a href=3D"mailto:bit= +coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</= +a><br>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bi= +tcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</= +a><br>><br>><br>><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">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br= +>><br></div> + +--94eb2c0809f4754534051d7f96b4-- + |