summaryrefslogtreecommitdiff
path: root/00/5fa4854367697135717a159075d1c5125a6d89
blob: 507d48267853d0f065435f11b5fc1fc7bb4e7cc4 (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
707
708
709
710
711
Delivery-date: Tue, 10 Jun 2025 06:32:52 -0700
Received: from mail-yb1-f188.google.com ([209.85.219.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDRIFMNQZANRB6HHUDBAMGQEMACFJZI@googlegroups.com>)
	id 1uOz5u-0002kq-6J
	for bitcoindev@gnusha.org; Tue, 10 Jun 2025 06:32:52 -0700
Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e81f8bf7c71sf491923276.2
        for <bitcoindev@gnusha.org>; Tue, 10 Jun 2025 06:32:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749562364; x=1750167164; 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=aC87yY7Pz5IONgLrrGkF02UwZ3GVqcZzda4oudvFrsc=;
        b=gw7dQBtHIEGQjqSSYndAK2MZ8e7DP/oEsbOcv5TkgH1GijimOy9TkT1Ek5KthrME31
         5cTu0JpucxpzVGDPnC+vvvC7TGtlnyz14AgXA5+CuvGud4mgviEPwSr+xVW/DwK6rQOc
         7vzT7af/x8oDX/rxg1lbLokRURKOb9wzk0BbRw9vtgRWvqiPSD9mdP69rd16g+kCJbvW
         V0EEEEfalM6ZRVKSWSaDCjDxSMLwm1JQba5QIqtJu5S1rbPii0Gq8CZTKRwiegLvf8z/
         2OngQp4UoU8+l4/yFxCx1SNjVy3cDilVrhVmvFc5+85yurWpU2QSC01Qsz+5s5LKT+eA
         AsRA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749562364; x=1750167164; 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=aC87yY7Pz5IONgLrrGkF02UwZ3GVqcZzda4oudvFrsc=;
        b=QYGfxRMMUQ6cBhHZxM9xiC75uMuFFsI7lrG2dt1d8qVVA+00ENsyMECd+Q5KNkTc2X
         xFMEXlhMTsMnsZztJCLgibgI9cz9dL9+1SWAC49EZzctD3jqvNnnnBGfg9iHNb1D7xTK
         jMDz/sGFItgFz14J2Bv+KiWv2H9OHd9zGo1+qdygGU8AgIy0l4J4Ka5Lvo2n9HFccvf5
         2fH8ZWd7Gk8FNosPL+r/lQs5f0eMKrKqY3B+2vcfG40pBmW9Czb/M3jBPgMyPH4byYhE
         5l9SqXrvaiXEhhbXsUTRsMjTLhvW9otH5BxvapqCsu3/vnKXRhZmLwMuELMqKRBrWS9g
         n5zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749562364; x=1750167164;
        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=aC87yY7Pz5IONgLrrGkF02UwZ3GVqcZzda4oudvFrsc=;
        b=ZEjZ8Nvu2iCLNDSWDIlvFpQ9yqH0C62qoyuWenzfR1JSGpOfJd40Nsj0lnMHMFYAb7
         AFMIyYDnX3XxbLLxPo2WWfpxl1dfu/U/4+W6lYHvQbCQ7c+6AD6GuVtTAMRVFfAEr1VH
         KxIBLR/+ZiZzX7m1DOmCzCd2COQjYNg7fPtuR59Vh26y6NF1D62XPQRtxVawEPkZWYfk
         fZJGoGnpnw3dp4pyI11aqLpASajgIBTNCCxYN2Rkt1xeyRbKrEaFr6HfvvECg98lHzND
         rpAp83LkERSiBOty/GMt8+aDthniKVbEz43LFK5hYy7U2ZiFsuYgTkc0jakPcypMUpKs
         N0gw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVh4lMnXMqcOrHpD7Sm3mqjWWlr99oJJzI1NP0jLj+fkX0cPRRcXGA0DkrJQN5kg+GlvgOHXGSJQAZQ@gnusha.org
X-Gm-Message-State: AOJu0Ywb2VK/c2wT0u7G29FSSKJSaFyWxwFHELlsEeiieUHXqlhMb8kM
	0d3D1w5z8UQYB66wi5AVJ3lMGLjeSU+hPeXRwJAmxOt6YVuS+wEcQQAp
X-Google-Smtp-Source: AGHT+IHNvObzfc48J8PDDucT3jV66Iitni1VI85ttx45XNks6zBNLPeu9JzPspH+aRSzC9+dxxTR2w==
X-Received: by 2002:a05:6902:220c:b0:e7f:263e:4304 with SMTP id 3f1490d57ef6-e81a21206b9mr24967990276.17.1749562364208;
        Tue, 10 Jun 2025 06:32:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZe1a7wLJ/jHZ/g2/8ZgTai81OJV1zpyQ6J/HK1YTrk4rg==
Received: by 2002:a25:ce90:0:b0:e7d:7490:4a2b with SMTP id 3f1490d57ef6-e8188961470ls5881702276.1.-pod-prod-02-us;
 Tue, 10 Jun 2025 06:32:40 -0700 (PDT)
X-Received: by 2002:a05:690c:a8e:b0:6ef:5097:5daa with SMTP id 00721157ae682-7113675e124mr34727657b3.34.1749562360082;
        Tue, 10 Jun 2025 06:32:40 -0700 (PDT)
Received: by 2002:a05:690c:fc7:b0:710:fccf:6901 with SMTP id 00721157ae682-710fccf6a41ms7b3;
        Tue, 10 Jun 2025 06:20:01 -0700 (PDT)
X-Received: by 2002:a05:690c:b17:b0:710:f6eb:9b33 with SMTP id 00721157ae682-711365ca71amr36433047b3.15.1749561600125;
        Tue, 10 Jun 2025 06:20:00 -0700 (PDT)
Date: Tue, 10 Jun 2025 06:19:59 -0700 (PDT)
From: Greg Sanders <gsanders87@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com>
In-Reply-To: <CAKaEYh+tLtzaqAcN26RLw3AeNhF6VYvMdKrQY6dfCdhYg2Ad3w@mail.gmail.com>
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <aEdoIvOgNNtT6L4s@mail.wpsoftware.net>
 <CAKaEYh+tLtzaqAcN26RLw3AeNhF6VYvMdKrQY6dfCdhYg2Ad3w@mail.gmail.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_279426_32049839.1749561599771"
X-Original-Sender: gsanders87@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_279426_32049839.1749561599771
Content-Type: multipart/alternative; 
	boundary="----=_Part_279427_819387427.1749561599771"

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


Sorry, this got very long at least for my standards.

I'd like to start off by saying I believe that Bitcoin is in good technical=
=20
hands regardless of how this shakes out. Good things take time and we've=20
learned a lot; let's continue doing so.

Before I dive into what I think needs to be answered for this proposal to=
=20
move forward, I'd like to respond to language in the letter to make sure=20
we're on a common understanding of the asks being given here.

> We respectfully ask Bitcoin Core contributors to prioritize the review=20
and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or=20
similar) within the next six months. We believe this timeline allows for=20
rigorous final review and activation planning.

This is the meat of the post. This seemingly dictates inclusion for=20
activation as a fait accompli. Is this intended? The most generous=20
interpretation is that it's an ask for rigorous review, with the explicit=
=20
intention that if there is broad technical consensus to activate, that=20
broader communication to non-technical world + activation discussions=20
occur. I'd like to think this this is especially a call for those who have=
=20
not spoken up, including those who have done the homework yet conceptually=
=20
disagree?

What efforts will be done by proponents to gather that feedback and make it=
=20
public?

Each co-signer should consider what feedback could be received that would=
=20
demonstrate lack of technical consensus. I think it's plain that there=20
isn't at least 100% excitement in the technical community for the proposal.=
=20
How much of this lack of enthusiasm stems from inattention vs outright=20
opposition?=20

> six months

What happens if this time runs out? Is this just an ask to have people take=
=20
a look within a "few months" and continue/cease work after depending on=20
results?

# Feedback on Effort

I grouped my specific feedback as larger conceptual concerns, specification=
=20
concerns, and deployment concerns. They don't need to be answered inline=20
here at this specific venue, but this is a synthesis of my hesitation about=
=20
the current effort, hopefully with some concrete actions that can be taken.

For sake of discussion:
"CTV" means "next tx" commitment capability, not BIP119 per se
"TXHASH" means CTV with many knobs for app devs to choose what to commit to
"CSFS" means what's on the tin (less wiggle room here for changes)

## Larger conceptual concern:

Given all the things we've learned over the lifetime of BIP119 and the=20
prior iterations, we need to consider "why here and not there". What's a=20
good stopping point for adding functionality to Bitcoin Script, when we=20
have essentially infinitely combinations possible and different strategies?

My mental model of where we should stop in terms of capabilities comes in=
=20
the form of:=20

"Why here and not there"?
 - Why not just CTV?
 - Why CTV + CSFS?
 - Why not TXHASH + CSFS?
 - Why not bucket of opcodes? "swiss army knife" approach

"MEVil" is one type of objection to generalized Bitcoin script=20
introspection. CTV+CSFS is not known to appreciably increase MEVil=20
potential. For the sake of argument, let's assume this dimension doesn't=20
matter, due to a mixture in technical/market realities, or ColliderVM is=20
deployed, or the deployment of based rollups on Bitcoin without any=20
softforks. In some of those cases we should deploy anti-MEV technology=20
regardless, but let's set that aside.

Everyone should consider these on their own but stating my own view to=20
start the conversation:

Why not just CTV? I think there is general agreement that CTV alone was=20
insufficiently exciting to enough of the technical community to be deployed=
=20
on its own. There are some cool usages without, but the complementary=20
nature of a straight forward CSFS capability is too much to overlook,=20
increasing the flagship use-cases substantially.

Why not TXHASH+CSFS? If the cost is a year of concentrated development to=
=20
do something better, we should just do it. We could easily as a community=
=20
decide that TXHASH (with CTV capabilities being baked in as a trivial=20
default mode thereof) is the thing we actually want and easily get the=20
design finalized within that timeframe. With TXHASH+CSFS we can let app=20
developers decide what they find important, versus the opinionated CTV=20
default, whatever that is.

Note that I'm not totally convinced by this argument in either direction.=
=20
Once we have TXHASH, there's really no reason to not have CAT (that's very=
=20
small too!), maybe big num math, perhaps direct introspection. Maybe=20
bllish, simplicity, or GSR? The community would have to agree on a stopping=
=20
point, and that seems like it could be difficult to do in a=20
short-in-year-terms timeline.

