summaryrefslogtreecommitdiff
path: root/39/8442af93ff377326886a23a82b57a02e71c83d
blob: 5a5c3ebd7c1840543a2b9f32d02645964c1a8907 (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
Delivery-date: Tue, 17 Jun 2025 04:31:43 -0700
Received: from mail-oo1-f56.google.com ([209.85.161.56])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBE5EYXBAMGQE3UVFUVQ@googlegroups.com>)
	id 1uRUXV-0001GB-8S
	for bitcoindev@gnusha.org; Tue, 17 Jun 2025 04:31:42 -0700
Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-60d60b8ef64sf2597828eaf.3
        for <bitcoindev@gnusha.org>; Tue, 17 Jun 2025 04:31:41 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1750159895; cv=pass;
        d=google.com; s=arc-20240605;
        b=cEiBNj4mutjOJws4GSZKcT0AYgFsP+hQx1ulS6xZPiQfL4nOKpMHFivpDO9TYThdXI
         TpuUj4HSDNmNBJAf8s6QLHLk6pS6QDW7FKfmsiclO8/3hYDwJgEEFQfhUbIC6ZZS1IaS
         Cw356Z/1y+sE95BXc0UvQ7bOpwMLkVwdLctufZJ/F18xMe7wYZVMhdN125QrVjXuPSwz
         +3IxlreH1HquLc5VvboC+48QzP4LrTRZNRWfS2xenYBdxDtk+2eY7Fu0qmhchWm0mZaA
         vdcq9qSIGVhIiCCqXEAEAYORshlZN5uU1NOr2IWkSuI74Tfc7njRyIBc7hQ7CDk3bBB8
         PCXA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:in-reply-to:from:content-language
         :references:to:subject:mime-version:date:message-id:sender
         :dkim-signature;
        bh=aw7kXnJz24+ijRGt20K/Z9ha8N9Xxm2PfcQdjQy20PY=;
        fh=kjt81XeejoaAGI9UhqEtGhbs4VBzymusSSocoH1pWh8=;
        b=iW6NlvN44UO3DTYmmtvLgFCLIrHrBZh/w9enjgpjI/Ix1O1A/yDByOHQeaYqdAMqvI
         +x2AsHEmDNkSAKMnQ0lPXfo3nyPLZPXGemxwVAUE9zWeiIeN+xJSaDRwJd8mHSgZv8LB
         4SEqBIv0XS66Z8xQxORE+ty+MEwqTsUJM1diyHBK4/I0RVKsqOzVDOFirEHLcPltzXh5
         z0J20C8rR74OIHcRySEOqHhtIL5936Ci3VF1cM1DRibvb3YSR7EV8O0jGIS7HBcdzKms
         61uYUmoUL4a9rlm8SJ1kQ5TRZzAzFPFU2UXtLW7iTuIHqsOtw/OlajtPA6yi1yR6x5Vt
         N8vQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@roose.io header.s=default header.b=ZXzFZ0Ri;
       spf=pass (google.com: domain of steven@roose.io designates 2a00:f820:417::202 as permitted sender) smtp.mailfrom=steven@roose.io;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=roose.io
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1750159895; x=1750764695; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:from:content-language:references:to
         :subject:mime-version:date:message-id:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aw7kXnJz24+ijRGt20K/Z9ha8N9Xxm2PfcQdjQy20PY=;
        b=DrkyZ22TU3cI7rWUeZUfJXPplPuODb5v8OUQowc5tKxmm6+qs0GClzXGHCLm1juB1U
         drOxqZRduUGlATPFMW5EM8sAR8Q9AaQTwzzwgdiiPoL2YsOUJ9tHXXo9ncvGv6xdUfDO
         OWJa0DdOrNtXZObxD6Tq+uB8MqMmUes7D5eQ3QMbnxymCPoY9+zr7kfk33mQ0rgkMD9i
         eJ7qqo3sAUwiJ1NQwxWxIJw9LufniLLA3lHskHoJUD2CPRTDZy8I47UEYD+/DSBrLMru
         W0vDm8+sVPLZX5OMeKFGI4c6NcJQ/ZGaTOgZAr/c4druzh22jepW+Hy5wyCI8kHP+AN+
         7oTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750159895; x=1750764695;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:from:content-language:references:to
         :subject:mime-version:date:message-id:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=aw7kXnJz24+ijRGt20K/Z9ha8N9Xxm2PfcQdjQy20PY=;
        b=XDhXKvR5BxKj9X+lpm1rOYdvVhBlS2Eb0HGBhhTKTbI7mwZhm1LOc5YZy5Vb13YLyS
         WbrOmSsF9qlJlsvyhL/ZKb78XtL3zm+M1eMEydP/LDD8eGnS4ZD01WYdizWqHRAPAGpg
         8jeIAYiE835vwVqWNuCZ8Ut9pKYjeYLecrr0KO63dehoV3ewNu7HgYxfPINN8pupZRSh
         qDtf4zBkw52My2WwwYsNEQ0G+2hw8qL0najG2GHb443pVFVZSnpmJ7cwrqMuxiFuQcYZ
         8QtzeGvICAWFLsJKiSKCXZWvy5u+ZTF1uxk63QHS7R6jAX9DpfBd9DFcbR0zVwrHPqyH
         bQhw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCW1u+6uI8UbO8p1C2qb3prWK8jqQ7xq/pY1O8t3HQOWJggq1qeHUX5Vi4OiWSgXOsx02ydI3jLt9MaH@gnusha.org
