summaryrefslogtreecommitdiff
path: root/ec/497cc1ee932702695c6b6397c0be1b31238714
blob: 779b4ee01906f53d8209839c315f53a6cab111a5 (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
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
Delivery-date: Mon, 09 Jun 2025 19:06:37 -0700
Received: from mail-yw1-f189.google.com ([209.85.128.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDCO7XPNUQFBBIVGT3BAMGQEOKYGOQQ@googlegroups.com>)
	id 1uOoNo-0003RI-0S
	for bitcoindev@gnusha.org; Mon, 09 Jun 2025 19:06:37 -0700
Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-7111ff9f2d4sf19541307b3.0
        for <bitcoindev@gnusha.org>; Mon, 09 Jun 2025 19:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749521190; x=1750125990; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=f/HF8c/E4CwvCVFAJi+M7PAdBzHSWUE3ap2A0JvmoT4=;
        b=uoMtNgi9310IDiWsDJcFK4zc7r45NxD0egTbgBr1fVeo5LzFvzLP/YQZpqsHMS/zKV
         5XaKLs/jERiuErIGnvJZ6QI4gb/uOx2VdhLOdRxt2GGk9rDpA2cLknYBiLDaoLpQnhhk
         fXp7hBz69YaBKvgnexMAIgrUPO76bRzWPD8/BO4pHN62P7Nigq31iya16/Ftays6bZEd
         H3usgQvNvlTu6FsVQXHy/CokQwHmavkEDGZBKFMezs99J9exKFUaRc/OaURJOhYYbFh3
         9l3bZU94qVU7z7NDjw09IM0XWhmCrcMTPFZQVxdkJIC5BSlSWF9zAfmtJSGnFowBaKPy
         37Eg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749521190; x=1750125990; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=f/HF8c/E4CwvCVFAJi+M7PAdBzHSWUE3ap2A0JvmoT4=;
        b=knmTbVOtfHeYYOr3mwK/GXufp1Qqn3ML4b5r2jqW2t+8H4sVFKexq4CFK5x5AIleNu
         dVWfE5deKkVX1uXXhzlEn44rc4lHKeSssd9YxW6RQRWCnzAL4GJwelCPuwtfm7cZ2GyP
         5UZW+LgJe24KEfyucJY0bApiaORerK4cxgAtyKxZ2vk6wu6yEhxBCElfjnbj94UC7LMm
         pfl+swTTiOQI2T9rWHg46cW1kyTy/lchi7f82BkTKfWzwjSu8Kv2BUJ29onlh5JrQOTb
         8wzQWuFpYm6iRagsbYZCLcaSK4aNwYG/4ZCd44hJ5m4bI2co8cvmrfK0P09VeKdgrFbS
         EgQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749521190; x=1750125990;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=f/HF8c/E4CwvCVFAJi+M7PAdBzHSWUE3ap2A0JvmoT4=;
        b=L8WzlVFvq5InqdxlfRTEI25ro9BBI8iSkzJgQ7eXOA19YcDbdKBrmBb4KPIEvbGk55
         c6pPFQyvbv1RvBWy0BtyiT6YsHvsI5323o/Slh/BvZChHd7RWgyoqwNKip3RQtzj9Jvj
         kUNiClLs3AFAuNNl/hI0CZTMCVJAn1UdAJR74UOdnuOd5/K2voHVOEBoiTxND3KJ3bs8
         DtanMhvc8k+fuq1XSWrQ6YKxlw/YNdTU/fSp1wy/aZFBPxC9o/iRyIemAumTyl204kqR
         YY7JIyLlalu37DYO/zcY3JBjv/B07Swax2jX3c3IsWoxellLoQPxfIgoN5B1wSjgocBd
         31xA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWD8H0p1KX5pdI+xtWrrhCJXCC2ANVzJIiBZ6lKOHV74yeIB8w3QhewAG9ha2t45Qkx+SzjixOuAx1U@gnusha.org
X-Gm-Message-State: AOJu0YxlBqarwVPB34vJmsL7eKPihRdX64b26F8P84G16A7dg+aHR+xz
	PIWzRUFQd1U5/mfrQevADohOFR/n3Z95iqhUZagi0msGUXDajoyoJCiK
X-Google-Smtp-Source: AGHT+IENJZ3HfJLatIBiHyGbJCy2gyIme25hvEx/GExP1a5eUDMZNUocch3CXibPnY/xuICm+k+okA==
X-Received: by 2002:a05:6902:4906:b0:e81:718c:e36a with SMTP id 3f1490d57ef6-e81a2350166mr21187159276.47.1749521190019;
        Mon, 09 Jun 2025 19:06:30 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZefPJtk1e0FJHgPZOKSyfwMXdAxDokaYPhKbw3n2+kk9A==
Received: by 2002:a25:d386:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e8188a2baf7ls5041447276.2.-pod-prod-00-us;
 Mon, 09 Jun 2025 19:06:26 -0700 (PDT)
X-Received: by 2002:a05:690c:8f05:b0:70d:f09a:bb4d with SMTP id 00721157ae682-711336833a0mr20443317b3.0.1749521186324;
        Mon, 09 Jun 2025 19:06:26 -0700 (PDT)
Received: by 2002:a05:690c:fc7:b0:710:fccf:6901 with SMTP id 00721157ae682-710fccf6a41ms7b3;
        Mon, 9 Jun 2025 19:02:46 -0700 (PDT)
X-Received: by 2002:a05:690c:6a11:b0:70d:fd6f:b151 with SMTP id 00721157ae682-711338b2837mr25902017b3.11.1749520965200;
        Mon, 09 Jun 2025 19:02:45 -0700 (PDT)
Date: Mon, 9 Jun 2025 19:02:44 -0700 (PDT)
From: Paul Sztorc <truthcoin@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <7db9795a-53ff-4a1e-973e-d6be029d9022n@googlegroups.com>
In-Reply-To: <n4MR-H83t3x3B5yI8tjdTXR21smp_Ur7fRpqk_4EOc_im_zu0-9GlqxC1wl-gEzS__TdJNrf6XsV4XXOzxWn4kpdUocR3Xp8d6Uwo1m4ILw=@protonmail.com>
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <n4MR-H83t3x3B5yI8tjdTXR21smp_Ur7fRpqk_4EOc_im_zu0-9GlqxC1wl-gEzS__TdJNrf6XsV4XXOzxWn4kpdUocR3Xp8d6Uwo1m4ILw=@protonmail.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_257704_1331639532.1749520964843"
X-Original-Sender: Truthcoin@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_257704_1331639532.1749520964843
Content-Type: multipart/alternative; 
	boundary="----=_Part_257705_1953748239.1749520964843"

------=_Part_257705_1953748239.1749520964843
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

 >  the urgency with a six months deadline is nothing short of reckless.=20

But why would 6 months be considered "urgent"?

I think the tiniest amount of clarity would help. I propose a new table=20
(like the covenants support table), where we each self-sort ourselves into=
=20
whichever category describes us BEST:

1) Those who believe ...that each soft fork should take 5+ years (like=20
CTV). ...that we can only activate one soft fork at a time. ...that we must=
=20
debate and "agree" upon which one, to activate. ...that soft forks are a=20
dramatic event, different from other pull requests. ...that we need=20
"consensus" among humans to activate a soft fork. [Etc, etc]
2) Those who would prefer Bitcoin development to revert, more back toward=
=20
the way things were, pre-SegWit drama. In other words: we can activate=20
multiple soft forks at once ; soft forks do not require "agreement" among=
=20
humans -- they just need to meet the same quality threshold as other=20
pull-requests ; we should merge any pull-request, if it is a good idea=20
(regardless of if it is a soft fork or not -- the soft fork part, only=20
affects when it is safe for users to rely on the feature). The [OP NOP / OP=
=20
Success]-style forks, are inherently very safe, ignore-able, and=20
reversible. In theory, we could activate 15 of these in the next release,=
=20
and then later change our mind, and "deactivate" any (or all) of these (by=
=20
banning that opcode from ever being spent to/from again). In that=20
hypothetical scenario (very different from ours today), we would=20
preemptively explain (to users), that all "new opcodes" (less than a year=
=20
old), are "experimental", and may be "deactivated" at any time -- each user=
=20
could decide for themselves if they want to take this risk (during the=20
first 12 months).
3) Those unwilling to clarify their opinion.

