From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5230197 for ; Fri, 7 Aug 2015 05:21:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2ACD30 for ; Fri, 7 Aug 2015 05:21:12 +0000 (UTC) Received: from localhost ([::1]:45916 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZNa4w-002sQG-N3; Fri, 07 Aug 2015 01:20:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 07 Aug 2015 01:20:21 -0400 From: jl2012@xbt.hk To: Wes Green In-Reply-To: References: Message-ID: X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [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: Fri, 07 Aug 2015 05:21:13 -0000 It won't work as you thought. If a miner has 95% of hashing power, he would have 95% of chance to find the next block and collect the penalty. In long term, he only needs to pay 5% penalty. It's clearly biased against small miners. Instead, you should require the miners to burn the penalty. Whether this is a good idea is another issue. Wes Green via bitcoin-dev 於 2015-08-06 19:52 寫到: > 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. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev