summaryrefslogtreecommitdiff
path: root/9d/920baeb9150a3f70c54d61b0a12a8fa5a807f0
blob: d450f892baec3ecf5c2cff508ac56a4cfd2ef67c (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
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
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
Return-Path: <michaelfolkson@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 66E7EC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:44:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2C30C41986
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:44:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2C30C41986
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=QawwU6Xr
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
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 bH4TldjqgkLn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:44:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B76C241977
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
 [185.70.40.134])
 by smtp4.osuosl.org (Postfix) with ESMTPS id B76C241977
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:44:43 +0000 (UTC)
Date: Sun, 18 Sep 2022 18:44:31 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1663526680; x=1663785880;
 bh=5lcpp/U1fN8VRA7gAGXoBHslzZLefMD42T1dPu7U/mU=;
 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=QawwU6Xrb/JwZyp6aog6yKIpLZWGrVuAkRkDN4t4vAlYuBLgeGhyhPlpV7CuFh4k9
 m9pcxraLp4Shr5X9R67Z2gd5JHsaO9YnAgbOqyXoer4QiLGTyXjIWWvsuiGNBVg2lI
 S1675igSdkGJREq8sEU9k6fCjGWycOSkarmchbInyV5JQnuig5aPIpV7I/al6Vxjlg
 a0x3d/g+ZsdIpe13Uh7JYkYdeqRqFue3d1N0JfN05ZKAwFOu/RGDAeByu7on6eloyR
 krb9lQfC6Rz/G+28vW0OdRDbX0934W9KYQDK4y94egzIIbNNw7SkzCrMVoHW/qo/JT
 JpYG6WO3RXFXg==
To: alicexbt <alicexbt@protonmail.com>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <O1zZVzh-olGF235lSIT4Y2C-Q91IACK1qhZbi4jOP5WMYOTD0-Zw9aqHs_1VKBn96h6kTiIRvQS10RkREaKAAQqMz-I58jW6nxr5HjmZlG4=@protonmail.com>
In-Reply-To: <T4meYqm1urcpCDED6kZjkjDt4hWkmRGKdRNMC2Y6SBHGqNm1t5id4v2GChIlCQwRiy20O9bR2PaT_jCCYEeG4sCkOp77fraTlunN7teZldQ=@protonmail.com>
References: <YyQioS3F942wu1HW@erisian.com.au>
 <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com>
 <YyVlra0AMIFO9Xid@erisian.com.au>
 <8e4dc33b-2992-0380-de2a-0b8afa3db5b7@mattcorallo.com>
 <8cU3OEEtb7Q8CRBHqeWV6qe4JSRnOeMjh2PRdYj4rsnxF4DxzQd1Bo-1DAPMWGNxjXsZQuSuPrDK5TF4ez6tONZ5ACoLJ_FqV6Y1q7ybSwI=@protonmail.com>
 <T4meYqm1urcpCDED6kZjkjDt4hWkmRGKdRNMC2Y6SBHGqNm1t5id4v2GChIlCQwRiy20O9bR2PaT_jCCYEeG4sCkOp77fraTlunN7teZldQ=@protonmail.com>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 19 Sep 2022 00:59:22 +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: Sun, 18 Sep 2022 18:44:46 -0000

Hi alicexbt

> Good to see some positivity, finally.

I had enthusiasm for this concept of enabling proposed soft fork functional=
ity on signet 2 years ago [0]. Nothing has changed, still enthusiastic :) N=
ot enthusiastic about the months wasted on unnecessary contentious soft for=
k drama since but can't change the past.

> 1)Nobody uses Liquid. Signet has more activity than Liquid.
  2)Testing something on Liquid will be completely different as its=20
  a separate blockchain with some similarities.

Perhaps you should take your own advice with regards to positivity (or at l=
east have more of an open mind) with regards Liquid and sidechains. Signet =
Bitcoin are totally free [1] and experimentation doesn't ever result in los=
s of real monetary value so you would expect more experimentation on signet=
 versus Liquid long term. However, building protocols and prototypes with r=
eal monetary value is a step up from doing so with worthless signet coins. =
So I don't really see them as direct competitors. Some things take a lot lo=
nger to come to fruition than others but the original vision [2] of sidecha=
ins still makes perfect sense to me. Competing sets of consensus rules aren=
't possible on a single mainnet blockchain. Hence you either go the sidecha=
in(-like) route or you go the altcoin route if you want to take the step up=
 from signet/testnet and start using real monetary value. I much prefer the=
 sidechain model to the altcoin route myself. Especially when in say vaults=
 you do want the equivalent of Bitcoin to be locked up rather than a more v=
