diff options
| author | Upal Chakraborty <bitcoin@upalc.com> | 2015-08-18 17:43:48 +0530 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-18 12:13:49 +0000 |
| commit | bec7cabb324dd495846f58734305a74501dc74fa (patch) | |
| tree | ae858d510f237bf15db11aac3def2312eec64aa1 | |
| parent | d14cdf583e6fe7450d23c58b185a941111991c0e (diff) | |
| download | pi-bitcoindev-bec7cabb324dd495846f58734305a74501dc74fa.tar.gz pi-bitcoindev-bec7cabb324dd495846f58734305a74501dc74fa.zip | |
[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
| -rw-r--r-- | e8/03335003e467c9c90148b817887373abcc1ee3 | 147 |
1 files changed, 147 insertions, 0 deletions
diff --git a/e8/03335003e467c9c90148b817887373abcc1ee3 b/e8/03335003e467c9c90148b817887373abcc1ee3 new file mode 100644 index 000000000..1de241f64 --- /dev/null +++ b/e8/03335003e467c9c90148b817887373abcc1ee3 @@ -0,0 +1,147 @@ +Return-Path: <bitcoin@upalc.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id D47587AA + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Aug 2015 12:13:49 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com + [209.85.213.180]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3621819A + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Aug 2015 12:13:49 +0000 (UTC) +Received: by igui7 with SMTP id i7so77976116igu.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Aug 2015 05:13:48 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:date:message-id:subject:from:to + :content-type; + bh=q8vHawa9zkylTkYO17U8B9vdf4nB4dZF0vG4OeZAhEY=; + b=N2A4id6dxnxO0Y83zMOCnphlYoPLQMDZxAXDHByc9l++c+YWwv32CnLWIFUjHOWL+Z + uVL38NSTFf2x8ieT4J6/TgFA0qViByn8gZ68/iF10OBt2z1/jFuLOJSMukovFFQU7SFV + 4RSdbTg4gT6HhzWj7gWt0MeH2g2ft8igGDfueYQ5agAqwfBLx/mtY0YuIEfoEiDalV7m + e6GN0VlBxtjswKknOIFlnEK5ezLBP/QcAcIxyLvpQUomf7ACNjXAT01Hg04QnVPPIF9P + /oOoVQ5KDCn8s/L7W78Zi3ZMnrSzIiFRbU4LlhV9LrpcAcxdzp/pX0nw7boV2djp0nQU + v8aA== +X-Gm-Message-State: ALoCoQkCL4QHv/7WAOmlH2NQezI7Q8ohmBHSD/GpxEaOnQA1/mxAsupGkBYMOqkbIVAbDFkVwDyL +MIME-Version: 1.0 +X-Received: by 10.50.79.202 with SMTP id l10mr20670247igx.7.1439900028572; + Tue, 18 Aug 2015 05:13:48 -0700 (PDT) +Received: by 10.107.18.155 with HTTP; Tue, 18 Aug 2015 05:13:48 -0700 (PDT) +X-Originating-IP: [203.171.245.240] +Date: Tue, 18 Aug 2015 17:43:48 +0530 +Message-ID: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com> +From: Upal Chakraborty <bitcoin@upalc.com> +To: bitcoin-dev@lists.linuxfoundation.org +Content-Type: multipart/alternative; boundary=089e0122aaeeb73789051d94d92d +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: [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: Tue, 18 Aug 2015 12:13:49 -0000 + +--089e0122aaeeb73789051d94d92d +Content-Type: text/plain; charset=UTF-8 + +Regarding: +http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html + + +I am arguing with the following statement here... + +*I see problems to this approach. The biggest one I see is that a miner +> with 11% of hash power could sabotage block size increases by only ever +> mining empty blocks.* + + + +First, I would like to argue from economics' point of view. If someone +wants to hold back the block size increase with 11% hash power by mining +empty blocks, he has to sacrifice Tx fees, which is not economical. 11% +hash power will most likely be a pool and pool miners will find out soon +that they are losing Tx fees because of pool owner's intention. Hence, +they'll switch pool and pool owner will lose out. This is the same reason +why 51% attack will never happen, even if a pool gets more than 51% hash +power. + + +Next, I would like to propose a slightly modified technical solution to +this problem in algorithmic format... + +If more than 50% of block's size, found in the first 2000 of the last +difficulty period, is more than 90% MaxBlockSize + Double MaxBlockSize +Else if more than 90% of block's size, found in the first 2000 of the last +difficulty period, is less than 50% MaxBlockSize + Half MaxBlockSize +Else + Keep the same MaxBlockSize + +This is how, those who want to stop increase, need to have more than 50% +hash power. Those who want to stop decrease, need to have more than 10% +hash power, but must mine more than 50% of MaxBlockSize in all blocks. In +this approach, not only miners, but also the end user have their say. +Because, end users will fill up the mempool, from where miners will take Tx +to fill up the blocks. Please note that, taking first 2000 of the last 2016 +blocks is important to avoid data discrepancy among different nodes due to +orphan blocks. It is assumed that a chain can not be orphaned after having +16 confirmation. + +Looking for comments. + +--089e0122aaeeb73789051d94d92d +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Regarding:=C2=A0<a href=3D"http://lists.linuxfoundation.or= +g/pipermail/bitcoin-dev/2015-August/010295.html">http://lists.linuxfoundati= +on.org/pipermail/bitcoin-dev/2015-August/010295.html</a><div><br><div><br><= +/div><div>I am arguing with the following statement here...</div><div><br><= +/div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= +ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty= +le:solid;padding-left:1ex"><i>I see problems to this approach. The biggest = +one I see is that a miner with 11% of hash power could sabotage block size = +increases by only ever mining empty blocks.</i></blockquote><div><br></div>= +<div><br></div><div>First, I would like to argue from economics' point = +of view. If someone wants to hold back the block size increase with 11% has= +h power by mining empty blocks, he has to sacrifice Tx fees, which is not e= +conomical. 11% hash power will most likely be a pool and pool miners will f= +ind out soon that they are losing Tx fees because of pool owner's inten= +tion. Hence, they'll switch pool and pool owner will lose out. This is = +the same reason why 51% attack will never happen, even if a pool gets more = +than 51% hash power.</div></div></div><div><br></div><div><br></div><div>Ne= +xt, I would like to propose a slightly modified technical solution to this = +problem in algorithmic format...</div><div><br></div><div>If more than 50% = +of block's size, found in the first 2000 of the last difficulty period,= + is more than 90% MaxBlockSize</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +Double MaxBlockSize</div><div><div>Else if more than 90% of block's siz= +e, found in the first 2000 of the last difficulty period, is less than 50% = +MaxBlockSize</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize<= +/div></div><div>Else</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the s= +ame MaxBlockSize</div><div><br></div><div>This is how, those who want to st= +op increase, need to have more than 50% hash power. Those who want to stop = +decrease, need to have more than 10% hash power, but must mine more than 50= +% of MaxBlockSize in all blocks. In this approach, not only miners, but als= +o the end user have their say. Because, end users will fill up the mempool,= + from where miners will take Tx to fill up the blocks. Please note that, ta= +king first 2000 of the last 2016 blocks is important to avoid data discrepa= +ncy among different nodes due to orphan blocks. It is assumed that a chain = +can not be orphaned after having 16 confirmation.</div><div><br></div><div>= +Looking for comments.</div><div><br></div><div><br></div><div><br></div><di= +v><br></div></div> + +--089e0122aaeeb73789051d94d92d-- + |