Why not bucket of opcodes? Same arguments apply on slippery slope but=20
moreso. There's no clear stopping point, turning it into a giant research=
=20
and engineering project, even if it's a good idea to start working on it=20
now.

## Specification concerns:

1. Why not commit to annex? I had considered future annex relay as=20
problematic for rolling out BIP119 due to its lack of commitment to the=20
annex field. Committing or not are both reasonable depending on usage. With=
=20
https://github.com/bitcoin/bitcoin/pull/32453 it at least won't impede=20
annex relay efforts unduly, so maybe this can be punted and CTV sticks=20
closer to it's minimalistic txid-stable design goal. Bringing this up=20
because few people seem to have considered this historically.

2. Legacy script support is not technically necessary for the capabilities=
=20
we desire. It considerably increases review surface for no known capability=
=20
gain and no known savings for protocols. Legacy scripting should not be=20
modified lightly, and if there's no strong motivation, it should be=20
abandoned in favor of solutions that don't touch it. See more discussion in=
=20
that direction here:=20
https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-ste=
p-towards-covenants/1509/75

2. BIP119 committing to other prevouts very indirectly is a surprising=20
anti-feature:=20
https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591

This feature is proported to make specific BitVM constructions trustless in=
=20
one respect, instead of the 1-of-n trust assumption held. This is extremely=
=20
surprising, and as can be seen in the thread extremely brittle and ugly.=20
BIP119 activated alone seemingly incentivizes very non-standard scriptSigs=
=20
on legacy scripting, rather than directly offering the functionality=20
desired. This is a bad sign which either means we should ban it outright by=
=20
f.e. requiring scriptSigs to be blank, or take another long hard look at=20
TXHASH to give app devs tools they actually want such as TXHASH.