If people think "2 soft forks per 10 years" is the right way to go, then=20
they should stand behind that point of view.

People seem to want it both ways -- on one hand, reluctant to stick their=
=20
neck out for any particular soft fork; but, on the other hand, too ashamed=
=20
to admit that they are quietly handcuffing the Bitcoin project to the "5+=
=20
years per softfork", bike-shedding timeline.

Cheers,
Paul

P.S. I have never used google groups before so I hope this email goes out=
=20
correctly.=20

On Monday, June 9, 2025 at 5:17:54=E2=80=AFPM UTC-4 Antoine Poinsot wrote:

> James, cosigners,
>
> I am sympathetic to the idea of a CTV+CSFS soft fork, mainly for its=20
> flagship use case: LN-Symmetry.
>
> However i think it is premature to call for a "final review and=20
> activation" of these opcodes when
> there is still:
> - disagreement between Bitcoin protocol developers/researchers that it is=
=20
> the way to go for enabling
> more expressive scripting capabilities in Bitcoin[^0];
> - disagreement between Bitcoin developers on how the functionality of at=
=20
> least one of the proposed
> opcodes should be achieved[^1];
> - no review after three months, from any of the champions or signers of=
=20
> this letter, on the PR for
> integrating one of the two proposed opcodes to the test network[^2].
>
> The flagship use case of the proposal has also not been properly=20
> demonstrated. As a point of
> comparison Greg Sanders provided motivation for `ANYPREVOUT`, a soft fork=
=20
> that no one even called
> to be "finally reviewed and activated", by publishing a detailed proof of=
=20
> concept of LN-Symmetry
> (with full specification as a BOLT draft + an implementation in one of th=
e=20
> major Lightning clients).
>
> A comprehensive exploration gives confidence a use case is actually=20
> realistic in practice. Of course
> it's not necessary to go to such lengths just to demonstrate it to be=20
> *possible*, but it is
> reasonable to expect a champion to have something to show if they are=20
> calling for changing Bitcoin.
> Fortunately i hear some have taken upon themselves to further explore=20
> LN-Symmetry and multiparty
> channels using CTV+CSFS, which could provide tangible motivation for the=
=20
> soft fork. Let's see what
> they come up with.
>
> Finally, it seems the post contains a built-in assumption that Bitcoin=20
> Core contributors are
> detached from the research in more expressive scripting capabilities. It=
=20
> is incorrect. A number of
> individuals have been involved both with Bitcoin Core development and=20
> Bitcoin protocol research,
> with substantial contributions in both areas.
>
> Therefore it seems the stalling state of the CTV+CSFS proposal is not due=
=20
> to apathy as this open
> letter would lead to believe, but controversy on the content of the=20
> proposal among Bitcoin protocol
> developers as well as a lack of involvement from the part of champions in=
=20
> reaching consensus.
>
> In these conditions calling for an impending change to Bitcoin's consensu=
s=20
> rules seems unadvisable,
> and the urgency with a six months deadline is nothing short of reckless.
>
> I remain confident we can make progress toward enabling more expressive=
=20
> scripting capabilities in
> Bitcoin. The path forward is by building consensus on the basis of strong=
=20
> technical arguments, and
> the politics of pushing for the premature activation of a consensus chang=
e=20
> are working against it.
>
> Best,
> Antoine Poinsot
>
>
> [^0]:=20
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-s=
tep-towards-covenants/1509/14
> https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4...@mattcorallo.com=20
> <https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4-ac51-b881d8df9f01@ma=
ttcorallo.com>
> [^1]:=20
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-s=
tep-towards-covenants/1509/58
> [^2]: https://github.com/bitcoin-inquisition/bitcoin/pull/72
> [^3]: https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
>
>
> On Monday, June 9th, 2025 at 7:54 AM, James O'Beirne <james....@gmail.com=
>=20
> wrote:
>
> > Good morning,
> >=20
> > A letter has been published advocating for the final review and
> > activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK
> > (BIP-348).
> >=20
> > The full text of the letter can be found at https://ctv-csfs.com. It is
> > reproduced below.
> >=20
> > ---
> >=20
> > To the technical bitcoin community,
> >=20
> > We believe that the best next step for bitcoin would be to activate
> > OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK (CSFS,
> > BIP-348). These opcodes enable functionality for a broad set of uses
> > that will allow bitcoin to preserve and expand its role as a scarce,
> > censorship-resistant store of value.
> >=20
> > While there are a few promising proposals to improve bitcoin at the
> > consensus layer which may someday be deployed, we believe that CTV and
> > CSFS are uniquely well reviewed, simple, and have been proven to be bot=
h
> > safe and widely demanded.
> >=20
> > CTV was first formalized in BIP-119 over 5 years ago. Despite many
> > attempts at refinement or replacement, it has remained the most widely
> > preferred method for enforcing pregenerated transaction sequences using
> > consensus. It unlocks valuable functionality for scaling solutions,
> > vaults, congestion control, non-custodial mining, discreet log
> > contracts, and more.
> >=20
> > CSFS is a primitive opcode that has been deployed to Blockstream=E2=80=
=99s
> > Elements for at least 8 years. It represents no significant
> > computational burden over bitcoin=E2=80=99s most often used opcode, OP_=
CHECKSIG.
> > It can be combined with CTV to implement ln-symmetry, a longstanding
> > improvement to Lightning. It also unlocks a variety of other use cases.
> >=20
> > We respectfully ask Bitcoin Core contributors to prioritize the review
> > and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or
> > similar) within the next six months. We believe this timeline allows fo=
r
> > rigorous final review and activation planning.
> >=20
> > This request isn't meant to suggest that these contributors dictate the
> > consensus process, but rather it is an acknowledgement that before thes=
e
> > opcodes can be activated, they must be implemented in the most widely
> > used bitcoin client.
> >=20
> > As application and protocol developers, we are convinced of the
> > significant benefits that these changes would bring to end users of
> > bitcoin =E2=80=93 even if only considering their use for layer 1 securi=
ty and
> > layer 2 scaling solutions. We are optimistic that given the limited siz=
e
> > and scope of these changes in both concept and implementation, they
> > represent a realistic next step in the continuing and important work of
> > preserving bitcoin's unique promise.
> >=20
> > Signed,
> >=20
> > Abdel (Starkware)
> > Andrew Poelstra (@apoelstra)
> > Ben Carman (@benthecarman)
> > Ben Kaufman (@ben-kaufman)
> > Brandon Black (@reardencode)
> > Brian Langel (for Five Bells)
> > Buck Perley (@puckberley)
> > Calle (Cashu)
> > Calvin Kim (@kcalvinalvin)
> > Chun Wang (f2pool)
> > Christian Decker (@cdecker)
> > Coinjoined Chris (Bitsurance.eu)
> > Evan Kaloudis (for Zeus)
> > fiatjaf (@fiatjaf)
> > Floppy (@1440000bytes)
> > Gary Krause (@average-gary)
> > Harsha Goli (@arshbot)
> > Hunter Beast (@cryptoquick)
> > Jad Mubaslat (@champbronc2)
> > James O=E2=80=99Beirne (@jamesob)
> > Jameson Lopp (@jlopp)
> > Johan Halseth (@halseth)
> > Luke Childs (@lukechilds)
> > Matt Black (for Atomic Finance)
> > Michael Tidwell (@miketwenty1)
> > Nick Hansen (for Luxor Mining)
> > Nitesh (@nitesh_btc)
> > nvk (@nvk)
> > Owen Kemeys (for Foundation)
> > Paul Sztorc (@psztorc)
> > Portland.HODL (for MARA Pool)
> > Rijndael (@rot13maxi)
> > Rob Hamilton (@rob1ham)
> > Robin Linus (@RobinLinus)
> > Sanket Kanjalkar (@sanket1729)
> > Sean Ryan (Anchorage)
> > Seth for Privacy (for Cake Wallet)
> > Simanta Gautam (Alpen Labs)
> > Steven Roose (@stevenroose)
> > stutxo (@stutxo)
> > Talip (@otaliptus)
> > mononaut (@mononautical)
> > vnprc (@vnprc)
> >=20
> >=20
> > --
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51be=
eb765163n%40googlegroups.com
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
7db9795a-53ff-4a1e-973e-d6be029d9022n%40googlegroups.com.

