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
|
Return-Path: <asix@disroot.org>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id DB13DC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 08:34:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id D823283470
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 08:34:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id oOzCTf79sfAJ
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 08:34:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 83B9D82473
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 08:34:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by disroot.org (Postfix) with ESMTP id 3FAC32547B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 09:34:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at disroot.org
Received: from knopi.disroot.org ([127.0.0.1])
by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mw-yhykC0P-G
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 09:34:25 +0100 (CET)
Mime-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail;
t=1578904465; bh=H/41617uujMvoVtK0o80OaSrWYMz6ZxSmJ1dGMuXpB8=;
h=Date:From:Subject:To;
b=CiHqgGqKSEiIu62FTOunNp7GSQQ3MrqfZEYihmHbUckqZlLVRgtWtWLLtT46IoROs
iKmEDczyAqpFa5+p0Kjirw0rFGU+gwHvcDeT1lMv7RQ4Yc9npn5mV4/LGYWzEK/2Oi
aPNXa54zxEydnGd6WvJNY9o9mgpc9cJl03oYXvN2wv0u4dqnPJPg6SiTBdONRjbyoH
TPW//Eca9zBz4amv/stMopX9sJOlgOW9fwEXRYfXNTKUH1JYsuVskrOWZb2HLJPglr
qjcMuPXLotDlhbiZ4PXYP+ze0LyBbseKJ/WFmJBVj5jtQslc/w/B+bjvCVMxAIoqdb
fKxOR2bOnRrSQ==
Date: Mon, 13 Jan 2020 08:34:24 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "Yosef" <asix@disroot.org>
Message-ID: <415e793656ab4326b48d9dc050a85eb8@disroot.org>
To: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Approved-At: Mon, 13 Jan 2020 15:12:19 +0000
Subject: [bitcoin-dev] Modern Soft Fork Activation
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: Mon, 13 Jan 2020 08:34:30 -0000
tl;dr How about 80% ?=0A=0AThe fallback to BIP-8 makes sense, but it's no=
t a graceful one and we absolutely prefer BIP-9 to succeed. A failure to =
reach 95% readiness signalling means 2.5 years delay, 3.5 years in total,=
not yet counting.=0A=0A95% can prove difficult to achieve. Some % of neg=
ligent miners that forget to upgrade is expected. Completing that to 5% i=
s not too difficult for a small malicious minority trying to delay the ac=
tivation. This is the issue Matt's goal #5 aims to prevent, and while the=
fallback to BIP-8 helps, BIP-9=E2=80=99s 95% requirement makes it worse =
by allowing quite a neglected minority to force a dramatic delay. Also no=
te how in such case it would have been better to skip BIP-9 altogether an=
d maybe save 1.5 years.=0A=0AMatt mentions the 95% requirement under goal=
#3 "Don't (needlessly) lose hashpower to un-upgraded miners". If that is=
the trade-off, I'd say 2.5 years delay is worse than a momentary loss of=
hashrate. The protocol is quiet resilient to hashrate fluctuations and, =
as others mentioned, at that point miners don=E2=80=99t just signal, but =
lose coins if they don't upgrade, so the hashpower loss is expected to sh=
ortly correct. This also means goal #4 is not really effected.=0A=0AOn Sa=
t Jan 11 14:42:07 UTC 2020, Anthony Towns wrote:=0A=0A> For me, the focus=
there is on Matt's first point: "avoid activating [or merging, or even p=
roposing] in the face of significant, reasonable, and directed objection"=
=0A=0AI agree, and believe the outreach and review process around taproot=
are maybe the best we had so far. Notably goal #1 should be mostly satis=
fied already at merge time, so risking 3.5 years delay after that, seems =
excessive.=0A=0ABIP-91 =E2=80=9CReduced threshold Segwit MASF=E2=80=9D wa=
s deployed by miners specifically to reduce the 95% requirement down to 8=
0% during the segwit drama. While hopefully taproot won=E2=80=99t produce=
any such excitements, the events around segwit activation and the weird =
=E2=80=9Chash wars=E2=80=9D meme that later followed =E2=80=93 might enco=
urage some to try similar games again.=0A=0AThe difference between `5% mi=
nus apathetic-miners` and `20% minus apathetic-miners` is dramatic and ca=
n make such attempts an order of magnitude more difficult.=0A=0AThe tapro=
ot process is looking great so far, I feel it will be a mistake to put it=
on a route that can easily extend to so many years. I suggest keeping Ma=
tt=E2=80=99s proposal as is but decrease BIP-9=E2=80=99s 95% threshold do=
wn to around 80%.=0A=0AYosef
|
