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 D4D09919 for ; Sun, 30 Aug 2015 17:13:57 +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 069F31F6 for ; Sun, 30 Aug 2015 17:13:55 +0000 (UTC) Received: from localhost ([::1]:43880 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZW6B0-003VLi-MX; Sun, 30 Aug 2015 13:13:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 30 Aug 2015 13:13:54 -0400 From: jl2012@xbt.hk To: =?UTF-8?Q?Jorge_Tim=C3=B3n?= In-Reply-To: References: <2081355.cHxjDEpgpW@crushinator> Message-ID: <8faa4df0135b558e5cd064ccaec09e73@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 Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 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: Sun, 30 Aug 2015 17:13:57 -0000 Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到: > > I still don't see the point in having a lower moving size maximum. > If 8 MB is mining-centralization-safe, let's move directly to 8 MB > without adding this seemingly useless extra complexity. > If it's not, mining voting on a lower moving maximum won't make it > safer. > > Once we have more objective tools (centralization metrics, simulators, > etc...) to determine whether or not a block size is > mining-centralization-safe for a given point in time (looking at > current centralization and current technology available), I don't see > the problem with repeating the equivalent of bip102 periodically > (every 2 years?) to adapt the size to better technology or lower > mining centralization. > It would be also helpful to have a tool to somehow measure "size > increase urgency" (ie right now free transactions get mined and blocks > aren't full or close to be full, I don't think the current general > sense of urgency on this matter is justified). > > With all respect, I believe bip100 and this proposal are > over-engineering; and bip101 and bip103 (pieter's) are > overly-optimistic (in their exponential technological growth > assumptions). This is based on the assumption that miners would always like to use up the last byte of the available block size. However, this is just not true: 1. The 6 year blockchain history has shown that most miners have a soft cap with their block size. 2. Chinese miners, controlling 60% of the network, rejected Gavin's initial 20MB proposal and asked for 8MB: http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size 3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with 8MB as a mid-term goal: https://vip.btcchina.com/page/noticetemplate?id=100. BTCChina is controlling 12% of the network in the past month. If BIP100 uses the 20-percentile vote as the block size, it takes only 8% more vote to keep the size at 2MB For many reasons miners may want to have a smaller block size, which we don't need to list them here. Although they can limit it by a softfork or even 51% attack, it is a very violent process. Why don't we just allow them to vote for a lower limit? So I think the right way is to choose a mining-centralization-safe limit, and let it free float within a range based on miner's vote. If we are lucky enough to have some responsible miners, they will keep it as low as possible, until the legitimate tx volume catches up. Even in the worst case, the block size is still mining-centralization-safe. The upper limit may increase linearly, if not exponentially, until we find a better long-term solution. (sort of a combination of BIP100 and 101, with different parameters) -------- For the matter of "urgency", I agree with you that there is no actual urgency AT THIS MOMENT. However, if a hardfork may take 5 years to deploy (as you suggested), we really have the urgency to make a decision now. Actually, the main point is not urgency but uncertainty. We have debated for 5 years. Why won't we have 5 more years of debate, plus 5 years of deployment delay? Are we sticking to 1MB for 10 years? In that case Bitcoin Core must be abandoned by the economic majority and a Schism fork must occur.