What other surprising capabilities lurk in BIP119 that would incentivize=20
deranged usage like this? Maybe nothing? Perhaps it's hubris to predict it=
=20
and we should just do TXHASH? Maybe this hack is not a big deal and I=20
shouldn't be physically repulsed by having to carve out a standardness rule=
=20
for it?

## Concrete Deployment concerns:

1. Summarize technical community objections and adequately address them in=
=20
a single discoverable location. I do not believe this has been done=20
adequately up until now.

2. Specification feedback fully addressed and discoverable in a single=20
location.

3. Flagship PoCs: At a minimum I would hope for some level of LN-Symmetry=
=20
PoC, and or perhaps proving out hArk(or Erk), and make sure they are=20
re-validated on whatever the final spec would end up being. If we want to=
=20
draw some lessons on taproot activation it should be that validation should=
=20
be done throughout the lifetime of the proposal, not early and then only=20
after activation.

I'm hopeful on this front but 6 months to get things like this done in=20
addition to everything else seems very short.

4. Second consensus implementation: It's important to validate the BIPs and=
=20
gather more design feedback before finality of spec. Again, let's learn=20
some lessons from past mistakes. Can btcd get a branch up and running that=
=20
matches the specs and bitcoind?
On Tuesday, June 10, 2025 at 5:52:27=E2=80=AFAM UTC-4 Melvin Carvalho wrote=
:

