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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqQAs-00019g-I8 for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 18:05:30 +0000 Received: from mail-wi0-f178.google.com ([209.85.212.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqQAq-00020n-Qk for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 18:05:30 +0000 Received: by wizk4 with SMTP id k4so1111228wiz.1 for ; Thu, 07 May 2015 11:05:22 -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=0lq9unNXLTs5grC/xsW6CqESctqwDJduvBu3+4gMBrg=; b=SCrIUre50r8b9C2FpCqif19CZcdYh0VNtdzpyNA8zrJann4jvggN8u64XhHqDc6rcH D1AiY9toQ0EGhYN5P8riO4HiaMNlVKQUcZ2YA+ewy00runHC7yRRurrUO5qWzQ9gUvCH jSRDYPy2UvcKLY81N7dQEq/hfPQa8Zw5Da+cCyj9TUai8YX/JpZXaM6dXedWnCS6CRlX SFxIr4EfcE9BNEVd9h6CPRGPRDsMQAHB1X0DKovHVkm3gyWPoe8xDc99uG3LcHeMsiRa 9bTozREeer2X5ATrRSoNfx/JrL2rlnJpZSXTOFOSWiVkqjfvOfNa/LfZ9OvEWC7URecG DPxw== X-Gm-Message-State: ALoCoQk1oD31/47lFUxIlUuU7ju/e8qwKoD7Qe1v1kWsWqho32grUretSbJl416kzfvfKvI+H9oX MIME-Version: 1.0 X-Received: by 10.180.188.193 with SMTP id gc1mr8865367wic.7.1431021922716; Thu, 07 May 2015 11:05:22 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Thu, 7 May 2015 11:05:22 -0700 (PDT) In-Reply-To: References: <554A91BE.6060105@bluematt.me> Date: Thu, 7 May 2015 20:05:22 +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-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YqQAq-00020n-Qk 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 18:05:30 -0000 On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen wr= ote: > Fee dynamics seems to come up over and over again in these discussions, w= ith > lots of talk and theorizing. > > I hope some data on what is happening with fees right now might help, so = I > wrote another blog post (with graphs, which can't be done in a mailing li= st > post): > http://gavinandresen.ninja/the-myth-of-not-full-blocks > > We don=E2=80=99t need 100% full one megabyte blocks to start to learn abo= ut what is > likely to happen as transaction volume rises and/or the one megabyte bloc= k > size limit is raised. Ok, the fact that the fee increases the probability of getting included faster already is a good thing, the graphs with the probability of getting included in the next block were less important to me. Although scarce space (beyond what miners chose to limit by themselves) would increase the fee competition, I didn't knew that there is actually some competition happening already. So I guess this diminishes the argument for maintaining the limits longer to observe the results of more scarce space. Still, I think maintaining a lower policy limit it's a good idea, even if we decide not to use it to observe that soon. For example, say we chose the 20 MB consensus limit, we can maintain the policy limit at 1 MB or move it to 2 MB, and slowly moving it up later as needed without requiring everyone to upgrade. Of course, not all miners have to follow the standard policy, but at least it's something. So please take this as a suggestion to improve your proposal. You can argue it like this "if we want to maintain the limits after the hardfork or increase them slowly, for observing fee dynamics with more scarce space or for any other reason, those limits can be partially enforced by the standard policy". I mean, I think that could be a reasonable compromise for that concrete line of arguments.