Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 512988DD for ; 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 ; Thu, 6 Aug 2015 23:52:42 +0000 (UTC) Received: by qkdv3 with SMTP id v3so32153358qkd.3 for ; 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 Date: Thu, 06 Aug 2015 23:52:32 +0000 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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>

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.

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)

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

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.

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.

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.


--001a1136ea6608c971051cad373f--