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
|
Return-Path: <alicexbt@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id EF0E9C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Sep 2022 20:02:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id B278A817F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Sep 2022 20:02:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B278A817F5
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=NoL9fZam
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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,
RCVD_IN_MSPIKE_H2=-0.001, 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 7O2d1wJ1mQad
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Sep 2022 20:02:00 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6F305817EB
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.osuosl.org (Postfix) with ESMTPS id 6F305817EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Sep 2022 20:02:00 +0000 (UTC)
Date: Wed, 28 Sep 2022 20:01:46 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1664395317; x=1664654517;
bh=KRBTsGhQI0xUKAyjI/jckAtBw9cc5Hadm4o27cxJ9RI=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=NoL9fZamIwgpX0Modbd5FLtasKbB8s5Fr36zKtqH6hmpTmbGUjsG+PfnDBW8lP7hX
gJNyT0e5Ru1s6+PphNYcLa+MJ77UAJlt6wh2NN2kd3PZPq5wpOzBxgM++sw/YFI8mO
NeS+SHb9ukUFAZHEUxg3yA36LQirGiLDp/UtwsibDPmbS8Kmc5zBz+NgJw7c/iFIXU
+EoduMex+xHmNRkTUtIzqFzaBpK+h21S5QQUBAtUW9GL1i59V7OIYjHHvg0BH+e+rM
OI6qdXBHusd0ZXF3adPTSIDGwaaMsCH+p559/aP9RcLsFQOgYLyUf4iD8mf1MM8cYe
zbNqUo/OKwDPg==
To: Michael Folkson <michaelfolkson@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <U3f8PdO0Wm3FyUH3FViPodLCWlvZckitTgchR8hqxGSBPVjV2WTtbyFRxx3OZUd9TEm-p_Juft9EqjjkWG1LdmFdPmDP0WfW3RW_TgXOqtI=@protonmail.com>
In-Reply-To: <lEYH8tZZf8onusZyemenCfTXz44xohxMwOflLeHnxcsk-MwNuOFLKId8GQnLBkAe10UOUjD6tQ-pJhbpMDQMA7Y5FIK7xvs2bAvQI2KBbQs=@protonmail.com>
References: <YyQioS3F942wu1HW@erisian.com.au>
<CALZpt+HksJ8BFi-8jvKJQLskSiLnm5f-QR_zmFrsgLX19R630Q@mail.gmail.com>
<Yyg++7tqBC9WGOzc@erisian.com.au>
<lEYH8tZZf8onusZyemenCfTXz44xohxMwOflLeHnxcsk-MwNuOFLKId8GQnLBkAe10UOUjD6tQ-pJhbpMDQMA7Y5FIK7xvs2bAvQI2KBbQs=@protonmail.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, 28 Sep 2022 20:24:34 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on
signet
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, 28 Sep 2022 20:02:04 -0000
Hi Michael,
> We then get into the situation where the block signers (currently AJ and =
Kalle) are the gatekeepers on what soft fork proposals are added.
Things that could solve the gatekeeping issue:
1) Adding more maintainers that are experienced enough to review consensus =
code.=20
2) Every soft fork that is implemented on signet should be discussed on mai=
ling list before merging the pull request.
3) Pull request that implements a soft fork should have at least 2 ACKs fro=
m the maintainers, 3 ACKs from developers who have either authored or revie=
wed enough consensus related pull requests in bitcoin core and 1 ACK from m=
aintainers of other implementations (knots, btcd, libbitcoin, bcoin etc.)
4) Every technical NACK from any developer or user in the pull request shou=
ld be resolved/answered before merging the pull request.
This was not the case in [implementing BIP][1] 119 however it could be used=
in future or something similar that everyone agrees upon including AJ and =
Kalle. Pull request implementing BIP 119 in bitcoin core is already reviewe=
d by lot of developers and I think AJ found a [bug][2] recently.
Gatekeeping at several levels already exists in bitcoin development and dif=
ficult to solve. If some developers believe a soft fork should have been im=
plemented on global signet but it was not, there is always the possibility =
of running custom signet with certain trade-offs.
> The default signet is directly supported with the -signet flag in Bitcoin=
Core. Even if we are moving the proposed soft fork code to an external rep=
o (to avoid it being merged into Core prematurely) it is still determining =
what soft forks are accessible from the signet flag in Bitcoin Core. I don'=
t think it is fair on the signet block signers to put them in that position=
and I don't think it is wise to put other Bitcoin Core contributors/mainta=
iners in the position of having to defend why some proposed soft forks are =
accessible on the default signet while others aren't.
Mainnet and Testnet have already been [removed][3] from the 'bitcoin-inquis=
ition/bitcoin' repository, and signet in bitcoin core is largely used by de=
velopers or power users, thus it should not be a problem. Signet could also=
be removed from bitcoin core binaries that are released regularly while be=
ing available if built from source.
Since signet coins have no value, utilizing this chain to experiment with s=
oft forks will only help the bitcoin development process. If we can't even =
agree to implement something on a network used for testing then it will be =
nearly impossible to do any soft forks on mainnet. This experiment has seve=
ral advantages. We can implement many consensus changes and compare alterna=
tives in a better way. Pre-baked ability to abandon the soft fork isn't imp=
lemented yet AFAIK, however that could further improve things.
[1]: https://github.com/bitcoin-inquisition/bitcoin/pull/3
[2]: https://github.com/bitcoin/bitcoin/pull/21702#discussion_r979273387
[3]: https://github.com/bitcoin-inquisition/bitcoin/pull/1
/dev/fd0
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, September 28th, 2022 at 5:18 PM, Michael Folkson via bitcoin-=
dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> I've given this some extra thought and discussed with others who may late=
r chime in on this thread. I'm now convinced this should be done on a custo=
m public signet rather than on the default signet. SegWit was added to a ne=
w testnet (Segnet) for testing rather than the pre-existing testnet and I t=
hink future soft fork proposals should follow a similar approach.
>=20
> Even if there is community consensus on what soft fork proposals should b=
e added to the default signet today (which may or may not be case) I find i=
t highly unlikely this will always be the case. We then get into the situat=
ion where the block signers (currently AJ and Kalle) are the gatekeepers on=
what soft fork proposals are added. The default signet is directly support=
ed with the -signet flag in Bitcoin Core. Even if we are moving the propose=
d soft fork code to an external repo (to avoid it being merged into Core pr=
ematurely) it is still determining what soft forks are accessible from the =
signet flag in Bitcoin Core. I don't think it is fair on the signet block s=
igners to put them in that position and I don't think it is wise to put oth=
er Bitcoin Core contributors/maintainers in the position of having to defen=
d why some proposed soft forks are accessible on the default signet while o=
thers aren't.
>=20
> The default signet was a long term project to address the unreliability a=
nd weaknesses of testnet. Many default signet users won't be interested in =
testing soft fork proposals and it is not reasonable for them to be subject=
to a stalling or forked blockchain because changes to a soft fork proposal=
or a buggy soft fork proposal pushed to the default signet makes previous =
valid/invalid transactions invalid/valid. If they want to test proposed sof=
t forks on a custom signet they are opting in to possible disruption rather=
than it being forced upon them.
>=20
> By focusing on custom signets rather than the default signet it also allo=
ws for more experimentation. Don't like the choices of which soft fork prop=
osals have been added to bitcoin-inquisition? Set up your own custom signet=
with a different set of soft fork proposals and get users for your custom =
signet on a level playing field to bitcoin-inquisition. A soft fork proposa=
l is found to be strictly inferior to another soft fork proposal? Just spin=
down the custom signet with that inferior soft fork proposal on it without=
impacting default signet users.
>=20
> So TL;DR still enthusiastic about this concept. Just with a strong prefer=
ence that it is done on a custom signet rather than on the default signet.
>=20
> Thanks
> Michael
>=20
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>=20
>=20
> ------- Original Message -------
> On Monday, September 19th, 2022 at 11:05, Anthony Towns via bitcoin-dev b=
itcoin-dev@lists.linuxfoundation.org wrote:
>=20
>=20
>=20
> > On Sun, Sep 18, 2022 at 02:47:38PM -0400, Antoine Riard via bitcoin-dev=
wrote:
> >=20
> > > Said succinctly, in the genesis of creative ideas, evaluation doesn't
> > > happen at a single clear point but all along the idea lifetime, where=
this
> > > evaluation is as much done by the original author than its peers and =
a
> > > wider audience.
> >=20
> > Sure. I definitely didn't mean to imply a waterfall development model,
> > or that the phases wouldn't overlap etc.
> >=20
> > > I would still expose a concern to not downgrade in the pure empiricis=
m in
> > > matter of consensus upgrades. I.e, slowly emerging the norm of a work=
ing
> > > prototype running on bitcoin-inquisition` as a determining factor of =
the
> > > soundness of a proposal. E.g with "upgrading lightning to support elt=
oo", a
> > > running e2e won't save us to think the thousands variants of pinnings=
, the
> > > game-theory soundness of a eltoo as mechanism in face of congestions,=
the
> > > evolvability of APO with more known upgrades proposals or the
> > > implementation complexity of a fully fleshed-out state machine and mo=
re
> > > questions.
> >=20
> > I agree here; but I think not doing prototypes also hinders thinking
> > about all the thousands of details in a fork. It's easy to handwave
> > details away when describing things on a whiteboard; and only realise
> > they're trickier than you thought when you go to implement things.
> >=20
> > > E,g if one implements the "weird" ideas
> > > about changes in the block reward issuance schedule discussed during =
the
> > > summer, another one might not want "noise" interferences with new
> > > fee-bumping primitives as the miner incentives are modified.
> >=20
> > (I don't think "miner incentives" are really something that can be
> > investigated on signet. You can assume how miners will respond to
> > incentives and program the mining software to act that way; but there's
> > no competitive pressure in signet mining so I don't think that really
> > demonstrates anything very much. Likewise, there's much less demand for
> > blockspace on signet than on mainnet, so it's probably hard to experime=
nt
> > with "fee incentives" too)
> >=20
> > > I hope the upcoming
> > > Contracting Primitives WG will be able to document and discuss some o=
f the
> > > relevant experiments run on bitcoin-inquisition.
> >=20
> > Likewise.
> >=20
> > (Lots trimmed due to either agreeing with it or having nothing to add)
> >=20
> > Cheers,
> > aj
> >=20
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|