------=_Part_257705_1953748239.1749520964843
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


&gt;=C2=A0 the urgency with a six months deadline is nothing short of reckl=
ess.

<br /><br />But why would 6 months be considered "urgent"?<br /><br />I thi=
nk the tiniest amount of clarity would help. I propose a new table (like th=
e covenants support table), where we each self-sort ourselves into whicheve=
r category describes us BEST:<br /><br />1)
 Those who believe ...that each soft fork should take 5+ years (like=20
CTV). ...that we can only activate one soft fork at a time. ...that we=20
must debate and "agree" upon which one, to activate. ...that soft forks=20
are a dramatic event, different from other pull requests. ...that we=20
need "consensus" among humans to activate a soft fork. [Etc, etc]<br /> 2)
 Those who would prefer Bitcoin development to revert, more back toward=20
the way things were, pre-SegWit drama. In other words: we can activate=20
multiple soft forks at once ; soft forks do not require "agreement"=20
among humans -- they just need to meet the same quality threshold as=20
other pull-requests ; we should merge any pull-request, if it is a good
 idea (regardless of if it is a soft fork or not -- the soft fork part,=20
only affects when it is safe for users to rely on the feature). The [OP=20
NOP / OP Success]-style forks, are inherently very safe, ignore-able,=20
and reversible. In theory, we could activate 15 of these in the next=20
release, and then later change our mind, and "deactivate" any (or all)=20
of these (by banning that opcode from ever being spent to/from again).=20
In that hypothetical scenario (very different from ours today), we would
 preemptively explain (to users), that all "new opcodes" (less than a=20
year old), are "experimental", and may be "deactivated" at any time --=20
each user could decide for themselves if they want to take this risk=20
(during the first 12 months).<div>3) Those unwilling to clarify their opini=
on.<br /><br />If people think "2 soft forks per 10 years" is the right way=
 to go, then they should stand behind that point of view.<br /><br />People
 seem to want it both ways -- on one hand, reluctant to stick=20
