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 A54C58EA for ; Thu, 6 Aug 2015 19:42:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8C4E166 for ; Thu, 6 Aug 2015 19:42:12 +0000 (UTC) Received: by labjt7 with SMTP id jt7so37862410lab.0 for ; Thu, 06 Aug 2015 12:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2O5Rtu2fojIjiFEmVQhCCXTPoiWJfK3b7b/iL5feY64=; b=hZrzwEwM0+dr5+XIPTQj69OvgpK1X1UxZp8sWU+VP4hQuOiLKHmzTpn4SVzIxm0chM H5Ujnga4yXWx1sWVEzI4UuThN8aHRRqWO+nTjA411ZTlZL0b2GRn9lvr201QMvEPKIQC Y3V8ch8/aRQvHIqmN83PEP27QPCZopHhHnC3KBi3ewI+PAUf08CKVsnKRcqxy1NRRwQd Tq/w9BZdg7Cr2oWszhpUywBGgsadA0OzjboJIxU1+UjcX0zGNM+Di+n3P1jDcLc0+Kj3 sFqJMe5pKirW5zjYCfRKFwIzM6ZHua1MPejLuKpm/KAcdKxTZRnPQXlip31tBEb0ls7U SzUg== MIME-Version: 1.0 X-Received: by 10.152.115.132 with SMTP id jo4mr4013453lab.113.1438890130610; Thu, 06 Aug 2015 12:42:10 -0700 (PDT) Received: by 10.25.143.195 with HTTP; Thu, 6 Aug 2015 12:42:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Aug 2015 15:42:10 -0400 Message-ID: From: Gavin Andresen To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=001a11c366d21b1f07051ca9b756 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 19:42:13 -0000 --001a11c366d21b1f07051ca9b756 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. 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." > 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 computers 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 "why this rate of increase." Part of my frustration with this whole debate is we're talking about a sanity-check upper-limit; as long as it doesn't open up some terrible new DoS possibility I don't think it really matters much what the exact number is. > 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...). And please read what I wrote: I said that the block limit has LITTLE effect 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 with very few organizations (and perhaps zero individuals) running full nodes. --=20 -- Gavin Andresen --001a11c366d21b1f07051ca9b756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 6, 2015 at 1:15 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
So I reformulate the question:=

1) If "not now", when will it be a good time to let the "mar= ket
minimum fee for miners to mine a transaction" rise above zero?

Two answers:

1. If you ar= e 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.=

2. The "market minimum fee" should be d= etermined by the market. It should not be up to us to decide "when is = a good time."
=C2=A0
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 require= s a cluster of computers or more than "pretty good" broadband ban= dwidth I think that's too far.=C2=A0 That's where original 20MB lim= it comes from, otherwise I'd have proposed a much higher limit.=C2=A0
=C2=A0
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 prop= osals should have to justify "why this size" or "why this ra= te of increase." Part of my frustration with this whole debate is we&#= 39;re talking about a sanity-check upper-limit; as long as it doesn't o= pen up some terrible new DoS possibility I don't think it really matter= s much what the exact number is.
=C2=A0
=C2=A0
Regardless of the history of the consensus rule (which I couldn't care<= br> 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 d= isk...).

And please read wh= at I wrote: I said that the block limit has LITTLE effect on MINING central= ization.=C2=A0 Not "no effect on any type of centralization."

If the li= mit was removed entirely, it is certainly possible we'd end up with ver= y few organizations (and perhaps zero individuals) running full nodes.

--
--
Gav= in Andresen
--001a11c366d21b1f07051ca9b756--