Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 28FB3273 for ; Mon, 22 Jun 2015 18:33:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA733133 for ; Mon, 22 Jun 2015 18:33:45 +0000 (UTC) Received: by qgal13 with SMTP id l13so55669836qga.3 for ; Mon, 22 Jun 2015 11:33:45 -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=+V1Mq6RiLIFtdyYimxGzVWN+d+lL8xPEJUDtslZRt0Q=; b=PilvGA/DjpcO7e/1GVvCg24k0iyQ5euzzf88LpQ67SnJ9wzAAkDBkyKG60uUtr2cfB MkTLrIqJVoKMuUwRzpSkSZtpG7UyK4YVC7jSh4Jax9PWpVeBVqDPmpHk1omGydwl1HHe vb+c8twRtwqcJrNddkK6lQU4DaOtqI+HM6eQ7mt0tLM8ZNuHNmg4cU8302/kJYEWXDEE wg3jv5K7WA1obBhD/hb4jVxxyqdt+As+BCcuWN9TS1g4qkalwVy+bPWHTnrJcDQrbbnq 1MsuSvOaCgiCJXDx6zdAbQKHIVCHq9xVyRNuyF9TxlaQ4XkV+voEBHlqvLANJE2IembH KJJg== MIME-Version: 1.0 X-Received: by 10.140.109.34 with SMTP id k31mr39725718qgf.94.1434998025067; Mon, 22 Jun 2015 11:33:45 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Mon, 22 Jun 2015 11:33:45 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Jun 2015 19:33:45 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a113a7d0a89a42805191f8305 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 18:33:46 -0000 --001a113a7d0a89a42805191f8305 Content-Type: text/plain; charset=UTF-8 The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than the standard 1000. Given that the threshold is lower than is normal for hard-forks, noise on the measurement could cause an activation even if less than 75% of miners agree. It also means that the vote has to be sustained for longer and inherently gives a longer notice period. Two weeks seems low for an upgrade warning. I guess there would be an alert on the network. Do old nodes detect an upgrade by version numbers? If that was headers only, then they could detect that large blocks have activated. Have you considered a "fail" condition? For example, if 750 of the last 1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the miners. Alternatively, if the rule doesn't activate by 11th Jan 2017, then it is disabled. --001a113a7d0a89a42805191f8305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The BIP-100 proposal uses a window of 12000 bloc= ks (83 days) rather than the standard 1000.=C2=A0 Given that the threshold = is lower than is normal for hard-forks, noise on the measurement could caus= e an activation even if less than 75% of miners agree.=C2=A0 It also means = that the vote has to be sustained for longer and inherently gives a longer = notice period.

Two weeks seems low for an upgrade warning= .=C2=A0 I guess there would be an alert on the network.

Do old nodes= detect an upgrade by version numbers?=C2=A0 If that was headers only, then= they could detect that large blocks have activated.

Hav= e you considered a "fail" condition?=C2=A0 For example, if 750 of= the last 1000 blocks set bits 4 and 14, then it counts as a rejection by 7= 5% of the miners.=C2=A0 Alternatively, if the rule doesn't activate by = 11th Jan 2017, then it is disabled.
--001a113a7d0a89a42805191f8305--