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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 31B70C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 17:29:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with UTF8SMTP id 1951E83B0F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 17:29:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with UTF8SMTP id J-y-pVYVXNgR
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 17:29:38 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp1.osuosl.org (Postfix) with UTF8SMTPS id 254CC83B0B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 17:29:38 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 799CB4BDE2B;
Sun, 28 Feb 2021 17:29:36 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1614531664; t=1614533376;
bh=CKkpWrRfQr8BtFlrWLYvWE6YCoSkDI65GK72xu8lkvs=;
h=Date:Subject:To:References:From:In-Reply-To:From;
b=RgBLZDG7MAvN++anDQ/dKisRjvI/a8aCon+nea3UM3W1YYMgx8rcf9hiF3G8gwqGK
LFDW0K/Rz6s8uvF9Lbt8Vql9I2solbsTGmB+vgZb0E6adSH01VxhYk6Y0pk3SckgbT
Hzl9KMDKb0IzmdR9FRRR0uT0zEr+APYJVO/xjL7fMLUVYnV86B0BdwqqtGEN5CR9LL
Y8cpzyeDK84XnWq98dtCaUcZOJu/YPCKovtzDe1ZAZn2eQUOFA1KKIm/e2TAMqGCYo
7S6jAXq5oAQxkvG+mielbaJv8ntghBkTpHDc2PryddEZQ/xAcjcdlkv+IIxQ2yZ7GZ
+TOqJ1UkaTu5g==
Message-ID: <c6a7a7ab-ee68-6594-ebd0-60f38ba40c37@mattcorallo.com>
Date: Sun, 28 Feb 2021 12:29:36 -0500
MIME-Version: 1.0
Content-Language: en-US
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org
References: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
<202102281720.07392.luke@dashjr.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <202102281720.07392.luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot 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: Sun, 28 Feb 2021 17:29:39 -0000
I think you may have misunderstood my proposal. I'm not suggesting some people run BIP 8(true), some run BIP8(false),
and some run a client which has a flag day, I'm suggesting a flag day activation instead of any BIP8-based activation.
Replies to your further points inline.
Matt
On 2/28/21 12:20, Luke Dashjr wrote:
> On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
> Concept NACK. This still has the same problems BIP149 would have had, as I
> just reminded in my last email to this ML:
>
> 1) Such a chain does not indicate activation at all, leaving it unresolved and
> debatable whether activation has occurred or not.
> 2) As a result, it is also impractical to intentionally reject the softfork
> should anyone decide to do so.
>
> Signalling is important to activation.
Several people responded disagreeing, including myself. I'll paste my response here in case you missed it:
Forced-signaling, or any form of signaling, does not materially change whether a soft fork can be seen to be safe to
use. Pieter wrote a great post[1] some time ago that goes into depth about the security of soft forks, but, while miners
can help to avoid the risk of forks, they aren't the determining factor in whether use of a fork should be considered
safe (ie the fork "has activated").
Not only that, but the signaling methods used in BIP 8/9 (ie the version field in the block header) do not imply
anything about whether mining pools are running full nodes which enforce the soft fork at all, only whether the pool has
configured their stratum software to signal or not.
Ultimately, forced-signaling, or signaling period, are not a substitute for having a broad set of upgraded nodes across
the network, including an overwhelming majority of economically-active nodes, enforcing the rules of a new fork. As this
can be difficult to measure, waiting some time after a fork and examining upgrade patterns across the network is important.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
|
