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
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 174F2C000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 14:51:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 0FD72849D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 14:51:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id I8wHot7ntSm5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 14:51:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
by smtp1.osuosl.org (Postfix) with ESMTPS id AD0EB849CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 14:51:34 +0000 (UTC)
Received: from mail-pg1-f182.google.com ([209.85.215.182]) by
mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id
0MLvf0-1lUsRd19fI-007lXv for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 06
Apr 2021 16:51:33 +0200
Received: by mail-pg1-f182.google.com with SMTP id b17so6882522pgh.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 06 Apr 2021 07:51:33 -0700 (PDT)
X-Gm-Message-State: AOAM531fYx1/JneaDFR2ASFjx0nc7vzIAVhfgZ8TyM4fiRgWOWrazN9a
X7jeC1OUeTaEh9N49ydP1vcS57JcvwtOzSK8vfk=
X-Google-Smtp-Source: ABdhPJy6HFSavXAXNNa5l1rh6zZpJ9leIWgz/eW/06BK00msbDZy+0UpBm/CdivIbX69wbHhBaORPyjL4YVEh12Bkr4=
X-Received: by 2002:aa7:824e:0:b029:20a:3a1:eeda with SMTP id
e14-20020aa7824e0000b029020a03a1eedamr27612840pfn.71.1617720692461; Tue, 06
Apr 2021 07:51:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgTKLhA82=PsF9EXrhvmx6zcA=ffOvHD4qt4q1sAqzhng@mail.gmail.com>
<20210405103452.GA15866@erisian.com.au>
<CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
In-Reply-To: <CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
Date: Tue, 6 Apr 2021 14:51:21 +0000
X-Gmail-Original-Message-ID: <CALqxMTE5ovk8dCQAGqqdGL3dnW2kWwQ+2hjAExe5SqVc7BtTHA@mail.gmail.com>
Message-ID: <CALqxMTE5ovk8dCQAGqqdGL3dnW2kWwQ+2hjAExe5SqVc7BtTHA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:CS/KiPf6LuIIpL81rrZuAgrma4wg/p9bBxTYtM71/VGYhRvsqju
fmulr6uTjGs2p/In0DbdW7zmghO0DJw2s6BEnnfjnuD1Mtza3D9B525q82n9iuyccoHBn0h
Ico/fgbMmnQyyz0YWJllaidz0FE3TUPziZQLkXTij1f7RUXi73WomFxn/oHlr0Wfh2qpkDU
nL2TtGbzfs4zOBt2zBtLw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:9oPUhf2Ep4U=:zjAN922Uq1iUjP1dX98qCO
VbPRsgdYeYALyGJEmxnXf8jCJcignmh9RjTmGUV/E2foarKECx6s1Y2P7g2Eu9oXCN35tk36Y
wfKYEDYXs0iOMA164ioqPckXIEO3HtbOgurcavmgDPwUrdXwS2hy4u8qpu8ZBTLwKytB7yxRd
+dTRCbhSPnFV85d+Qj4gpLyAbRKJjIIYzVm8eEfxqq9GKFj12PDxWmSoH+1/SNZtIWQQhr6OI
52B+4TjbZiRPxrhZ01Qm6K7Eb/S0T+IQkPSaSkia+L1XdS3LdL/hUqkH4741OYqePCE193+tR
wEEhkFXwuzMxwxo2NAOuezEYcOGEprw4P4AEkk8JtdmYEbWWrpasCqklojek8rY+dDurTr/0o
148gseq6PsL2aLjCoiKQfnWV95yMSQHRNDxAWTtelUBkD/EhW0YjGnAXcWBOMZ1jRBwqP0ir/
BdgKFTxsquhM4nlWr4ZibftJYx3MboLv00NEnd4iaYgpQrcIHFGp
X-Mailman-Approved-At: Tue, 06 Apr 2021 15:28:21 +0000
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th
19:00 UTC bitcoin/bitcoin-dev
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: Tue, 06 Apr 2021 14:51:36 -0000
As I understand Andrew Chow has a patchset for height based activation
of Speedy Trial, so that it would be great if people could review that
to help increase the review-cycles.
Personally I also somewhat prefer block-height based activation, and
for myself it seems like a mild step backwards to go back to MTP, when
as far as I understand most consider height-based to be a better
defined and cleaner, more predictable solution.
Adam
On Tue, 6 Apr 2021 at 15:35, Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'm pretty sure that the question of "is signalling still possible by the=
time enough miners have upgraded and are ready to start signalling?" Stron=
gly benefits from a guaranteed number of signaling periods that height base=
d activation offers. Especially for the short activation period of Speedy =
Trial.
>
> The other relevant value of giving enough time for users to upgrade is no=
t very sensitive. It's not like 180 days is magic number that going over i=
s safe and going below is unsafe.
>
> That said, as Jeremy has pointed out before (maybe it was on IRC), we can=
almost ensure a minimum of 7 retargeting periods by carefully selecting si=
gnaling start and end dates to line up in the middle of expected retargetin=
g periods that we would otherwise chose with height based activation. Why w=
e would rather use MTP to fake a height based activation, I will never unde=
rstand. But if this is what it takes to activate taproot, that is fine by m=
e.
>
> The differences between height and MTP activation are too small to matter=
that much for what is ultimately transient code. As long as MTP activatio=
n can pass code review it is okay with me.
>
>
> On Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>>
>> On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:
>> > As such, the main conversation in this agenda item is
>> > around the pros/cons of height or MTP and determining if we can reach =
consensus
>> > on either approach.
>>
>> Here's some numbers.
>>
>> Given a desired signalling period of xxx days, where signaling begins
>> on the first retarget boundary after the starttime and ends on the last
>> retarget boundary before the endtime, this is how many retarget periods
>> you get (based on blocks since 2015-01-01):
>>
>> 90 days: mainnet 5-7 full 2016-block retarget periods
>> 180 days: mainnet 11-14
>> 365 days: mainnet 25-27
>> 730 days: mainnet 51-55
>>
>> (This applies to non-signalling periods like the activation/lock in dela=
y
>> too of course. If you change it so that it ends at the first retarget
>> period after endtime, all the values just get incremented -- ie, 6-8,
>> 12-15 etc)
>>
>> If I've got the maths right, then requiring 1814 of 2016 blocks to signa=
l,
>> means that having 7 periods instead of 5 lets you get a 50% chance of
>> successful activation by maintaining 89.04% of hashpower over the entire
>> period instead of 89.17%, while 55 periods instead of 51 gives you a 50%
>> chance of success with 88.38% hashpower instead of 88.40% hashpower.
>> So the "repeated trials" part doesn't look like it has any significant
>> effect on mainnet.
>>
>> If you target yy periods instead of xxx days, starting and ending on a
>> retarget boundary, you get the following stats from the last few years
>> of mainnet (again starting at 2015-01-01):
>>
>> 1 period: mainnet 11-17 days (range 5.2 days)
>> 7 periods: mainnet 87-103 days (range 15.4 days)
>> 13 periods: mainnet 166-185 days (range 17.9 days)
>> 27 periods: mainnet 352-377 days (range 24.4 days)
>> 54 periods: mainnet 711-747 days (range 35.0 days)
>>
>> As far as I can see the questions that matter are:
>>
>> * is signalling still possible by the time enough miners have upgraded
>> and are ready to start signalling?
>>
>> * have nodes upgraded to enforce the new rules by the time activation
>> occurs, if it occurs?
>>
>> But both those benefit from less real time variance, rather than less
>> variance in the numbers of signalling periods, at least in every way
>> that I can think of.
>>
>> Corresponding numbers for testnet:
>>
>> 90 days: testnet 5-85
>> 180 days: testnet 23-131
>> 365 days: testnet 70-224
>> 730 days: testnet 176-390
>>
>> (A 50% chance of activating within 5 periods requires sustaining 89.18%
>> hashpower; within 85 periods, 88.26% hashpower; far smaller differences
>> with all the other ranges -- of course, presumably the only way the
>> higher block rates ever actually happen is by someone pointing an ASIC a=
t
>> testnet, and thus controlling 100% of blocks for multiple periods anyway=
)
>>
>> 1 period: testnet 5.6minutes-26 days (range 26.5 days)
>> 13 periods: testnet 1-135 days (range 133.5 days)
>> 27 periods: testnet 13-192 days (range 178.3 days)
>> 54 periods: testnet 39-283 days (range 243.1 days)
>> 100 periods: testnet 114-476 days (range 360.9 days)
>> (this is the value used in [0] in order to ensure 3 months'
>> worth of signalling is available)
>> 132 periods: testnet 184-583 days (range 398.1 days)
>> 225 periods: testnet 365-877 days (range 510.7 days)
>> 390 periods: testnet 725-1403 days (range 677.1 days)
>>
>> [0] https://github.com/bitcoin/bips/pull/1081#pullrequestreview-62193464=
0
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