X-Gm-Message-State: AOJu0Yw6xqh69IBhTpF3OYXc4UqsSItNTLEjTQ4otZ6/WGTxuXd9On6R
	MMuvlrfyqHNsUILPEfq21H2+A2O5Di8Nsjni4Ar4TlgzqQcfNMZTMbqE
X-Google-Smtp-Source: AGHT+IEKDGafGXNaTMVydwvJyEvsZOzTxCyw8hr67LwtL0tBja4oG3biNmcj/UAhJdFiVZZpNZl4NQ==
X-Received: by 2002:a05:6820:1c9c:b0:610:fbf2:bd7d with SMTP id 006d021491bc7-61110ed108emr7673913eaf.6.1750159895022;
        Tue, 17 Jun 2025 04:31:35 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdrziJHNFM2QqOZtMA0wknD1Amljg8VufrypQiWWMuuGQ==
Received: by 2002:a05:6820:4982:b0:603:2c01:784b with SMTP id
 006d021491bc7-610fd380cfbls914090eaf.2.-pod-prod-02-us; Tue, 17 Jun 2025
 04:31:31 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCWN1pHosSew6Gloyt+Gp8InCSOPqJ2vqTUEaVf6GReBPGVB+r9mcf1vu9XDHainZA55EiDbaXFukiqW@googlegroups.com
X-Received: by 2002:a05:6808:19a5:b0:3fa:daa:dd8e with SMTP id 5614622812f47-40a7c2709b0mr9001440b6e.35.1750159891425;
        Tue, 17 Jun 2025 04:31:31 -0700 (PDT)
Received: by 2002:a05:6808:6091:b0:3f9:f009:458e with SMTP id 5614622812f47-40a7193ecc8msb6e;
        Tue, 17 Jun 2025 04:22:18 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVLKW+8r0SGqPPH4yG3fp4QeVsFY9YIQe6/eDXnNthM60ID688UYUmM/WyX0W7uMVt6IV3yiRKoX+re@googlegroups.com
X-Received: by 2002:a05:6808:508d:b0:408:e68d:975a with SMTP id 5614622812f47-40a7c284a39mr8378107b6e.39.1750159337338;
        Tue, 17 Jun 2025 04:22:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1750159337; cv=none;
        d=google.com; s=arc-20240605;
        b=eAV2U0mkIuL9GdgjdgYqmPAOBFFb/mxaPnyMLzTrLiinRzz5tIiqWGzFIjWyrIs1eD
         h7+1L6MfpXJmWIoAyoJi+rrDeP+9cY//H4ekZqPyaqeRebqLV5bsQcxBKEitRguStKaK
         bFCltTGvFHnNRbjbvCht53F+3SjNDsUgVWzGneSZvvdgsX51zX3MpwxfzGWXrLFMPXH3
         ZtzHEgYMs0AdQoccH4b3+8V3+gR4JZQFg99WoWFHwmnBOM8cxrW2H9/L4PCx2Ajp8AL8
         85vZPhTefMOTJkjNdvskQzyfLw20x346ybg9fNg9ar8y0GSxqqNs7ANWdn3AdoJyWW6N
         hbjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=in-reply-to:from:content-language:references:to:subject
         :mime-version:date:message-id:dkim-signature;
        bh=BFHsnFC+vZPCdAFP8fezQcYqy3IMsWHuiwE07NSrpiQ=;
        fh=CyTJ+shPvYF3fdBQQSSAVJMS+eC3Z7H/LTBC0sdqY6M=;
        b=RruPg+/kziXRfBvmMEe1ivwUF7wI0SRF9jFfEeDgT4TF0ZBN0nNKm+ruxacaEMcnx9
         K8Ks8KNA5OWFTvWFjt1rxHy9AluOJsRTKVi2SYd8lq183COHrVdMV0aj66yL6uqRBgKj
         5Kek2q+P6hY1aOIED/GunxJTUj+yLliXZlUZan0ZBdZ2jZ/St3XEUxsdIg0mw1iLkiT7
         e0n8VPLDYF4vH5n4Vtnb1+37RGREEXTHeJ6C7IktGiTTZwwAOr50sL4KlJGU0BZf7k4l
         esF5AJC2PYzarzFM1HgqTZzpQUBU5AnkqoHct3xnS3R/h0kh6zr22A6G8aFtZt+sx2Zp
         iOlQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@roose.io header.s=default header.b=ZXzFZ0Ri;
       spf=pass (google.com: domain of steven@roose.io designates 2a00:f820:417::202 as permitted sender) smtp.mailfrom=steven@roose.io;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=roose.io
Received: from hosted.mailcow.de (hosted.mailcow.de. [2a00:f820:417::202])
        by gmr-mx.google.com with ESMTPS id 5614622812f47-40a740b4f9asi426909b6e.1.2025.06.17.04.22.16
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 17 Jun 2025 04:22:17 -0700 (PDT)
Received-SPF: pass (google.com: domain of steven@roose.io designates 2a00:f820:417::202 as permitted sender) client-ip=2a00:f820:417::202;
Received: from [10.151.38.60] (unknown [146.70.129.152])
	(Authenticated sender: steven@roose.io)
	by hosted.mailcow.de (Postcow) with ESMTPSA id 089825C06D0;
	Tue, 17 Jun 2025 13:22:10 +0200 (CEST)
Content-Type: multipart/alternative;
 boundary="------------WJMLxOyp006ErkFcX1Uwt80c"
Message-ID: <035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io>
Date: Tue, 17 Jun 2025 12:22:10 +0100
MIME-Version: 1.0
Subject: Re: [bitcoindev] CTV + CSFS: a letter
To: James O'Beirne <james.obeirne@gmail.com>,
 Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
Content-Language: en-US
From: Steven Roose <steven@roose.io>
In-Reply-To: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
X-Original-Sender: steven@roose.io
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@roose.io header.s=default header.b=ZXzFZ0Ri;       spf=pass
 (google.com: domain of steven@roose.io designates 2a00:f820:417::202 as
 permitted sender) smtp.mailfrom=steven@roose.io;       dmarc=pass (p=NONE
 sp=NONE dis=NONE) header.from=roose.io
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.7 (/)

This is a multi-part message in MIME format.
--------------WJMLxOyp006ErkFcX1Uwt80c
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hey all


I've been following the discussion and noticed TXHASH is mentioned a=20
lot. As a signer of the letter and author of the TXHASH proposal, I'd=20
like to chime in with some thoughts.

