summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorWes Green <maveric100@gmail.com>2015-08-06 23:52:32 +0000
committerbitcoindev <bitcoindev@gnusha.org>2015-08-06 23:52:43 +0000
commit22e1e596ad4cdb6cbe6ef09ac0e600ce6cde5e66 (patch)
treec9297805efa101260c54774aad632ca2743442c6
parent33718b565d4c14afaca60fa19a926afe4f1491b2 (diff)
downloadpi-bitcoindev-22e1e596ad4cdb6cbe6ef09ac0e600ce6cde5e66.tar.gz
pi-bitcoindev-22e1e596ad4cdb6cbe6ef09ac0e600ce6cde5e66.zip
[bitcoin-dev] Block size implementation using Game Theory
-rw-r--r--5c/5c11a4690c95bd6297c2043bc8585f3c81801c158
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 &quot;block size issue&quot; 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&#39;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&#39;s law of =
+Nielsen&#39;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 &quot;how&quot; 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--
+