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
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3F2A1C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 19:16:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 15E4A60B97
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 19:16:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id RQXiaUYlhIaZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 19:16:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com
[IPv6:2607:f8b0:4864:20::733])
by smtp3.osuosl.org (Postfix) with ESMTPS id 4CC8460B7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 19:16:45 +0000 (UTC)
Received: by mail-qk1-x733.google.com with SMTP id o12so3563674qke.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 11:16:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=4avthQpV/tf6uFTr/D5rAvkP8GCIoEDsSnmSbxdk+Nw=;
b=jmvvQRQacN0UJjTNGBrtfaywtNGXyC6Rh7PQoXrb2a+XKUY7CO7wx5OiGSveM6mzGK
z3EJHQBT1TzekVjmpmPXs6yvjDu5J0EuC/ZeU90UtHJH36OqL1oGO6ZrfxsWeatvdJ24
yKlos2s7HiTCThm7FXbd5Hra2kbmipV7vK9gvPxiWMPMM2KlqLQGWtPbPcN5+90tPyu5
HufwPIfUqSbp+BDdnlcXxlNh2WJITJswvxb/81EkxXkXwmp0grf5P5b1Cv2t+N2JDxwa
buhpqVbIyk9Gsyfj4suRoAkZ7oUBiML/Qk1my1XoyMnGbf9gi1IIgj98nRFEQDfkqsCv
MZdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=4avthQpV/tf6uFTr/D5rAvkP8GCIoEDsSnmSbxdk+Nw=;
b=toy4Io7g3oJTkMpoA7jeh6Uc4dPhwm5G4C8qZkrFq3DmywR/wrzIYCcX4Vw3NMOr8c
XOz1oQnzcgiOvxm+JgWgEETqIl9uLrCMQai3ULTGgJSOfc54IMNFOPn+QUzdTnzsvU1S
bW55A/NUNxFvnryHwI+pigPr1kBYpS8Ew3n2fKcwivyFD9/pg6K5KGHey/eDLJaJcaEB
/Wt0xVQnYFweXmkkY/nP3drij8nPjEiL4D0og/DQT9MWMdlp6gmnd6qmXpIN7Sx0O4b0
6QuOSsOIaSBGZiM3ElOwtgf4XGouw91Tyez4gZY81l+NEvv6R27fKCzB9wYH6lVuurf2
vpxw==
X-Gm-Message-State: AOAM532gsunBBsYAvOboIWKm6IlP03L4fxMsJoJvz0YtzTVtp/s03AaZ
32pattWNGFS7+V341MKUrnDMTzK0mmuxqJsFplQbgqs55sIX1g==
X-Google-Smtp-Source: ABdhPJygcv9Pt84Ri3cBp/o9/QAtTu3wE9MDQgW9RRr50qc9pd6rtQHjWDehPZBmyBqddf9R32Hc1dy/fq44qBZfSlE=
X-Received: by 2002:a05:620a:1922:: with SMTP id
bj34mr3760351qkb.548.1643311004597;
Thu, 27 Jan 2022 11:16:44 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
<CAD5xwhhwqJ_AETAb3p_zUZmRX-Dzh8J9G984zwEs=KFsGN8aNQ@mail.gmail.com>
In-Reply-To: <CAD5xwhhwqJ_AETAb3p_zUZmRX-Dzh8J9G984zwEs=KFsGN8aNQ@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Thu, 27 Jan 2022 14:16:33 -0500
Message-ID: <CAMZUoKmU1cwUAQaBv5m8oo8H3TWBvgsZ_OkQaMC0n0+3cpFtWg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000af5a0005d695288a"
X-Mailman-Approved-At: Thu, 27 Jan 2022 22:19:39 +0000
Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV
and ANYPREVOUT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2022 19:16:49 -0000
--000000000000af5a0005d695288a
Content-Type: text/plain; charset="UTF-8"
I am sensitive to technical debt and soft fork processes, and I don't
believe I'm unordinary particular about these issues. Once implemented,
opcodes must be supported and maintained indefinitely. Some opcodes are
easier to maintain than others. These particular opcodes involve caching
of hash computations and, for that reason, I would judge them to be of
moderate complexity.
But more importantly, soft-forks are inherently a risky process, so we
should be getting as much value out of them as we reasonably can. I don't
think implementing a CTV opcode that we expect to largely be obsoleted by a
TXHASH at a later date is yielding good value from a soft fork process.
The strongest argument I can make in favour of CTV would be something like:
"We definitely want bare CTV and if we are going to add CTV to legacy
script (since we cannot use TXHASH in legacy script), then it is actually
easier not to exclude it from tapscript, even if we plan to add TXHASH to
tapscript as well."
But that argument basically rests the entire value of CTV on the shoulders
of bare CTV. As I understand, the argument for why we want bare CTV,
instead of just letting people use tapscript, involves the finer details of
weight calculations, and I haven't really reviewed that aspect yet. I
think it would need to be pretty compelling to make it worthwhile to add
CTV for that one use case.
Regarding "OP_TXHASH+CSFSV doesn't seem to be the 'full' set of things
needed", I totally agree we will want more things such as CAT, rolling
SHA256 opcodes, wider arithmetic, pushing amounts onto the stack, some kind
of tapleaf manipulation and/or TWEAKVERIFY. For now, I only want to argue
TXHASH+CSFSV is better than CTV+APO because it gives us more value, namely
oracle signature verification. In particular, I want to argue that
TXHASH's push semantics is better that CTV's verify semantics because it
composes better by not needing to carry an extra 32-bytes (per instance) in
the witness data. I expect that in a world of full recursive covenants,
TXHASH would still be useful as a fast and cheap way to verify the
"payload" of these covenants, i.e. that a transaction is paying a certain,
possibly large, set of addresses certain specific amounts of money. And
even if not, TXHASH+CSFSV would still be the way that eltoo would be
implemented under this proposal.
On Wed, Jan 26, 2022 at 5:16 PM Jeremy <jlrubin@mit.edu> wrote:
> Hi Russell,
>
> Thanks for this email, it's great to see this approach described.
>
> A few preliminary notes of feedback:
>
> 1) a Verify approach can be made to work for OP_TXHASH (even with CTV
> as-is) E.g., suppose a semantic added for a single byte stack[-1] sighash
> flag to read the hash at stack[-2], then the hash can be passed in instead
> of put on the stack. This has the disadvantage of larger witnesses, but the
> advantage of allowing undefined sighash flags to pass for any hash type.
> 2) using the internal key for APO covenants is not an option because it
> makes transaction construction interactive and precludes contracts with a
> NUMS point taproot key. Instead, if you want similar savings, you should
> advocate an OP_GENERATOR which puts G on the stack. Further, an untagged
> APO variant which has split R and S values would permit something like
> <sig> OP_GENERATOR OP_GENERATOR CHECKSIGAPO, which would be only 2 more
> bytes than CTV.
> 3) I count something like 20 different flags in your proposal. As long as
> flags are under 40 bytes (and 32 assuming we want it to be easy) without
> upgrading math this should be feasible to manipulate on the stack
> programmatically. This is ignoring some of the more flexible additions you
> mention about picking which outputs/inputs are included. However, 20 flags
> means that for testing we would want comprehensive tests and understanding
> for ~1 million different flag combos and the behaviors they expose. I think
> this necessitates a formal model of scripting and transaction validity
> properties. Are there any combinations that might be undesirable?
> 4) Just hashing or not hashing isn't actually that flexible, because it
> doesn't natively let you do things like (for example) TLUV. You really do
> need tx operations for directly manipulating the data on the stack to
> construct the hash if you want more flexible covenants. This happens to be
> compatible with either a Verify or Push approach, since you either
> destructure a pushed hash or build up a hash for a verify.
> 5) Flexible hashing has the potential for quadratic hashing bugs. The
> fields you propose seem to be within similar range to work you could cause
> with a regular OP_HASH256, although you'd want to be careful with some of
> the proposed extensions that you don't create risk of quadratic hashing,
> which seems possible with an output selecting opcode unless you cache
> properly (which might be tricky to do). Overall for the fields explicitly
> mentioned, seems safe, the "possibles" seem to have some more complex
> interactions. E.g., CTV with the ability to pick a subset of outputs would
> be exposed to quadratic hashing.
> 6) Missing field: covering the annex or some sub-range of the annex
> (quadratic hashing issues on the latter)
> 7) It seems simpler to, for many of these fields, push values directly (as
> in OP_PUSHTXDATA from Johnson Lau) because the combo of flags to push the
> hash of a single output's amount to emulate OP_AMOUNT looks 'general but
> annoying'. It may make more sense to do the OP_PUSHTXDATA style opcode
> instead. This also makes it simpler to think about the combinations of
> flags, since it's really N independent multi-byte opcodes.
>
>
> Ultimately if we had OP_TXHASH available "tomorrow", I would be able to
> build out the use cases I care about for CTV (and more). So I don't have an
> opposition on it with regards to lack of function.
>
> However, if one finds the TXHASH approach acceptable, then you should also
> be relatively fine doing APO, CTV, CSFS, TXHASH acceptable in any order
> (whenever "ready"), unless you are particularly sensitive to "technical
> debt" and "soft fork processes". The only costs of doing something for CTV
> or APO given an eventual TXHASH is perhaps a wasted key version or the 32
> byte argument of a NOP opcode and some code to maintain.
>
> Are there other costs I am missing?
>
> However, as it pertains to actual rollout:
>
> - OP_TXHASH+CSFSV doesn't seem to be the "full" set of things needed (we
> still need e.g. OP_CAT, Upgraded >=64 bit Math, TLUV or OP_TWEAK
> OP_TAPBRANCH OP_MANIPULATETAPTREE, and more) to full realize covenanting
> power it intends to introduce.
> - What sort of timeline would it take to ready something like TXHASH (and
> desired friends) given greater scope of testing and analysis (standalone +
> compared to CTV)?
> - Is there opposition from the community to this degree of
> general/recursive covenants?
> - Does it make "more sense" to invest the research and development effort
> that would go into proving TXHASH safe, for example, into Simplicity
> instead?
>
> Overall, *my opinion *is that:
>
> - TXHASH is an acceptable theoretical approach, and I am happy to put more
> thought into it and maybe draft a prototype of it.
> - I prefer CTV as a first step for pragmatic engineering and availability
> timeline reasons.
> - If TXHASH were to take, optimistically, 2 years to develop and review,
> and then 1 year to activate, the "path dependence of software" would put
> Bitcoin in a much better place were we to have CTV within 1 year and
> applications (that are to be a subset of TXHASH later) being built over the
> next few years enhanced in the future by TXHASH's availability.
> - There is an element of expediency meritted for something like CTV
> insofar as it provides primitives to tackle time sensitive issues around
> privacy, scalability, self custody, and decentralization. The
> aforementioned properties may be difficult to reclaim once given away (with
> the exception of perhaps scalability).
> - Bringing CTV to an implemented state of near-unanimous "we could do
> this, technically" is good for concretely driving the process of review for
> any covenant proposals forward, irrespective of if we ultimately activate.
> (I.e., if there were a reason we could not do CTV safely, it would likely
> have implications for any other future covenant)
>
> Concretely, I'm not going to stop advocating for CTV based on the above,
> but I'm very happy to have something new in the mix to consider!
>
> Best,
>
> Jeremy
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Wed, Jan 26, 2022 at 9:23 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Recapping the relationship between CTV and ANYPREVOUT::
>>
>> It is known that there is a significant amount of overlap in the
>> applications that are enabled by the CTV and ANYPREVOUT proposals despite
>> the fact that their primary applications (congestion control for CTV and
>> eltoo lightning channels for ANYPREVOUT) are quite distinct.
>> In particular, ANYPREVOUT can enable most of the applications of CTV,
>> albeit with a higher cost. The primary functionality of CTV is to allow a
>> scriptPubKey to make a commitment to its spending transaction's hash with
>> the input's TXID excluded from the hash. This exclusion is necessary
>> because the scriptPubKey is hashed into the input's TXID, and including the
>> TXID would cause a cycle of hash commitments, which is impossible to
>> construct. On the other hand, ANYPREVOUT defines a signature hash mode
>> that similarly excludes the inputs TXID for its purpose of rebindable
>> signatures.
>>
>> This means that ANYPREVOUT can mimic most of the properties of CTV by
>> committing both a public key along with an ANYPREVOUT signature inside
>> scriptPubKey. In fact, the only reason Bitcoin doesn't have covenants
>> today is due to this cycle between scriptPubKeys and the TXIDs that occur
>> in all the sighash modes.
>>
>> The major differences between simulating CTV via ANYPREVOUT and the
>> actual CTV proposal is: (1) The cost of simulating CTV. With CTV the
>> spending transaction is committed using a hash of 32 bytes, while
>> simulating it with ANYPREVOUT requires 64 bytes for a signature, and 32
>> bytes for some public key, plus a few more bytes for various flags. Some
>> of that cost could be reduced by using the inner public key (1 byte
>> representation) and, if we had CAT, maybe by assembling the signature from
>> reusable pieces (i.e. setting the nonce of the commited signature equal to
>> the public key).
>>
>> The other major difference is: (2) CTV's transaction hash covers values
>> such as the number of inputs in the transaction and their sequence numbers,
>> which ANYPREVOUT does not cover. CTV's hash contains enough information so
>> that when combined with the missing TXIDs, you can compute the TXID of the
>> spending transaction. In particular if the number of inputs is committed
>> to being 1, once the scriptpubkey's transaction id is known and committed
>> to the blockchain, the TXID of its spending transaction is deducible. And
>> if that transaction has outputs that have CTV commitments in them, you can
>> deduce their spending TXIDs in turn. While this is a pretty neat feature,
>> something that ANYPREVOUT cannot mimic, the main application for it is
>> listed as using congestion control to fund lightning channels, fixing their
>> TXIDs in advance of them being placed on chain. However, if ANYPREVOUT
>> were used to mimic CTV, then likely it would be eltoo channels that would
>> be funded, and it isn't necessary to know the TXIDs of eltoo channels in
>> advance in order to use them.
>>
>>
>>
>> An Alternative Proposal::
>>
>> Given the overlap in functionality between CTV and ANYPREVOUT, I think it
>> makes sense to decompose their operations into their constituent pieces and
>> reassemble their behaviour programmatically. To this end, I'd like to
>> instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.
>>
>> OP_TXHASH would pop a txhash flag from the stack and compute a (tagged)
>> txhash in accordance with that flag, and push the resulting hash onto the
>> stack.
>> OP_CHECKSIGFROMSTACKVERIFY would pop a pubkey, message, and signature
>> from the stack and fail if the signature does not verify on that message.
>>
>> CTV and TXHASH have roughly equivalent functionality. 'CTV DROP' can be
>> simulated by '<ctv_style_flag> TXHASH EQUALVERIFY'. The reverse is also
>> true where '<ctv_style_flag> TXHASH' can be simulated by CTV by
>> '<ctv-result-from-witness-stack> CTV', however, as you can see, simulating
>> TXHASH from CTV is much more expensive than the other way around, because
>> the resulting 32-byte hash result must be included as part of the witness
>> stack.
>>
>> '<anyprevout-pubkey> CHECKSIGVERIFY can be simulated by '<apo_style_flag>
>> TXHASH <pubkey> CHECKSIGFROMSTACKVERIFY'. Here we see the advantage of
>> pushing the hash value onto the stack. APO can be simulated without
>> needing to include a copy of the resulting txhash inside the witness data.
>>
>> In addition to the CTV and ANYPREVOUT applications, with
>> CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages
>> signed by oracles for oracle applications. This is where we see the
>> benefit of decomposing operations into primitive pieces. By giving users
>> the ability to program their own use cases from components, we get more
>> applications out of fewer op codes!
>>
>>
>>
>> Caveats::
>>
>> First, I acknowledge that replicating the behaviour of CTV and ANYPREVOUT
>> does cost a few more bytes than using the custom purpose built proposals
>> themselves. That is the price to be paid when we choose the ability to
>> program solutions from pieces. But we get to reap the advantages of being
>> able to build more applications from these pieces.
>>
>> Unlike CTV, TXHASH is not NOP-compatable and can only be implemented
>> within tapscript. In particular, bare CTV isn't possible with this
>> proposal. However, this proposal doesn't preclude the possibility of
>> having CTV added to legacy script in while having TXHASH added to tapscript.
>>
>> For similar reasons, TXHASH is not amenable to extending the set of
>> txflags at a later date. In theory, one could have TXHASH
>> abort-with-success when encountering an unknown set of flags. However,
>> this would make analyzing tapscript much more difficult. Tapscripts would
>> then be able to abort with success or failure depending on the order script
>> fragments are assembled and executed, and getting the order incorrect would
>> be catastrophic. This behavior is manifestly different from the current
>> batch of OP_SUCCESS opcodes that abort-with-success just by their mere
>> presence, whether they would be executed or not.
>>
>> I believe the difficulties with upgrading TXHASH can be mitigated by
>> designing a robust set of TXHASH flags from the start. For example having
>> bits to control whether (1) the version is covered; (2) the locktime is
>> covered; (3) txids are covered; (4) sequence numbers are covered; (5) input
>> amounts are covered; (6) input scriptpubkeys are covered; (7) number of
>> inputs is covered; (8) output amounts are covered; (9) output scriptpubkeys
>> are covered; (10) number of outputs is covered; (11) the tapbranch is
>> covered; (12) the tapleaf is covered; (13) the opseparator value is
>> covered; (14) whether all, one, or no inputs are covered; (15) whether all,
>> one or no outputs are covered; (16) whether the one input position is
>> covered; (17) whether the one output position is covered; (18) whether the
>> sighash flags are covered or not (note: whether or not the sighash flags
>> are or are not covered must itself be covered). Possibly specifying which
>> input or output position is covered in the single case and whether the
>> position is relative to the input's position or is an absolute position.
>>
>> That all said, even if other txhash flag modes are needed in the future,
>> adding TXHASH2 always remains an option.
>>
>>
>>
>> Interactions with potential future opcodes::
>>
>> We should give some consideration on how these opcodes may interact with
>> future opcodes such as CAT, rolling SHA256 opcodes, or how it might
>> interface with other covenant opcodes that may do things like, directly
>> push input or output amounts onto the stack for computation purposes,
>> opcodes which have been added to the Elements project.
>>
>> With CAT and/or rolling SHA256 opcodes and/or existing SHA256 opcodes,
>> the CHECKSIGFROMSTACKVERIFY could verify signatures on programmatically
>> assembled messages. Also, in combination with multiple calls to TXHASH,
>> could be used to create signatures that commit to complex subsets of
>> transaction data.
>>
>> If new opcodes are added to push parts of the transaction data direction
>> onto the stack, e.g. OP_INSPECTOUTPUTVALUE, there is perhaps concern that
>> they would obsolete TXHASH, since, in the presence of rolling SHA256
>> opcodes, TXHASH could be simulated. However, given that TXHASH can
>> compactly create a hash of large portions of transaction data, it seems
>> unlikely that TXHASH would fall into disuse. Also, a combination of TXHASH
>> and transaction introspection opcodes can be used to build "*subtractive
>> covenants*".
>>
>> The usual way of building a covenant, which we will call "*additive *
>> *covenants*", is to push all the parts of the transaction data you would
>> like to fix onto the stack, hash it all together, and verify the resulting
>> hash matches a fixed value. Another way of building covenants, which we
>> will call "*subtractive covenants*", is to push all the parts of the
>> transaction data you would like to remain free onto the stack. Then use
>> rolling SHA256 opcodes starting from a fixed midstate that commits to a
>> prefix of the transaction hash data. The free parts are hashed into that
>> midstate. Finally, the resulting hash value is verified to match a value
>> returned by TXHASH. The ability to nicely build subtractive covenants
>> depends on the details of how the TXHASH hash value is constructed,
>> something that I'm told CTV has given consideration to.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
--000000000000af5a0005d695288a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I am sensitive to technical debt and soft fork=C2=A0p=
rocesses, and I don't believe I'm unordinary particular about these=
issues.=C2=A0 Once implemented, opcodes must be supported and maintained i=
ndefinitely.=C2=A0 Some opcodes are easier to maintain than others.=C2=A0 T=
hese particular opcodes involve caching of hash computations and, for that =
reason, I would judge them to be of moderate complexity.<br></div><div><br>=
</div><div>But more importantly, soft-forks are inherently a risky process,=
so we should be getting as much value out of them as we reasonably can. I =
don't think implementing a CTV opcode that we expect to largely be obso=
leted by a TXHASH at a later date is yielding good value from a soft fork p=
rocess.</div><div><br></div><div>The strongest argument I can make in favou=
r of CTV would be something like: "We definitely want bare CTV and if =
we are going to add CTV to legacy script (since we cannot use TXHASH in leg=
acy script), then it is actually easier not to exclude it from tapscript, e=
ven if we plan to add TXHASH to tapscript as well."</div><div><br></di=
v><div>But that argument basically rests the entire value of CTV on the sho=
ulders of bare CTV.=C2=A0 As I understand, the argument for why we want bar=
e CTV, instead of just letting people use tapscript, involves the finer det=
ails of weight calculations, and I haven't really reviewed that aspect =
yet.=C2=A0 I think it would need to be pretty compelling to make it worthwh=
ile to add CTV for that one use case.</div><div><br></div><div><br></div><d=
iv>Regarding "OP_TXHASH+CSFSV doesn't seem to be the 'full'=
; set of things needed", I totally agree we will want more things such=
as CAT, rolling SHA256 opcodes, wider arithmetic, pushing amounts onto the=
stack, some kind of tapleaf manipulation and/or TWEAKVERIFY.=C2=A0 For now=
, I only want to argue TXHASH+CSFSV is better than CTV+APO because it gives=
us more value, namely oracle signature verification.=C2=A0 In particular, =
I want to argue that TXHASH's push semantics is better that CTV's v=
erify semantics because it composes better by not needing to carry an extra=
32-bytes (per instance) in the witness data.=C2=A0 I expect that in a worl=
d of full recursive covenants, TXHASH would still be useful as a fast and c=
heap way to verify the "payload" of these covenants, i.e. that a =
transaction is paying a certain, possibly large, set of addresses certain s=
pecific amounts of money.=C2=A0 And even if not, TXHASH+CSFSV would still b=
e the way that eltoo would be implemented under this proposal.<br></div><di=
v><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Wed, Jan 26, 2022 at 5:16 PM Jeremy <<a href=3D"mailto:jlrubin@mit.=
edu">jlrubin@mit.edu</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">Hi Russell,</div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:rgb(0,0,0)">Thanks for this email, it's great to see this =
approach described.</div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">A few preliminar=
y notes of feedback:</div><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1) a Verify app=
roach can be made to work for OP_TXHASH (even with CTV as-is) E.g., suppose=
a semantic added for a single byte stack[-1] sighash flag to read the hash=
at stack[-2], then the hash can be passed in instead of put on the stack. =
This has the disadvantage of larger witnesses, but the advantage=C2=A0of al=
lowing undefined sighash flags to pass for any hash type.</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">2) using the internal key for APO covenants is not an option because it m=
akes transaction construction interactive and precludes contracts with a NU=
MS point taproot key. Instead, if you want similar savings, you should advo=
cate an OP_GENERATOR which puts G on the stack. Further, an untagged APO va=
riant which has split R and S values would permit something like <sig>=
; OP_GENERATOR OP_GENERATOR CHECKSIGAPO, which would be only 2 more bytes t=
han CTV.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">3) I count something like 20 different flags in y=
our proposal. As long as flags are under 40 bytes (and 32 assuming we want =
it to be easy) without upgrading math this should be feasible to manipulate=
on the stack programmatically. This is ignoring some of the more flexible =
additions you mention about picking which outputs/inputs are included. Howe=
ver, 20 flags means that for testing we would want comprehensive tests and =
understanding for ~1 million different flag combos and the behaviors they e=
xpose. I think this necessitates a formal model of scripting and transactio=
n validity properties. Are there any combinations that might be undesirable=
?</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">4) Just hashing or not hashing isn't actually that f=
lexible, because it doesn't natively let you do things like (for exampl=
e) TLUV. You really do need tx operations for directly manipulating the dat=
a on the stack to construct the hash if you want more flexible covenants. T=
his happens to be compatible with either a Verify or Push approach, since y=
ou either destructure a pushed hash or build up a hash for a verify.</div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">5) Flexible hashing has the potential for quadratic hashing bugs=
. The fields you propose seem to be within similar range to work you could =
cause with a regular OP_HASH256, although you'd want to be careful with=
some of the proposed extensions that you don't create risk of quadrati=
c hashing, which seems possible with an output selecting opcode unless you =
cache properly (which might be tricky to do). Overall for the fields explic=
itly mentioned, seems safe, the "possibles" seem to have some mor=
e complex interactions. E.g., CTV with the ability to pick a subset of outp=
uts would be exposed to quadratic hashing.</div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">6) Missing fiel=
d: covering the annex or some sub-range of the annex (quadratic hashing iss=
ues on the latter)</div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">7) It seems simpler to, for many of the=
se fields, push values directly (as in OP_PUSHTXDATA from Johnson Lau) beca=
use the combo of flags to push the hash of a single output's amount to =
emulate OP_AMOUNT looks 'general but annoying'. It may make more se=
nse to do the OP_PUSHTXDATA=C2=A0style opcode instead. This also makes it s=
impler to think about the combinations of flags, since it's really N in=
dependent multi-byte opcodes.</div><div style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></=
div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)">Ultimately if we had OP_TXHASH available "tomorrow&quo=
t;, I would be able to build out the use cases I care about for CTV (and mo=
re). So I don't have an opposition on it with regards to lack of functi=
on.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)"><div>However, if one finds the T=
XHASH approach acceptable, then you should also be relatively fine doing AP=
O, CTV, CSFS, TXHASH acceptable in any order (whenever "ready"), =
unless you are particularly sensitive to "technical debt" and &qu=
ot;soft fork=C2=A0processes". The only costs of doing something for CT=
V or APO given an eventual TXHASH=C2=A0is perhaps a wasted key version or t=
he 32 byte argument of a NOP opcode and some code to maintain.</div><div><b=
r></div><div>Are there other costs I am missing?</div><div></div></div><div=
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">However, as it pertains to actual rollout:</d=
iv><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">- OP_TXHASH+CSFSV doesn't seem to =
be the "full" set of things needed (we still need e.g. OP_CAT, Up=
graded >=3D64 bit Math, TLUV or OP_TWEAK OP_TAPBRANCH OP_MANIPULATETAPTR=
EE, and more) to full realize covenanting power it intends to introduce.=C2=
=A0</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">- What sort of timeline would it take to ready somethi=
ng like TXHASH=C2=A0(and desired friends) given greater scope of testing an=
d analysis (standalone=C2=A0+ compared to CTV)?</div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Is there=
opposition from the community to this degree of general/recursive covenant=
s?</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">- Does it make "more sense" to invest the res=
earch and development effort that would go into proving=C2=A0TXHASH safe, f=
or example, into Simplicity instead?</div><div style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">Overall, <i>my opinion </i>is that:</div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">- TXHASH=C2=A0is an acceptable theoretical approach, and I am happy to pu=
t more thought into it and maybe draft a prototype of it.</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">- I prefer CTV as a first step for pragmatic engineering and availability=
timeline reasons.</div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">- If TXHASH were to take, optimisticall=
y, 2 years to develop and review, and then 1 year to activate, the "pa=
th dependence of software" would put Bitcoin in a much better place we=
re we to have CTV within 1 year and applications (that are to be a subset o=
f TXHASH=C2=A0later) being built over the next few years enhanced in the fu=
ture by TXHASH's availability.=C2=A0</div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- There is an ele=
ment of expediency meritted for something like CTV insofar as it provides p=
rimitives to tackle time sensitive issues around privacy, scalability, self=
custody, and decentralization. The aforementioned properties may be diffic=
ult to reclaim once given away (with the exception of perhaps scalability).=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">- Bringing CTV to an implemented state of near-unanimous =
"we could do this, technically" is good for concretely driving th=
e process of review for any covenant proposals forward, irrespective of if =
we ultimately activate. (I.e., if there were a reason we could not do CTV s=
afely, it would likely have implications for any other future covenant)</di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">Concretely, I'm not going to stop a=
dvocating for CTV based on the above, but I'm very happy to have someth=
ing new in the mix to consider!</div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Best=
,</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)">Jeremy</div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><br></div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h=
ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><=
/div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Wed, Jan 26, 2022 at 9:23 AM Russell O'Connor via bitcoin-d=
ev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><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"><div dir=3D"ltr"><div>Recapping=
the relationship between CTV and ANYPREVOUT::<br></div><div><br></div><div=
>It is known that there is a significant amount of overlap in the applicati=
ons that are enabled by the CTV and ANYPREVOUT proposals despite the fact t=
hat their primary applications (congestion control for CTV and eltoo lightn=
ing channels for ANYPREVOUT) are quite distinct.</div><div>In particular, A=
NYPREVOUT can enable most of the applications of CTV, albeit with a higher =
cost.=C2=A0 The primary functionality of CTV is to allow a scriptPubKey to =
make a commitment to its spending transaction's hash with the input'=
;s TXID excluded from the hash.=C2=A0 This exclusion is necessary because t=
he scriptPubKey is hashed into the input's TXID, and including the TXID=
would cause a cycle of hash commitments, which is impossible to construct.=
=C2=A0 On the other hand, ANYPREVOUT defines a signature hash mode that sim=
ilarly excludes the inputs TXID for its purpose of rebindable signatures.</=
div><div><br></div><div>This means that ANYPREVOUT can mimic most of the pr=
operties of CTV by committing both a public key along with an ANYPREVOUT si=
gnature inside scriptPubKey.=C2=A0 In fact, the only reason Bitcoin doesn&#=
39;t have covenants today is due to this cycle between scriptPubKeys and th=
e TXIDs that occur in all the sighash modes.<br></div><div><br></div><div>T=
he major differences between simulating CTV via ANYPREVOUT and the actual C=
TV proposal is: (1) The cost of simulating CTV.=C2=A0 With CTV the spending=
transaction is committed using a hash of 32 bytes, while simulating it wit=
h ANYPREVOUT requires 64 bytes for a signature, and 32 bytes for some publi=
c key, plus a few more bytes for various flags.=C2=A0 Some of that cost cou=
ld be reduced by using the inner public key (1 byte representation) and, if=
we had CAT, maybe by assembling the signature from reusable pieces (i.e. s=
etting the nonce of the commited signature equal to the public key).<br></d=
iv><div><br></div><div>The other major difference is: (2) CTV's transac=
tion hash covers values such as the number of inputs in the transaction and=
their sequence numbers, which ANYPREVOUT does not cover.=C2=A0 CTV's h=
ash contains enough information so that when combined with the missing TXID=
s, you can compute the TXID of the spending transaction.=C2=A0 In particula=
r if the number of inputs is committed to being 1, once the scriptpubkey=
9;s transaction id is known and committed to the blockchain, the TXID of it=
s spending transaction is deducible.=C2=A0 And if that transaction has outp=
uts that have CTV commitments in them, you can deduce their spending TXIDs =
in turn.=C2=A0 While this is a pretty neat feature, something that ANYPREVO=
UT cannot mimic, the main application for it is listed as using congestion =
control to fund lightning channels, fixing their TXIDs in advance of them b=
eing placed on chain.=C2=A0 However, if ANYPREVOUT were used to mimic CTV, =
then likely it would be eltoo channels that would be funded, and it isn'=
;t necessary to know the TXIDs of eltoo channels in advance in order to use=
them.</div><div><br></div><div><br></div><div><br></div><div>An Alternativ=
e Proposal::<br></div><div><br></div><div>Given the overlap in functionalit=
y between CTV and ANYPREVOUT, I think it makes sense to decompose their ope=
rations into their constituent pieces and reassemble their behaviour progra=
mmatically.=C2=A0 To this end, I'd like to instead propose OP_TXHASH an=
d OP_CHECKSIGFROMSTACKVERIFY.</div><div><br></div><div>OP_TXHASH would pop =
a txhash flag from the stack and compute a (tagged) txhash in accordance wi=
th that flag, and push the resulting hash onto the stack.<br></div><div>OP_=
CHECKSIGFROMSTACKVERIFY would pop a pubkey, message, and signature from the=
stack and fail if the signature does not verify on that message.</div><div=
><br></div><div>CTV and TXHASH have roughly equivalent functionality.=C2=A0=
'CTV DROP' can be simulated by '<ctv_style_flag> TXHASH =
EQUALVERIFY'.=C2=A0 The reverse is also true where '<ctv_style_f=
lag> TXHASH' can be simulated by CTV by '<ctv-result-from-wit=
ness-stack> CTV', however, as you can see, simulating TXHASH from CT=
V is much more expensive than the other way around, because the resulting 3=
2-byte hash result must be included as part of the witness stack.</div><div=
><br></div><div>'<anyprevout-pubkey> CHECKSIGVERIFY can be simula=
ted by '<apo_style_flag> TXHASH <pubkey> CHECKSIGFROMSTACKV=
ERIFY'.=C2=A0 Here we see the advantage of pushing the hash value onto =
the stack.=C2=A0 APO can be simulated without needing to include a copy of =
the resulting txhash inside the witness data.<br></div><div><br></div><div>=
In addition to the CTV and ANYPREVOUT applications, with CHECKSIGFROMSTACKV=
ERIFY we can verify signatures on arbitrary messages signed by oracles for =
oracle applications.=C2=A0 This is where we see the benefit of decomposing =
operations into primitive pieces.=C2=A0 By giving users the ability to prog=
ram their own use cases from components, we get more applications out of fe=
wer op codes!</div><div><br></div><div><br></div><div><br></div><div>Caveat=
s::</div><div><br></div><div>First, I acknowledge that replicating the beha=
viour of CTV and ANYPREVOUT does cost a few more bytes than using the custo=
m purpose built proposals themselves.=C2=A0 That is the price to be paid wh=
en we choose the ability to program solutions from pieces.=C2=A0 But we get=
to reap the advantages of being able to build more applications from these=
pieces.<br></div><div><br></div><div>Unlike CTV, TXHASH is not NOP-compata=
ble and can only be implemented within tapscript.=C2=A0 In particular, bare=
CTV isn't possible with this proposal.=C2=A0 However, this proposal do=
esn't preclude the possibility of having CTV added to legacy script in =
while having TXHASH added to tapscript.</div><div><br></div><div>For simila=
r reasons, TXHASH is not amenable to extending the set of txflags at a late=
r date.=C2=A0 In theory, one could have TXHASH abort-with-success when enco=
untering an unknown set of flags.=C2=A0 However, this would make analyzing =
tapscript much more difficult. Tapscripts would then be able to abort with =
success or failure depending on the order script fragments are assembled an=
d executed, and getting the order incorrect would be catastrophic.=C2=A0 Th=
is behavior is manifestly different from the current batch of OP_SUCCESS op=
codes that abort-with-success just by their mere presence, whether they wou=
ld be executed or not.</div><div><br></div><div>I believe the difficulties =
with upgrading TXHASH can be mitigated by designing a robust set of TXHASH =
flags from the start.=C2=A0 For example having bits to control whether (1) =
the version is covered; (2) the locktime is covered; (3) txids are covered;=
(4) sequence numbers are covered; (5) input amounts are covered; (6) input=
scriptpubkeys are covered; (7) number of inputs is covered; (8) output amo=
unts are covered; (9) output scriptpubkeys are covered; (10) number of outp=
uts is covered; (11) the tapbranch is covered; (12) the tapleaf is covered;=
(13) the opseparator value is covered; (14) whether all, one, or no inputs=
are covered; (15) whether all, one or no outputs are covered; (16) whether=
the one input position is covered; (17) whether the one output position is=
covered; (18) whether the sighash flags are covered or not (note: whether =
or not the sighash flags are or are not covered must itself be covered).=C2=
=A0 Possibly specifying which input or output position is covered in the si=
ngle case and whether the position is relative to the input's position =
or is an absolute position.</div><div><br></div><div>That all said, even if=
other txhash flag modes are needed in the future, adding TXHASH2 always re=
mains an option.<br></div><div><br></div><div><br></div><div><br></div><div=
>Interactions with potential future opcodes::<br></div><div><div><br></div>=
<div>We should give some consideration on how these opcodes may interact wi=
th future opcodes such as CAT, rolling SHA256 opcodes, or how it might inte=
rface with other covenant opcodes that may do things like, directly push in=
put or output amounts onto the stack for computation purposes, opcodes whic=
h have been added to the Elements project.</div><div><br></div><div>With CA=
T and/or rolling SHA256 opcodes and/or existing SHA256 opcodes, the CHECKSI=
GFROMSTACKVERIFY could verify signatures on programmatically assembled mess=
ages.=C2=A0 Also, in combination with multiple calls to TXHASH, could be us=
ed to create signatures that commit to complex subsets of transaction data.=
</div><div><br></div><div>If new opcodes are added to push parts of the tra=
nsaction data direction onto the stack, e.g. OP_INSPECTOUTPUTVALUE, there i=
s perhaps concern that they would obsolete TXHASH, since, in the presence o=
f rolling SHA256 opcodes, TXHASH could be simulated.=C2=A0 However, given t=
hat TXHASH can compactly create a hash of large portions of transaction dat=
a, it seems unlikely that TXHASH would fall into disuse.=C2=A0 Also, a comb=
ination of TXHASH and transaction introspection opcodes can be used to buil=
d "<i>subtractive covenants</i>".</div><div><br></div><div>The us=
ual way of building a covenant, which we will call "<i>additive </i><i=
>covenants</i>", is to push all the parts of the transaction data you =
would like to fix onto the stack, hash it all together, and verify the resu=
lting hash matches a fixed value.=C2=A0 Another way of building covenants, =
which we will call "<i>subtractive covenants</i>", is to push all=
the parts of the transaction data you would like to remain free onto the s=
tack.=C2=A0 Then use rolling SHA256 opcodes starting from a fixed midstate =
that commits to a prefix of the transaction hash data. The free parts are h=
ashed into that midstate.=C2=A0 Finally, the resulting hash value is verifi=
ed to match a value returned by TXHASH.=C2=A0 The ability to nicely build s=
ubtractive covenants depends on the details of how the TXHASH hash value is=
constructed, something that I'm told CTV has given consideration to.<b=
r></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div></div>
--000000000000af5a0005d695288a--
|