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 27AC3117C for ; Thu, 4 Feb 2016 18:24:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9EDB01C0 for ; Thu, 4 Feb 2016 18:24:32 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id mw1so65328440igb.1 for ; Thu, 04 Feb 2016 10:24:32 -0800 (PST) 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=Vepgsfi0tv6/3rLi+YcZVQ65r9Jp8qdi8F6rVJWXNC0=; b=vFsP+O1H7UO5FiXW3X+8k/CWlcpDppaUgQO2J3Fui1sjulSZOX3vz/weGvc9Xl1kZE GxnHhA0oOunzvmCJwowoFxvkLs0/ic7NfP6lEiQKvjpdrzO7tI4t8fwgMZDmJQI06MxX QRn8n7cvX7uUwyH8Eji95qeb2YTQvGbpkJNnWPvZ68eD1gtLn2zHOweC3ZhLjsFO6wem wF50Dsw+DyGioNzP7yiwHh3saEdKr2dzEBB59/vs9J4nDhb/RrL1soSNDbgdnv43wDpM j14TCWvSiwqK6L0P0BJkRy7EtTxy9RsHC1iKbWVqPrhWMe6ZhTe0X5QEOOmZCg43AOix zl+Q== 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:cc:content-type; bh=Vepgsfi0tv6/3rLi+YcZVQ65r9Jp8qdi8F6rVJWXNC0=; b=MU4bkBnoX6D/cl9hUqFwM8gYPT9xHQ2dlBRUvx69DoV2ZBYAxSic5d3/KEyjzx8+Gu 4+DQszYQZrBqs8U24gULVVQCOZI2SpBdIJCgmH/Q5q1+L1HjKRkC45wXAQypvYpgSM5R PiKs4VG6h+sO1XhkIIFB9PlN0BLAxCf6jKGDrxn1pURxeZnVOCvcvBo1hc6xE45f+J0F 4btimoojH31MkXwQTGQ307qrRs5U2FlnOmK6M3H0t5n+4EmQkaxIaY4ICgGOJMgWZds1 kXjbkDv5K9vbSmlZqXPWezvKvEf81zOvW2aOKL/8QIN3CmnL40ADEk6+ISZUiiNNLS6L ZaKw== X-Gm-Message-State: AG10YOT0U1DzIp+aIhHaYTs8dqBHCTGU0aa0hEHWiQXQ88S1c2b1zZ1Goou4DZ970/dU9aLYqhYZae+4qNVmxQ== MIME-Version: 1.0 X-Received: by 10.50.79.230 with SMTP id m6mr5610520igx.95.1454610272041; Thu, 04 Feb 2016 10:24:32 -0800 (PST) Received: by 10.79.77.65 with HTTP; Thu, 4 Feb 2016 10:24:31 -0800 (PST) In-Reply-To: References: Date: Thu, 4 Feb 2016 18:24:31 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e01229aaa8d4408052af5d890 X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_IMAGE_ONLY_24, HTML_MESSAGE, HTML_SHORT_LINK_IMG_3, MALFORMED_FREEMAIL, MISSING_HEADERS, RCVD_IN_DNSWL_LOW, T_REMOTE_IMAGE autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Hardfork bit BIP 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, 04 Feb 2016 18:24:33 -0000 --089e01229aaa8d4408052af5d890 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 4, 2016 at 5:56 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > No, the "triggering block" you mentioned is NOT where the hardfork starts. > Using BIP101 as an example, the hardfork starts when the first >1MB is > mined. For people who failed to upgrade, the "grace period" is always zero, > which is the moment they realize a hardfork. Clients have to update in some way to get the benefit of this right? An SPV client which fully validated the header chain would simply reject the hard forking header. Last time I checked, the Bitcoinj SPV wallet ignored the version bits, and just followed the longest chain. Is that still the case? In fact, does Core enforce the 95% rule for the soft-forks before checking for long forks? I am assuming that it happens when checking headers rather than when checking full blocks. This email has been sent from a virus-free computer protected by Avast. www.avast.com <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --089e01229aaa8d4408052af5d890 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 4, 2016 at 5:56 PM, jl2012 via bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:
No, the "triggering block" you mentioned is NOT where the hardfor= k starts. Using BIP101 as an example, the hardfork starts when the first &g= t;1MB is mined. For people who failed to upgrade, the "grace period&qu= ot; is always zero, which is the moment they realize a hardfork.

Clients have to update in some way to get the benefit= of this right?

An SPV client which fully validate= d the header chain would simply reject the hard forking header.=C2=A0 Last = time I checked, the Bitcoinj SPV wallet ignored the version bits, and just = followed the longest chain.=C2=A0 Is that still the case?

In fact, does Core enforce the 95% rule for the soft-forks before che= cking for long forks?=C2=A0 I am assuming that it happens when checking hea= ders rather than when checking full blocks.
This email has been = sent from a virus-free computer protected by Avast.
www.avas= t.com
--089e01229aaa8d4408052af5d890--