their neck out for any particular soft fork; but, on the other hand, too=20
ashamed to admit that they are quietly handcuffing the Bitcoin project to t=
he=20
"5+ years per softfork", bike-shedding timeline.<br /><br />Cheers,<br />Pa=
ul</div><br />P.S. I have never used google groups before so I hope this em=
ail goes out correctly.

<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_att=
r">On Monday, June 9, 2025 at 5:17:54=E2=80=AFPM UTC-4 Antoine Poinsot wrot=
e:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex=
; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">James, cos=
igners,
<br>
<br>I am sympathetic to the idea of a CTV+CSFS soft fork, mainly for its fl=
agship use case: LN-Symmetry.
<br>
<br>However i think it is premature to call for a &quot;final review and ac=
tivation&quot; of these opcodes when
<br>there is still:
<br>- disagreement between Bitcoin protocol developers/researchers that it =
is the way to go for enabling
<br>  more expressive scripting capabilities in Bitcoin[^0];
<br>- disagreement between Bitcoin developers on how the functionality of a=
t least one of the proposed
<br>  opcodes should be achieved[^1];
<br>- no review after three months, from any of the champions or signers of=
 this letter, on the PR for
<br>  integrating one of the two proposed opcodes to the test network[^2].
<br>
<br>The flagship use case of the proposal has also not been properly demons=
trated. As a point of
<br>comparison Greg Sanders provided motivation for `ANYPREVOUT`, a soft fo=
rk that no one even called
<br>to be &quot;finally reviewed and activated&quot;, by publishing a detai=
led proof of concept of LN-Symmetry
<br>(with full specification as a BOLT draft + an implementation in one of =
the major Lightning clients).
<br>
<br>A comprehensive exploration gives confidence a use case is actually rea=
listic in practice. Of course
<br>it&#39;s not necessary to go to such lengths just to demonstrate it to =
be *possible*, but it is
<br>reasonable to expect a champion to have something to show if they are c=
alling for changing Bitcoin.
<br>Fortunately i hear some have taken upon themselves to further explore L=
N-Symmetry and multiparty
<br>channels using CTV+CSFS, which could provide tangible motivation for th=
e soft fork. Let&#39;s see what
<br>they come up with.
<br>
<br>Finally, it seems the post contains a built-in assumption that Bitcoin =
Core contributors are
<br>detached from the research in more expressive scripting capabilities. I=
t is incorrect. A number of
<br>individuals have been involved both with Bitcoin Core development and B=
itcoin protocol research,
<br>with substantial contributions in both areas.
<br>
<br>Therefore it seems the stalling state of the CTV+CSFS proposal is not d=
ue to apathy as this open
<br>letter would lead to believe, but controversy on the content of the pro=
posal among Bitcoin protocol
<br>developers as well as a lack of involvement from the part of champions =
in reaching consensus.
<br>
<br>In these conditions calling for an impending change to Bitcoin&#39;s co=
nsensus rules seems unadvisable,
<br>and the urgency with a six months deadline is nothing short of reckless=
.
<br>
<br>I remain confident we can make progress toward enabling more expressive=
 scripting capabilities in
