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
712
|
Delivery-date: Sun, 09 Mar 2025 23:02:13 -0700
Received: from mail-oo1-f61.google.com ([209.85.161.61])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDN456FOY4IRBWUAXK7AMGQE4QNIMNI@googlegroups.com>)
id 1trWDL-00025W-Hn
for bitcoindev@gnusha.org; Sun, 09 Mar 2025 23:02:13 -0700
Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-5fd07df2f45sf1331474eaf.3
for <bitcoindev@gnusha.org>; Sun, 09 Mar 2025 23:02:11 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1741586525; cv=pass;
d=google.com; s=arc-20240605;
b=ZS8xiYFncdzYwktgkShJaQ/ts/w6a8rakt/r3PNLFUTLHnKnIGEGFDrbq+P4icRPf6
SF+W1fYQ/jrB4b14/2kd8Tx8T8twT6xnVAZFAIwWBTowIm6QT8QWpCWkXd+DfyT6wmWx
PxzuVydcb3dM/a+vtqETf6DZa5qnbe+X5WAzzF845dw+7v/ryVq3cCAM0KyIYbAprjMP
iPGY8TyNgRb1bwPpsvTPoO3hSx22b4Aq/sI9kvWZYq/iVpy3Zv3jzVVsq+FgFEn1e7ny
RxOihDkEBuTLGnK2erwl5DXN1qeoBCE9x1LAFKzTC8faXAov63DiXvKyHK4iVRkfEYhb
KAuA==
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:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:sender:dkim-signature;
bh=Tfpiihux4Zgw/Oy+tvh4fXXd1XVyxF2I1CZr5tH9jIY=;
fh=AjpSbJmK9tU+q9fiO3FShybAEsw9Tgf44RGSXqg3g4w=;
b=ceGLOJocMLOa36AUee47LY8lRAxrzE7lw5qM+S6O3PfM6ljvbZOV5mAOzbhDj3E0cn
yeVUSSHiqUJ83KCGetQR6pvEPigsbPb+mPHw91W+4tI6hetT6/ErH01Zl5xwdp/+PbZN
eajBK5BmmOzcKf3Hl/adZWqm3lRCkfHf29Xh0/MvEtSWWglkZZfET6UHc+M44pIRcCg8
/G4MluiIMtZ3HdS29h8LsxdbxwIVbcZ/Jxa/eBytebyrrTcRS/QulNjxslJEhHpOvBER
Ttm/Cntd4j+1DZogqzBpWDd3Pe3EF7gtOymRbcQ8TEjBvvy0LpNjlsDya41YaabLlsnO
XwIw==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@shesek.info header.s=google header.b=ZMdZXTQG;
spf=pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::b29 as permitted sender) smtp.mailfrom=nadav@shesek.info;
dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1741586525; x=1742191325; 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:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=Tfpiihux4Zgw/Oy+tvh4fXXd1XVyxF2I1CZr5tH9jIY=;
b=SFPKrXE9DG2OyIa6WsT5I1XJL5q10XbwJcQYsbFu7Gw2u8/o3bj3W8ebVmGzsY5514
apJM/CGvyrPCZQ2BUmtJfIxJYcInU23NECIrnO58CjeeJE3Lua8pEzfNlpnrgqB+1TKg
ugOykKH80hpds91KAncFg78UFCS6iLmqVJasOHQCi4Rk2qcwJQgMhXpd14NVS4IqOhyN
5h44Pt6398A0bNe71Wda3yUFo4KZqxLameo+FQ86YVuge1MJUyb6OaLCa3ISCLBpJADp
8Xt0064tL8/p+mFcUqSYpNxUgaHs/pl18wDP+bsGYxG1Lp6Fml4xAskhBhmBxOT0kBFw
NMBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1741586525; x=1742191325;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:x-beenthere:x-gm-message-state:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=Tfpiihux4Zgw/Oy+tvh4fXXd1XVyxF2I1CZr5tH9jIY=;
b=f71ZabZTptl7+1+cPeRZAWfZTnk4euk+uYWPcT7p2MbeaZ2lgMKx2NPKBiRlqOmy6n
nrQvU7vylgW2Cxw79tZ6wncG5tv6ftiB/RSzFIhW+x0CsVLH+aeX/hMasONOlWDtqoRo
GS8I7FV1uBzbtROO28Vh1pBA7VQn+KuqqYVxWvU2RrstS5DGulBj94DhtsaflC2aujeh
PXzLA73/NQZsiGOgD9ka29t539ppjjUdTqY+Lr3BKaY9h0eRYEI0csBc8Rsm9V1Jpsqy
Hkk4O4HCAxjnGfRAOEK74SQYpLwom7vjNeyyTFbbU3b31oK8EZsgAGM7Eoy/+UZ0qF4K
3bBA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVBzU9MN0sRma3Hpn7i+rBJYYlte8ZUQSJN6TSv4bZuX5XfcnGX35SwDAFv0u1EctJXNnIyzTAaY4Ga@gnusha.org
X-Gm-Message-State: AOJu0YzcyXnhCXT3a7TOgu8Fhy9q3bu5+yIRhCs85J+ary2Zm5g5qjJQ
Ho+3OBq4hYhuLICArqPoTWOV92yVlaakXbJ0wvMp0Rx1+rzYIHCr
X-Google-Smtp-Source: AGHT+IFugVY9gIhcl4GYDlrSiD+X/7a5p0ci7SBIksENPvb9xrKs2GvKM2uPTDcH6gPN9oc9F2xHew==
X-Received: by 2002:a05:6820:1805:b0:601:a4df:27e5 with SMTP id 006d021491bc7-601a4df28c1mr2922393eaf.8.1741586525242;
Sun, 09 Mar 2025 23:02:05 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVH5IthUCTRlcEJTUdrH2ltOcu8d6tCkHkCBfkZRF0A/xw==
Received: by 2002:a4a:a80c:0:b0:601:b199:d967 with SMTP id 006d021491bc7-601b199db38ls98694eaf.2.-pod-prod-04-us;
Sun, 09 Mar 2025 23:02:02 -0700 (PDT)
X-Received: by 2002:a05:6808:bcc:b0:3f7:724:4b9d with SMTP id 5614622812f47-3f707244fb2mr2778874b6e.13.1741586522272;
Sun, 09 Mar 2025 23:02:02 -0700 (PDT)
Received: by 2002:a05:6808:287:b0:3f7:3c67:63cc with SMTP id 5614622812f47-3f73c6764damsb6e;
Sun, 9 Mar 2025 22:14:44 -0700 (PDT)
X-Received: by 2002:a17:902:e80a:b0:224:6ee:ad with SMTP id d9443c01a7336-22428c01371mr216446225ad.44.1741583682187;
Sun, 09 Mar 2025 22:14:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1741583682; cv=none;
d=google.com; s=arc-20240605;
b=YH8IAn5UkL00bNdVvyTaQ2EdOAEkFxRmj7hYyS1+0Bp9VHw8hMSYUGO6gkrBQ6zNum
L4xfsnyCT4aAxtkf9ghACjRsg/fSHMOrfj9A/hxhCVqB/F04BPppgLZ4cHzCfXd/6Fi9
fVk92T6hNYiffVhRrZeK4e+p+Spe/cmnzASAZC/aCFZ/TiogkL/W2BLAPHjU5auBduK4
osfeAZau0/eNbb1EmmACCogHdT7TC4InhEQlSR1hkOZGo9Upo/HS9Qq/WgLV4/w1Lc5l
o+mpHT25yu/MMfZO8htuD38mJe90i+1AEJ2jNqlhnxpgQLgGp0u9viuwjM3zA5yA9LD3
aoug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:dkim-signature;
bh=xUOtF3AEMuSThr+wSSovGBcOPwD+KayHoq8NL7S4bio=;
fh=ZhIePvtzD2qBgm9PadABf9spV2moFvlPRwwE8o08T1o=;
b=jL/ChVgmXcTf9ucGThL8DFAa0/nMjKUCmXiBIQb+sz8eFjBHOdoQ31laKwbtmS9gk+
AyttTU3B7IA6MhT13Yhge2S03Yw08lXwHr7ofgxNfLETZoc429hlu13jPAHqN6/yF1pp
0m6qs3aDExiOI0DQKOr1sEqY3Gp2c5AUccZKU3W6w4LEx1VoNWjtwD6FzcTAxaESGADC
WjBZ9aAj3Pi1JxWNMM8krFu/FINJvUrr7SdYa1KM+2FnM9y4/R8oi83quATrYOGBDYRH
hJ0roWLd7Ivjtoacogd51upMa4j/UybdsI9BVt/SxoawDlm8q82Y/+a5fn15AYp2MDjU
HhZQ==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@shesek.info header.s=google header.b=ZMdZXTQG;
spf=pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::b29 as permitted sender) smtp.mailfrom=nadav@shesek.info;
dara=pass header.i=@googlegroups.com
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com. [2607:f8b0:4864:20::b29])
by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-2ff36be83ffsi734427a91.1.2025.03.09.22.14.42
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 09 Mar 2025 22:14:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::b29 as permitted sender) client-ip=2607:f8b0:4864:20::b29;
Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e53ef7462b6so3188410276.3
for <bitcoindev@googlegroups.com>; Sun, 09 Mar 2025 22:14:41 -0700 (PDT)
X-Gm-Gg: ASbGncvJvF2wZG1oZYJC33V7LkbXq+YpltIMFiJDp42f9Hqv6XsD4aUyTB99hWMnLjQ
vGylcJE4ffx/tVXgWQ16lVAXGYofSIn0G990x8x5LpiW0nj5kze8vvpFy9vg/zEV9IH9UQUSm6u
7UgBjtcL++wFSLYrFt+OeLTm0B8IqYQVvGMFCW9lTTrMwAZUTOWtTNqKp0Y9g4vvkUIWvjZTk=
X-Received: by 2002:a05:6902:2007:b0:e60:a2e0:2fbf with SMTP id
3f1490d57ef6-e635c0f804emr16415920276.2.1741583681387; Sun, 09 Mar 2025
22:14:41 -0700 (PDT)
MIME-Version: 1.0
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
In-Reply-To: <Z8eUQCfCWjdivIzn@erisian.com.au>
From: Nadav Ivgi <nadav@shesek.info>
Date: Mon, 10 Mar 2025 07:14:30 +0200
X-Gm-Features: AQ5f1JrAJNfjGMQ188itF2oZzBYMBqkD-S1ayKoEFuIgg54VrwXAK6wggqExs84
Message-ID: <CAGXD5f3EGyUVBc=bDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q@mail.gmail.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
To: Anthony Towns <aj@erisian.com.au>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000ad1712062ff60ccc"
X-Original-Sender: nadav@shesek.info
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@shesek.info header.s=google header.b=ZMdZXTQG; spf=pass
(google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::b29 as
permitted sender) smtp.mailfrom=nadav@shesek.info; dara=pass header.i=@googlegroups.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.7 (/)
--000000000000ad1712062ff60ccc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
For some historical context, it's interesting to note that CTV originally
had the constexpr requirement which prevented your CSFS+CTV construct by
requiring the CTV hash to come from a literal push preceding the opcode
(i.e. not dynamically computed/pre-verified and not from the witness). This
was eventually removed because it was deemed an unnecessary safeguard and
to simplify the implementation.
Also, it seems that APO alone also enables the same kind of construct as
what you're describing. For example, a 'recursive' APO signature spending
back to the same address could similarly be used as the basis for a BMM
Spacechain.
> I'd encourage people to try implementing that themselves with their
preferred tooling; personally, I found it pretty inconvenient
Here's my go at it using Minsc:
https://min.sc/v0.3/#gist=3D3aa538b384d3aaf4282d1acaf943f608
Example transaction:
https://mutinynet.com/tx/9c941dc9c0068eb817b2d18416b174468203c6ad090d8d5735=
cc9b3732959e39
Note however that what you described is creating 0-fee transactions, with
no way to attach additional fees. So this would also need either an anchor
output or a CTV template that allows the inclusion of an additional input,
which I did not implement in the gist.
> For me, the two components that are annoying is doing complicated taproot
script path spends, and calculating CTV hashes
I've been working on improving Minsc to make these kinds of things easier.
It supports Taproot, CTV, PSBT, Descriptors, Miniscript, raw Script, BIP32,
and more. Much of it is still undocumented (the min.sc website is very much
outdated), but I have some examples demonstrating different uses that might
be of interest:
- A simple one that involves calculating CTV hashes and a multi-script
Taproot tree: https://min.sc/v0.3/#github=3Dexamples/ctv-simple.minsc
- More advanced example implementing a CTV vault:
https://min.sc/v0.3/#github=3Dexamples/ctv-vault.minsc
- Another vault, with key delegation using CTV+CSFS+PAIRCOMMIT+INTERNALKEY:
https://min.sc/v0.3/#gist=3D82d92568c2fcba62203157f8df11354e
- Decaying multisig using PSBT/Miniscript:
https://min.sc/v0.3/#github=3Dexamples/3of3-into-2of3.minsc
More examples are available on the README: https://github.com/shesek/minsc
Cheers,
shesek
On Wed, Mar 5, 2025 at 3:06=E2=80=AFAM Anthony Towns <aj@erisian.com.au> wr=
ote:
> Hello world,
>
> Some people on twitter are apparently proposing the near-term activation =
of
> CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
>
> https://x.com/JeremyRubin/status/1895676912401252588
> https://x.com/lopp/status/1895837290209161358
> https://x.com/stevenroose3/status/1895881757288996914
> https://x.com/reardencode/status/1871343039123452340
> https://x.com/sethforprivacy/status/1895814836535378055
>
> Since BIP 119's motivation is entirely concerned with its concept of
> covenants and avoiding what it calls recursive covenants, I think it
> is interesting to note that the combination of CSFS and CTV trivially
> enables the construction of a "recursive covenant" as BIP 119 uses those
> terms. One approach is as follows:
>
> * Make a throwaway BIP340 private key X with 32-bit public key P.
> * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
> its corresponding scriptPubKey K when combined with P as the internal
> public
> key.
> * Calculate the CTV hash corresponding to a payment of some specific
> value V
> to K; call this hash H
> * Calculate the BIP 340 signature for message H with private key X, call
> it S.
> * Discard the private key X
> * Funds sent to K can only be spent by the witness data "<H> <S>" that
> forwards
> an amount V straight back to K.
>
> Here's a demonstration on mutinynet:
>
>
> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmy=
jejrmqqx525gsk5nr58
>
> I'd encourage people to try implementing that themselves with their
> preferred tooling; personally, I found it pretty inconvenient, which I
> don't think is a good indication of ecosystem readiness wrt deployment.
> (For me, the two components that are annoying is doing complicated
> taproot script path spends, and calculating CTV hashes)
>
> I don't believe the existence of a construction like this poses any
> problems in practice, however if there is going to be a push to activate
> BIP 119 in parallel with features that directly undermine its claimed
> motivation, then it would presumably be sensible to at least update
> the BIP text to describe a motivation that would actually be achieved by
> deployment.
>
> Personally, I think BIP 119's motivation remains very misguided:
>
> - the things it describes are, in general, not "covenants" [0]
> - the thing it avoids is not "recursion" but unbounded recursion
> - avoiding unbounded recursion is not very interesting when arbitrarily
> large recursion is still possible [1]
> - despite claiming that "covenants have historically been widely
> considering to be unfit for Bitcoin", no evidence for this claim has
> been able to be provided [2,3]
> - the opposition to unbounded recursion seems to me to either mostly
> or entirely be misplaced fear of things that are already possible in
> bitcoin and easily avoided by people who want to avoid it, eg [4]
>
> so, at least personally, I think almost any update to BIP 119's motivatio=
n
> section would be an improvement...
>
> [0]
> https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/
> [1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/
> [2]
> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2=
-4a82b580ba99-000000@email.amazonses.com/
> [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> [4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au=
/
>
> Beyond being a toy example of a conflict with BIP 119's motivation
> section, I think the above script could be useful in the context of the
> "blind-merged-mining" component of spacechains [5]. For example, if
> the commitment was to two outputs, one the recursive step and the other
> being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
> would allow for both providing fees conveniently and for encoding the
> spacechain block's commitment; competing spacechain miners would then
> just be rbf'ing that spend with the parent spacechain update remaining
> unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
> need to be used to ensure the "one spacechain update per bitcoin block"
> rule. (I believe mutinynet doesn't support ephemeral anchors however, so
> I don't think there's anywhere this can be tested)
>
> [5]
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file=
-bmm-svg
>
> (For a spacechain, miners would want to be confident that the private key
> has been discarded. This confidence could be enhanced by creating X as a
> musig2 key by a federation, in which case provided any of the private key=
s
> used in generating X were correctly discarded, then everything is fine,
> but that's still a trust assumption. Simple introspection opcodes would
> work far better for this use case, both removing the trust assumption
> and reducing the onchain data required)
>
> If you're providing CTV and CSFS anyway, I don't see why you wouldn't
> provide the same or similar functionality via a SIGHASH flag so that you
> can avoid specifying the hash directly when you're signing it anyway,
> giving an ANYPREVOUT/NOINPUT-like feature directly.
>
> (Likewise, I don't see why you'd want to activate CAT on mainnet without
> also at least re-enabling SUBSTR, and potentially also the redundant
> LEFT and RIGHT operations)
>
> For comparison, bllsh [6,7] takes the approach of providing
> "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
> for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
> equivalent would then either involve simplying writing:
>
> (=3D (bip342_txmsg 3) 0x.....)
>
> meaining "calculate the message hash of the current tx for SIGHASH_SINGLE=
,
> then evaluate whether the result is exactly equal to this constant"
> providing one of the standard sighashes worked for your use case, or
> replacing the bip342_txmsg opcode with a custom calculation of the tx
> hash, along the lines of the example reimplementation of bip342_txmsg
> for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
> someone wants to write up the BIP 119 hashing formula in bllsh, I'd
> be happy to include that as an example; I think it should be a pretty
> straightforward conversion from the test-tx example.
>
> If bllsh were live today (eg on either signet or mainnet), and it were
> desired to softfork in a more optimised implementation of either CTV or
> ANYPREVOUT to replace people coding their own implementation in bllsh
> directly, both would simply involve replacing calls to "bip342_txmsg"
> with calls to a new hash calculation opcode. For CTV behaviour, usage
> would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
> usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
> is, the underlying "I want to hash a message in such-and-such a way"
> looks the same, and how it's used is the wallet author's decision,
> not a matter of how the consensus code is written.
>
> I believe simplicity/simfony can be thought of in much the same way;
> with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
> [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
> behaviour [10].
>
> [6] https://github.com/ajtowns/bllsh/
> [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
> [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
> [9]
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.=
simf
> [10]
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.s=
imf
>
> For me, the bllsh/simplicity approach makes more sense as a design
> approach for the long term, and the ongoing lack of examples of killer
> apps demonstrating big wins from limited slices of new functionality
> leaves me completely unexcited about rushing something in the short term.
> Having a flood of use cases that don't work out when looked into isn't
> a good replacement for a single compelling use case that does.
>
> Cheers,
> aj
>
> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.c=
om.au
> .
>
--=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/=
CAGXD5f3EGyUVBc%3DbDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q%40mail.gmail.com.
--000000000000ad1712062ff60ccc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>For some historical context, it's interesting to =
note that CTV=20
originally had the constexpr requirement which prevented your CSFS+CTV=20
construct by requiring the CTV hash to come from a literal push=20
preceding the opcode (i.e. not dynamically computed/pre-verified and not
from the witness). This was eventually removed because it was deemed an
unnecessary safeguard and to simplify the implementation.</div><div><br></=
div><div>Also,
it seems that APO alone also enables the same kind of construct as what
you're describing. For example, a 'recursive' APO signature sp=
ending=20
back to the same address could similarly be used as the basis for a BMM=20
Spacechain.</div><span class=3D"gmail-im"><div><br></div><div>>=C2=A0 I&=
#39;d=20
encourage people to try implementing that themselves with their=20
preferred tooling; personally, I found it pretty inconvenient</div><div><br=
></div></span><div>Here's my go at it using Minsc: <a href=3D"https://m=
in.sc/v0.3/#gist=3D3aa538b384d3aaf4282d1acaf943f608" target=3D"_blank">http=
s://min.sc/v0.3/#gist=3D3aa538b384d3aaf4282d1acaf943f608</a></div><div><br>=
</div><div>Example transaction: <a href=3D"https://mutinynet.com/tx/9c941dc=
9c0068eb817b2d18416b174468203c6ad090d8d5735cc9b3732959e39" target=3D"_blank=
">https://mutinynet.com/tx/9c941dc9c0068eb817b2d18416b174468203c6ad090d8d57=
35cc9b3732959e39</a></div><div><br></div><div>Note
however that what you described is creating 0-fee transactions, with no
way to attach additional fees. So this would also need either an anchor
output or a CTV template that allows the inclusion of an additional=20
input, which I did not implement in the gist.</div><span class=3D"gmail-im"=
><div><br></div><div>> For me, the two components that are annoying is d=
oing complicated taproot script path spends, and calculating CTV hashes</di=
v><div><br></div></span><div>I've
been working on improving Minsc to make these kinds of things easier.=20
It supports Taproot, CTV, PSBT, Descriptors, Miniscript, raw Script,=20
BIP32, and more. Much of it is still undocumented (the <a href=3D"http://mi=
n.sc" target=3D"_blank">min.sc</a> website is very much outdated),=20
but I have some examples demonstrating different uses that might be of inte=
rest:</div><div><br></div><div><div>- A simple one that involves calculatin=
g CTV hashes and a=20
multi-script Taproot tree:=20
<a href=3D"https://min.sc/v0.3/#github=3Dexamples/ctv-simple.minsc" target=
=3D"_blank">https://min.sc/v0.3/#github=3Dexamples/ctv-simple.minsc</a></di=
v><div><br></div><div>- More advanced example implementing a CTV vault: <a =
href=3D"https://min.sc/v0.3/#github=3Dexamples/ctv-vault.minsc" target=3D"_=
blank">https://min.sc/v0.3/#github=3Dexamples/ctv-vault.minsc</a></div><div=
><br></div><div>- Another vault, with key delegation using CTV+CSFS+PAIRCOM=
MIT+INTERNALKEY: <a href=3D"https://min.sc/v0.3/#gist=3D82d92568c2fcba62203=
157f8df11354e" target=3D"_blank">https://min.sc/v0.3/#gist=3D82d92568c2fcba=
62203157f8df11354e</a></div><div><br></div><div>- Decaying multisig using P=
SBT/Miniscript: <a href=3D"https://min.sc/v0.3/#github=3Dexamples/3of3-into=
-2of3.minsc" target=3D"_blank">https://min.sc/v0.3/#github=3Dexamples/3of3-=
into-2of3.minsc</a></div><div><br></div><div>More examples are available on=
the README: <a href=3D"https://github.com/shesek/minsc" target=3D"_blank">=
https://github.com/shesek/minsc</a></div></div><div><br></div><div>Cheers,<=
/div><div>shesek</div><br></div><br><div class=3D"gmail_quote gmail_quote_c=
ontainer"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 5, 2025 at 3:06=
=E2=80=AFAM Anthony Towns <<a href=3D"mailto:aj@erisian.com.au">aj@erisi=
an.com.au</a>> wrote:<br></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">Hello world,<br>
<br>
Some people on twitter are apparently proposing the near-term activation of=
<br>
CTV and CSFS (BIP 119 and BIP 348 respectively), eg:<br>
<br>
=C2=A0<a href=3D"https://x.com/JeremyRubin/status/1895676912401252588" rel=
=3D"noreferrer" target=3D"_blank">https://x.com/JeremyRubin/status/18956769=
12401252588</a><br>
=C2=A0<a href=3D"https://x.com/lopp/status/1895837290209161358" rel=3D"nore=
ferrer" target=3D"_blank">https://x.com/lopp/status/1895837290209161358</a>=
<br>
=C2=A0<a href=3D"https://x.com/stevenroose3/status/1895881757288996914" rel=
=3D"noreferrer" target=3D"_blank">https://x.com/stevenroose3/status/1895881=
757288996914</a><br>
=C2=A0<a href=3D"https://x.com/reardencode/status/1871343039123452340" rel=
=3D"noreferrer" target=3D"_blank">https://x.com/reardencode/status/18713430=
39123452340</a><br>
=C2=A0<a href=3D"https://x.com/sethforprivacy/status/1895814836535378055" r=
el=3D"noreferrer" target=3D"_blank">https://x.com/sethforprivacy/status/189=
5814836535378055</a><br>
<br>
Since BIP 119's motivation is entirely concerned with its concept of<br=
>
covenants and avoiding what it calls recursive covenants, I think it<br>
is interesting to note that the combination of CSFS and CTV trivially<br>
enables the construction of a "recursive covenant" as BIP 119 use=
s those<br>
terms. One approach is as follows:<br>
<br>
=C2=A0* Make a throwaway BIP340 private key X with 32-bit public key P.<br>
=C2=A0* Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY O=
P_CTV", and<br>
=C2=A0 =C2=A0its corresponding scriptPubKey K when combined with P as the i=
nternal public<br>
=C2=A0 =C2=A0key.<br>
=C2=A0* Calculate the CTV hash corresponding to a payment of some specific =
value V<br>
=C2=A0 =C2=A0to K; call this hash H<br>
=C2=A0* Calculate the BIP 340 signature for message H with private key X, c=
all it S.<br>
=C2=A0* Discard the private key X<br>
=C2=A0* Funds sent to K can only be spent by the witness data "<H&g=
t; <S>" that forwards<br>
=C2=A0 =C2=A0an amount V straight back to K.<br>
<br>
Here's a demonstration on mutinynet:<br>
<br>
=C2=A0<a href=3D"https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafc=
sg2lf5jd33tznmyjejrmqqx525gsk5nr58" rel=3D"noreferrer" target=3D"_blank">ht=
tps://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejr=
mqqx525gsk5nr58</a><br>
<br>
I'd encourage people to try implementing that themselves with their<br>
preferred tooling; personally, I found it pretty inconvenient, which I<br>
don't think is a good indication of ecosystem readiness wrt deployment.=
<br>
(For me, the two components that are annoying is doing complicated<br>
taproot script path spends, and calculating CTV hashes)<br>
<br>
I don't believe the existence of a construction like this poses any<br>
problems in practice, however if there is going to be a push to activate<br=
>
BIP 119 in parallel with features that directly undermine its claimed<br>
motivation, then it would presumably be sensible to at least update<br>
the BIP text to describe a motivation that would actually be achieved by<br=
>
deployment.<br>
<br>
Personally, I think BIP 119's motivation remains very misguided:<br>
<br>
=C2=A0- the things it describes are, in general, not "covenants" =
[0]<br>
=C2=A0- the thing it avoids is not "recursion" but unbounded recu=
rsion<br>
=C2=A0- avoiding unbounded recursion is not very interesting when arbitrari=
ly<br>
=C2=A0 =C2=A0large recursion is still possible [1]<br>
=C2=A0- despite claiming that "covenants have historically been widely=
<br>
=C2=A0 =C2=A0considering to be unfit for Bitcoin", no evidence for thi=
s claim has<br>
=C2=A0 =C2=A0been able to be provided [2,3]<br>
=C2=A0- the opposition to unbounded recursion seems to me to either mostly<=
br>
=C2=A0 =C2=A0or entirely be misplaced fear of things that are already possi=
ble in<br>
=C2=A0 =C2=A0bitcoin and easily avoided by people who want to avoid it, eg =
[4]<br>
<br>
so, at least personally, I think almost any update to BIP 119's motivat=
ion<br>
section would be an improvement...<br>
<br>
[0] <a href=3D"https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@eris=
ian.com.au/" rel=3D"noreferrer" target=3D"_blank">https://gnusha.org/pi/bit=
coindev/20220719044458.GA26986@erisian.com.au/</a><br>
[1] <a href=3D"https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com=
.au/" rel=3D"noreferrer" target=3D"_blank">https://gnusha.org/pi/bitcoindev=
/87k0dwr015.fsf@rustcorp.com.au/</a><br>
[2] <a href=3D"https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4=
c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/" rel=3D"noreferrer" =
target=3D"_blank">https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355=
d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/</a><br>
[3] <a href=3D"https://x.com/Ethan_Heilman/status/1194624166093369345" rel=
=3D"noreferrer" target=3D"_blank">https://x.com/Ethan_Heilman/status/119462=
4166093369345</a><br>
[4] <a href=3D"https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisi=
an.com.au/" rel=3D"noreferrer" target=3D"_blank">https://gnusha.org/pi/bitc=
oindev/20220217151528.GC1429@erisian.com.au/</a><br>
<br>
Beyond being a toy example of a conflict with BIP 119's motivation<br>
section, I think the above script could be useful in the context of the<br>
"blind-merged-mining" component of spacechains [5]. For example, =
if<br>
the commitment was to two outputs, one the recursive step and the other<br>
being a 0sat ephemeral anchor, then the spend of the ephemeral anchor<br>
would allow for both providing fees conveniently and for encoding the<br>
spacechain block's commitment; competing spacechain miners would then<b=
r>
just be rbf'ing that spend with the parent spacechain update remaining<=
br>
unchanged. The "nLockTime" and "sequences_hash" commitm=
ent in CTV would<br>
need to be used to ensure the "one spacechain update per bitcoin block=
"<br>
rule. (I believe mutinynet doesn't support ephemeral anchors however, s=
o<br>
I don't think there's anywhere this can be tested)<br>
<br>
[5] <a href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34=
906b16a5#file-bmm-svg" rel=3D"noreferrer" target=3D"_blank">https://gist.gi=
thub.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg</a><br>
<br>
(For a spacechain, miners would want to be confident that the private key<b=
r>
has been discarded. This confidence could be enhanced by creating X as a<br=
>
musig2 key by a federation, in which case provided any of the private keys<=
br>
used in generating X were correctly discarded, then everything is fine,<br>
but that's still a trust assumption. Simple introspection opcodes would=
<br>
work far better for this use case, both removing the trust assumption<br>
and reducing the onchain data required)<br>
<br>
If you're providing CTV and CSFS anyway, I don't see why you wouldn=
't<br>
provide the same or similar functionality via a SIGHASH flag so that you<br=
>
can avoid specifying the hash directly when you're signing it anyway,<b=
r>
giving an ANYPREVOUT/NOINPUT-like feature directly.<br>
<br>
(Likewise, I don't see why you'd want to activate CAT on mainnet wi=
thout<br>
also at least re-enabling SUBSTR, and potentially also the redundant<br>
LEFT and RIGHT operations)<br>
<br>
For comparison, bllsh [6,7] takes the approach of providing<br>
"bip340_verify" (directly equivalent to CSFS), "ecdsa_verify=
" (same but<br>
for ECDSA rather than schnorr), "bip342_txmsg" and "tx"=
opcodes. A CTV<br>
equivalent would then either involve simplying writing:<br>
<br>
=C2=A0 =C2=A0(=3D (bip342_txmsg 3) 0x.....)<br>
<br>
meaining "calculate the message hash of the current tx for SIGHASH_SIN=
GLE,<br>
then evaluate whether the result is exactly equal to this constant"<br=
>
providing one of the standard sighashes worked for your use case, or<br>
replacing the bip342_txmsg opcode with a custom calculation of the tx<br>
hash, along the lines of the example reimplementation of bip342_txmsg<br>
for SIGHASH_ALL [8] in the probably more likely case that it didn't. If=
<br>
someone wants to write up the BIP 119 hashing formula in bllsh, I'd<br>
be happy to include that as an example; I think it should be a pretty<br>
straightforward conversion from the test-tx example.<br>
<br>
If bllsh were live today (eg on either signet or mainnet), and it were<br>
desired to softfork in a more optimised implementation of either CTV or<br>
ANYPREVOUT to replace people coding their own implementation in bllsh<br>
directly, both would simply involve replacing calls to "bip342_txmsg&q=
uot;<br>
with calls to a new hash calculation opcode. For CTV behaviour, usage<br>
would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO be=
haviour,<br>
usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". T=
hat<br>
is, the underlying "I want to hash a message in such-and-such a way&qu=
ot;<br>
looks the same, and how it's used is the wallet author's decision,<=
br>
not a matter of how the consensus code is written.<br>
<br>
I believe simplicity/simfony can be thought of in much the same way;<br>
with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like beh=
aviour<br>
[9], or "jet::eq_256" comparing a tx hash and a constant for CTV-=
like<br>
behaviour [10].<br>
<br>
[6] <a href=3D"https://github.com/ajtowns/bllsh/" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/ajtowns/bllsh/</a><br>
[7] <a href=3D"https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224" r=
el=3D"noreferrer" target=3D"_blank">https://delvingbitcoin.org/t/debuggable=
-lisp-scripts/1224</a><br>
[8] <a href=3D"https://github.com/ajtowns/bllsh/blob/master/examples/test-t=
x" rel=3D"noreferrer" target=3D"_blank">https://github.com/ajtowns/bllsh/bl=
ob/master/examples/test-tx</a><br>
[9] <a href=3D"https://github.com/BlockstreamResearch/simfony/blob/master/e=
xamples/p2pk.simf" rel=3D"noreferrer" target=3D"_blank">https://github.com/=
BlockstreamResearch/simfony/blob/master/examples/p2pk.simf</a><br>
[10] <a href=3D"https://github.com/BlockstreamResearch/simfony/blob/master/=
examples/ctv.simf" rel=3D"noreferrer" target=3D"_blank">https://github.com/=
BlockstreamResearch/simfony/blob/master/examples/ctv.simf</a><br>
<br>
For me, the bllsh/simplicity approach makes more sense as a design<br>
approach for the long term, and the ongoing lack of examples of killer<br>
apps demonstrating big wins from limited slices of new functionality<br>
leaves me completely unexcited about rushing something in the short term.<b=
r>
Having a flood of use cases that don't work out when looked into isn=
9;t<br>
a good replacement for a single compelling use case that does.<br>
<br>
Cheers,<br>
aj<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40eri=
sian.com.au</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" 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/CAGXD5f3EGyUVBc%3DbDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAGXD5f3EGyUVBc%3DbDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q%40ma=
il.gmail.com</a>.<br />
--000000000000ad1712062ff60ccc--
|