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 3DF0D481 for ; Fri, 31 Jul 2015 14:33:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B401C1C9 for ; Fri, 31 Jul 2015 14:33:16 +0000 (UTC) Received: by wicmv11 with SMTP id mv11so60605329wic.0 for ; Fri, 31 Jul 2015 07:33:15 -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=kytUwBBsA4G2K339vEXdMXsyzXau+tEBFGjtS2SuO58=; b=P9NrS9zuQLFSZ6Zb0Ay4F5NUeqFlLIYqMQXAHNkDEcnOLdas4KybiD548rgDKUXfCK +2q5GzxOiB2L8xQ9lerPPVZ+w4VamOP1XROw3i3K7tW44UNiAbn0f5OxMr9DqILnO1Ds U5z8EPO98TwBMqRQr2om2I39gci4QQMn7YJ/AkMq+nT3nUdVVJ3MK13IIpzJK530gSkj auVLZYfEaGE9HL1RzBkPNU9WNhZIxmTKn7Yl9++nqhXpdp/+6j5VKwOkFDZOnHDJ5aob +q3cYaT6Ga24SXeYtb1IpsXtpZ6leEYvWTXtTgrcpAbEeNLLUFbCDBqhHaW3tkoOWN2P 28nw== X-Gm-Message-State: ALoCoQn9KVPW5t0RWyqb5rJoA1vVA/h9uOSYjYzFejUoECUaYCFpO7q1MSgnUlvhsHRBBVzQLvya MIME-Version: 1.0 X-Received: by 10.181.13.169 with SMTP id ez9mr6568263wid.92.1438353195082; Fri, 31 Jul 2015 07:33:15 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Fri, 31 Jul 2015 07:33:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Jul 2015 16:33:14 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Mike Hearn 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] Block size following technological growth 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: Fri, 31 Jul 2015 14:33:18 -0000 On Fri, Jul 31, 2015 at 2:15 PM, Mike Hearn wrote: > Hey Jorge, > >> He is not saying that. Whatever the reasons for centralization are, it >> is obvious that increasing the size won't help. > > > It's not obvious. Quite possibly bigger blocks == more users == more nodes > and more miners. How more users or more nodes can bring more miners, or more importantly, improve mining decentralization? > To repeat: it's not obvious to me at all that everything wrong with Bitcoin > can be solved by shrinking blocks. I don't think that's going to suddenly > make everything magically more decentralised. I don't think anybody is defending that position so you can stop refuting it. > The 8mb cap isn't quite arbitrary. It was picked through negotiation with > different stakeholders, in particular, Chinese miners. But it should be high > enough to ensure organic growth is not constrained, which is good enough. Well, negatiations don't make the number less arbitrary. As far as I know, the sequence of events was this: 1) Gavin proposes 20MB to 20GB 2) Some chinese miners say they can securely handle at most 8 MB. 3) Gavin proposes 8 MB to 8 GB In any case, history is irrelevant for this point: if party 1 proposes arbitrary value A and party 2 proposes arbitrary value B, any "compromise" value between those 2 is still an arbitrary value. For example, A + ((B-A)/2) is still an arbitrary value. I'm sorry, but until there's a simulation that I can run with different sizes' testchains (for example using #6382) to somehow compare them, I will consider any value arbitrary. A "I run this with blocksize=X and nothing seems to have broken" doesn't help here. We need to compare, and a criterion to compare. >> I think it would be nice to have some sort of simulation to calculate >> a "centralization heuristic" for different possible blocksize values >> so we can compare these arbitrary numbers somehow. > > > Centralization is not a single floating point value that is controlled by > block size. It's a multi-faceted and complex problem. You cannot "destroy > Bitcoin through centralization" by adjusting a single constant in the source > code. Agreed on the first sentence, I'm just saying that the influence of the blocksize in that function is monotonic: with bigger sizes, equal or worse mining centralization. About the second sentence, yes, I could destroy Bitcoin by changing one single constant if I could somehow force users to adopt my version of the software. I'm sure I can actually find several examples if necessary. "Through centralization" is harder, but say we chose std::numeric_limits::max() as the maximum block size (in practice, entirely removing the block size limit), then the consensus rules don't have any rule to limit mining centralization. Sacrificing that tool, and doing so this early on could certainly turn Bitcoin into an effectively centralized system, destroying Bitcoin (or at least the "p2p currency" part of it, which is the most interesting one for many Bitcoin users including me). So, once it's clear that nobody is saying that centralization depends ONLY on the block size, can you tell us please if you think it's useful for limiting mining centralization or not? If you think the blocksize consensus limit does nothing to limit centralization then there's no tradeoff to consider and you should be consequently advocating for full removal of the limit rather than changes towards bigger arbitrary values. Otherwise you may want to explain why you think 8 GB is enough of a limit to impede further centralization. > To say once more: block size won't make much difference to how many > merchants rely on payment processors because they aren't using them due to > block processing overheads anyway. So trying to calculate such a formula > won't work. Ditto for end users on phones, ditto for developers who want > JSON/REST access to an indexed block chain, or hosted wallet services, or > miners who want to reduce variance. Sorry, I don't know about Pieter, but I was mostly talking about mining centralization, certainly not about payment services. > What people like you are Pieter are doing is making a single number a kind > of proxy for all fears and concerns about the trend towards outsourcing in > the Bitcoin community. Everything gets compressed down to one number you > feel you can control, whether it is relevant or not. No, that's not what we are doing. It's good that you talk about your fears but, please, let other people talk about theirs on their own. >> > So why should anyone go through the massive hassle of setting up >> > exchanges, >> > without the lure of large future profits? >> >> Are you suggesting that bitcoin consensus rules should be designed to >> maximize the profits of Bitcoin exchanges? > > > That isn't what I said at all Jorge. Let me try again. > > Setting up an exchange is a lot of risky and expensive work. The motivation > is profit, and profits are higher when there are more users to sell to. This > is business 101. I can imagine a non-for-profit exchange but there's no point in finding edge cases: no general disagreement here. > If you remove the potential for future profit, you remove the motivation to > create the services that we now enjoy and take for granted. Because if you > think Bitcoin can be useful without exchanges then let me tell you, I was > around when there were none. Bitcoin was useless. My first post on the bitcoin forums (and vague hardfork proposal, I started reading in December 2010) was January 21, 2011 (vs yours Dec 14th 2010, as Greg pointed out in the other thread). I bought my first bitcoins (and also sold most of them shortly after, stupid me) using some web that used paypal and was closed down not too long after that. At first I couldn't participate in exchanges because I had no Liberty Reserve account... Look, I'm sure there's many stories about how we met Bitcoin that we can share having a beer in a bar or something. But probably most of the subscribers to this list don't really care, and if they care they can ask us privately, or you can create a new thread (probably better in bitcointalk or somewhere else than here): they are completely irrelevant in this technical discussion. So, back on-topic: do I agree that exchanges are extremely important for the Bitcoin ecosystem? Yes, of course I do. But that doesn't mean that their "potential for future profit" should be a primary concern when deciding consensus rules changes that affect ALL users. But even before that, I disagree with the premise that "not rising the consensus blocksize as soon as possible" will ruin the exchanges or "remove their potential for future profit".