diff options
author | Wes Green <maveric100@gmail.com> | 2015-08-06 23:52:32 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-06 23:52:43 +0000 |
commit | 22e1e596ad4cdb6cbe6ef09ac0e600ce6cde5e66 (patch) | |
tree | c9297805efa101260c54774aad632ca2743442c6 | |
parent | 33718b565d4c14afaca60fa19a926afe4f1491b2 (diff) | |
download | pi-bitcoindev-22e1e596ad4cdb6cbe6ef09ac0e600ce6cde5e66.tar.gz pi-bitcoindev-22e1e596ad4cdb6cbe6ef09ac0e600ce6cde5e66.zip |
[bitcoin-dev] Block size implementation using Game Theory
-rw-r--r-- | 5c/5c11a4690c95bd6297c2043bc8585f3c81801c | 158 |
1 files changed, 158 insertions, 0 deletions
diff --git a/5c/5c11a4690c95bd6297c2043bc8585f3c81801c b/5c/5c11a4690c95bd6297c2043bc8585f3c81801c new file mode 100644 index 000000000..5f293612c --- /dev/null +++ b/5c/5c11a4690c95bd6297c2043bc8585f3c81801c @@ -0,0 +1,158 @@ +Return-Path: <maveric.all@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 512988DD + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Aug 2015 23:52:43 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com + [209.85.220.175]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3661173 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Aug 2015 23:52:42 +0000 (UTC) +Received: by qkdv3 with SMTP id v3so32153358qkd.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 06 Aug 2015 16:52:41 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:from:date:message-id:subject:to:content-type; + bh=/i3OvpZvLKKKGPZaVbLEnxjrJ3eRTeQqJ+Re/7AqxEU=; + b=MqPZ/gOmGu13ahpCI/Rnd6EVqmZcsU6MN0ZDdi+iCIicK7j9IFpbtBViiFuoAYXde4 + XsWL6DB1xEW1pkWu7MdKpLn0OyxiZnUJ4k36X3XFABooB6qiawyEqfZtsknbDlydhTgJ + cHzJrOm4mG6Vj4Y2cEV8pzXBrSduJINrd53//+a+Mo+zt8m+URcmUEj1HYHqb/k2yDln + 1LOCz3y+/NEXam7x/y0SCEn3+7Vq+3Xafc2vNx/2l13jSEMCwGieS4JHupk2JMz8VnS5 + +SMgc28+fZS6+s97/0jXGMknMpQN6zlupHWI6s0jVczDLyYtxmAOV5MAIT5MgAW0tiEM + utlg== +X-Received: by 10.55.17.168 with SMTP id 40mr7620273qkr.83.1438905161794; Thu, + 06 Aug 2015 16:52:41 -0700 (PDT) +MIME-Version: 1.0 +From: Wes Green <maveric100@gmail.com> +Date: Thu, 06 Aug 2015 23:52:32 +0000 +Message-ID: <CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com> +To: bitcoin-dev@lists.linuxfoundation.org +Content-Type: multipart/alternative; boundary=001a1136ea6608c971051cad373f +X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_20,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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] Block size implementation using Game Theory +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: Thu, 06 Aug 2015 23:52:43 -0000 + +--001a1136ea6608c971051cad373f +Content-Type: text/plain; charset=UTF-8 + +Bitcoin is built on game theory. Somehow we seem to have forgotten that and +are trying to fix our "block size issue" with magic numbers, projected +percentage growth of bandwidth speeds, time limits, etc... There are +instances where these types of solutions make sense, but this doesn't +appear to be one of them. Lets return to game theory. + +Proposal: Allow any miner to, up to, double the block size at any given +time - but penalize them. Using the normal block reward, whatever +percentage increase the miner makes over the previous limit is taken from +both the normal reward and fees. The left over is rewarded to the next +miner that finds a block. + +If blocks stay smaller for an extended period of time, it goes back down to +the previous limit/ x amount decrease/% decrease (up for debate) + +Why would this work?: Miners only have incentive to do raise the limit when +they feel there is organic growth in the network. Spam attacks, block bloat +etc would have to be dealt with as it is currently. There is no incentive +to raise the size for spam because it will subside and the penalty will +have been for nothing when the attack ends and block size goes back down. + +I believe it would have the nice side effect of forcing miners to hold the +whole block chain. I believe SPV does not allow you to see all the +transactions in a block and be able to calculate if you should be adding +more to your reward transaction if the last miner made the blocks bigger. +Because of this, the miners would also have an eye on blockchain size and +wont want it getting huge too fast (outsize of Moore's law of Nielsen's +Law). Adding to the gamification. + +This system would encourage block size growth due to organic growth and the +penalty would encourage it to be slow as to still keep reward high and +preserve ROE. + +What this would look like: The miners start seeing what looks like natural +network growth, and make the decision (or program an algorithm, the beauty +is it leaves the "how" up to the miners) to increase the blocksize. They +think that, in the long run, having larger blocks will increase their +revenue and its worth taking the hit now for more fees later. They increase +the size to 1.25 MB. As a result, they reward would be 18.75 (75%). The +miner fees were .5BTC. The miner fees are also reduced to .375BTC. Everyone +who receives that block can easily calculate 1) if the previous miner gave +themselves the proper reward 2) what the next reward should be if they win +it. Miners now start building blocks with a 31.25 reward transaction and +miner fee + .125. + +--001a1136ea6608c971051cad373f +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><p style=3D"margin:0px 0px 0.357142857142857em;padding:1px= + 0px;font-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;= +color:rgb(34,34,34)">Bitcoin is built on game theory. Somehow we seem to ha= +ve forgotten that and are trying to fix our "block size issue" wi= +th magic numbers, projected percentage growth of bandwidth speeds, time lim= +its, etc... There are instances where these types of solutions make sense, = +but this doesn't appear to be one of them. Lets return to game theory.<= +/p><p style=3D"margin:0.357142857142857em 0px;padding:1px 0px;font-size:14p= +x;line-height:1.3em;font-family:Verdana,arial,sans-serif;color:rgb(34,34,34= +)">Proposal: Allow any miner to, up to, double the block size at any given = +time - but penalize them. Using the normal block reward, whatever percentag= +e increase the miner makes over the previous limit is taken from both the n= +ormal reward and fees. The left over is rewarded to the next miner that fin= +ds a block.</p><p style=3D"margin:0.357142857142857em 0px;padding:1px 0px;f= +ont-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;color:= +rgb(34,34,34)">If blocks stay smaller for an extended period of time, it go= +es back down to the previous limit/ x amount decrease/% decrease =C2=A0(up = +for debate)</p><p style=3D"margin:0.357142857142857em 0px;padding:1px 0px;f= +ont-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;color:= +rgb(34,34,34)">Why would this work?: Miners only have incentive to do raise= + the limit when they feel there is organic growth in the network. Spam atta= +cks, block bloat etc would have to be dealt with as it is currently. There = +is no incentive to raise the size for spam because it will subside and the = +penalty will have been for nothing when the attack ends and block size goes= + back down.=C2=A0</p><p style=3D"margin:0.357142857142857em 0px;padding:1px= + 0px;font-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;= +color:rgb(34,34,34)">I believe it would have the nice side effect of forcin= +g miners to hold the whole block chain. I believe SPV does not allow you to= + see all the transactions in a block and be able to calculate if you should= + be adding more to your reward transaction if the last miner made the block= +s bigger. Because of this, the miners would also have an eye on blockchain = +size and wont want it getting huge too fast (outsize of Moore's law of = +Nielsen's Law). Adding to the gamification.</p><p style=3D"margin:0.357= +142857142857em 0px;padding:1px 0px;font-size:14px;line-height:1.3em;font-fa= +mily:Verdana,arial,sans-serif;color:rgb(34,34,34)">This system would encour= +age block size growth due to organic growth and the penalty would encourage= + it to be slow as to still keep reward high and preserve ROE.</p><p style= +=3D"margin:0.357142857142857em 0px;padding:1px 0px;font-size:14px;line-heig= +ht:1.3em;font-family:Verdana,arial,sans-serif;color:rgb(34,34,34)">What thi= +s would look like: The miners start seeing what looks like natural network = +growth, and make the decision (or program an algorithm, the beauty is it le= +aves the "how" up to the miners) to increase the blocksize. They = +think that, in the long run, having larger blocks will increase their reven= +ue and its worth taking the hit now for more fees later. They increase the = +size to 1.25 MB. As a result, they reward would be 18.75 (75%). The miner f= +ees were .5BTC. The miner fees are also reduced to .375BTC. Everyone who re= +ceives that block can easily calculate 1) if the previous miner gave themse= +lves the proper reward 2) what the next reward should be if they win it. Mi= +ners now start building blocks with a 31.25 reward transaction and miner fe= +e + .125.</p><p style=3D"margin:0.357142857142857em 0px;padding:1px 0px;fon= +t-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;color:rg= +b(34,34,34)"><br></p></div> + +--001a1136ea6608c971051cad373f-- + |