>
>
> =C3=BAt 10. 6. 2025 v 1:11 odes=C3=ADlatel Andrew Poelstra <apoe...@wpsof=
tware.net>=20
> napsal:
>
>> Le Mon, Jun 09, 2025 at 04:40:52AM -0700, James O'Beirne a =C3=A9crit :
>> > Good morning,
>> >=20
>> > A letter has been published advocating for the final review and
>> > activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTAC=
K
>> > (BIP-348).=20
>> >=20
>> > The full text of the letter can be found at https://ctv-csfs.com. It i=
s
>> > reproduced below.
>> >
>>
>> Hi all,
>>
>>
>> James, thanks for posting the letter. Matt, Antoine -- thanks for
>> replying quickly and respectfully even though you disagree with its
>> contents. Let me try to clarify my stance and why I signed onto the
>> letter.
>>
>> First, the specific choice of CTV + CSFS would not be my first choice
>> on technical grounds. But what I'd like to see is something that is
>> technically "good enough" to enable vaults and some new script usecases,
>> while avoiding things that are politically toxic (which seems to be
>> pretty-much everything, but maybe right now does not include CTV+CSFS?).
>>
>> So any arguments about CTV+CSFS on the technical merits I think are
>> great and within the purview of "review and integration" that the letter
>> talks about. (The word "final" I think is too strong and in retrospect
>> I think we should've dropped it. But it's super difficult when writing
>> these things to identify which specific points of language need to be
>> changed.)
>>
>>
>> Second, regarding the ultimatum language -- it was quite difficult to
>> strike a balance between "Core consists of volunteers working on their
>> on projects, with no obligation to anybody, and certainly no obligation
>> to drive forward consensus changes" and "this is a letter that says
>> nothing substantial at all".
>>
>> The message that I want to communicate is: Bitcoin Core, like many
>> stakeholders, can veto any consensus changes because there will never be
>> a large enough contigent of the Bitcoin community confident to rush in
>> where angels dare to tread. But furthermore, if nobody in Core wants to
>> engage at all with consensus changes, then the result is effectively the
>> same as a veto.
>>
>> Therefore, if we want to see an increase in script expressivity, somebod=
y
>> on the Core team needs to help champion it. (There's no one in particula=
r
>> I imagine this "somebody" to be, and I suppose you could accuse me of
>> hypocrisy since I'm not volunteering myself, even though I have the
>> social and technical knowledge to help. It could be, and probably would
>> have to be, somebody who isn't currently active on Core. But it needs to
>> be somebody willing and able to work within the Core review process, to
>> deal with ongoing rebases, etc.)
>>
>>
>> Third, I really really hope that this letter does not lead to further
>> brigading or twitter fights or whatever bleeding into the Github repo.
>> (This is the one point where I think that my fellow cosigners agree with
>> me fully.) But on the other hand, I don't think that I personally should
>> shy away from discussion to mitigate that risk; it needs to be mitigated
>> by more agressive moderation or by higher barriers to entry for people
>> posting on Core PRs.
>>
>
>
> Andrew, would you agree with this premise?=20
>
> Bitcoin changes must be demonstrably proven safe, needed, and wanted=20
> before adoption.  Proposers bear the burden, not the community.  If the=
=20
> benefit doesn't demonstrably outweigh the risk, the answer is simple: don=
't=20
> fork the rules.
> =20
>
>>
>>
>>
>> Best
>> Andrew
>>
>>
>>
>>
>> --=20
>> Andrew Poelstra
>> Director, Blockstream Research
>> Email: apoelstra at wpsoftware.net
>> Web:   https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>>     -Justin Lewis-Webster
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to bitcoindev+...@googlegroups.com.
>>
> To view this discussion visit=20
>> https://groups.google.com/d/msgid/bitcoindev/aEdoIvOgNNtT6L4s%40mail.wps=
oftware.net
>> .
>>
>

