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 4753A273 for ; Mon, 22 Jun 2015 20:43:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BCD98AA for ; Mon, 22 Jun 2015 20:43:42 +0000 (UTC) Received: by qkfe185 with SMTP id e185so106892657qkf.3 for ; Mon, 22 Jun 2015 13:43:42 -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:cc :content-type; bh=5jGyNbg9zokMogMIP36wwJnJ0PQMRgTDZ9sNDNY5KzU=; b=AKWWAVcrs3NVKhjlZlxnJdmCbLFq2q6XMaWxQ2B2XcmYdb/svvUw1l9XMx7sDVL2aB PA1b13DWSIQwNGzhIBxX8NLrlzk/oKp5PwNpLMNjI31FSy+1OZTqfm2uV4MzM90Z2J84 lTCwo3cN2e4562LCe9VvC7zYgks/5QfImzZ1IPaC4XcYhJiW8QT3wYDm5qjfJY5u0K6k dpt9kg4xf0JC/U9Osdq9POAHjJb6ciABALtXoijXh5s+SPWc8fKB/63oDYy5nVV2i9CC +r5AENcTWWQrXSbeeAN7ozswGPkO4u0tXTECDoE0o/sffD955t2lech9A7yEXuPliCXU 5IDw== MIME-Version: 1.0 X-Received: by 10.55.31.85 with SMTP id f82mr52671979qkf.88.1435005822006; Mon, 22 Jun 2015 13:43:42 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Mon, 22 Jun 2015 13:43:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Jun 2015 21:43:41 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1147b3ae4579240519215403 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW 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] Draft BIP : fixed-schedule block size increase 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: Mon, 22 Jun 2015 20:43:43 -0000 --001a1147b3ae4579240519215403 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 8:32 PM, Jean-Paul Kogelman wrote: > > Since it's possible that block timestamps aren't chronological in order, > what would happen if a block following a size increase trigger is back in > the past before the size increase? Would that block have a lower size > restriction again? Would using block height not be a more stable number to > work with? > The activation or not rule is purely timestamp based. Blocks with a timestamp less than 1452470400 have a limit of 1MB. There could be an 8MB block followed by a block that is limited to 1MB. --001a1147b3ae4579240519215403 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 22, 2015 at 8:32 PM, Jean-Paul Kogelman <jeanpaulkogelman@me= .com> wrote:

Since it's = possible that block timestamps aren't chronological in order, what woul= d happen if a block following a size increase trigger is back in the past b= efore the size increase? Would that block have a lower size restriction aga= in? Would using block height not be a more stable number to work with?

The activation or not rule i= s purely timestamp based.=C2=A0 Blocks with a timestamp less than 1452470400 have a limit of 1MB.=C2= =A0 There could be an 8MB block followed by a block that is limited to 1MB.=
--001a1147b3ae4579240519215403--