olatile altcoin.

Thanks
Michael

[0]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on=
-signet-with-multiple-proposed-soft-forks-whilst-maintaining
[1]: https://signetfaucet.com/
[2]: https://blockstream.com/sidechains.pdf

--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


------- Original Message -------
On Sunday, September 18th, 2022 at 13:27, alicexbt <alicexbt@protonmail.com=
> wrote:


> Hi Michael,
>=20
> > I agree with Matt. The less said about the "Aw shucks Jeremy didn't kno=
w that CTV didn't have community consensus at the time" 0 and "it was the l=
ack of process that was the problem" the better.
>=20
>=20
> The linked gist cannot be taken seriously and I am not sure why you keep =
sharing it as some document to prove there was no technical consensus for B=
IP 119. Nadav has already mentioned this in the comments. If you care about=
 community consensus, maybe feedback about the links in that gist should al=
so be respected. There was chaos, misinformation and lot of drama on twitte=
r. Some people that opposed CTV on twitter still have no clue what CTV actu=
ally does and a few were super enthusiastic because of the author for BIP 1=
19.
>=20
> > I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpain=
t, let's park that for the moment) but I do like the idea of signet having =
soft fork proposals enabled on it 1 whether that be CTV, APO etc and if tha=
t requires more of the signet code to be moved out of the Core repo so be i=
t.
>=20
>=20
> Good to see some positivity, finally. Because tx introspection aka covena=
nts would help everyone involved in bitcoin. This idea of experimenting wit=
h soft forks on signet together with research and meetings suggested by Ant=
oine should help in better evaluation phase with less drama, politics etc. =
and more technical discussions to reach a goal.
>=20
> > I'm surprised more isn't being done on Liquid already with what possibl=
e future functionality is (and could be) enabled 2 there but maybe there is=
 more happening than I'm aware of.
>=20
>=20
> 1)Nobody uses Liquid. Signet has more activity than Liquid.
> 2)Testing something on Liquid will be completely different as its a separ=
ate blockchain with some similarities.
>=20
> I have summarized a few other positives of testing soft forks on signet b=
ased on AJ's email:
>=20
> a)Better evaluation
> b)PR implementing soft fork could be reviewed and merged outside core
> c)Testing on signet with pre-existing signet infrastructure
> d)Can deploy multiple consensus changes so easier to compare alternative =
approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc)
> e)Pre-baked ability to abandon the soft fork
> f)No need to regularly rebase consensus changes against bitcoin core's ma=
ster branch
>=20
> /dev/fd0
>=20
> Sent with Proton Mail secure email.
>=20
> ------- Original Message -------
> On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin=
-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>=20
>=20
>=20
> > I agree with Matt. The less said about the "Aw shucks Jeremy didn't kno=
w that CTV didn't have community consensus at the time" 0 and "it was the l=
ack of process that was the problem" the better. If people don't care about=
 lack of community consensus there is no process in a permissionless, open =
source community that can stop them or direct them down a more patient, pro=
ductive path (I tried). I think it is a shame because I think (maybe I'm wr=
ong) at least in the technical community there is an understanding that lon=
g term Bitcoin is far from finished in exhausting its potential and we do n=
eed people who will work on changes that we'll need in the long term.
> >=20
> > There are a few interesting things in here though. I'm not convinced by=
 the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for t=
he moment) but I do like the idea of signet having soft fork proposals enab=
led on it 1 whether that be CTV, APO etc and if that requires more of the s=
ignet code to be moved out of the Core repo so be it. I'm surprised more is=
n't being done on Liquid already with what possible future functionality is=
 (and could be) enabled 2 there but maybe there is more happening than I'm =
aware of. Protocols or use cases built out and demonstrated on signet (and/=
or Liquid/sidechains) seem an obvious stepping stone to me for convincing t=
he community that it is potentially worth taking the chain split risk for a=
 particular upgrade. It is a long slog to get community consensus on an upg=