--=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/=
b17d0544-d292-4b4d-98c6-fa8dc4ef573cn%40googlegroups.com.

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

<br />Sorry, this got very long at least for my standards.<br /><br />I'd l=
ike to start off by saying I believe that Bitcoin is in good technical hand=
s regardless of how this shakes out. Good things take time and we've learne=
d a lot; let's continue doing so.<br /><br />Before I dive into what I thin=
k needs to be answered for this proposal to move forward, I'd like to respo=
nd to language in the letter to make sure we're on a common understanding o=
f the asks being given here.<br /><br />&gt; We respectfully ask Bitcoin Co=
re 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 for rigorous final review and activation plann=
ing.<br /><br />This is the meat of the post. This seemingly dictates inclu=
sion for activation as a fait accompli. Is this intended? The most generous=
 interpretation is that it's an ask for rigorous review, with the explicit =
intention that if there is broad technical consensus to activate, that broa=
der communication to non-technical world + activation discussions occur. I'=
d like to think this this is especially a call for those who have not spoke=
n up, including those who have done the homework yet conceptually disagree?=
<br /><br />What efforts will be done by proponents to gather that feedback=
 and make it public?<br /><br />Each co-signer should consider what feedbac=
k could be received that would demonstrate lack of technical consensus. I t=
hink it's plain that there isn't at least 100% excitement in the technical =
community for the proposal. How much of this lack of enthusiasm stems from =
inattention vs outright opposition? <br /><br />&gt; six months<br /><br />=
What happens if this time runs out? Is this just an ask to have people take=
 a look within a "few months" and continue/cease work after depending on re=
sults?<br /><br /># Feedback on Effort<br /><br />I grouped my specific fee=
dback as larger conceptual concerns, specification concerns, and deployment=
 concerns. They don't need to be answered inline here at this specific venu=
e, but this is a synthesis of my hesitation about the current effort, hopef=
ully with some concrete actions that can be taken.<br /><br />For sake of d=
iscussion:<br />"CTV" means "next tx" commitment capability, not BIP119 per=
 se<br />"TXHASH" means CTV with many knobs for app devs to choose what to =
commit to<br />"CSFS" means what's on the tin (less wiggle room here for ch=
anges)<br /><br />## Larger conceptual concern:<br /><br />Given all the th=
ings we've learned over the lifetime of BIP119 and the prior iterations, we=
 need to consider "why here and not there". What's a good stopping point fo=
