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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
|
Return-Path: <carlo@spiller.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 36601C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Mar 2021 08:40:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 1D877430F8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Mar 2021 08:40:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001]
autolearn=ham autolearn_force=no
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 49ovH9FNRwqs
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Mar 2021 08:40:25 +0000 (UTC)
X-Greylist: delayed 22:26:36 by SQLgrey-1.8.0
Received: from smtprelay.hostedemail.com (smtprelay0043.hostedemail.com
[216.40.44.43])
by smtp2.osuosl.org (Postfix) with ESMTPS id 94FFA430F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Mar 2021 08:40:25 +0000 (UTC)
Received: from smtprelay.hostedemail.com (10.5.19.251.rfc1918.com
[10.5.19.251])
by smtpgrave03.hostedemail.com (Postfix) with ESMTP id 2FD3318014D27
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Mar 2021 08:24:23 +0000 (UTC)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net
[216.40.38.60])
by smtprelay08.hostedemail.com (Postfix) with ESMTP id A7402182CED2A;
Mon, 8 Mar 2021 08:24:19 +0000 (UTC)
X-Session-Marker: 6361726C6F407370696C6C65722E636F6D
X-Spam-Summary: 2, -9, 0, , d41d8cd98f00b204, carlo@spiller.com, ,
RULES_HIT:1:2:41:69:72:152:355:379:599:800:854:960:962:967:968:973:983:988:989:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1381:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1606:1730:1776:1792:2068:2069:2194:2195:2198:2199:2200:2201:2525:2553:2568:2628:2682:2685:2829:2859:2897:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4037:4250:4321:4362:4605:5007:6117:6248:6657:6674:6678:6996:6997:7514:7903:7996:8957:9010:9025:9036:9108:9121:9177:9388:10004:10848:11232:11233:11473:11657:11658:11914:12043:12050:12297:12379:12555:12660:12663:12683:12740:12895:12986:13139:14096:14659:15054:21060:21080:21401:21433:21450:21451:21627:21795:21809:21888:21939:22179:30051:30054:30056:30060:30070:30090,
0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none,
DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL
X-HE-Tag: angle95_2215547276ef
X-Filterd-Recvd-Size: 10959
Received: from Carlos-Mac-Mini.local (bbcs-93-229.pub.wingo.ch [144.2.93.229])
(Authenticated sender: carlo@spiller.com)
by omf18.hostedemail.com (Postfix) with ESMTPA;
Mon, 8 Mar 2021 08:24:18 +0000 (UTC)
To: Ariel Lorenzo-Luaces <arielluaces@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <5a779c13-8ebf-5052-5bf7-846f970c21ef@spiller.com>
<baad4898-6605-4edc-ad13-0f74289484ae@gmail.com>
From: Carlo Spiller <carlo@spiller.com>
Message-ID: <f1613726-527c-360f-f1c2-c34f8f933626@spiller.com>
Date: Mon, 8 Mar 2021 09:24:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0)
Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <baad4898-6605-4edc-ad13-0f74289484ae@gmail.com>
Content-Type: multipart/alternative;
boundary="------------1B3F731BF784D277617C1FEF"
X-Mailman-Approved-At: Mon, 08 Mar 2021 08:55:35 +0000
Subject: Re: [bitcoin-dev] Yet another Taproot activation logic
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, 08 Mar 2021 08:40:27 -0000
This is a multi-part message in MIME format.
--------------1B3F731BF784D277617C1FEF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Ariel
Thanks for your reply with the link to the SMA proposal, which I had
missed previoulsy. It is indeed very similar.
I see that Speedy trial is currently gaining broad support, which is
good. I think my proposal with the threshold set to 51% instead of 80%
to change LOT=false to LOT=true is also pretty similar to ST, with the
key difference being that the next step after a fail of MASF is already
baked in.
Excited to see how it all plays out.
Best
Carlo
Carlo Spiller
+41 79 368 85 06
www.carlospiller.com
Am 07.03.21 um 22:13 schrieb Ariel Lorenzo-Luaces:
> Hi Carlo
>
> This your proposal is similar to the Simple Majority Activation
> proposal (SMA). The difference is that your proposal has the final
> activation threshold set to 80% and SMA has it set to 51%
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html>
>
> The problem with what you're proposing is what do users do if
> signaling is somewhere between 51% to 79%? Users that want to promote
> a UASF know that their miner majority can activate Taproot and
> activate without the 21% to 49% of miners needing to signal (or
> purposefully stalling). A UASF knows they have majority mining power
> so there is little risk to them and a big reward (activating Taproot)
> so they are incentivized to do a UASF.
>
> A UASF with a miner majority can scare everyone else about them being
> at risk of big reorgs to gain traction and followers.
>
> With the same proposal but the final threshold set to 51% instead of
> 80% there can't be risk of a UASF because if 51% is not reached they
> know they don't have enough miner support to keep the chain together.
>
> If support is less than 50% a UASF movement needs to hard fork anyway
> to change the PoW (for protection) and change addresses to prevent
> double spends.
>
> I really like the SMA proposal with 51% because it removes the
> incentive to do a UASF.
>
> Cheers
> Ariel Lorenzo-Luaces
> On Mar 7, 2021, at 6:37 AM, Carlo Spiller via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Hi everybody
>
> I'm new to this list, but not new to Bitcoin, having skin in the game
> since 2014. I was there for the scaling war and the drama around SegWit,
> as a simple user. This time, I run my own full node and follow
> development. I hope to bring something new to the table.
>
> Having witnessed the miner's unwillingness to activate SegWit truly
> makes me concerened for a simple LOT=false. After reading the discussion
> now for some time and thinking about it myself, I have come to the
> following proposal.
>
> Initially deploy with LOT=false and an activation threshold of 95% of
> miner signaling.
>
> *IFF* after 6 months Taproot is not activated by MASF, BUT at least 80%
> of hashpower signaled for the upgrade, LOT gets a lock-in date another 6
> months later and the threshold for MASF is lowered to 90%.
>
> If after the initial 6 months of signaling with LOT=false, 80% is not
> reached, the proposal expires.
>
> This way, a small percent of hashpower does not get to stall activation,
> rather, 80% of hashpower can activate LOT=true, and later, 90% can
> activate Taproot. If a flaw is found in Taproot in the first six months
> (unlikely anyway), miners simply don't signal and the proposal expires.
> If miners don't signal at all, only six months are lost, before a new
> activation logic can be deployed.
>
> Don't mind this if something similar was already proposed somewhere else.
>
> Best
>
> Carlo
>
> ------------------------------------------------------------------------
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
--------------1B3F731BF784D277617C1FEF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Ariel</p>
<p>Thanks for your reply with the link to the SMA proposal, which I
had missed previoulsy. It is indeed very similar. <br>
</p>
<p>I see that Speedy trial is currently gaining broad support, which
is good. I think my proposal with the threshold set to 51% instead
of 80% to change LOT=false to LOT=true is also pretty similar to
ST, with the key difference being that the next step after a fail
of MASF is already baked in.</p>
<p>Excited to see how it all plays out.</p>
<p>Best</p>
<p>Carlo<br>
</p>
<pre class="moz-signature" cols="72">Carlo Spiller
+41 79 368 85 06
<a class="moz-txt-link-abbreviated" href="http://www.carlospiller.com">www.carlospiller.com</a></pre>
<div class="moz-cite-prefix">Am 07.03.21 um 22:13 schrieb Ariel
Lorenzo-Luaces:<br>
</div>
<blockquote type="cite"
cite="mid:baad4898-6605-4edc-ad13-0f74289484ae@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Hi Carlo<br>
<br>
</div>
<div dir="auto">This your proposal is similar to the Simple
Majority Activation proposal (SMA). The difference is that your
proposal has the final activation threshold set to 80% and SMA
has it set to 51% <a
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html"
moz-do-not-send="true">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html</a><br>
<br>
</div>
<div dir="auto">The problem with what you're proposing is what do
users do if signaling is somewhere between 51% to 79%? Users
that want to promote a UASF know that their miner majority can
activate Taproot and activate without the 21% to 49% of miners
needing to signal (or purposefully stalling). A UASF knows they
have majority mining power so there is little risk to them and a
big reward (activating Taproot) so they are incentivized to do a
UASF.<br>
<br>
</div>
<div dir="auto">A UASF with a miner majority can scare everyone
else about them being at risk of big reorgs to gain traction and
followers.<br>
<br>
</div>
<div dir="auto">With the same proposal but the final threshold set
to 51% instead of 80% there can't be risk of a UASF because if
51% is not reached they know they don't have enough miner
support to keep the chain together.<br>
<br>
</div>
<div dir="auto">If support is less than 50% a UASF movement needs
to hard fork anyway to change the PoW (for protection) and
change addresses to prevent double spends.<br>
<br>
</div>
<div dir="auto">I really like the SMA proposal with 51% because it
removes the incentive to do a UASF.<br>
<br>
</div>
<div dir="auto">Cheers<br>
</div>
<div dir="auto">Ariel Lorenzo-Luaces<br>
</div>
<div class="gmail_quote">On Mar 7, 2021, at 6:37 AM, Carlo Spiller
via bitcoin-dev <<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>>
wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<pre class="blue">Hi everybody
I'm new to this list, but not new to Bitcoin, having skin in the game
since 2014. I was there for the scaling war and the drama around SegWit,
as a simple user. This time, I run my own full node and follow
development. I hope to bring something new to the table.
Having witnessed the miner's unwillingness to activate SegWit truly
makes me concerened for a simple LOT=false. After reading the discussion
now for some time and thinking about it myself, I have come to the
following proposal.
Initially deploy with LOT=false and an activation threshold of 95% of
miner signaling.
*IFF* after 6 months Taproot is not activated by MASF, BUT at least 80%
of hashpower signaled for the upgrade, LOT gets a lock-in date another 6
months later and the threshold for MASF is lowered to 90%.
If after the initial 6 months of signaling with LOT=false, 80% is not
reached, the proposal expires.
This way, a small percent of hashpower does not get to stall activation,
rather, 80% of hashpower can activate LOT=true, and later, 90% can
activate Taproot. If a flaw is found in Taproot in the first six months
(unlikely anyway), miners simply don't signal and the proposal expires.
If miners don't signal at all, only six months are lost, before a new
activation logic can be deployed.
Don't mind this if something similar was already proposed somewhere else.
Best
Carlo
<hr>
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" moz-do-not-send="true">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
</div>
</blockquote>
</body>
</html>
--------------1B3F731BF784D277617C1FEF--
|