<br>Bitcoin. The path forward is by building consensus on the basis of stro=
ng technical arguments, and
<br>the politics of pushing for the premature activation of a consensus cha=
nge are working against it.
<br>
<br>Best,
<br>Antoine Poinsot
<br>
<br>
<br>[^0]: <a href=3D"https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-con=
sensus-on-a-first-step-towards-covenants/1509/14" target=3D"_blank" rel=3D"=
nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-=
step-towards-covenants/1509/14&amp;source=3Dgmail&amp;ust=3D174960581318500=
0&amp;usg=3DAOvVaw2hMB5SO4xxu4A_HAOzXMxs">https://delvingbitcoin.org/t/ctv-=
csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/14</a>
<br>      <a href=3D"https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4-ac=
51-b881d8df9f01@mattcorallo.com" target=3D"_blank" rel=3D"nofollow" data-sa=
feredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gnusha.=
org/pi/bitcoindev/6f78b702-4bd0-4aa4-ac51-b881d8df9f01@mattcorallo.com&amp;=
source=3Dgmail&amp;ust=3D1749605813185000&amp;usg=3DAOvVaw0Wnay8X18Yyh-lzId=
mt7Nl">https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4...@mattcorallo.c=
om</a>
<br>[^1]: <a href=3D"https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-con=
sensus-on-a-first-step-towards-covenants/1509/58" target=3D"_blank" rel=3D"=
nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-=
step-towards-covenants/1509/58&amp;source=3Dgmail&amp;ust=3D174960581318500=
0&amp;usg=3DAOvVaw0fdMxKtEHmCMgkJHE-aca4">https://delvingbitcoin.org/t/ctv-=
csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/58</a>
<br>[^2]: <a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/72=
" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.go=
ogle.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin-inquisition/bitcoin=
/pull/72&amp;source=3Dgmail&amp;ust=3D1749605813185000&amp;usg=3DAOvVaw3AR7=
4osriCcnZA0BLFQaZT">https://github.com/bitcoin-inquisition/bitcoin/pull/72<=
/a>
<br>[^3]: <a href=3D"https://delvingbitcoin.org/t/ln-symmetry-project-recap=
/359" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://ww=
w.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.org/t/ln-symmetry-p=
roject-recap/359&amp;source=3Dgmail&amp;ust=3D1749605813185000&amp;usg=3DAO=
vVaw2E_hkjxckb20aP_1dZ4S_o">https://delvingbitcoin.org/t/ln-symmetry-projec=
t-recap/359</a>
<br>
<br>
<br>On Monday, June 9th, 2025 at 7:54 AM, James O&#39;Beirne &lt;<a href da=
ta-email-masked rel=3D"nofollow">james....@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Good morning,
<br>&gt;=20
<br>&gt; A letter has been published advocating for the final review and
<br>&gt; activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROM=
STACK
<br>&gt; (BIP-348).
<br>&gt;=20
<br>&gt; The full text of the letter can be found at <a href=3D"https://ctv=
-csfs.com" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Den&amp;q=3Dhttps://ctv-csfs.com&amp;source=3Dgma=
il&amp;ust=3D1749605813185000&amp;usg=3DAOvVaw0JPfbgaslm_KZvarOwji4K">https=
://ctv-csfs.com</a>. It is
<br>&gt; reproduced below.
<br>&gt;=20
<br>&gt; ---
<br>&gt;=20
<br>&gt; To the technical bitcoin community,
<br>&gt;=20
<br>&gt; We believe that the best next step for bitcoin would be to activat=
e
<br>&gt; OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK (CS=
FS,
<br>&gt; BIP-348). These opcodes enable functionality for a broad set of us=
es
<br>&gt; that will allow bitcoin to preserve and expand its role as a scarc=
e,
<br>&gt; censorship-resistant store of value.
<br>&gt;=20
<br>&gt; While there are a few promising proposals to improve bitcoin at th=
e
<br>&gt; consensus layer which may someday be deployed, we believe that CTV=
 and
