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
|
Return-Path: <luke@dashjr.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id DF392C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 17:20:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id C5A7C434ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 17:20:12 +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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dashjr.org
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 OlFs9nK1bD-r
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 17:20:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp2.osuosl.org (Postfix) with ESMTP id 13EC44349D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 17:20:11 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.214])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 8826B38A00A7;
Sun, 28 Feb 2021 17:20:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1614532810; bh=VoQ2o8ksvKWETQrOW/ga/w/axLRvTzCHLKj1y1Cd060=;
h=From:To:Subject:Date:References:In-Reply-To;
b=aJ/JL/LzoDES5bo4QVq7pjCLtlJCbN5UTi4aSsTxQZZiYSnqJvhrssBQ37zRNKOUQ
cV6jWQlFmDp90l6lGvt5PNz0nICxBQURfO+cEPlDjXtGy6kyIP/zA1AlAzxPNpOT2Y
+Tf84H+S99+EzZN5eSOZTC12Il8Z2VoyJxZ0G92E=
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Matt Corallo <lf-lists@mattcorallo.com>
Date: Sun, 28 Feb 2021 17:20:05 +0000
User-Agent: KMail/1.9.10
References: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
In-Reply-To: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202102281720.07392.luke@dashjr.org>
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:20:13 -0000
On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
> many individuals are committing themselves to running
> incompatible consensus rules.
Yet that is exactly what you propose herein...
> Given this, it seems one way to keep the network in consensus would be to
> simply activate taproot through a traditional, no-frills, flag-day (or
> -height) activation with a flag day of roughly August, 2022.
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.
> 2) The high node-level-adoption bar is one of the most critical goals, and
> the one most currently in jeopardy in a BIP 8 approach.
It is only jeopardized if people continue to push for a LOT=False deployment
(or this new proposal of yours).
BIP 8 itself, with LOT=True, does not create such a risk at all.
> Users demanding alternative consensus rules (or, worse, configuration flags
> to change consensus rules on individual nodes with an expectation of use)
> makes this very complicated in the context of BIP 8.
Alternative consensus rules is exactly what you are proposing here.
More alternative rules to choose from just increase the risks. Two options is
annoying, but adding a third for no reason is just absurd.
Luke
|
