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
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <famonid@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 83FF41024
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Feb 2018 18:57:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f65.google.com (mail-lf0-f65.google.com
[209.85.215.65])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A0E23FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Feb 2018 18:57:06 +0000 (UTC)
Received: by mail-lf0-f65.google.com with SMTP id x196so10255237lfd.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Feb 2018 10:57:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:cc; bh=WVHQIChxxiMgjtKV1tz1eMae9TDp1lzAN3u0qm+6rgY=;
b=FLiE+0h43FQRLL3bXlCvFxOsGay7NLfhP8l2aJArZaXnPyZk6ZHAtqbFSjR7xTst/e
KFH3CxCLyqnSVfj66agObysoOtBQ7E00sfni5Jx4ANYpdeVxB4uzhxSWEIsGi2zOlzS6
pLp5y7+aXGJqlvenBat9RBVTAwFw1u5S0WZd/6lsekxj5ijvHKpChHmkazuzVXEtRg5K
9j4diuP6vuhAYPnOeqJJ92ny9Qm+rK9zJDcUyM+TZx42SMAyaPaGlTeL0covc1b1bwqU
w6szdPu6g7SlXR2lksqgy2472glnlfl4Oz/ACswVDG9sKU2LyeQVApB9O4kwVHMp6HH0
ecrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:cc;
bh=WVHQIChxxiMgjtKV1tz1eMae9TDp1lzAN3u0qm+6rgY=;
b=YJavCqmn6Sxv4wdbeSh9gpsf39ml45Pf+HOMwArm+UCPwtkcLYaGRLkMaM2X7uOu6l
oyXmOcWy5a4b+XJ+vxxB5oez778RMQtGWEo58wXpdwQPwB8Kia2DmAjENBTHEG6e0GD1
pdUquy7CS0lPc5l2jsXs4229Q8IZ7VScWGAac6kibBKVUEizd09RnsY2Y71p72sP/QSt
QKaW0gANOL7HNV5NBXBb0QXOafoTkKMXmewmx818EJxIIBocpdh6UQzu7I8WpHcMYqZF
AqVzMVeyHKQ0QtbFjuEgNTbb9pNN6hpk+8sn6VUDBoueRoLhOKRGivWV1+L3EQS6+Jgw
j9tQ==
X-Gm-Message-State: APf1xPBaHm+RRCSKFpGx+SLkold8BBg4mo2wrXruhApOBSN9yLxlgTSe
n3U/sJmWVteiBi+od+K5tVdS76hmnopf8je749kiL+rC
X-Google-Smtp-Source: AH8x227aU5PBcQlDUrbV24edVjzyB1AU6FjWxyWX5wC7g9IZNV1hVJ24tINz74V6o8Mqhru+RLdEhIyCIzNEjsMqGqc=
X-Received: by 10.46.27.211 with SMTP id c80mr8536805ljf.46.1518980224610;
Sun, 18 Feb 2018 10:57:04 -0800 (PST)
MIME-Version: 1.0
Sender: famonid@gmail.com
Received: by 10.25.230.1 with HTTP; Sun, 18 Feb 2018 10:57:03 -0800 (PST)
In-Reply-To: <8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org>
References: <CAK51vgDaSMH96VmHxgLswVQTxGGjy4VU0VnT4CZ7H+WJrrTApw@mail.gmail.com>
<8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org>
From: Marco Falke <falke.marco@gmail.com>
Date: Sun, 18 Feb 2018 13:57:03 -0500
X-Google-Sender-Auth: UlXxz74v2ze2WipxydLjLGyz1vs
Message-ID: <CAK51vgDgxDMqO4Zp5daRnRaStOUE545+0iX-mgJ9WrTi8u77XA@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, MISSING_HEADERS,
RCVD_IN_DNSWL_NONE 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] Amend the BIP 123 process to include 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: Sun, 18 Feb 2018 18:57:08 -0000
> They also do not require software coordination. Therefore, why should there be
> BIPs at all? Seems to me that we should instead add these documents to
> https://github.com/bitcoin-core/docs
Consensus is not trivial. I think documentation is important, even if
it seems simple to some.
Personally, I don't care too much where to place the documentation,
but the BIPs repo seems a good place, since it also hosts other
informational documents.
To prevent "two BIPs for every protocol change", related buried
deployments could be bundled. E.g. the ISM BIP 90 change.
On Wed, Feb 14, 2018 at 6:57 PM, Eric Voskuil <eric@voskuil.org> wrote:
> On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote:
>> I define a buried deployment as a consensus rule change that affects
>> validity of blocks that are buried by a sufficiently large number of
>> blocks in the current valid most-work chain,
>
> Sufficient for what, specifically?
Sufficiently large to prevent potential bike-shedding. The expected
number of blocks in two weeks could be considered a lower bound. Then
multiply that by 10 or 20.
>
>> but the current block (and all its parents) remain valid.
>
> Remain valid in the case where the depth assumption is "sufficient" to
> ensure that a chain split is not possible?
>
> If this was true (which it is not), it would imply that there is no
> reason to validate any block deeper than the most recent 25,000.
> Presumably this means that people may continuously rely on some
> authority (like Bitcoin Core?) to determine the checkpoint for tip-25,000.
>
Note that a checkpoint *freezes* the chain completely at a given
height. Buried deployments are *not* checkpoints.
Also note that buried deployments only make sense after a protocol
upgrade has happened (i.e. a soft fork or hard fork). If a miner has
the resources to cause a chain split, they could trivially do that
even in the complete absence of buried deployments. Buried deployments
are *not* a solution to 50% attacks.
>> BIP 123 suggests that BIPs in the consensus layer should be assigned a
>> label "soft fork" or "hard fork". However, I think the differentiation
>> into soft fork or hard fork should not be made for BIPs that document
>> buried deployments. In contrast to soft forks and hard forks, buried
>> deployments do not require community and miner coordination for a safe
>> deployment.
>
> They can only avoid this requirement based on the assumption that the
> hard fork cannot result in a chain split. This is not the case.
>
>> For a chain fork to happen due to a buried deployment, a massive chain
>> reorganization must be produced off of a block in the very past.
>
> In other words a "buried deployment" is a hard fork that is not likely
> to cause a chain split. This is a subjective subcategory of hard fork,
> not an independent category - unless maybe you can show that there is
> the 25,000 blocks number is an objective threshold.
Please note that a buried deployment can very well be a soft fork. I
think this makes it even clearer, that such a label makes no sense for
buried deployments.
>> In the extremely unlikely event of such a large chain reorganization,
>> Bitcoin's general security assumptions would be violated regardless of
>> the presence of a buried deployment.
>
> This is untrue. The "security assumptions" of Bitcoin do not preclude
> deep reorganizations.
> e
>
|