<br>&gt; CSFS are uniquely well reviewed, simple, and have been proven to b=
e both
<br>&gt; safe and widely demanded.
<br>&gt;=20
<br>&gt; CTV was first formalized in BIP-119 over 5 years ago. Despite many
<br>&gt; attempts at refinement or replacement, it has remained the most wi=
dely
<br>&gt; preferred method for enforcing pregenerated transaction sequences =
using
<br>&gt; consensus. It unlocks valuable functionality for scaling solutions=
,
<br>&gt; vaults, congestion control, non-custodial mining, discreet log
<br>&gt; contracts, and more.
<br>&gt;=20
<br>&gt; CSFS is a primitive opcode that has been deployed to Blockstream=
=E2=80=99s
<br>&gt; Elements for at least 8 years. It represents no significant
<br>&gt; computational burden over bitcoin=E2=80=99s most often used opcode=
, OP_CHECKSIG.
<br>&gt; It can be combined with CTV to implement ln-symmetry, a longstandi=
ng
<br>&gt; improvement to Lightning. It also unlocks a variety of other use c=
ases.
<br>&gt;=20
<br>&gt; We respectfully ask Bitcoin Core contributors to prioritize the re=
view
<br>&gt; and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 =
or
<br>&gt; similar) within the next six months. We believe this timeline allo=
ws for
<br>&gt; rigorous final review and activation planning.
<br>&gt;=20
<br>&gt; This request isn&#39;t meant to suggest that these contributors di=
ctate the
<br>&gt; consensus process, but rather it is an acknowledgement that before=
 these