However, I'd like to first express my disappointment with the amount of=20
drama this letter has caused. It quite literally merely asks Core=20
contributors to put this proposal on their agenda with some urgency. No=20
threats, no hard words.
Given that only a handful of Core contributors had thus far participated=20
in the conversation on the proposal elsewhere, it seemed like a suitable=20
next step to communicate that we want Core contributors to provide their=20
position within this conversation.
I strongly stand against an approach involving independent activation=20
clients and I think the sentiment of this e-mail aligns with the=20
preference of having Core be involved in any deployment of protocol=20
upgrades.

On the proposal itself. I have heard some mentions of TXHASH and why we,=20
as the developer community, wouldn't go=C2=A0 straight for TXHASH.

  * I think TXHASH is too far from being ready at this point:
      o The TXHASH BIP and spec has not had the level of
        review/engagement that I had hoped for. I'm personally pretty
        happy with the result, especially since it only has had serious
        looks from myself and Rearden. But it definitely needs a lot
        more scrutiny. It's a very opinionated design (I think it's
        unavoidable for such an opcode), so there is a lot of room for
        making different and maybe better decisions on many fronts.
      o Once we have the TXHASH semantics, it would be very valuable to
        consider also introducing the same semantics as a top-level
        sighash flag system, so you can spend coins directly with a
        sighash based on TXHASH semantics. (I dubbed this TXSIGHASH and
        I recently did some simulations on how such a construction would
        look for fee sponsoring and stacking
        https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options=
-for-sponsorring-and-stacking/1760)
      o However, this also invites some additional review of possible
        taproot changes (pay-to-tapscript, re-adding parity byte, ..)
        and will necessarily take some more time for consideration and
        design.
  * I strongly believe it would benefit development of new bitcoin use
    cases if we would have a simple version of templating and rebindable
    signatures sooner rather than later. Both BitVM and Ark are fairly
    recent ideas that stand to benefit significantly from such new
    functionality, but I think having them actually available will
    invite a lot more engagement leading to new ideas and new
    improvements. These are not use case-specific changes, but useful
    general building blocks.
  * Both CSFS and CTV are fairly unopinionated opcodes by design, when
    you think of CTV in the sense that it fixes the minimum tx fields to
    ensure txid stability.
  * I think there is both enough excitement for this proposal and there
    would be enough future excitement for a TXHASH or CCV addition that
    I don't fear upgrade churn will be a future hurdle.
  * Even after possible TXHASH activation, I think there will stay some
    demand for the simpler CTV/TEMPLATEHASH variant. It doesn't just
    save a byte on the wire, but thinking in a txid-stable model is just
    more intuitive. I believe that many advanced use cases will take
    advantage from doing things the TXHASH way (enabling stacking and
    cheaper fee sponsoring), but some developers will always favor the
    simplicity of txid stability over the benefits of adding complexity.

The above arguments convinced me that an activation based on CTV and=20
CSFS makes sense today. We have lots of developers waiting to make use=20
of the functionality it enables and we can continue development of=20
further changes meanwhile.

That being said, I'm in no way married to the exact details of the=20
proposals.

  * I am sympathetic to worries of changing legacy/v0 script. I failed
    to convince myself of any valuable usage for bare CTV.
  * I am sympathetic to the consideration of revisiting scriptSig and
    annex-related modifications to the template hash.
  * I am sympathetic to the decision to optimize better for the
    rebindable signature use cases, meaning:
      o the idea to swap CTV for a TEMPLATEHASH opcode which adds a
        1-byte VERIFY for the template use case but saves 33 bytes for
        the signature use case
      o the addition of an INTERNALKEY opcode, saving an additional 33
        bytes for the rebindable signature use case

All of the above changes I think can be decided on with minimal=20
bikeshedding and still encompass the same semantics of the original=20
proposal.


Best

Steven


