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 917664A3 for ; Sun, 11 Dec 2016 21:53:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2437C134 for ; Sun, 11 Dec 2016 21:53:48 +0000 (UTC) Received: by mail-io0-f181.google.com with SMTP id p42so147150812ioo.1 for ; Sun, 11 Dec 2016 13:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bittorrent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S63mhj7VsB6aURk7ABCTvXh04EURCN5qrFkgXye5Wc8=; b=FjFspOgQK81coHSNXE73b6wxRpX01B7f4p2e6RapMDAQV6qhwl8j9p0yJ9LO53TNTO aSTqZK57k0RH5bArhrwvS1QmGqThD4ywz8Xf5mYRFzS8i7/Fzr2rTSi198UVP8PmVYSv V8b7NyaAGaCtV3CFqgL6Fivos8nRldF0rQXDkwQ2+s0RCoYxiGBLw4QZJ0oH5+1f/gZr 2meO0ZUxHYyUna9pXbdnVztMl+u01xPHWwuX6DMrPP9vjy3ZTNKzYYMlordOZZH3icUW nIT4SNCz1JE3Cy60sfM8vo6x77ZSWqC+yFAs1zJaKk7d7wC8/4fBcUn0uwV+Ap5wF9tB iDzA== 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:from:date :message-id:subject:to:cc; bh=S63mhj7VsB6aURk7ABCTvXh04EURCN5qrFkgXye5Wc8=; b=REDZ5AYE+6TXBaiFxfn7TopPXBh1qWkVYePXqDCCbQTzSz1lVddY/OZml0azFx8WJO 7/7KTb2qruVjZhQMi7g2Z466N/Z1dIzBlpvmkOFV36hArKLysZNytDVn27T7uCvgOX2p Kcuj7d8+LpnX1mp3INPu4b83O9RveLnEPtn6efYOxmOIJDp03K9rsU41IQvNCqFv0cjj WwgMA3NmbwwwcxYiLmKYy6hPlwSYBpLMb3oKeSTQJhG9ra1ZRq9wfpndnRUwAryCHct5 G4Wr2qGM2O1+v+Z3G371Z++GwfwwK8Hvr7LOQDU5prlEfcopwT3ZKlgWAfffZgqrqrhg 7bcQ== X-Gm-Message-State: AKaTC02WrYLXyOFbXUFYg12vJ69rKBVM//lIWbQjnndRsIkQJQStSz5j8C1ttRIxUYV2Tqd6SKdVkhxQF2/l71oI X-Received: by 10.107.136.164 with SMTP id s36mr79503037ioi.214.1481493227518; Sun, 11 Dec 2016 13:53:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.224.199 with HTTP; Sun, 11 Dec 2016 13:53:46 -0800 (PST) In-Reply-To: References: From: Bram Cohen Date: Sun, 11 Dec 2016 13:53:46 -0800 Message-ID: To: "t. khan" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a113eb2c290547e0543690540 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 21:53:48 -0000 --001a113eb2c290547e0543690540 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 11, 2016 at 1:40 PM, t. khan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Block75 is not exponential scaling. It's true the max theoretical increase > in the first year would be 7x, but the next year would be a max of 2x, and > the next could only increase by 50% and so on. > With those limits there's very little reason to not simply have a fixed schedule. Blocks are likely to all be full in the future anyway, with a real fee market, and the idea that miners will be held back on block sizes for worry about propagation delay is a myth, and even if it were true it would favor collective pooling a lot, which would be a very bad thing. --001a113eb2c290547e0543690540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Dec 11, 2016 at 1:40 PM, t. khan via bitcoin-dev <= = bitcoin-dev@lists.linuxfoundation.org> wrote:

Block75 is not exponential scaling. It's true t= he max theoretical increase in the first year would be 7x, but the next yea= r would be a max of 2x, and the next could only increase by 50% and so on.<= /div>

With those limits t= here's very little reason to not simply have a fixed schedule. Blocks a= re likely to all be full in the future anyway, with a real fee market, and = the idea that miners will be held back on block sizes for worry about propa= gation delay is a myth, and even if it were true it would favor collective = pooling a lot, which would be a very bad thing.
--001a113eb2c290547e0543690540--