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 AD0D0308 for ; Sun, 30 Aug 2015 18:56:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8FCBE8 for ; Sun, 30 Aug 2015 18:56:24 +0000 (UTC) Received: by widfa3 with SMTP id fa3so3946072wid.1 for ; Sun, 30 Aug 2015 11:56:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aa6c7nuL4qSjLxyr9fc2Q54GMsuaMSr/mevvuOZLYY0=; b=XnVsyKm4Abec4DDphI4n3Paiq/VOy9GlYcSVwlYjFnCyyj4pT91gBWBId0IsNXSTAo k4UWkFzIaAiS/HPieRnf605P4yMTItu/o+lnqgn/qB1gocLnzgAA7T05lENwGBoLkFGN CXMjEs3cWza1IrhggA0Aaai4EXymsgqmURJPy4JTG0hh8NL7tRzKPf0olriLvBE37zTg UxtHS7+JipKZgjmLL6n90JgCqD0sBhSwJH614hck4wU28ldxEDbxVj8ALalWPRi70R7+ c7GiEMfI9oC3VFWgpC7clO/HbmpoH/2HXOoU++uMq977zzytXdsAfbGD6TLDBGykKwjm ugew== X-Gm-Message-State: ALoCoQnqoZ3ATHt/VoR/f7t/X6bP+V8uc5Xt6sKZ/DN5bLSNAliITB7s6a7ty0ONKRhfEPVHe5jG MIME-Version: 1.0 X-Received: by 10.180.39.136 with SMTP id p8mr8241991wik.92.1440960983111; Sun, 30 Aug 2015 11:56:23 -0700 (PDT) Received: by 10.194.64.234 with HTTP; Sun, 30 Aug 2015 11:56:22 -0700 (PDT) In-Reply-To: <8faa4df0135b558e5cd064ccaec09e73@xbt.hk> References: <2081355.cHxjDEpgpW@crushinator> <8faa4df0135b558e5cd064ccaec09e73@xbt.hk> Date: Sun, 30 Aug 2015 20:56:22 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: jl2012@xbt.hk Content-Type: text/plain; charset=UTF-8 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 18:56:25 -0000 On Sun, Aug 30, 2015 at 7:13 PM, wrote: > 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 > [...] No, I'm not making such assumption. I'm focusing on what they CAN do, while suspending judgement on their good will and not trying to predict their future behavior from historic behaviour. With 60% of the hashrate, you can easily get 100% by orphaning everybody else's blocks. More importantly, being under the same jurisdiction they can be forced to behave in certain way (for example, censor transactions) by law. I'm very worried about the current situation no matter how benevolent current miners are. Thus weakening the only limit to mining centralization that we have at the consensus rule level seems extremely risky at this point. > 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) My point is, a "soft cap" determined by miners clearly doesn't protect us from mining centralization: the "hard cap" does. Knowing that, and given that miners can currently set their own policy block size maximum, what does this "voting on a lower limit" achieve? What are the gains? Why are we "lucky" if they keep the lower one as low as possible? > 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. Thank you for admitting it is not urgent! I suggested 5 years for the concrete hardfork in bip99 because it's clearly non-urgent and I wanted to be very conservative. I'm happy to reduce that to say, 1 year (specially given that the change is very simple to implement). For a simple block size change (like, say bip102) 1 year (maybe 6 months + miner's confirmation) is probably more than enough as well. And we can always deploy an urgency hardfork if it is necessary. > 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. Fortunately we haven't been discussing this for 5 years, I don't know where you get that from. A schism fork it's certainly always a possibility but I would only consider it after an urgency hardfork (once the issue becomes urgent) fails due to not being uncontroversial. Would you agree with me on that? What would be your criterion for considering an increase in block size urgent? Mine is: we should consider a block increase only when minimum market fees for transactions to be mined (currently zero satoshis) increase above a high fee (admittedly undefined, but certainly greater than zero). Even if it's "urgent", I think we should only increase the maximum if, at the same time, the new size can be considered safe mining-centralization-wise (unfortunately we don't have any metric to measure that nor enough tools to realistically simulate different sizes in different network topologies at the moment). But once we have them, the next discussion will be much simpler, so I don't see the need for block size maximum that changes over time (neither exponentially nor linearly). Would you agree with me that mining centralization should be the most important criterion when changing the block size maximum rule rather than the level of minimum fees? If the community can't agree on this, I'm afraid there will be a schism hardfork eventually. Another possibility is that those who aren't concerned with mining centralization start their own altcoin (centralizedcoin? ), maybe a spinoff [ https://bitcointalk.org/index.php?topic=563972.0 ] if they want to keep Bitcoin's utxo at the moment of the separation. But if the community agrees with this and just disagrees on the maximum block size consensus rule having any effect on mining centralization (like Gavin and I disagree), we should calm down and use scientific processes to find out what the relation between the two actually is (if there's any relation at all). Would you agree with me on this?