rade (Taproot certainly was a slog) but I think the vast majority of us thi=
nk Taproot was worth that slog and Bitcoin would be poorer today without it=
.
> >=20
> > The Great Consensus Cleanup is an interesting example in that I get Mat=
t doesn't have time to champion it or focus on it with his LDK commitments =
but I have no idea where it would rank on his long term priority list if he=
 wasn't working on LDK. Similarly I have no idea what people who understand=
 this evolving system much better than I do are thinking with regards to sa=
y adding new opcodes, sighash flags versus say waiting on Simplicity and po=
ssibly adding new functionality within that potential upgrade. For people l=
ike me who are extremely unlikely to propose their own consensus change(s) =
getting some signal on what to spend time digging into would be useful rath=
er than second guessing what people are thinking. There is a danger that yo=
u flirt with perceived public roadmaps when possible authority figures stic=
k their necks out and effectively say "I'm not in charge but in an imaginar=
y world where I was this is my current thinking of the ordering in which we=
 could improve this system
> > long term. But this could change depending on x, y and z and possible u=
pgrades are only ready when they're ready and they have community consensus=
." There is no way people don't play these exercises in their minds. I do, =
I just have very few answers :) I personally think APO is in prime position=
 to improve Lightning channel state management with eltoo and if it enables=
 some covenant schemes too that seems like an added bonus. On APO versus wa=
iting for APO like functionality in Simplicity I have no idea. Work on APO/=
eltoo and Simplicity both seem to be progressing in parallel so the APO ver=
sus Simplicity discussion perhaps rests on whether people think certain cov=
enants should only really be enabled once we have the security guarantees o=
f Simplicity 3 (if at all).
> >=20
> > Antoine's covenant R&D effort 4 seems really promising and I hope the s=
henanigans from earlier in the year don't put people off from engaging with=
 that. Hopefully we can see more exploration, development and research in c=
ovenants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways=
 to Control the Future" 5) and we can foster a community which has very hig=
h standards, is open to new ideas and new research but can avoid these mont=
hs long resisting chain split fights. I think the discussion would be much =
more interesting and much more productive if people didn't have to think "I=
f I express a view now it will be used to attack me personally later" or wo=
rse "If I express a view now it will be used to justify an upcoming chain s=
plit".
> >=20
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >=20
> > ------- Original Message -------
> > On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-de=
v bitcoin-dev@lists.linuxfoundation.org wrote:
> >=20
> > > On 9/17/22 2:14 AM, Anthony Towns wrote:
> > >=20
> > > > On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-=
dev wrote:
> > > >=20
> > > > > On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
> > > > >=20
> > > > > > As we've seen from the attempt at a CHECKTEMPLATEVERIFY activat=
ion earlier
> > > > > > in the year 0, the question of "how to successfully get soft fo=
rk
> > > > > > ideas from concept to deployment" doesn't really have a good an=
swer today.
> > > > > > I strongly disagree with this.
> > > >=20
> > > > Okay? "X is good" is obviously just a statement of opinion, so if y=
ou
> > > > want to disagree, that's obviously allowed.
> > > >=20
> > > > I also kind of feel like that's the least interesting paragraph in =
the
> > > > entire email to talk further about; if you think the current answer=
's
> > > > already good, then the rest of the mail's just about (hopefully) ma=
king
> > > > it better, which would be worthwhile anyway?
> > >=20
> > > No, I think its at least a good chunk of the "statement of problem". =
Yes, more testing is good, and
> > > this project is a way to get that. Cool. But implying that lack of te=
st frameworks is in any
> > > material way part of the lack of movement on forks in Bitcoin I think=
 is very wrong, so its worth
> > > pointing out, whether the particular project is useful or not is sepa=
rate.
> > >=20
> > > > > Going back many, many years we've had many
> > > > > discussions about fork process, and the parts people (historicall=
y) agreed
> > > > > with tend to be:
> > > > > (1) come up with an idea
> > > > > (2) socialize the idea in the technical community, see if anyone =
comes up
> > > > > with any major issues or can suggest better ideas which solve the=
 same
> > > > > use-cases in cleaner ways
> > > > > (3) propose the concrete idea with a more well-defined strawman, =
socialize
> > > > > that, get some kind of rough consensus in the loosely-defined, su=
bjective,
> > > > > "technical community" (ie just ask people and adapt to feedback u=
ntil you
> > > > > have found some kind of average of the opinions of people you, th=
e
> > > > > fork-champion, think are reasonably well-informed!).
> > > > > (4) okay, admittedly beyond this is a bit less defined, but we ca=
n deal with it when we get there.
> > > > > Turns out, the issue today is a lack of champions following steps=
 1-3, we