On 6/9/25 12:40, James O'Beirne wrote:
> Good morning,
>
> A letter has been published advocating for the final review and
> activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK
> (BIP-348).
>
> The full text of the letter can be found at https://ctv-csfs.com. It is
> reproduced below.
>
> ---
>
> To the technical bitcoin community,
>
> 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.
>
> 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 both
> safe and widely demanded.
>
> 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.
>
> CSFS is a primitive opcode that has been deployed to Blockstream=E2=80=99=
s
> Elements for at least 8 years. It represents no significant
> computational burden over bitcoin=E2=80=99s most often used opcode, OP_CH=
ECKSIG.
> It can be combined with CTV to implement ln-symmetry, a longstanding
> improvement to Lightning. It also unlocks a variety of other use cases.
>
> 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 for
> rigorous final review and activation planning.
>
> This request isn't meant to suggest that these contributors dictate the
> consensus process, but rather it is an acknowledgement that before these
> opcodes can be activated, they must be implemented in the most widely
> used bitcoin client.
>
> 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 security=
 and
> layer 2 scaling solutions. We are optimistic that given the limited size
> 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.
>
> Signed,
>
> 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
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51be=
eb765163n%40googlegroups.com=20
> <https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51b=
eeb765163n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>.

--=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/=
035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io.

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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
    <p>Hey all</p>
    <p><br>
    </p>
    <p>I've been following the discussion and noticed TXHASH is
      mentioned a lot. As a signer of the letter and author of the
      TXHASH proposal, I'd like to chime in with some thoughts.</p>
    <p>However, I'd like to first express my disappointment with the
      amount of drama this letter has caused. It quite literally merely
      asks Core contributors to put this proposal on their agenda with
      some urgency. No threats, no hard words.<br>
      Given that only a handful of Core contributors had thus far
      participated in the conversation on the proposal elsewhere, it
      seemed like a suitable next step to communicate that we want Core
      contributors to provide their position within this conversation.<br>
      I strongly stand against an approach involving independent
      activation clients and I think the sentiment of this e-mail aligns
      with the preference of having Core be involved in any deployment
      of protocol upgrades.<br>
    </p>
    <p>On the proposal itself. I have heard some mentions of TXHASH and
      why we, as the developer community, wouldn't go=C2=A0 straight for
      TXHASH.</p>
    <ul>
      <li>I think TXHASH is too far from being ready at this point:<br>
      </li>
      <ul>
        <li>The TXHASH BIP and spec has not had the level of
          review/engagement that I had hoped for. I'm personally pretty
          happy with the result, especially since it only has had
          serious looks from myself and Rearden. But it definitely needs
          a lot more scrutiny. It's a very opinionated design (I think
          it's unavoidable for such an opcode), so there is a lot of
          room for making different and maybe better decisions on many
          fronts.</li>
        <li>Once we have the TXHASH semantics, it would be very valuable
          to consider also introducing the same semantics as a top-level
          sighash flag system, so you can spend coins directly with a
          sighash based on TXHASH semantics. (I dubbed this TXSIGHASH
          and I recently did some simulations on how such a construction
          would look for fee sponsoring and stacking
<a class=3D"moz-txt-link-freetext" href=3D"https://delvingbitcoin.org/t/jit=
-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760">http=
s://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsor=
ring-and-stacking/1760</a>)</li>
        <li>However, this also invites some additional review of
          possible taproot changes (pay-to-tapscript, re-adding parity
          byte, ..) and will necessarily take some more time for
          consideration and design.<br>
        </li>
      </ul>
      <li>I strongly believe it would benefit development of new bitcoin
        use cases if we would have a simple version of templating and
        rebindable signatures sooner rather than later. Both BitVM and
        Ark are fairly recent ideas that stand to benefit significantly
        from such new functionality, but I think having them actually
        available will invite a lot more engagement leading to new ideas
        and new improvements. These are not use case-specific changes,
        but useful general building blocks.<br>
      </li>
      <li>Both CSFS and CTV are fairly unopinionated opcodes by design,
        when you think of CTV in the sense that it fixes the minimum tx
        fields to ensure txid stability.<br>
      </li>
      <li>I think there is both enough excitement for this proposal and
        there would be enough future excitement for a TXHASH or CCV
        addition that I don't fear upgrade churn will be a future
        hurdle.</li>
      <li>Even after possible TXHASH activation, I think there will stay
        some demand for the simpler CTV/TEMPLATEHASH variant. It doesn't
        just save a byte on the wire, but thinking in a txid-stable
        model is just more intuitive. I believe that many advanced use
        cases will take advantage from doing things the TXHASH way
        (enabling stacking and cheaper fee sponsoring), but some
        developers will always favor the simplicity of txid stability
        over the benefits of adding complexity.<br>
      </li>
    </ul>
    <p>The above arguments convinced me that an activation based on CTV
      and CSFS makes sense today. We have lots of developers waiting to
      make use of the functionality it enables and we can continue
      development of further changes meanwhile. </p>
    <p>That being said, I'm in no way married to the exact details of
      the proposals.<br>
    </p>
    <ul>
      <li>I am sympathetic to worries of changing legacy/v0 script. I
        failed to convince myself of any valuable usage for bare CTV.</li>
      <li>I am sympathetic to the consideration of revisiting scriptSig
        and annex-related modifications to the template hash.<br>
      </li>
      <li>I am sympathetic to the decision to optimize better for the
        rebindable signature use cases, meaning:<br>
      </li>
      <ul>
        <li>the idea to swap CTV for a TEMPLATEHASH opcode which adds a
          1-byte VERIFY for the template use case but saves 33 bytes for
          the signature use case</li>
        <li>the addition of an INTERNALKEY opcode, saving an additional
          33 bytes for the rebindable signature use case</li>
      </ul>
    </ul>
    All of the above changes I think can be decided on with minimal
    bikeshedding and still encompass the same semantics of the original
    proposal.<br>
    <p><br>
    </p>
    <p>Best</p>
    <p>Steven<br>
    </p>
    <p><br>
    </p>
    <div class=3D"moz-cite-prefix">On 6/9/25 12:40, James O'Beirne wrote:<b=
