From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqOxt-0005rE-VY for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 16:48:01 +0000 Received: from mail-wi0-f169.google.com ([209.85.212.169]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqOxr-000809-Ni for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 16:48:01 +0000 Received: by wiun10 with SMTP id n10so67032356wiu.1 for ; Thu, 07 May 2015 09:47:53 -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=3JbtExqBzViRqT+Gisepaavg3Ca6TL8ae6dibSVxvlk=; b=BsBS5d4DFXKZf86Nj+6MIlFRLZdjhGexc8ySTFD92sMCX9WFrfKN93KeOcRuH76HL3 Cuz8niyF6WiJPag7AJOBDu8DcIt40uZL0uSssCmKh3K6qZ2mQCFvHZJInYJXuhxfIUzM nVFCihbWn/qq16q3QmbNozCsg8YC/FAVQOFc3nCtu3NHr5bl6aUfU2Kr7i6FbD3QFpBA q2otbUkomj+xFj/WXTtaPvtSMwyGSty7eZh6AkcEtl5T5t24lCFrTFZbHNuSj9YGKXzp 4Uz3HtO2n8Z9ptYXfCVwZ5u5HyVgryjxOBgj+4X5o/VELEJIFStyvXdbxtcoSUhhWKDD /0ew== X-Gm-Message-State: ALoCoQmfKr4O7QR+i9R6C7OiyRDstzk5JsIoAiA0k8lDBXSyX45XEdkwgbuzGVBHM4dBIi3ax7U8 MIME-Version: 1.0 X-Received: by 10.180.105.193 with SMTP id go1mr8167146wib.92.1431017273702; Thu, 07 May 2015 09:47:53 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Thu, 7 May 2015 09:47:53 -0700 (PDT) In-Reply-To: References: <554A91BE.6060105@bluematt.me> Date: Thu, 7 May 2015 18:47:53 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YqOxr-000809-Ni Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:48:02 -0000 On Thu, May 7, 2015 at 6:11 PM, Mike Hearn wrote: >> It is an argument against my admittedly vague definition of >> "non-controversial change". > > > If it's an argument against something you said, it's not a straw man, right > ;) Yes, but it was an argument against something I didn't said ;) > Consensus has to be defined as agreement between a group of people. Who are > those people? If you don't know, it's impossible to decide when there is > consensus or not. > > Right now there is this nice warm fuzzy notion that decisions in Bitcoin > Core are made by consensus. "Controversial" changes are avoided. I am trying > to show you that this is just marketing. Nobody can define what these terms > even mean. It would be more accurate to say decisions are vetoed by whoever > shows up and complains enough, regardless of technical merit. Yes, that's why I drafted a definition for "uncontroversial change" rather than "change accepted by consensus". It will still be vague and hard to define, but consensus seems much harder. And, yes, you're right, it is more like giving power to anyone with valid arguments to veto hardfork changes. But as you say, that could lead to make hardforks actually impossible, so we should limit what constitutes a valid argument. I later listed some examples of invalid arguments: logical fallacies, unrelated arguments, outright lies. Certainly I don't think technical merits should count here or that we could veto a particular person from vetoing. We should filter the arguments, not require an identity layer to blacklist individuals. We should even accept arguments from anonymous people in the internet (you know, it wouldn't be the first time). > Unfortunately it's hard to know what other kinds of meet-in-the-middle > compromise could be made here. I'm sure Gavin would consider them if he > knew. But the concerns provided are too vague to address. There are no > numbers in them, for example: > > We need more research -> how much more? Some research at all about fee market dynamics with limited size that hasn't happened at all. If we're increasing the consensus max size maybe we could at least maintain the 1MB limit as a standard policy limit, so that we can study it a little bit (like we could have done instead of removing the initial policy limit). > I'm not against changing the size, just not now -> then when? I don't know yet, but I understand now that having a clearer roadmap is what's actually urgent, not the change itself. > I'm not wedded to 1mb, but not sure 20mb is right -> then what? What about 2 MB consensus limit and 1 MB policy limit for now? I know that's arbitrary too. > Full node count is going down -> then what size do you think would fix that? > 100kb? As others have explained, the number of full nodes is not the improtant part, but how easy it is to run one. I think a modest laptop with the average internet connection of say, India or Brazil, should be able to run a full node. I haven't made those numbers myself but I'm sure that's possible with 1 MB blocks today, and probably with 2 MB blocks too. > It will make mining more centralised -> how do you measure that and how much > centralisation would you accept? This is an excellent question for both sides. Unfortunately I don't know the answer to this. Do you?