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
|
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 18981E3A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Feb 2018 22:01:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com
[209.85.215.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8099418A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Feb 2018 22:01:49 +0000 (UTC)
Received: by mail-lf0-f50.google.com with SMTP id w10so18681171lfc.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Feb 2018 14:01:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:from:date:message-id:subject:to;
bh=fTw2EXPuemA1gNLQpwu5rSpy9cg70a/VddOtoPMfqb8=;
b=dlupE4Z4ftlWsYBAJe3WjZ+p2fDylBiZ8tLscZ8ofj60vnNdWzPxUy8I/DY/7FnT6T
edTrobM1090DvIzqyYDqfPEXdknjO9TvXDyhTD8Xo18/4+iEOz9C0j68c5QcLT+mhh4j
ookC8EX+EyNoKMQ69ZGmxaeAbx+CVwVp8iCg75Zve+ahLm4XQQiVWqssjuuzx7Ujb0Cm
bT0PWXAPj/cafFgcEsMw8NCDTq/oaLvdgsvTpv7TrKnw7J/lV4nSJ8Eb5ct7JQfhP0UQ
avXBzn9DuTmRxy7r/O36N9HUbL/07SvgkiqAGNzfQkSAN9hyrQU7Kvk+p2JKQg1wk3Cm
ZuCQ==
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:from:date:message-id:subject
:to; bh=fTw2EXPuemA1gNLQpwu5rSpy9cg70a/VddOtoPMfqb8=;
b=e3fVYsqBR5Y9EZgKoBaX27ZQ2qsetMVCz3cCWaEU7x0gIIvAaV074sc/Rz8UqxjxBP
0zIMGqdi59OMky/lnnhHROjJ7YbACUnp6IM/qnLNTwExYFwYXt97W65PyXH8puXYxaFp
ctTuwV6KgOrQ1/sSJFjgRt3cn8DwSXBqVJYt/ZxDcPTacEac0/E7wKuTJzSGBCl7DafI
sfgawGeijkaVhGFolUrVPRAQser31oHcUGfH/s3sVtlzGVkkfkefjD4QwYXtlqdcXKN5
8ZA0f8hymxpztgsypXppyg15JAH4hy8FlTVyOhyMtW9nUgvSIi/yOu7JF8EalHPZg9eY
IdXg==
X-Gm-Message-State: APf1xPC0LebEXQSiqEcdbsEzcYuzS0lGuuZ0M/TVr7V6IsT1wk3s3a44
+krDj83GtWIr0hFxWTXzDBz5vHR38r10D8I0Dn+w1wXh
X-Google-Smtp-Source: AH8x225ltp6ZsimVeAOFATYxD58f46+YVmV2ncXwBKOhOovTM/1ndA41OY34Gzj0lrFbnpdqpRZ7a5XEoeXFDBcOuDo=
X-Received: by 10.46.80.6 with SMTP id e6mr300284ljb.129.1518645707376; Wed,
14 Feb 2018 14:01:47 -0800 (PST)
MIME-Version: 1.0
Sender: famonid@gmail.com
Received: by 10.25.230.1 with HTTP; Wed, 14 Feb 2018 14:01:46 -0800 (PST)
From: Marco Falke <falke.marco@gmail.com>
Date: Wed, 14 Feb 2018 17:01:46 -0500
X-Google-Sender-Auth: W1AF50VHAvlprbrXE-bYL76rU7Y
Message-ID: <CAK51vgDaSMH96VmHxgLswVQTxGGjy4VU0VnT4CZ7H+WJrrTApw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [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: Wed, 14 Feb 2018 22:01:50 -0000
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, but the current block
(and all its parents) remain valid.
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.
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
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.
|