r>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
      Good morning,<br>
      <br>
      A letter has been published advocating for the final review and<br>
      activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and
      OP_CHECKSIGFROMSTACK<br>
      (BIP-348). <br>
      <br>
      The full text of the letter can be found at <a class=3D"moz-txt-link-=
freetext" href=3D"https://ctv-csfs.com">https://ctv-csfs.com</a>.
      It is<br>
      reproduced below.<br>
      <br>
      ---<br>
      <br>
      To the technical bitcoin community,<br>
      <br>
      We believe that the best next step for bitcoin would be to
      activate<br>
      OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK
      (CSFS,<br>
      BIP-348). These opcodes enable functionality for a broad set of
      uses<br>
      that will allow bitcoin to preserve and expand its role as a
      scarce,<br>
      censorship-resistant store of value.<br>
      <br>
      While there are a few promising proposals to improve bitcoin at
      the<br>
      consensus layer which may someday be deployed, we believe that CTV
      and<br>
      CSFS are uniquely well reviewed, simple, and have been proven to
      be both<br>
      safe and widely demanded.<br>
      <br>
      CTV was first formalized in BIP-119 over 5 years ago. Despite many<br=
>
      attempts at refinement or replacement, it has remained the most
      widely<br>
      preferred method for enforcing pregenerated transaction sequences
      using<br>
      consensus. It unlocks valuable functionality for scaling
      solutions,<br>
      vaults, congestion control, non-custodial mining, discreet log<br>
      contracts, and more.<br>
      <br>
      CSFS is a primitive opcode that has been deployed to Blockstream=E2=