r adding functionality to Bitcoin Script, when we have essentially infinite=
ly combinations possible and different strategies?<br /><br />My mental mod=
el of where we should stop in terms of capabilities comes in the form of: <=
br /><br />"Why here and not there"?<br />=C2=A0- Why not just CTV?<br />=
=C2=A0- Why CTV + CSFS?<br />=C2=A0- Why not TXHASH + CSFS?<br />=C2=A0- Wh=
y not bucket of opcodes? "swiss army knife" approach<br /><br />"MEVil" is =
one type of objection to generalized Bitcoin script introspection. CTV+CSFS=
 is not known to appreciably increase MEVil potential. For the sake of argu=
ment, let's assume this dimension doesn't matter, due to a mixture in techn=
ical/market realities, or ColliderVM is deployed, or the deployment of base=
d rollups on Bitcoin without any softforks. In some of those cases we shoul=
d deploy anti-MEV technology regardless, but let's set that aside.<br /><br=
 />Everyone should consider these on their own but stating my own view to s=
tart the conversation:<br /><br />Why not just CTV? I think there is genera=
l agreement that CTV alone was insufficiently exciting to enough of the tec=
hnical community to be deployed on its own. There are some cool usages with=
out, but the complementary nature of a straight forward CSFS capability is =
too much to overlook, increasing the flagship use-cases substantially.<br /=
><br />Why not TXHASH+CSFS? If the cost is a year of concentrated developme=
nt to do something better, we should just do it. We could easily as a commu=
nity decide that TXHASH (with CTV capabilities being baked in as a trivial =
default mode thereof) is the thing we actually want and easily get the desi=
gn finalized within that timeframe. With TXHASH+CSFS we can let app develop=
ers decide what they find important, versus the opinionated CTV default, wh=
atever that is.<br /><br />Note that I'm not totally convinced by this argu=
ment in either direction. Once we have TXHASH, there's really no reason to =
not have CAT (that's very small too!), maybe big num math, perhaps direct i=
ntrospection. Maybe bllish, simplicity, or GSR? The community would have to=
 agree on a stopping point, and that seems like it could be difficult to do=
 in a short-in-year-terms timeline.<br /><br />Why not bucket of opcodes? S=
ame arguments apply on slippery slope but moreso. There's no clear stopping=
 point, turning it into a giant research and engineering project, even if i=
t's a good idea to start working on it now.<br /><br />## Specification con=
cerns:<br /><br />1. Why not commit to annex? I had considered future annex=
 relay as problematic for rolling out BIP119 due to its lack of commitment =
to the annex field. Committing or not are both reasonable depending on usag=
e. With https://github.com/bitcoin/bitcoin/pull/32453 it at least won't imp=
ede annex relay efforts unduly, so maybe this can be punted and CTV sticks =
closer to it's minimalistic txid-stable design goal. Bringing this up becau=
se few people seem to have considered this historically.<br /><br />2. Lega=
cy script support is not technically necessary for the capabilities we desi=
re. It considerably increases review surface for no known capability gain a=
nd no known savings for protocols. Legacy scripting should not be modified =
lightly, and if there's no strong motivation, it should be abandoned in fav=
or of solutions that don't touch it. See more discussion in that direction =
here: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-fir=
st-step-towards-covenants/1509/75<br /><br />2. BIP119 committing to other =
prevouts very indirectly is a surprising anti-feature: https://delvingbitco=
in.org/t/how-ctv-csfs-improves-bitvm-bridges/1591<br /><br />This feature i=
s proported to make specific BitVM constructions trustless in one respect, =
instead of the 1-of-n trust assumption held. This is extremely surprising, =
and as can be seen in the thread extremely brittle and ugly. BIP119 activat=
ed alone seemingly incentivizes very non-standard scriptSigs on legacy scri=
pting, rather than directly offering the functionality desired. This is a b=
ad sign which either means we should ban it outright by f.e. requiring scri=
ptSigs to be blank, or take another long hard look at TXHASH to give app de=
vs tools they actually want such as TXHASH.<br /><br />What other surprisin=
g capabilities lurk in BIP119 that would incentivize deranged usage like th=
is? Maybe nothing? Perhaps it's hubris to predict it and we should just do =
TXHASH? Maybe this hack is not a big deal and I shouldn't be physically rep=
ulsed by having to carve out a standardness rule for it?<br /><br />## Conc=
rete Deployment concerns:<br /><br />1. Summarize technical community objec=
tions and adequately address them in a single discoverable location. I do n=
ot believe this has been done adequately up until now.<br /><br />2. Specif=
ication feedback fully addressed and discoverable in a single location.<br =
/><br />3. Flagship PoCs: At a minimum I would hope for some level of LN-Sy=
mmetry PoC, and or perhaps proving out hArk(or Erk), and make sure they are=
 re-validated on whatever the final spec would end up being. If we want to =
draw some lessons on taproot activation it should be that validation should=
 be done throughout the lifetime of the proposal, not early and then only a=
fter activation.<br /><br />I'm hopeful on this front but 6 months to get t=
hings like this done in addition to everything else seems very short.<br />=
<br />4. Second consensus implementation: It's important to validate the BI=
Ps and gather more design feedback before finality of spec. Again, let's le=
arn some lessons from past mistakes. Can btcd get a branch up and running t=
hat matches the specs and bitcoind?<br /><div class=3D"gmail_quote"><div di=
r=3D"auto" class=3D"gmail_attr">On Tuesday, June 10, 2025 at 5:52:27=E2=80=
=AFAM UTC-4 Melvin Carvalho wrote:<br/></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=C3=BAt 10. 6. =
2025 v=C2=A01:11 odes=C3=ADlatel Andrew Poelstra &lt;<a href data-email-mas=
ked rel=3D"nofollow">apoe...@wpsoftware.net</a>&gt; napsal:<br></div></div>=
</div><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Le Mon, Jun 09, 2025 at 04:40:52AM -0700, James O&=
#39;Beirne a =C3=A9crit :<br>
&gt; Good morning,<br>
&gt; <br>
&gt; A letter has been published advocating for the final review and<br>
&gt; activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTAC=
K<br>
&gt; (BIP-348). <br>
&gt; <br>
&gt; The full text of the letter can be found at <a href=3D"https://ctv-csf=
s.com" rel=3D"noreferrer nofollow" target=3D"_blank" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://ctv-csfs.com&amp;sou=
rce=3Dgmail&amp;ust=3D1749647915532000&amp;usg=3DAOvVaw0R_qCaXsuVP7m006soUg=
aj">https://ctv-csfs.com</a>. It is<br>
&gt; reproduced below.<br>
&gt;<br>
<br>
Hi all,<br>
<br>
<br>
James, thanks for posting the letter. Matt, Antoine -- thanks for<br>
replying quickly and respectfully even though you disagree with its<br>
contents. Let me try to clarify my stance and why I signed onto the<br>
letter.<br>
<br>
First, the specific choice of CTV + CSFS would not be my first choice<br>
on technical grounds. But what I&#39;d like to see is something that is<br>
technically &quot;good enough&quot; to enable vaults and some new script us=
ecases,<br>
while avoiding things that are politically toxic (which seems to be<br>
pretty-much everything, but maybe right now does not include CTV+CSFS?).<br=
>
<br>
So any arguments about CTV+CSFS on the technical merits I think are<br>
great and within the purview of &quot;review and integration&quot; that the=
 letter<br>
talks about. (The word &quot;final&quot; I think is too strong and in retro=
spect<br>
I think we should&#39;ve dropped it. But it&#39;s super difficult when writ=
ing<br>
these things to identify which specific points of language need to be<br>
changed.)<br>
<br>
<br>
Second, regarding the ultimatum language -- it was quite difficult to<br>
strike a balance between &quot;Core consists of volunteers working on their=
<br>
on projects, with no obligation to anybody, and certainly no obligation<br>
to drive forward consensus changes&quot; and &quot;this is a letter that sa=
ys<br>
nothing substantial at all&quot;.<br>
<br>
The message that I want to communicate is: Bitcoin Core, like many<br>
stakeholders, can veto any consensus changes because there will never be<br=
>
a large enough contigent of the Bitcoin community confident to rush in<br>
where angels dare to tread. But furthermore, if nobody in Core wants to<br>
engage at all with consensus changes, then the result is effectively the<br=
>
same as a veto.<br>
<br>
Therefore, if we want to see an increase in script expressivity, somebody<b=
r>
on the Core team needs to help champion it. (There&#39;s no one in particul=
ar<br>
I imagine this &quot;somebody&quot; to be, and I suppose you could accuse m=
e of<br>
hypocrisy since I&#39;m not volunteering myself, even though I have the<br>
social and technical knowledge to help. It could be, and probably would<br>
have to be, somebody who isn&#39;t currently active on Core. But it needs t=
o<br>
be somebody willing and able to work within the Core review process, to<br>
deal with ongoing rebases, etc.)<br>
<br>
<br>
Third, I really really hope that this letter does not lead to further<br>
brigading or twitter fights or whatever bleeding into the Github repo.<br>
(This is the one point where I think that my fellow cosigners agree with<br=
>
me fully.) But on the other hand, I don&#39;t think that I personally shoul=
d<br>
shy away from discussion to mitigate that risk; it needs to be mitigated<br=
>
by more agressive moderation or by higher barriers to entry for people<br>
posting on Core PRs.<br></blockquote><div><br></div><div><br></div></div></=
div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Andrew, would you agre=
e with this premise?=C2=A0</div><div><br></div><div>Bitcoin changes must be=
 demonstrably proven safe, needed, and wanted before adoption.=C2=A0 Propos=
ers bear the burden, not the community.=C2=A0 If the benefit doesn&#39;t de=
monstrably outweigh the risk, the answer is simple: don&#39;t fork the rule=
s.</div><div>=C2=A0</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">=
</blockquote></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
Best<br>
Andrew<br>
<br>
<br>
<br>
<br>
-- <br>
Andrew Poelstra<br>
Director, Blockstream Research<br>
Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferrer nof=
ollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url=
?hl=3Den&amp;q=3Dhttp://wpsoftware.net&amp;source=3Dgmail&amp;ust=3D1749647=
915532000&amp;usg=3DAOvVaw0A81EFCr9YYw-j6PR6eGK1">wpsoftware.net</a><br>
Web:=C2=A0 =C2=A0<a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noref=
errer nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.googl=
e.com/url?hl=3Den&amp;q=3Dhttps://www.wpsoftware.net/andrew&amp;source=3Dgm=
ail&amp;ust=3D1749647915532000&amp;usg=3DAOvVaw1Pft3txT9zEnzUzinuPjRJ">http=
s://www.wpsoftware.net/andrew</a><br>
<br>
The sun is always shining in space<br>
=C2=A0 =C2=A0 -Justin Lewis-Webster<br>
<br></blockquote></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
-- <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 data-email-masked rel=3D"nofollow">bitcoindev+...@googlegro=
ups.com</a>.<br></blockquote></div></div><div dir=3D"ltr"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/aEdoIvOgNNtT6L4s%40mail.wpsoftware.net" rel=3D"noreferrer nofoll=
ow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/aEdoIvOgNNtT6L4s=
%2540mail.wpsoftware.net&amp;source=3Dgmail&amp;ust=3D1749647915532000&amp;=
usg=3DAOvVaw3It4Gd0eRy0a9RczlSlqI6">https://groups.google.com/d/msgid/bitco=
indev/aEdoIvOgNNtT6L4s%40mail.wpsoftware.net</a>.<br>
</blockquote></div></div>
</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/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn%40googlegroups.com</a>.<br />

------=_Part_279427_819387427.1749561599771--

------=_Part_279426_32049839.1749561599771--