summaryrefslogtreecommitdiff
path: root/f4/b1d370c468edaff1055519e4b0e35308cbe13c
blob: 8f931294d24a0ce441ab54ddcc81eb4b7827df26 (plain)
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
Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E8B01C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:31:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id C2AF6416DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:31:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id AfHT_kpiC5fn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:31:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com
 [IPv6:2607:f8b0:4864:20::42f])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 569EC416D9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:31:35 +0000 (UTC)
Received: by mail-pf1-x42f.google.com with SMTP id bo5so15237868pfb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 08:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=fagO/nsby7vPAsamUZlZJ4Hh/q1i7zYtb2ckxnBsidc=;
 b=TFVV5BX0prcg0BGFnprSDO80XRPxJ0QJagggpegoNQYVIG88VGjjJSQE28RFqIbOwT
 OiPSc3Vv/cTE96kZeIeF/ZgmC1BAHx8JZI/tRjUFqORDTSG7iR/tHkChYAo+ERbsWMSM
 oVWu8iAieRrerG4xvSMxk69LE83gG80vvUzeaXXteDh+0hqU8prmkOoiVwYaEPQ7d6gY
 aWMeJXEJaylJHWhq153KHWuvG0uV8x015+0uy+9SbmOJFg1D5Sh6OCRQGfxjTeS1HGRa
 coHp/BhxN74fbNyvRPAEi6UkMx2NUc9hS3hwnI5oKT01a6sHyqRyo2ntpekL78Jz9yuH
 7rgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=fagO/nsby7vPAsamUZlZJ4Hh/q1i7zYtb2ckxnBsidc=;
 b=EXUDzdc3jbPb0c0PZHWhGsDyOE1VtD7gphl/yVxZK9LXj2ZQqR8V6pdC+eOGazDWfT
 4QtCWmKPPwJG/djouD6G3UfoGGRvBUYdRs6Wbc7m5WJnBipkmcPZzmvLtv5/ZZtZcR28
 GNNKtLr98HdGsyn35SxJtdO3vGvzpTzBIrIJPbQxfbaXuJaHtnWONZEH4tfszi7gjFaX
 3a2/rhWmSDk3DdpU5C8jemZzBp+t9z+MZztkgDiwdbr4pSqNvGimfS2bCq9bMtsRjoOU
 BKXAn3DJERtFjiQTWc6oYcZ7k0NPThDV22ALF5CNPLS33bqsx7C+UF7bEQI3eiOx1f0t
 kSww==
X-Gm-Message-State: AOAM532MrLRcNQKdmjTTWSn8qStB4HP9MFB43lSGh8HvQRuIh0NqBbRz
 MWagupfpLCLf4kHgNkHou9jsh8LF9BR+fs5S9dkcbrbf
X-Google-Smtp-Source: ABdhPJyNwS00E4jtPhwanNKMynYox4MBOL2YNcPEZaA+ie4rhXRp8PZTilY3LReb8r10AkVWtHNAxNjYLX59wBVvaAM=
X-Received: by 2002:a05:6a02:19b:b0:39d:cfa:5cda with SMTP id
 bj27-20020a056a02019b00b0039d0cfa5cdamr17108250pgb.175.1652196694684; Tue, 10
 May 2022 08:31:34 -0700 (PDT)
MIME-Version: 1.0
References: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com>
In-Reply-To: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 10 May 2022 10:31:17 -0500
Message-ID: <CAGpPWDbHUqf5_APr3e_hr7npo=ObJvLuWooJc5azMDCDOVSfOA@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000015f66f05deaa0558"
X-Mailman-Approved-At: Tue, 10 May 2022 15:35:06 +0000
Subject: Re: [bitcoin-dev] Improving BIP 8 soft fork 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: Tue, 10 May 2022 15:31:37 -0000

--00000000000015f66f05deaa0558
Content-Type: text/plain; charset="UTF-8"

I think this is a useful proposal. There are certainly things about BIP9
that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
a BIP spec was never produced for it afaik. A possibly unhelpful comment:

> minimum_activation_height

