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 6755B9BA for ; Wed, 16 Nov 2016 14:18:47 +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 3726928C for ; Wed, 16 Nov 2016 14:18:46 +0000 (UTC) Received: by mail-qk0-f172.google.com with SMTP id x190so176470872qkb.0 for ; Wed, 16 Nov 2016 06:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=BrzDepoa3WJ9RVn80MlAHPcHbc3Cq6xxgbTkaTTQpcM=; b=WrNc+Sm/Ta4zMqiGhnYZei8TF7RfIF9M4HsKfoEYEGgPuOH7TkIQWVPfIJsvz0ncNE YcGn1jFZY6nrAMLeK3EbjTU/KOyqnv71zQn3tp7/0KZwHT76esq7qR4HXld16fHxGZdM u7R+8Svdlkv6SS55QcCFuu52xKEVbASKcApirqxnPEIExRwPQAnwq12uXd0I91ZdayGG vt3Przc1PNc8r0bnC5wR5kxA3vrifsFmBeHKxTZDM8n0U9rBj5/A2cITXpJslisNjrdD 0qxn55XjWbqJcWhIJkbv4T0OzPKq8V2d2ZxJOsnnaHH4WvqC9mp7Is8H2sD6XgOjpbVH Hz6Q== 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; bh=BrzDepoa3WJ9RVn80MlAHPcHbc3Cq6xxgbTkaTTQpcM=; b=ZYyBJa9+YhgpsUFipXq5Ev0NiWqg2XSHKsqPqvdrvm1+hAMhM6HNQRV8DGl3voLiZe OOXasxKve48tBn025MvD+YejQzJR5shGXInUyjIpfnC5Ri3uWUNX/lUr91e8G+JePxwC BwGwFcGZpMj3wuz41KHp8XUzADAFc5KwRjwM51l/6O+DJQRurutsv5Uqk+9eMKFV9Ygd H6MWGvvSeqUdF0IA096Vp3wnXzUTDB+g0EaKFDLbSiALXU1oIj7bUtUWFdXhFAd7Zhts uK85jmQUDl9vfa01zjTgC2sxAoic5LJ+kAyO1picpAyeFy+DkoKjnr3yaRnCsEP2oNmP H2mA== X-Gm-Message-State: AKaTC02P2G/cvXGDEsqZG6TYevDhiGIC1ZhBvfFmfCg7yBI2bq1jdg0tfkXQzKuh3aGcfKIIZa7SeKcbWiafUA== X-Received: by 10.55.154.200 with SMTP id c191mr3468127qke.117.1479305925327; Wed, 16 Nov 2016 06:18:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.55.227 with HTTP; Wed, 16 Nov 2016 06:18:44 -0800 (PST) In-Reply-To: References: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> From: Tier Nolan Date: Wed, 16 Nov 2016 14:18:44 +0000 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a114d6624317fc505416bc059 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 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: Wed, 16 Nov 2016 14:18:47 -0000 --001a114d6624317fc505416bc059 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Are checkpoints good now? Are hard forks okay now? > I think that at least one checkpoint should be included. The assumption is that no 50k re-orgs will happen, and that assumption should be directly checked. Checkpointing only needs to happen during the headers-first part of the download. If the block at the BIP-65 height is checkpointed, then the comparisons for the other ones are automatically correct. They are unnecessary, since the checkpoint protects all earlier block, but many people would like to be able to verify the legacy chain. This makes the change a soft-fork rather than a hard fork. Chains that don't go through the checkpoint are rejected but no new chains are allowed. --001a114d6624317fc505416bc059 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Are checkpoints good n= ow? Are hard forks okay now?

I think = that at least one checkpoint should be included.=C2=A0 The assumption is th= at no 50k re-orgs will happen, and that assumption should be directly check= ed.

Checkpointing only needs to happen during the headers-first part= of the download.

If the block at the BIP-65 height is ch= eckpointed, then the comparisons for the other ones are automatically corre= ct.=C2=A0 They are unnecessary, since the checkpoint protects all earlier b= lock, but many people would like to be able to verify the legacy chain.
=

This makes the change a soft-fork rath= er than a hard fork.=C2=A0 Chains that don't go through the checkpoint = are rejected but no new chains are allowed.
--001a114d6624317fc505416bc059--