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
158
159
160
161
162
163
|
Return-Path: <efaula.prafbodous@ctemplar.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id AF192C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 16:31:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 96D6D434D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 16:31:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level:
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=ctemplar.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id UgynHzeimzLm
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 16:31:53 +0000 (UTC)
X-Greylist: delayed 00:05:31 by SQLgrey-1.8.0
Received: from mail.ctemplar.com (mail.ctemplar.com [82.221.128.126])
by smtp2.osuosl.org (Postfix) with ESMTPS id 88862434B7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 16:31:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=ctemplar.com; s=ctemplar; h=Message-Id:Date:To:From:Subject:
Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Reply-To:Cc:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=u6jqDx4jNtrDHu24xjzhzOVbpXWeRTbk68mAl889i9k=; b=ZfGK/peZpUvfk0NgZQaT4T5jp
xfzvKngvWaNGPKSay80S1an9y1meDxiB290rV6OeW5eJSjgawBIY3ZfrcTsiprtsNxOtVzc9HiRdG
WikkyHBvCczKnM8gij6V93yvtX715dc1rrZNU5uUltDpH7O8t9ArbwmGXtF0D6hH5gTTk=;
Received: from [::1] (helo=mail.ctemplar.com)
by mail.ctemplar.com with esmtp (envelope-from
<efaula.prafbodous@ctemplar.com>) id 1lGOte-0002PO-No
for bitcoin-dev@lists.linuxfoundation.org; Sun, 28 Feb 2021 16:26:19 +0000
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Efaula Prafbodous" <efaula.prafbodous@ctemplar.com>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Sun, 28 Feb 2021 16:26:18 -0000
Message-Id: <467af32d3c6e4758a8d6ffcd9cc60140-efaula.prafbodous@ctemplar.com>
Feedback-ID: ZWZhdWxhLnByYWZib2RvdXNAY3RlbXBsYXIuY29t:ctemplar
X-Mailman-Approved-At: Sun, 28 Feb 2021 21:16:47 +0000
Subject: [bitcoin-dev] Proposal: Scheduled Activation with Potential
Miner-Signaled Delay
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2021 16:31:54 -0000
Hello Bitcoin Protocol Discussion Mailing List,
The binary presented by "Lock on Timeout" or LOT; is inherently divisive. Hence, after taking some time to meditate; please consider the following as an overview, and a possible solution:
---
The lingering bad-taste from the drama surrounding the activation of SegWit (Using, BIP9, BIP91, and BIP148) lead to the development of the very reasonable activation protocol: BIP8.
The BIP8 protocol includes an optional feature, called "Lock on Timeout", that is essentially a technically improved version of the flag-day activation proposed in BIP148.
Many in the Bitcoin Community find the use of blind flag-day activations needlessly divisive and dangerous. In particular:
# A flag-day activation imposes itself on the network, without consideration of the deployment concerns that the miners may have when implementing the network upgrade on their unique infrastructure; and risks decreasing the good-will between users and miners.
# A flag-day activation proceeds, even if, before activation, a critical bug in the design is found in the process of doing the miner software upgrades. There is no back-out path for the community and miners alike.
# A flag-day activation can have wide-reaching damaging effects if activated with only a small amount of the miners in active support.
Others in the Bitcoin Community, however do not find these concerns weighty enough to override the certainty and reliability that a flag-day activation provides. Hence, this binary-option of using a flag-day activation, or not, is always going to be divisive for the community.
---
The activation procedure for new consensus rules should be empowering for both the users and the miners alike. It should respect the reality that the proposed network upgrade (Taproot: BIP340, 341, and 342) has already completed its consensus building process within the Bitcoin Community.
This proposal decides against using a blind flag-day activation; instead it uses a more nuanced approach. It allows a majority of the miners to block deployment (if they maintain consensus to postpone the deployment for at least half of the activation period) and it also allows a minority of the miners to temporarily delay the deployment.
Signaling "readiness" for a consensus change has been confused with implying political support of this change. This proposal addresses this confusion by inverting the meaning of the "Version Bit". Now miners will signal they are "not-ready", instead of the previously used behavior of signaling when they are "ready".
After a lengthy pre-starting period of 6 months, an upgrade may be further delayed, or be postponed by miners signaling. In the default case, where the vast majority of the miners have successfully upgraded within the pre-starting period, the first 2016 block period will lock-in the upgrade without any delay or postponement.
This is far more accurately resolving the primary worry of both the Bitcoin users and Bitcoin miners, that is to allow an upgrade to proceed too-quickly while some lag behind with difficulties. Miners who are having difficulties can explicitly notify the community through signaling their lack of readiness, and thus triggering a delay, or entirely postponing the deployment.
---
Please find following a rough, and incomplete, draft of the proposal written in BIP form. If the community finds this approach conceptually sound, this BIP will be completed to a high-standard and hopefully be considered to be used for the activation of Taproot.
Lovely Regards,
Efaula.
BIP: scheduled-activation-delay
Title: Scheduled Activation with Potential Miner-Signaled Delay
Author: Efaula Prafbodous
Created: 2021-02-26
License: BSD-3-Clause
CC0-1.0
==Abstract==
This document specifies an alternative to [[bip-0008.mediawiki|BIP8]], where the signalling intention is inverted, and the activation may be delayed a limited number of times, or postponed (and ultimately fail deployment).
Unlike previous proposals, where miners signaled that they are '''ready''' for the consensus change. This proposal has miners signal that they are '''not-ready''', and proceeds with the upgrade in the default case.
The core assumption within this proposal is that it is far easier and faster for a miner to adjust the signaling within the blocks they produce, than to certify and validate new software that enforces advanced new consensus rules. Hence, miners will quickly signal they are '''not-ready''', and once upgraded; they will remove this signal; allowing the upgrade to proceed.
The authors of this proposal suggest this is more appropriate, as it directly focuses on the core issue: allowing miners to delay the activation of new consensus rules until they have solved their technological and validation issues.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
==Motivation==
Flag-day activations are the simplest way to introduce consensus changes to the Bitcoin Network. However, without overwhelming miner support, a flag-day activation can cause a damaging chain split to occur.
Since [[bip-0016.mediawiki|BIP16]], the Bitcoin Community has used miner-signaling (where miners place a specific flag in the blocks they produce) to trigger the activation of a consensus change. This has worked to assure that the network remains in good consensus throughout the activation period. However, in the case of [[bip-0141.mediawiki|BIP141]], this activation process of signaling '''readiness''' resulted in confusion between signaling readiness of the miner software; and signaling political support of the consensus change.
This lead to much drama; and a strong movement within the users to move back to using flag-day style activations.
In this proposal we address this issue by requiring miners to explicitly signal that they are '''not-ready''' for the proposed network upgrade. This removes a great amount of the political confusion, as the default behavior is now ambiguous:
# A miner chooses to enforce the new consensus rules.
# A miner may choose not to upgrade; and not enforce the new consensus rules. In a soft-fork this behavior is acceptable; except for the loss of funds and disruption caused by mining on-top of other invalid blocks without detection.
In the case of signaling '''not-ready''', the miner is simply referencing the technological reality of their lack-of-readiness. This allows the Bitcoin Community to focus on the miners who have signaled that they are not-yet-ready, and build support with them. Thus, helping the miners implement the technological aspects of this network upgrade.
==Specification==
This proposal uses 2016 block intervals; using the same set of intervals as used for difficulty adjustment calculations.
# The '''start_height''' should be 13 x 2016 block intervals (approximately six months) after the release of the software that implements this upgrade.
# The '''stop_height''' should be 26 x 2016 block intervals (approximately one year) after the '''start_height'''.
--
There will be exactly 26 intervals, to attempt activation:
'''LOCKED_IN''' becomes activated IF:
# Less than 126 blocks signal '''not-ready'''. In any interval. OR
# Less than 1008 blocks, but 126 or more blocks signal '''not-ready'''. For a total of 14 intervals.
'''FAILED''', i.e. activation failed IF:
# 1008 or more blocks signal '''not-ready'''. For a total of 13 intervals. AND
# 126 or more blocks signal '''not-ready'''. In all remaining intervals.
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
|
