From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqNoI-0000Zn-D3 for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 15:34:02 +0000 Received: from mail-wi0-f170.google.com ([209.85.212.170]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqNoG-0005b6-MM for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 15:34:02 +0000 Received: by wizk4 with SMTP id k4so247648956wiz.1 for ; Thu, 07 May 2015 08:33:54 -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=KT/OB5EbCcLgo70C8cH6e6SEJGavUPN1utIDb9rxcJ8=; b=WNLV7CmSqr6z2aA+AwyaWRJG4MOPtAP7PpRKI9LnFQ+n8ZmmB6Uetxrp5nnK4uuZX4 FDsq0cs2EL8AKHGSQ3N7UpaFLBqbgj5yjd29HnAeaH+0Cj67h16NS0iBc32sylsta7Gg yfDiNkOS9kT2FYLi/pUpieXsD8wEOpskekSqfmf0sN4ZaYAIZt/HX1V51BeqUnu2yOjP Q9KnF9DR1HqojLdSps+HCGwYE94mav3RE7X0iWJobPm2EL0tc3LeMvN3wSlDVX1OdHEQ KNyBaieDLadt8b0hlKmTGkd1EdOKRqgWD5ieMZ5TCuwaIe3Ihg+D36m1nMtcI95yRN65 N95g== X-Gm-Message-State: ALoCoQkPqZYhQK7Ks197dpwnlEwhF2f/YbydsR74TXsrZ5N3mwXOWqOhkrMCiXQPvd4NH7l3V+C7 MIME-Version: 1.0 X-Received: by 10.180.99.166 with SMTP id er6mr7818803wib.58.1431012834539; Thu, 07 May 2015 08:33:54 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Thu, 7 May 2015 08:33:54 -0700 (PDT) In-Reply-To: References: <554A91BE.6060105@bluematt.me> Date: Thu, 7 May 2015 17:33:54 +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: 1YqNoG-0005b6-MM 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 15:34:02 -0000 On Thu, May 7, 2015 at 4:05 PM, Mike Hearn wrote: >> If his explanation was "I will change my mind after we increase block >> >> size", I guess the community should say "then we will just ignore your >> nack because it makes no sense". > > > Oh good! We can just kick anyone out of the consensus process if we think > they make no sense. > > I guess that means me and Gavin can remove everyone else from the developer > consensus, because we think trying to stop Bitcoin growing makes no sense. > > Do you see the problem with this whole notion? It cannot possibly work. > Whenever you try and make the idea of developer consensus work, what you end > up with is "I believe in consensus as long as it goes my way". Which is > worthless. That is not what I said. Then you demonstrated that it was absurd. That's called a straw man argument and it's a well known fallacy, it is precisely the example of arguments that can be safely ignored. It is an argument against my admittedly vague definition of "non-controversial change". More importantly, I never said anything about "removing anyone", I was always talking about arguments and not people. One person could use fallacious arguments to attack or defend a given proposal and use perfectly valid ones in another, a person can even mix valid and invalid arguments in the same mail. >> One thing is the Bitcoin core project where you could argue that the 5 >> committers decide (I don't know why Wladimir would have any more >> authority than the others). > > > Because he is formally the maintainer. Yes, the maintainer of the Bitcoin core free software project (I cannot stressed this enough, that can be forked by anyone), not the president of Bitcoin the p2p network. > Maybe you dislike that idea. It's so .... centralised. So let's say Gavin > commits his patch, because his authority is equal to all other committers. > Someone else rolls it back. Gavin sets up a cron job to keep committing the > patch. Game over. > > You cannot have committers fighting over what goes in and what doesn't. > That's madness. There must be a single decision maker for any given > codebase. I'm sure that if they become that stupid, developers would move to a fork of the project in no time. >> Ok, so in simple terms, you expect people to have to pay enormous fees >> and/or wait thousands of blocks for their transactions to get included >> in the chain. Is that correct? > > > No. I'll write an article like the others, it's better than email for more > complicated discourse. Ok, thanks in advance. >> As others have said, if the answer is "forever, adoption is always the >> most important thing" then we will end up with an improved version of Visa. > > > This appears to be another one of those fundamental areas of disagreement. I > believe there is no chance of Bitcoin ending up like Visa, even if it is > wildly successful. I did the calculations years ago that show that won't > happen: > > https://en.bitcoin.it/wiki/Scalability > > Decentralisation is a spectrum and Bitcoin will move around on that spectrum > over time. But claiming we have to pick between 1mb blocks and "Bitcoin = > VISA" is silly. Again, I didn't say any of that. My point is that a network that becomes too "centralized" (like visa, that is centralized vs p2p, not vs distributed) doesn't offer any security or decentralization advantage over current networks (and of course I meant that could happen with larger blocks, not 1 MB blocks). I'm sure that's not what the proponents of the size increase want, and I'm not defending 1 MB as a sacred limit or anything, but my question is "where is the limit for them?" Even a limitless block size would technically work because miners would limit it to limit the orphan rate. So "no hardcoded consensus limit on transaction volume/block size" could be a valid answer to the question "what is the right consensus limit to block size?" for which there's no real right answer because there is a tradeoff between transaction volume and centralization. Should we maintain 1 MB forever? Probably not. Is 20 MB a bad size? I honestly don't know. Is this urgent? I don't think so. Should we rush things when we don't have clear answers to many related questions? I don't think so. You think that it is too soon to start restricting transaction volume in any way. You will answer why in your post. When is the right time and what is the right limitation then? I want to have fee competition as soon as possible, at least temporarily. But you say that it can wait for later. Ok, when do you think we should make that happen then? When 20 MB are full, will that be the right time to let the fee market develop then or will it be urgent to increase the block size again? Should we directly remove the limit then and let miners handle it as they want? If so, why not now? Maybe we can increase to 2 MB, then wait for fee competition, then wait for 2 more subsidy halvings and then increase to 11 or 20 MB? There's so many possibilities that I don't understand how can be surprising that "20 MB, as soon as possible" is not the obvious answer to everyone...