diff options
author | jl2012 <jl2012@xbt.hk> | 2015-08-07 01:20:21 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-07 05:21:13 +0000 |
commit | 99f43d3565fa0d20bb6ece7774b7757e8b47bdd7 (patch) | |
tree | 9b9ac45631e894158439fb4854f9519f8ee6bbcd /4c/332a73075cbd7a957e3860ef9f561b56259115 | |
parent | 842daee75690fd1635c073dc21fcc88688ac9ecb (diff) | |
download | pi-bitcoindev-99f43d3565fa0d20bb6ece7774b7757e8b47bdd7.tar.gz pi-bitcoindev-99f43d3565fa0d20bb6ece7774b7757e8b47bdd7.zip |
Re: [bitcoin-dev] Block size implementation using Game Theory
Diffstat (limited to '4c/332a73075cbd7a957e3860ef9f561b56259115')
-rw-r--r-- | 4c/332a73075cbd7a957e3860ef9f561b56259115 | 122 |
1 files changed, 122 insertions, 0 deletions
diff --git a/4c/332a73075cbd7a957e3860ef9f561b56259115 b/4c/332a73075cbd7a957e3860ef9f561b56259115 new file mode 100644 index 000000000..7cefe857f --- /dev/null +++ b/4c/332a73075cbd7a957e3860ef9f561b56259115 @@ -0,0 +1,122 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 5230197 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <jl2012@xbt.hk>) + 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 <maveric100@gmail.com> +In-Reply-To: <CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com> +References: <CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com> +Message-ID: <ee3ac5ef1febb7d9a66d89c41543a64f@xbt.hk> +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 <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: 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 + + |