I think a minor improvement would be to specify this as
minimum_activation_blocks, ie a number of blocks passed the start_height.
Slightly easier to reason about and change when necessary. I proposed
semantics like that here
<https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/bip-trinary-version-bits.md>
.

In any case, I'll give this a concept ACK. I would very much like future
soft forks to use a previously specified activation mechanism rather than
rolling out a rushed unspeced thing as part of the (very orthogonal) soft
fork implementation.

On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> There were some disagreements with speedy trial activation method recently
> and BIP 8 became controversial because of LOT earlier. I have tried to
> solve these two problems after reading some arguments for/against different
> activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL
> state based on threshold reached.
>
> BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
>
> State transitions diagram: https://i.imgur.com/dj4bFVK.png
>
> This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
>
> MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and
> blocks that fail to signal in MUST_SIGNAL phase are invalid.
>
> Example:
>
> - This activation method is used for a soft fork
> - Only 60% miners signaled readiness and timeout height was reached
> - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> - LOCKED_IN and ACTIVE states remain same as BIP 8
> - Soft fork is activated with a delay of 2 months
>
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000015f66f05deaa0558
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think this is a useful proposal. There are certainly thi=
ngs about BIP9 that BIP8 fixes. I believe taproot&#39;s speedy=C2=A0trial d=
id kind of a hybrid, but a BIP spec was never produced for it afaik. A poss=
ibly unhelpful comment:<div><br></div>&gt; minimum_activation_height <div><=
br></div>I think a minor improvement would be to specify this as minimum_ac=
tivation_blocks, ie a number of blocks passed=C2=A0the start_height. Slight=
ly easier to reason about and change when necessary. I proposed semantics l=
ike that <a href=3D"https://github.com/fresheneesz/bip-trinary-version-sign=
aling/blob/master/bip-trinary-version-bits.md" target=3D"_blank">here</a>.=
=C2=A0<div><br></div><div>In any case, I&#39;ll give this a concept ACK. I =
would very much like future soft forks to use a previously specified activa=
tion mechanism rather than rolling out a rushed unspeced thing as part of t=
he (very orthogonal) soft fork implementation.</div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 10, 2022 at=
 9:02 AM alicexbt via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div style=3D"font-family:arial;font-size:14px">Hi Bitcoin Developers,<br>
<br>
There were some disagreements with speedy trial activation method recently =
and BIP 8 became controversial because of LOT earlier. I have tried to solv=
e these two problems after reading some arguments for/against different act=
ivation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL stat=
e based on threshold reached.<br>
<br>
BIP draft with no code and some changes in BIP 8:=C2=A0<a href=3D"https://g=
ist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1" target=3D"_bl=
ank">https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1<=
/a><br>
<br>
State transitions diagram:=C2=A0<a href=3D"https://i.imgur.com/dj4bFVK.png"=
 target=3D"_blank">https://i.imgur.com/dj4bFVK.png</a><br>
<br>
This proposal removes lockinontimeout flag, activation never fails although=
 MUST_SIGNAL can be longer if miners signaling does not reach the threshold=
. Longer period for MUST_SIGNAL state is useful for coordination if LOCKED_=
IN was not reached.<br>
<br>
MUST_SIGNAL =3D ((100-t)/10)*2016 blocks, where t is threshold reached and =
blocks that fail to signal in MUST_SIGNAL phase are invalid.<br>
<br>
Example:=C2=A0<br>
<br>
- This activation method is used for a soft fork=C2=A0<br>
- Only 60% miners signaled readiness and timeout height was reached<br>
- MUST_SIGNAL phase starts and will last for 4*2016 blocks<br>
- LOCKED_IN and ACTIVE states remain same as BIP 8<br>
- Soft fork is activated with a delay of 2 months</div><div style=3D"font-f=
amily:arial;font-size:14px"><br>
<br>
/dev/fd0<br><br>

<div style=3D"font-family:arial;font-size:14px">
    <div>

            </div>

            <div>
        Sent with <a href=3D"https://protonmail.com/" rel=3D"noopener noref=
errer" target=3D"_blank">ProtonMail</a> secure email.
    </div>
</div>
</div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000015f66f05deaa0558--