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
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BC6AFD0A;
Fri, 4 Oct 2019 18:33:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB5308BB;
Fri, 4 Oct 2019 18:33:22 +0000 (UTC)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com
[209.85.166.44]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x94IXKqv028848
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
Fri, 4 Oct 2019 14:33:21 -0400
Received: by mail-io1-f44.google.com with SMTP id z19so15743409ior.0;
Fri, 04 Oct 2019 11:33:21 -0700 (PDT)
X-Gm-Message-State: APjAAAUGowNjQZANtRRyZzZGieHY+fegnDcktHaxPvDUS6mcVki6rdu1
mznftwrIt6GrV8HUCv2BN2bw9d2IOcYp7ZVZVK4=
X-Google-Smtp-Source: APXvYqw1ZRbAjY3NH1JsmkUmk7a0d9ve1v9PQmKRHNiCOAm2AsrDrw0droZ2WyO3yKanKHxSSkGVgo0wLkY3ndzM56s=
X-Received: by 2002:a6b:c382:: with SMTP id t124mr2121770iof.105.1570214000448;
Fri, 04 Oct 2019 11:33:20 -0700 (PDT)
MIME-Version: 1.0
References: <87wodp7w9f.fsf@gmail.com>
<20191001155929.e2yznsetqesx2jxo@erisian.com.au>
<CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com>
<CAEM=y+XbP3Dn7X8rHu7h0vbX6DkKA0vFK5nQqzcJ_V+D4EVMmw@mail.gmail.com>
<C1OLL5FLxdOgfQ_A15mf88wIyztDapkyXJ2HZ0HxwmQADhRXGRe3le7Veso4tMIlbis6I0qiCd22xug5_GCKtgrjGnBtojWxOCMgn1UldkE=@protonmail.com>
<CAEM=y+WCGSF_=WXpgXJUZCZcGUQhxzXF6Wv1_iX+VwEyYSWypg@mail.gmail.com>
<CAD5xwhi7=5eiv1jjf72-rUezZMfj3caR+PGfZEa8i8rjNjodFg@mail.gmail.com>
<NVDIhcpuRV6VduUgfMNyGSU1U24ErWPuxpA07fMkIIgXqxEL2aX1_oYJ189Wf5ZigGDBa860gJ-p8d3iAMAWsjHx-5tZHZLjXr7gEmQbL0c=@protonmail.com>
In-Reply-To: <NVDIhcpuRV6VduUgfMNyGSU1U24ErWPuxpA07fMkIIgXqxEL2aX1_oYJ189Wf5ZigGDBa860gJ-p8d3iAMAWsjHx-5tZHZLjXr7gEmQbL0c=@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 4 Oct 2019 11:33:09 -0700
X-Gmail-Original-Message-ID: <CAD5xwhh_WbpSvou7sORjG9JeVonU8UR3qR0Bc9cmhp5sep34OA@mail.gmail.com>
Message-ID: <CAD5xwhh_WbpSvou7sORjG9JeVonU8UR3qR0Bc9cmhp5sep34OA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000b7dbbf059419efb4"
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the
discussion about noinput / anyprevout
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Fri, 04 Oct 2019 18:33:24 -0000
--000000000000b7dbbf059419efb4
Content-Type: text/plain; charset="UTF-8"
Good point -- in our discussion, we called it OP_FFS -- Fold Functional
Stream, and it could be initialized with a different integer to select for
different functions. Therefore the stream processing opcodes would be
generic, but extensible.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, Oct 4, 2019 at 12:00 AM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
> Good morning Jeremy,
>
> > Awhile back, Ethan and I discussed having, rather than OP_CAT, an
> OP_SHA256STREAM that uses the streaming properties of a SHA256 hash
> function to allow concatenation of an unlimited amount of data, provided
> the only use is to hash it.
> >
> > You can then use it perhaps as follows:
> >
> > // start a new hash with item
> > OP_SHA256STREAM (-1) -> [state]
> > // Add item to the hash in state
> > OP_SHA256STREAM n [item] [state] -> [state]
> > // Finalize
> > OP_SHA256STREAM (-2) [state] -> [Hash]
> >
> > <-1> OP_SHA256STREAM <tag> <subnode 2> <subnode 3> <3> OP_SHA256STREAM
> <-2> OP_SHA256STREAM
> >
> > Or it coul
> >
>
> This seems a good idea.
>
> Though it brings up the age-old tension between:
>
> * Generically-useable components, but due to generalization are less
> efficient.
> * Specific-use components, which are efficient, but which may end up not
> being useable in the future.
>
> In particular, `OP_SHA256STREAM` would no longer be useable if SHA256
> eventually is broken, while the `OP_CAT` will still be useable in the
> indefinite future.
> In the future a new hash function can simply be defined and the same
> technique with `OP_CAT` would still be useable.
>
>
> Regards,
> ZmnSCPxj
>
> > --
> > @JeremyRubin
> >
> > On Thu, Oct 3, 2019 at 8:04 PM Ethan Heilman <eth3rs@gmail.com> wrote:
> >
> > > I hope you are having an great afternoon ZmnSCPxj,
> > >
> > > You make an excellent point!
> > >
> > > I had thought about doing the following to tag nodes
> > >
> > > || means OP_CAT
> > >
> > > `node = SHA256(type||SHA256(data))`
> > > so a subnode would be
> > > `subnode1 = SHA256(1||SHA256(subnode2||subnode3))`
> > > and a leaf node would be
> > > `leafnode = SHA256(0||SHA256(leafdata))`
> > >
> > > Yet, I like your idea better. Increasing the size of the two inputs to
> > > OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowable
> > > size of object on the stack seems sensible and also doesn't special
> > > case the logic of OP_CAT.
> > >
> > > It would also increase performance. SHA256(tag||subnode2||subnode3)
> > > requires 2 compression function calls whereas
> > > SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3 compression
> > > function calls (due to padding).
> > >
> > > >Or we could implement tagged SHA256 as a new opcode...
> > >
> > > I agree that tagged SHA256 as an op code that would certainty be
> > > useful, but OP_CAT provides far more utility and is a simpler change.
> > >
> > > Thanks,
> > > Ethan
> > >
> > > On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj <ZmnSCPxj@protonmail.com>
> wrote:
> > > >
> > > > Good morning Ethan,
> > > >
> > > >
> > > > > To avoid derailing the NO_INPUT conversation, I have changed the
> > > > > subject to OP_CAT.
> > > > >
> > > > > Responding to:
> > > > > """
> > > > >
> > > > > - `SIGHASH` flags attached to signatures are a misdesign, sadly
> > > > > retained from the original BitCoin 0.1.0 Alpha for Windows
> design, on
> > > > > par with:
> > > > > [..]
> > > > >
> > > > > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > > > [..]
> > > > > """
> > > > >
> > > > > OP_CAT is an extremely valuable op code. I understand why it
> was
> > > > > removed as the situation at the time with scripts was dire.
> However
> > > > > most of the protocols I've wanted to build on Bitcoin run into
> the
> > > > > limitation that stack values can not be concatenated. For
> instance
> > > > > TumbleBit would have far smaller transaction sizes if OP_CAT
> was
> > > > > supported in Bitcoin. If it happens to me as a researcher it is
> > > > > probably holding other people back as well. If I could wave a
> magic
> > > > > wand and turn on one of the disabled op codes it would be
> OP_CAT. Of
> > > > > course with the change that size of each concatenated value
> must be 64
> > > > > Bytes or less.
> > > >
> > > > Why 64 bytes in particular?
> > > >
> > > > It seems obvious to me that this 64 bytes is most suited for
> building Merkle trees, being the size of two SHA256 hashes.
> > > >
> > > > However we have had issues with the use of Merkle trees in Bitcoin
> blocks.
> > > > Specifically, it is difficult to determine if a hash on a Merkle
> node is the hash of a Merkle subnode, or a leaf transaction.
> > > > My understanding is that this is the reason for now requiring
> transactions to be at least 80 bytes.
> > > >
> > > > The obvious fix would be to prepend the type of the hashed object,
> i.e. add at least one byte to determine this type.
> > > > Taproot for example uses tagged hash functions, with a different tag
> for leaves, and tagged hashes are just
> prepend-this-32-byte-constant-twice-before-you-SHA256.
> > > >
> > > > This seems to indicate that to check merkle tree proofs, an `OP_CAT`
> with only 64 bytes max output size would not be sufficient.
> > > >
> > > > Or we could implement tagged SHA256 as a new opcode...
> > > >
> > > > Regards,
> > > > ZmnSCPxj
> > > >
> > > >
> > > > >
> > > > > On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
> > > > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > >
> > > > >
> > > > > > Good morning lists,
> > > > > > Let me propose the below radical idea:
> > > > > >
> > > > > > - `SIGHASH` flags attached to signatures are a misdesign,
> sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on
> par with:
> > > > > > - 1 RETURN
> > > > > > - higher-`nSequence` replacement
> > > > > > - DER-encoded pubkeys
> > > > > > - unrestricted `scriptPubKey`
> > > > > > - Payee-security-paid-by-payer (i.e. lack of P2SH)
> > > > > > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > > > > - transaction malleability
> > > > > > - probably many more
> > > > > >
> > > > > > So let me propose the more radical excision, starting with
> SegWit v1:
> > > > > >
> > > > > > - Remove `SIGHASH` from signatures.
> > > > > > - Put `SIGHASH` on public keys.
> > > > > >
> > > > > > Public keys are now encoded as either 33-bytes (implicit
> `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type,
> followed by pubkey coordinate).
> > > > > > `OP_CHECKSIG` and friends then look at the public key to
> determine sighash algorithm rather than the signature.
> > > > > > As we expect public keys to be indirectly committed to on every
> output `scriptPubKey`, this is automatically output tagging to allow
> particular `SIGHASH`.
> > > > > > However, we can then utilize the many many ways to hide public
> keys away until they are needed, exemplified in MAST-inside-Taproot.
> > > > > > I propose also the addition of the opcode:
> > > > > >
> > > > > > <sighash> <pubkey> OP_SETPUBKEYSIGHASH
> > > > > >
> > > > > >
> > > > > > - `sighash` must be one byte.
> > > > > > - `pubkey` may be the special byte `0x1`, meaning "just use
> the Taproot internal pubkey".
> > > > > > - `pubkey` may be 33-byte public key, in which case the
> `sighash` byte is just prepended to it.
> > > > > > - `pubkey` may be 34-byte public key with sighash, in which
> case the first byte is replaced with `sighash` byte.
> > > > > > - If `sighash` is `0x00` then the result is a 33-byte public
> key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit.
> > > > > >
> > > > > > This retains the old feature where the sighash is selected at
> time-of-spending rather than time-of-payment.
> > > > > > This is done by using the script:
> > > > > >
> > > > > > <pubkey> OP_SETPUBKEYSIGHASH OP_CHECKSIG
> > > > > >
> > > > > >
> > > > > > Then the sighash can be put in the witness stack after the
> signature, letting the `SIGHASH` flag be selected at time-of-signing, but
> only if the SCRIPT specifically is formed to do so.
> > > > > > This is malleability-safe as the signature still commits to the
> `SIGHASH` it was created for.
> > > > > > However, by default, public keys will not have an attached
> `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default
> non-`SIGHASH_ALL`).
> > > > > > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`,
> as they are allowed only if the output specifically says they are allowed.
> > > > > > Would this not be a superior solution?
> > > > > > Regards,
> > > > > > ZmnSCPxj
> > > > > >
> > > > > > bitcoin-dev mailing list
> > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > >
> > > > > Lightning-dev mailing list
> > > > > Lightning-dev@lists.linuxfoundation.org
> > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > > >
> > > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--000000000000b7dbbf059419efb4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Good point -- in our disc=
ussion, we called it OP_FFS -- Fold Functional Stream, and it could be init=
ialized with a different integer to select for different functions. Therefo=
re the stream processing opcodes would be generic, but extensible.<br clear=
=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartma=
il=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.co=
m/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter=
.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 4=
, 2019 at 12:00 AM ZmnSCPxj via Lightning-dev <<a href=3D"mailto:lightni=
ng-dev@lists.linuxfoundation.org">lightning-dev@lists.linuxfoundation.org</=
a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Go=
od morning Jeremy,<br>
<br>
> Awhile back, Ethan and I discussed having, rather than OP_CAT, an OP_S=
HA256STREAM that uses the streaming properties of a SHA256 hash function to=
allow concatenation of an unlimited amount of data, provided the only use =
is to hash it.<br>
><br>
> You can then use it perhaps as follows:<br>
><br>
> // start a new hash with item<br>
> OP_SHA256STREAM=C2=A0 (-1) -> [state]<br>
> // Add item to the hash in state<br>
> OP_SHA256STREAM n [item] [state] -> [state]<br>
> // Finalize<br>
> OP_SHA256STREAM (-2) [state] -> [Hash]<br>
><br>
> <-1> OP_SHA256STREAM <tag> <subnode 2> <subnode 3=
> <3> OP_SHA256STREAM <-2> OP_SHA256STREAM<br>
><br>
> Or it coul<br>
><br>
<br>
This seems a good idea.<br>
<br>
Though it brings up the age-old tension between:<br>
<br>
* Generically-useable components, but due to generalization are less effici=
ent.<br>
* Specific-use components, which are efficient, but which may end up not be=
ing useable in the future.<br>
<br>
In particular, `OP_SHA256STREAM` would no longer be useable if SHA256 event=
ually is broken, while the `OP_CAT` will still be useable in the indefinite=
future.<br>
In the future a new hash function can simply be defined and the same techni=
que with `OP_CAT` would still be useable.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
> --<br>
> @JeremyRubin<br>
><br>
> On Thu, Oct 3, 2019 at 8:04 PM Ethan Heilman <<a href=3D"mailto:eth=
3rs@gmail.com" target=3D"_blank">eth3rs@gmail.com</a>> wrote:<br>
><br>
> > I hope you are having an great afternoon ZmnSCPxj,<br>
> ><br>
> > You make an excellent point!<br>
> ><br>
> > I had thought about doing the following to tag nodes<br>
> ><br>
> > || means OP_CAT<br>
> ><br>
> > `node =3D SHA256(type||SHA256(data))`<br>
> > so a subnode would be<br>
> > `subnode1 =3D SHA256(1||SHA256(subnode2||subnode3))`<br>
> > and a leaf node would be<br>
> > `leafnode =3D SHA256(0||SHA256(leafdata))`<br>
> ><br>
> > Yet, I like your idea better. Increasing the size of the two inpu=
ts to<br>
> > OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowa=
ble<br>
> > size of object on the stack seems sensible and also doesn't s=
pecial<br>
> > case the logic of OP_CAT.<br>
> ><br>
> > It would also increase performance. SHA256(tag||subnode2||subnode=
3)<br>
> > requires 2 compression function calls whereas<br>
> > SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3D3 compressio=
n<br>
> > function calls (due to padding).<br>
> ><br>
> > >Or we could implement tagged SHA256 as a new opcode...<br>
> ><br>
> > I agree that tagged SHA256 as an op code that would certainty be<=
br>
> > useful, but OP_CAT provides far more utility and is a simpler cha=
nge.<br>
> ><br>
> > Thanks,<br>
> > Ethan<br>
> ><br>
> > On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj <<a href=3D"mailto:Zmn=
SCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>> wro=
te:<br>
> > ><br>
> > > Good morning Ethan,<br>
> > ><br>
> > ><br>
> > > > To avoid derailing the NO_INPUT conversation, I have ch=
anged the<br>
> > > > subject to OP_CAT.<br>
> > > ><br>
> > > > Responding to:<br>
> > > > """<br>
> > > ><br>
> > > > -=C2=A0 =C2=A0`SIGHASH` flags attached to signatures ar=
e a misdesign, sadly<br>
> > > >=C2=A0 =C2=A0 =C2=A0retained from the original BitCoin 0=
.1.0 Alpha for Windows design, on<br>
> > > >=C2=A0 =C2=A0 =C2=A0par with:<br>
> > > >=C2=A0 =C2=A0 =C2=A0[..]<br>
> > > ><br>
> > > > -=C2=A0 =C2=A0`OP_CAT` and `OP_MULT` and `OP_ADD` and f=
riends<br>
> > > >=C2=A0 =C2=A0 =C2=A0[..]<br>
> > > >=C2=A0 =C2=A0 =C2=A0"""<br>
> > > ><br>
> > > >=C2=A0 =C2=A0 =C2=A0OP_CAT is an extremely valuable op c=
ode. I understand why it was<br>
> > > >=C2=A0 =C2=A0 =C2=A0removed as the situation at the time=
with scripts was dire. However<br>
> > > >=C2=A0 =C2=A0 =C2=A0most of the protocols I've wante=
d to build on Bitcoin run into the<br>
> > > >=C2=A0 =C2=A0 =C2=A0limitation that stack values can not=
be concatenated. For instance<br>
> > > >=C2=A0 =C2=A0 =C2=A0TumbleBit would have far smaller tra=
nsaction sizes if OP_CAT was<br>
> > > >=C2=A0 =C2=A0 =C2=A0supported in Bitcoin. If it happens =
to me as a researcher it is<br>
> > > >=C2=A0 =C2=A0 =C2=A0probably holding other people back a=
s well. If I could wave a magic<br>
> > > >=C2=A0 =C2=A0 =C2=A0wand and turn on one of the disabled=
op codes it would be OP_CAT. Of<br>
> > > >=C2=A0 =C2=A0 =C2=A0course with the change that size of =
each concatenated value must be 64<br>
> > > >=C2=A0 =C2=A0 =C2=A0Bytes or less.<br>
> > ><br>
> > > Why 64 bytes in particular?<br>
> > ><br>
> > > It seems obvious to me that this 64 bytes is most suited for=
building Merkle trees, being the size of two SHA256 hashes.<br>
> > ><br>
> > > However we have had issues with the use of Merkle trees in B=
itcoin blocks.<br>
> > > Specifically, it is difficult to determine if a hash on a Me=
rkle node is the hash of a Merkle subnode, or a leaf transaction.<br>
> > > My understanding is that this is the reason for now requirin=
g transactions to be at least 80 bytes.<br>
> > ><br>
> > > The obvious fix would be to prepend the type of the hashed o=
bject, i.e. add at least one byte to determine this type.<br>
> > > Taproot for example uses tagged hash functions, with a diffe=
rent tag for leaves, and tagged hashes are just prepend-this-32-byte-consta=
nt-twice-before-you-SHA256.<br>
> > ><br>
> > > This seems to indicate that to check merkle tree proofs, an =
`OP_CAT` with only 64 bytes max output size would not be sufficient.<br>
> > ><br>
> > > Or we could implement tagged SHA256 as a new opcode...<br>
> > ><br>
> > > Regards,<br>
> > > ZmnSCPxj<br>
> > ><br>
> > ><br>
> > > ><br>
> > > >=C2=A0 =C2=A0 =C2=A0On Tue, Oct 1, 2019 at 10:04 PM ZmnS=
CPxj via bitcoin-dev<br>
> > > >=C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a> wrote:<br>
> > > ><br>
> > > ><br>
> > > > > Good morning lists,<br>
> > > > > Let me propose the below radical idea:<br>
> > > > ><br>
> > > > > -=C2=A0 =C2=A0`SIGHASH` flags attached to signatur=
es are a misdesign, sadly retained from the original BitCoin 0.1.0 Alpha fo=
r Windows design, on par with:<br>
> > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A01 RETURN<br>
> > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0higher-`nSequence=
` replacement<br>
> > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0DER-encoded pubke=
ys<br>
> > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0unrestricted `scr=
iptPubKey`<br>
> > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0Payee-security-pa=
id-by-payer (i.e. lack of P2SH)<br>
> > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0`OP_CAT` and `OP_=
MULT` and `OP_ADD` and friends<br>
> > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0transaction malle=
ability<br>
> > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0probably many mor=
e<br>
> > > > ><br>
> > > > > So let me propose the more radical excision, start=
ing with SegWit v1:<br>
> > > > ><br>
> > > > > -=C2=A0 =C2=A0Remove `SIGHASH` from signatures.<br=
>
> > > > > -=C2=A0 =C2=A0Put `SIGHASH` on public keys.<br>
> > > > ><br>
> > > > > Public keys are now encoded as either 33-bytes (im=
plicit `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type,=
followed by pubkey coordinate).<br>
> > > > > `OP_CHECKSIG` and friends then look at the public =
key to determine sighash algorithm rather than the signature.<br>
> > > > > As we expect public keys to be indirectly committe=
d to on every output `scriptPubKey`, this is automatically output tagging t=
o allow particular `SIGHASH`.<br>
> > > > > However, we can then utilize the many many ways to=
hide public keys away until they are needed, exemplified in MAST-inside-Ta=
proot.<br>
> > > > > I propose also the addition of the opcode:<br>
> > > > ><br>
> > > > >=C2=A0 =C2=A0 =C2=A0<sighash> <pubkey> =
OP_SETPUBKEYSIGHASH<br>
> > > > ><br>
> > > > ><br>
> > > > > -=C2=A0 =C2=A0`sighash` must be one byte.<br>
> > > > > -=C2=A0 =C2=A0`pubkey` may be the special byte `0x=
1`, meaning "just use the Taproot internal pubkey".<br>
> > > > > -=C2=A0 =C2=A0`pubkey` may be 33-byte public key, =
in which case the `sighash` byte is just prepended to it.<br>
> > > > > -=C2=A0 =C2=A0`pubkey` may be 34-byte public key w=
ith sighash, in which case the first byte is replaced with `sighash` byte.<=
br>
> > > > > -=C2=A0 =C2=A0If `sighash` is `0x00` then the resu=
lt is a 33-byte public key (the sighash byte is removed) i.e. `SIGHASH_ALL`=
implicit.<br>
> > > > ><br>
> > > > > This retains the old feature where the sighash is =
selected at time-of-spending rather than time-of-payment.<br>
> > > > > This is done by using the script:<br>
> > > > ><br>
> > > > >=C2=A0 =C2=A0 =C2=A0<pubkey> OP_SETPUBKEYSIGH=
ASH OP_CHECKSIG<br>
> > > > ><br>
> > > > ><br>
> > > > > Then the sighash can be put in the witness stack a=
fter the signature, letting the `SIGHASH` flag be selected at time-of-signi=
ng, but only if the SCRIPT specifically is formed to do so.<br>
> > > > > This is malleability-safe as the signature still c=
ommits to the `SIGHASH` it was created for.<br>
> > > > > However, by default, public keys will not have an =
attached `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default=
non-`SIGHASH_ALL`).<br>
> > > > > This removes the problems with `SIGHASH_NONE` `SIG=
HASH_SINGLE`, as they are allowed only if the output specifically says they=
are allowed.<br>
> > > > > Would this not be a superior solution?<br>
> > > > > Regards,<br>
> > > > > ZmnSCPxj<br>
> > > > ><br>
> > > > > bitcoin-dev mailing list<br>
> > > > > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> > > > > <a href=3D"https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists=
.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
> > > ><br>
> > > > Lightning-dev mailing list<br>
> > > > <a href=3D"mailto:Lightning-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
> > > > <a href=3D"https://lists.linuxfoundation.org/mailman/li=
stinfo/lightning-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
> > ><br>
> > ><br>
> > _______________________________________________<br>
> > Lightning-dev mailing list<br>
> > <a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=
=3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lig=
htning-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundat=
ion.org/mailman/listinfo/lightning-dev</a><br>
<br>
<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>
--000000000000b7dbbf059419efb4--
|