<br>&gt; opcodes can be activated, they must be implemented in the most wid=
ely
<br>&gt; used bitcoin client.
<br>&gt;=20
<br>&gt; As application and protocol developers, we are convinced of the
<br>&gt; significant benefits that these changes would bring to end users o=
f
<br>&gt; bitcoin =E2=80=93 even if only considering their use for layer 1 s=
ecurity and
<br>&gt; layer 2 scaling solutions. We are optimistic that given the limite=
d size
<br>&gt; and scope of these changes in both concept and implementation, the=
y
<br>&gt; represent a realistic next step in the continuing and important wo=
rk of
<br>&gt; preserving bitcoin&#39;s unique promise.
<br>&gt;=20
<br>&gt; Signed,
<br>&gt;=20
<br>&gt; Abdel (Starkware)
<br>&gt; Andrew Poelstra (@apoelstra)
<br>&gt; Ben Carman (@benthecarman)
<br>&gt; Ben Kaufman (@ben-kaufman)
<br>&gt; Brandon Black (@reardencode)
<br>&gt; Brian Langel (for Five Bells)
<br>&gt; Buck Perley (@puckberley)
<br>&gt; Calle (Cashu)
<br>&gt; Calvin Kim (@kcalvinalvin)
<br>&gt; Chun Wang (f2pool)
<br>&gt; Christian Decker (@cdecker)
<br>&gt; Coinjoined Chris (Bitsurance.eu)
<br>&gt; Evan Kaloudis (for Zeus)
<br>&gt; fiatjaf (@fiatjaf)
<br>&gt; Floppy (@1440000bytes)
<br>&gt; Gary Krause (@average-gary)
<br>&gt; Harsha Goli (@arshbot)
<br>&gt; Hunter Beast (@cryptoquick)
<br>&gt; Jad Mubaslat (@champbronc2)
<br>&gt; James O=E2=80=99Beirne (@jamesob)
<br>&gt; Jameson Lopp (@jlopp)
<br>&gt; Johan Halseth (@halseth)
<br>&gt; Luke Childs (@lukechilds)
<br>&gt; Matt Black (for Atomic Finance)
<br>&gt; Michael Tidwell (@miketwenty1)
<br>&gt; Nick Hansen (for Luxor Mining)
<br>&gt; Nitesh (@nitesh_btc)
<br>&gt; nvk (@nvk)
<br>&gt; Owen Kemeys (for Foundation)
<br>&gt; Paul Sztorc (@psztorc)
<br>&gt; Portland.HODL (for MARA Pool)
<br>&gt; Rijndael (@rot13maxi)
<br>&gt; Rob Hamilton (@rob1ham)
<br>&gt; Robin Linus (@RobinLinus)
<br>&gt; Sanket Kanjalkar (@sanket1729)
<br>&gt; Sean Ryan (Anchorage)
<br>&gt; Seth for Privacy (for Cake Wallet)
<br>&gt; Simanta Gautam (Alpen Labs)
<br>&gt; Steven Roose (@stevenroose)
<br>&gt; stutxo (@stutxo)
<br>&gt; Talip (@otaliptus)
<br>&gt; mononaut (@mononautical)
<br>&gt; vnprc (@vnprc)
<br>&gt;=20
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.co=
m" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/=
a86c2737-db79-4f54-9c1d-51beeb765163n%2540googlegroups.com&amp;source=3Dgma=
il&amp;ust=3D1749605813185000&amp;usg=3DAOvVaw3ltY90fcFT_a41ZZ3FVyqw">https=
://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb76516=
3n%40googlegroups.com</a>.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/7db9795a-53ff-4a1e-973e-d6be029d9022n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/7db9795a-53ff-4a1e-973e-d6be029d9022n%40googlegroups.com</a>.<br />

------=_Part_257705_1953748239.1749520964843--

------=_Part_257704_1331639532.1749520964843--