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 041FB305 for ; Thu, 6 Aug 2015 21:51:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C75DB118 for ; Thu, 6 Aug 2015 21:51:01 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so41796127wib.1 for ; Thu, 06 Aug 2015 14:51:00 -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 :content-transfer-encoding; bh=UppBvbJbL+czVXo1Fyf/TVSGghCr5IfE9qtLPlkT5ak=; b=IXVCa6yZfAyTX0Q91GxpX8Olk3rZUW8SVaU1s48zK3WPG9KwvU+KOFgOuU6AQODFoG FGNe9t0vSN6Q0NGRasqx1G1vRhd6Y8YlaklmF42vgW6X6pmyxzzLzSJsb1h03vIeyhhJ pwSLyeiRzxXkcvoBZVSDRB2mSxJ+0jbJsThTg273q8QA10Y0JUM32gzsGjR5tTC9RY/I cuWLw0Pu0t9Lsm743J3wQCULv3YlJforDa5bPsxdrnBBMzegQOb57LeZdAwJRq964hFY aOeuafSUCD9bAHcqqNTorAVMR52enVbYdPaPZ2/FevIYm/DL6311GJzByX2XN+qZbWF0 46OQ== X-Gm-Message-State: ALoCoQlgTXJjjKbFlfJbYNf2ekCg8zVJu+zoH8m8WoExWP5dKrg/GTne10R31EB1qkWdTyo1cwn5 MIME-Version: 1.0 X-Received: by 10.194.122.97 with SMTP id lr1mr7655209wjb.26.1438897860392; Thu, 06 Aug 2015 14:51:00 -0700 (PDT) Received: by 10.194.31.230 with HTTP; Thu, 6 Aug 2015 14:51:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Aug 2015 23:51:00 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 06 Aug 2015 21:51:03 -0000 Really, thanks again for replying and not getting mad when I get your thoughts wrong. I believe that I've learned more about your position on the subject today than in months of discussion and blogs (that's not a critique to your blog post, it's just that they didn't answer to some questions that I personally needed responded). On Thu, Aug 6, 2015 at 9:42 PM, Gavin Andresen wr= ote: > On Thu, Aug 6, 2015 at 1:15 PM, Jorge Tim=C3=B3n wrote= : >> >> So I reformulate the question: >> >> 1) If "not now", when will it be a good time to let the "market >> minimum fee for miners to mine a transaction" rise above zero? > > > Two answers: > > 1. If you are willing to wait an infinite amount of time, I think the > minimum fee will always be zero or very close to zero, so I think it's a > silly question. I'm very happy to have made the stupid question then. It has revealed another big difference in the fundamental assumptions we're using. My assumption is that for any reasonable size, free transactions will eventually disappear (assuming Bitcoin doesn't "fail" for some other reason). Maybe I'm being too optimistic about the demand side of the market in the long term. In contrast, your assumption seems to be (and please correct me on anything I get wrong) that... "The limit will always be big enough so that free transactions are mined forever. Therefore fees just allow users to prioritize their urgent transactions and relay policies to protect their nodes against DoS attacks. Well, obviously, they also serve to pay for mining in a low-subsidy future, but even with the presence of free transactions, fees will be enough to cover mining costs, or a new mechanisms will be developed to make a low-total-reward blockchain safe or expensive proof of work will be replaced or complemented with something else that's cheaper. The main point is that fees are not a mechanism to decide what gets priced out of the blockchain, because advancements in technology will always give as enough room for free transactions." - jtimon putting words in Gavin's mouth, with the only intention to understand him better. I'm using "free transactions" even though you said "zero or very close to z= ero". To you, "zero or very close to zero" may be the same thing, but to me zero and very close to zero are like...different galaxies. To me, entering the "very close to zero galaxy" is a huge step in the development of the fee market. I've been always assuming that moving from zero to 1 satoshi was precisely what "big block advocates" wanted to avoid. What they meant by "Bitcoin is going to become a high-value only network" and similar things. Knowing that for "big block advocates" zero and "very close to zero" are equally acceptable changes things. > 2. The "market minimum fee" should be determined by the market. It should > not be up to us to decide "when is a good time." I completely agree, but the block size limit is a consensus rule that doesn't adapt to the market. The market will adapt to whatever limit is chosen by the consensus rules. >> 2) Do you have any criterion (automatic or not) that can result in you >> saying "no, this is too much" for any proposed size? > > > Sure, if keeping up with transaction volume requires a cluster of compute= rs > or more than "pretty good" broadband bandwidth I think that's too far. > That's where original 20MB limit comes from, otherwise I'd have proposed = a > much higher limit. > >> Would you agree that blocksize increase proposals should have such a >> criterion/test? > > > Although I've been very clear with my criterion, no, I don't think all > blocksize increase proposals should have to justify "why this size" or "w= hy > this rate of increase." I would really like a more formal criterion, ideally automatic (like any other test, the parameters can be modified as technology advances). But fair enough, even though your criterion is too vague or not future-proof enough, I guess it is still a criterion. It seems that this is a matter of disagreements and ideal ways of doing things and not really a disagreement on fundamental assumptions. So it seems this question wasn't so interesting after all. > Part of my frustration with this whole debate is > we're talking about a sanity-check upper-limit; as long as it doesn't ope= n > up some terrible new DoS possibility I don't think it really matters much > what the exact number is. That's what you think you are discussing, but I (and probably some other people) think we are discussing something entirely different. Because we have a fundamentally different assumption on what the block size limit is about. I really hope that identifying these "fundamental assumption discrepancies" (FAD from now own) will help us avoid circular discussions so that everything is less frustrating and more productive for everyone. >> Regardless of the history of the consensus rule (which I couldn't care >> less about), I believe the only function that the maximum block size >> rule currently serves is limiting centralization. >> Since you deny that function, do you think the (artificial) consensus >> rule is currently serving any other purpose that I'm missing? > > > It prevents trivial denial-of-service attacks (e.g. I promise to send you= a > 1 Terabyte block, then fill up your memory or disk...). This could be prevented in some other ways. If this is the only concern, it doesn't need to be a consensus rule. > And please read what I wrote: I said that the block limit has LITTLE effe= ct > on MINING centralization. Not "no effect on any type of centralization." > > If the limit was removed entirely, it is certainly possible we'd end up w= ith > very few organizations (and perhaps zero individuals) running full nodes. Sorry, another try: You think the maximum block size rule serves to limit centralization by limiting how hard it is to run a full node. I agree with that, but I would add something more and you wouldn't: The maximum block size consensus rule limits how hard it is to be a competitive miner. In other words, you think the last statement is false or incorrect. Meta: I think we should try to collect and list more of this "FADs" (we have at least 2 of them already). If you think it can be useful, I'm more than happy to repeat this process in the opposite direction: you make the questions and I give the answers, you write what you think I think and I correct you in iterations. Probably we should finish with you correcting what I think you think first. I am really excited about understanding your point of view better. Stupid humor (hopefully not out of context and not offensive): I'm happy to discover that what I thought it was FUD was just FAD. More seriously, I'm really happy for your interest in understanding and being understood. Let's worry about where do we think differently first and about who is right on each point later. In the end, only the conclusions on each point will matter and not who claimed the final conclusions (in the points where we find them) first (if we get to final common conclusions on that point at all).