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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9B199C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 20:21:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with UTF8SMTP id 897104EBF3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 20:21:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 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_LOW=-0.7, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with UTF8SMTP id jkILxJv8DeR5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 20:20:58 +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 smtp4.osuosl.org (Postfix) with UTF8SMTPS id 9B29A4EB76
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 20:20:58 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 98CEA4BE347;
Sun, 28 Feb 2021 20:20:56 +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=1614542463; t=1614543656;
bh=cFFaR3grN62e0kiINabfVJyP2b2BcX2yYtbOApIt/Ko=;
h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
b=caIFmORuTdm5DzVthoEWRu1Uu5CEt4fiGElr/Jy+lFR9UOshBneOPAZxBOWwtSJu3
KqF92n/NYp/mZ8NIwcPxKHxRmh2tH6SvXzxb29AJV7kR3ixQ8fHHQ9A8+ERlfI2Ae4
gzx7HItxXjsrQusse5JLjbCPUWPSd7k52nYA3qJIkjtRerR9DqQGeItt/Sx/+p3b4i
hqh/DumpqtRUBg+CYxptVWgwdFSE8CymcRKtWN/IfKK0xRiv/LZ9QmrrFP5Vj/jjD/
qTLjT39D+wEC86N0KYpR+/zmAc+Pg9awWXFM1xXnrZnoPdzbGX4wqtqaE8LC+Noweb
/9VgTsz61uK7w==
Message-ID: <11b00a3a-91ff-54dd-6a48-b6f860dccfb6@mattcorallo.com>
Date: Sun, 28 Feb 2021 15:20:56 -0500
MIME-Version: 1.0
Content-Language: en-US
To: Jeremy <jlrubin@mit.edu>
References: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
<202102281720.07392.luke@dashjr.org>
<c6a7a7ab-ee68-6594-ebd0-60f38ba40c37@mattcorallo.com>
<CAD5xwhhRCBa86B0ApZ=VioZngREOh1bth4H=zk69k4xsZc9d0Q@mail.gmail.com>
<20c5eb39-915d-6af9-5b0a-f488ff40ef3f@mattcorallo.com>
<CAD5xwhh89-5WRdnhA0X0CueWe6s2HneeEFiW5nZs4KFQw4iG6Q@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAD5xwhh89-5WRdnhA0X0CueWe6s2HneeEFiW5nZs4KFQw4iG6Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 20:21:00 -0000
SPV mining has been curtailed somewhat to only apply for a brief period of time (based on public statements) since the
last time SPV mining caused a fork. Indeed, if you can make other miners mine on top of an invalid block, you can make
money by reducing the difficulty, but that is true as much today as during a fork. Still, I think you've made my point -
someone has to take an active, malicious action in order to mine a bad block, vs with forced signaling, someone only
needs to forget to reconfigure one out of one hundred pool servers they operate.
Matt
On 2/28/21 15:02, Jeremy wrote:
> Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block enhanced
> selfish mining" to take advantage of it.
>
>
> Hard to analyze exactly what that looks like, but...
>
> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the
> time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze
> out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this for
> too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving
> themselves a larger % of hashrate.
>
> So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners
> leads to some nasty oscillating hashrate being optimal.
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
>
>
> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo.com <mailto:lf-lists@mattcorallo.com>> wrote:
>
> Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running Bitcoin
> Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3) from
> my original post - it results in any miner who has not taken active action (and ensured every part of their often-large
> infrastructure has been correctly reconfigured) generating invalid blocks.
>
> As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
> already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
>
> Matt
>
> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
> > I agree with much of the logic presented by Matt here.
> >
> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a
> "tiny"
> > parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept
> > here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
> > universally understood by all network participants to just have a flag day. It is easier to communicate what users
> > should do and when.
> >
> > This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on its
> own,
> > but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain date
> are
> > not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a
> cooptable
> > consensus process than something more straightforward.
> >
> >
> > That said, a few points strike me as worth delving into.
> >
> >
> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days --
> one for
> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and flag
> day
> > for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV
> mining
> > (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
> > ensure the tip is valid).
> > 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients
> would
> > not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g.,
> LOT=true
> > is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation
> is/was
> > ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering
> schedules,
> > etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a
> quantized
> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
> > 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if
> signaling does
> > not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with
> start
> > times being proposed 1 month after release?) so we don't have certainty around how much time there is for that
> secondary
> > review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining
> reward). So I
> > think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard fork if
> > there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
> > 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
> > activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year
> flag
> > day, to do that via LOT=true so that taproot can still have early activation if desired.
> >
> > Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
> > closer to a flag day might not be so bad either for future forks as well.
> >
> > However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best
> option
> > at this time as it allows our flag day to remain compatible with such an early activation.
> >
> > I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any
> future
> > forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
> > parameters).
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
>
|
