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
|
Return-Path: <alicexbt@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 23A5CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2022 15:15:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 1269C83E28
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2022 15:15:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level:
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, BITCOIN_IMGUR=1, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
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 P3MnpfWcb3AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2022 15:15:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp1.osuosl.org (Postfix) with ESMTPS id 18B8483E23
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2022 15:15:23 +0000 (UTC)
Date: Wed, 11 May 2022 15:15:15 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail2; t=1652282120;
bh=j0XMyRzvVmZxSRC29q2lwz9XtPMSLeFVaczv5w4LCww=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
Feedback-ID:Message-ID;
b=INsGzCsLT3SjoyTC+0DxM7YOgEaiiWJAPwCHaZ+E6hL1qGiTi21eSZC6DXi9Opfgl
SAapPDO4IxVd3dY3cL+mvipyhYUNg3HroKuCb/Z6IsRKMTNJMqUmyE+KxAbxNiTMou
++oVD9OKs0+EsE8iz1gU+X/DIp/h3x0qSz98uGJlOETBSB/t0TgKVO3KfQYyRDJwVr
THVA9msjvmdCnpNcTq4YXRra5dwaODXW5ABwqMU2Nw7sjZr2GQ4iDblpi5ka0FIwC1
bP0CMLjzS70cEeJ4Xht04ZcIOSMiEiRkffi7iCqNZsk0OPAOz6Pgse/6O5vLYIyFN5
31azYz2bw7OFA==
To: Billy Tetrud <billy.tetrud@gmail.com>
From: alicexbt <alicexbt@protonmail.com>
Reply-To: alicexbt <alicexbt@protonmail.com>
Message-ID: <k_QSGEzNPna1m81VnNhvzXE1e6asLJwXOslQNRTOs6Sqv2BG9K3t0UznguMpoeB11V3I4by5QxbNpyWlRTjtGrO8Y_nlGOaO03Qj-2H9a7A=@protonmail.com>
In-Reply-To: <CAGpPWDbHUqf5_APr3e_hr7npo=ObJvLuWooJc5azMDCDOVSfOA@mail.gmail.com>
References: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com>
<CAGpPWDbHUqf5_APr3e_hr7npo=ObJvLuWooJc5azMDCDOVSfOA@mail.gmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 11 May 2022 15:19:26 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 11 May 2022 15:15:25 -0000
Hi Billy,
Thanks for the feedback. I agree with everything and=C2=A0bip-trinary-versi=
on-signaling looks interesting.
> A primary difference from both BIP8 and BIP9 is that this proposal uses t=
ri-state version signaling (rather than binary version bits) that can encod=
e both active support as well as active opposition to an active soft fork.
I think 'support' and 'opposition' can be replaced with readiness. Miners s=
hould not consider signaling as voting.
> The meaning for each ternary value is as follows:
0 - No signal
1 - Ready for new consensus rules
2 - Not ready for new consensus rules
The concept of a minimum and maximum threshold sounds intriguing, and I'm i=
nterested to read what other developers have to say about it.
Concept ACK on removing LOT, using tri-state version signaling,=C2=A0min/ma=
x threshold and required threshold calculation.
/dev/fd0
Sent with ProtonMail secure email.
------- Original Message -------
On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tetrud@gmail.com =
wrote:
> 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_activat=
ion_blocks, ie a number of blocks passed the start_height. Slightly easier =
to reason about and change when necessary. I proposed semantics like that h=
ere.
> > In any case, I'll give this a concept ACK. I would very much like futur=
e 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@li=
sts.linuxfoundation.org wrote:
>
> > Hi Bitcoin Developers,
> >
> > There were some disagreements with speedy trial activation method recen=
tly 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.c=
om/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
> >
> > State transitions diagram: https://i.imgur.com/dj4bFVK.png
> >
> > This proposal removes lockinontimeout flag, activation never fails alth=
ough MUST_SIGNAL can be longer if miners signaling does not reach the thres=
hold. Longer period for MUST_SIGNAL state is useful for coordination if LOC=
KED_IN was not reached.
> >
> > 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.
> >
> > 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 secure email._____________________________________=
__________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
