summaryrefslogtreecommitdiff
path: root/ee/95e479bf4537c5f3abf1b456b7b8d29d95e9dd
blob: 122d23e7bebfe078254e52a292e398338cd845b1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6755B9BA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 14:18:46 +0000 (UTC)
Received: by mail-qk0-f172.google.com with SMTP id x190so176470872qkb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
	<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
	<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
	<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
	<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
	<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Wed, 16 Nov 2016 14:18:44 +0000
Message-ID: <CAE-z3OXdiyS_5HEFu1VLG1DH_K1QUBTSy49nXh1M4tcuoi6D_w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"auto"><div></div>Are checkpoints good n=
ow? Are hard forks okay now?</div></blockquote><div><br></div><div>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.<br><br>Checkpointing only needs to happen during the headers-first part=
 of the download.<br><br></div><div>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.<br>=
</div><div><br></div><div></div><div>This makes the change a soft-fork rath=
er than a hard fork.=C2=A0 Chains that don&#39;t go through the checkpoint =
are rejected but no new chains are allowed.<br></div></div></div></div>

--001a114d6624317fc505416bc059--