=80=99s<br>
      Elements for at least 8 years. It represents no significant<br>
      computational burden over bitcoin=E2=80=99s most often used opcode,
      OP_CHECKSIG.<br>
      It can be combined with CTV to implement ln-symmetry, a
      longstanding<br>
      improvement to Lightning. It also unlocks a variety of other use
      cases.<br>
      <br>
      We respectfully ask Bitcoin Core contributors to prioritize the
      review<br>
      and integration of CTV (PR #31989 or similar) and CSFS (PR #32247
      or<br>
      similar) within the next six months. We believe this timeline
      allows for<br>
      rigorous final review and activation planning.<br>
      <br>
      This request isn't meant to suggest that these contributors
      dictate the<br>
      consensus process, but rather it is an acknowledgement that before
      these<br>
      opcodes can be activated, they must be implemented in the most
      widely<br>
      used bitcoin client.<br>
      <br>
      As application and protocol developers, we are convinced of the<br>
      significant benefits that these changes would bring to end users
      of<br>
      bitcoin =E2=80=93 even if only considering their use for layer 1 secu=
rity
      and<br>
      layer 2 scaling solutions. We are optimistic that given the
      limited size<br>
      and scope of these changes in both concept and implementation,
      they<br>
      represent a realistic next step in the continuing and important
      work of<br>
      preserving bitcoin's unique promise.<br>
      <br>
      Signed, <br>
      <br>
      Abdel (Starkware)<br>
      Andrew Poelstra (@apoelstra)<br>
      Ben Carman (@benthecarman)<br>
      Ben Kaufman (@ben-kaufman)<br>
      Brandon Black (@reardencode)<br>
      Brian Langel (for Five Bells)<br>
      Buck Perley (@puckberley)<br>
      Calle (Cashu)<br>
      Calvin Kim (@kcalvinalvin)<br>
      Chun Wang (f2pool)<br>
      Christian Decker (@cdecker)<br>
      Coinjoined Chris (Bitsurance.eu)<br>
      Evan Kaloudis (for Zeus)<br>
      fiatjaf (@fiatjaf)<br>
      Floppy (@1440000bytes)<br>
      Gary Krause (@average-gary)<br>
      Harsha Goli (@arshbot)<br>
      Hunter Beast (@cryptoquick)<br>
      Jad Mubaslat (@champbronc2)<br>
      James O=E2=80=99Beirne (@jamesob)<br>
      Jameson Lopp (@jlopp)<br>
      Johan Halseth (@halseth)<br>
      Luke Childs (@lukechilds)<br>
      Matt Black (for Atomic Finance)<br>
      Michael Tidwell (@miketwenty1)<br>
      Nick Hansen (for Luxor Mining)<br>
      Nitesh (@nitesh_btc)<br>
      nvk (@nvk)<br>
      Owen Kemeys (for Foundation)<br>
      Paul Sztorc (@psztorc)<br>
      Portland.HODL (for MARA Pool)<br>
      Rijndael (@rot13maxi)<br>
      Rob Hamilton (@rob1ham)<br>
      Robin Linus (@RobinLinus)<br>
      Sanket Kanjalkar (@sanket1729)<br>
      Sean Ryan (Anchorage)<br>
      Seth for Privacy (for Cake Wallet)<br>
      Simanta Gautam (Alpen Labs)<br>
      Steven Roose (@stevenroose)<br>
      stutxo (@stutxo)<br>
      Talip (@otaliptus)<br>
      mononaut (@mononautical)<br>
      vnprc (@vnprc)<br>
      <br>
      -- <br>
      You received this message because you are subscribed to the Google
      Groups "Bitcoin Development Mailing List" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a
        href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com"
        moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">bitcoindev=
+unsubscribe@googlegroups.com</a>.<br>
      To view this discussion visit <a
href=3D"https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1=
d-51beeb765163n%40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfoot=
er"
        moz-do-not-send=3D"true">https://groups.google.com/d/msgid/bitcoind=
ev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com</a>.<br>
    </blockquote>
  </body>
</html>

<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/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io?utm_medium=3Dema=
il&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/035f8b=
9c-9711-4edb-9d01-bef4a96320e1%40roose.io</a>.<br />

--------------WJMLxOyp006ErkFcX1Uwt80c--