Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8219E8F4 for ; Thu, 6 Aug 2015 20:01:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF14F166 for ; Thu, 6 Aug 2015 20:01:54 +0000 (UTC) Received: by ioeg141 with SMTP id g141so92231633ioe.3 for ; Thu, 06 Aug 2015 13:01:54 -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=sIS5j2cCMoFv31hjI570oPyllwFOg506+WmXrWqX0bI=; b=sV2877gG2ubYvN7KPoo6ZiSyESNAtE1LSTzbY4AHf1uDrn+v5njnoszitTDpQ+RFKA Mp8ONQij3x8uRSeB54d+oJWy2jtkvACUhtWdgcVQTZ7wpn5VFb7jXDciSYOkvs1IngeN nJ3mr/wyRugjtxMrLjDAPdGgr4HiLntXd3j8ywSl+jQcCqWfgPbsm+0Gg56hRtMiFuf5 5ZaE3yP/6TBOepQU9990yrmi8qYX4jDf1yZjRPaDf+I+2y3zdG2RSWBEtEX5pW5H3LE3 W56+aRDI+BDh0Fdnbt9imf4r4RfyWpVA/1WS2jBlhs/ygTIzjrSH3Zer9qBVPUfze7E5 DKMQ== MIME-Version: 1.0 X-Received: by 10.107.9.137 with SMTP id 9mr4492509ioj.50.1438891314176; Thu, 06 Aug 2015 13:01:54 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 6 Aug 2015 13:01:53 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 6 Aug 2015 13:01:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Aug 2015 22:01:53 +0200 Message-ID: From: Pieter Wuille To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a113f8f14a6ebb8051ca9fd6f 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 20:01:55 -0000 --001a113f8f14a6ebb8051ca9fd6f Content-Type: text/plain; charset=UTF-8 On Aug 6, 2015 9:42 PM, "Gavin Andresen via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: 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 partially agree. The community should decide what risks it is willing to take, and set limits accordingly. Let the market decide how that space is best used. > >> >> 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. It is only a DoS protection limit if you want to rely on trusting miners. I prefer a system where I don't have to do that. But I agree the numbers don't matter much, for a different reason: the market will fill up whatever space is available, and we'll have the same discussion when the new limit doesn't seem enough anymore. -- Pieter --001a113f8f14a6ebb8051ca9fd6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 6, 2015 9:42 PM, "Gavin Andresen via bitcoin-dev" <bitcoin-dev@lists.linu= xfoundation.org> wrote:
2. The "market minimum fee" should be determined by the market. I= t should not be up to us to decide "when is a good time."

I partially agree. The community should decide what risks it= is willing to take, and set limits accordingly. Let the market decide how = that space is best used.

> =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 t= hink all blocksize increase proposals should have to justify "why this= size" or "why this rate of increase." Part of my frustratio= n with this whole debate is we're talking about a sanity-check upper-li= mit; 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.

It is only a DoS protection limit if you want to rely on tru= sting miners. I prefer a system where I don't have to do that.

But I agree the numbers don't matter much, for a differe= nt reason: the market will fill up whatever space is available, and we'= ll have the same discussion when the new limit doesn't seem enough anym= ore.

--
Pieter

--001a113f8f14a6ebb8051ca9fd6f--