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 9121747F for ; Thu, 30 Jul 2015 17:46:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D059F262 for ; Thu, 30 Jul 2015 17:46:31 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so1869276wib.0 for ; Thu, 30 Jul 2015 10:46:30 -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; bh=U/2xZnOY0lzyPGaJqMDNWhSyVNEE/DLBcjZ1ueVGVwA=; b=dqsSiXmnosy78IJwg/ezRQhVsrIydO6G/o9uXw0u+7PpEtmvJZP3pQxXuGDmpChBfP 0GPgZc/qmKJL2d5ArVoSnktp+3Sv0fI++4XAX/w2UM07v4kzSOflWcjv5Dizv79n3ObK 6DDcZT6vgAC0WSIRMzwMsErKM2tsRELOzHRnLpZU3rIlLsbQQXUYDqY7cJKQeBblO/uA 94pH07hK/SBWa6Kj1L+Abn5Dk9qnZX+Zo4xs6KSAk2zl8eORJI6CakIiTmh43hM4U5bw KocQ/4S8nyXKBGvjTqfz+7sYgt/X4jw5tW8QZXsSWzoCDCmlFyKKov2WCrTzTIGMCz/S 07LA== X-Gm-Message-State: ALoCoQmjwuQvBR1hv/BvhFP/q5brxb/Dp9l+hZOIx/GwfPDCVp2NWPsJb7W6yK7fv+AIqaetZuT3 MIME-Version: 1.0 X-Received: by 10.180.186.35 with SMTP id fh3mr8596067wic.7.1438278390437; Thu, 30 Jul 2015 10:46:30 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 10:46:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 19:46:30 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 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, 30 Jul 2015 17:46:32 -0000 On Thu, Jul 30, 2015 at 6:20 PM, Gavin Andresen via bitcoin-dev wrote: > On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev > wrote: > So we'd get to 2MB blocks in the year 2021. I think that is much too > conservative When considering "too conservative" options, let's not forget that, say, scheduling 2MB for 2020 doesn't preclude us from deciding that was too conservative and schedule, say 4MB for 2018 later. The first hardfork would be "useless", but it would set a "minimum increase" that would have been useful if the second one never happened. > I'll comment on using median time generally in Jorge's thread, but why does > monotonically increasing matter for max block size? I can't think of a > reason why a max block size of X bytes in block N followed by a max size of > X-something bytes in block N+1 would cause any problems. To be clear, for this concrete case block.nTime would just work just fine. I just want us to decide on one of the options and uniformly recommend that options for all cases in BIP99 [just renamed the file, https://github.com/jtimon/bips/blob/bip-forks/bip-0099.org ]. But, yes, please, let's discuss this in the other thread.