> > > > > can debate what the correct answer is to step (4) once we actuall=
y have
> > > > > people who want to be champions who are willing to (humbly) push =
an idea
> > > > > forward towards rough agreement of the world of technical bitcoin=
ers
> > > > > (without which I highly doubt you'd ever see broader-community co=
nsensus).
> > > >=20
> > > > Personally, I think this is easily refuted by contradiction.
> > > >=20
> > > > 1) If we did have a good answer for how to progress a soft-fork, th=
en
> > > > the great consensus cleanup 0 would have made more progress over th=
e
> > > > past 3.5 years
> > >=20
> > > No? Who is the champion for it? I haven't been. No one else is oblige=
d to take up the reins and run
> > > with it, that's not how open-source works. And no one has emerged who=
 has strong interest in doing
> > > so, and that's totally fine. It means it hasn't made any progress, bu=
t that's an indication that no
> > > one feels strongly enough about it that its risen to the top of their=
 personal priority list so
> > > clearly doesn't need to make progress.
> > >=20
> > > > Maybe not all of the ideas in it were unambiguously good
> > > > 1, but personally, I'm convinced at least some of them are, and I
> > > > don't think I'm alone in thinking that. Even if the excuse is that =
its
> > > > original champion wasn't humble enough, there's something wrong wit=
h
> > > > the process if there doesn't exist some other potential champion wi=
th
> > > > the right balance of humility, confidence, interest and time who co=
uld
> > > > have taken it over in that timeframe.
> > >=20
> > > No? Its not up to the community to find a champion for someone who wa=
nts a fork to happen. Either
> > > someone thinks its a good enough idea that they step up, or no one do=
es. If no one does, then so be
> > > it. If the original proper (me, in this case) thought it was that imp=
ortant then its their
> > > responsibility to be the champion, no one else's.
> > >=20
> > > > 2) Many will argue that CTV has already done steps (1) through (3) =
above:
> > > > certainly there's been an idea, it's been socialised through giving=
 talks,
> > > > having discussion forums, having research workshops 2, documenting =
use
> > > > cases use cases; there's been a concrete implementation for years n=
ow,
> > > > with a test network that supports the proposed feature, and new too=
ls
> > > > that demonstrate some of the proposed use cases, and while alternat=
ive
> > > > approaches have been suggested 3, none of them have even really mad=
e
> > > > it to step (2), let alone step (3).
> > >=20
> > > I don't really see how you can make this argument seriously. Honestly=
, if a soft-fork BIP only has
> > > one author on the list, then I'm not sure one can argue that step (3)=
 has really been completed, and
> > > maybe not even step (2).
> > >=20
> > > > So that leaves a few possibilities
> > > > to my mind:
> > >=20
> > > > * CTV should be in step (4), and its lack of definition is a proble=
m,
> > > > and trying the "deal with it when we get there" approach is precise=
ly
> > > > what didn't work back in April.
> > > >=20
> > > > * The evaluation process is too inconclusive: it should either be
> > > > saying "CTV is not good enough, fix these problems", or "CTV hasn't
> > > > sufficiently demonstrated its value/cost, work on X next", but it
> > > > isn't.
> > > >=20
> > > > * Parts (2) to (3) are too hard, and that's preventing alternatives
> > > > from making progress, which in turn is preventing people from
> > > > being able to decide whether CTV is the superior approach, or some
> > > > alternative is.
> > >=20
> > > I think this is most of it, but its not that they're too hard, its th=
at people are too busy. There
> > > seemed to be more positive feedback, for example, to Rusty's proposal=
, but being the champion for a
> > > soft-fork is a full-time job for months on end, and last I checked Ru=
sty has a lightning
> > > implementation to maintain, which tends to be a more-than-full-time j=
ob already.
> > >=20
> > > To my knowledge, no one but Jeremy has made any serious attempt at be=
ing the champion for a
> > > soft-fork since Taproot, and before that Segwit (if someone reading t=
his who contributes to Core
> > > already wants to, and isn't sure how to, there's lots of people who w=
ould happily mentor you! I'm
> > > sure you can figure out who to reach out to!).
> > >=20
> > > Matt
> > > _______________________________________________
> > > 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