summaryrefslogtreecommitdiff
path: root/cb/d05a00d947563525d2c7eaa6ddd4ec2a8dcd3a
blob: 9c99e3ff040b35cc28f91e1ed68c1229123ac334 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
Delivery-date: Sun, 07 Sep 2025 03:41:07 -0700
Received: from mail-ot1-f57.google.com ([209.85.210.57])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD7O3WHWY4JRBNOC6XCQMGQETZDCHLY@googlegroups.com>)
	id 1uvCpW-0007Mc-28
	for bitcoindev@gnusha.org; Sun, 07 Sep 2025 03:41:07 -0700
Received: by mail-ot1-f57.google.com with SMTP id 46e09a7af769-74be52f5459sf1899700a34.1
        for <bitcoindev@gnusha.org>; Sun, 07 Sep 2025 03:41:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1757241657; x=1757846457; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=5bH3pTfdisCwnxVTZSzZP99KHESzcuNKjw+ZteTqq1c=;
        b=fbLmQEpiS/XlAzZS51pLc6Q7nZ7T/e9CMjzw6w0Gn8PlNbCjV3s5D+1wovONVIqcom
         l3RxubYuEhJeiCAMu3lsMHIuZQdcdlqG8gLM+Da6Ybjunp78PWfa1gBOCGyMeP9iT6Bk
         +iU33AZiZFJgcYLzC2uqmgOf5rVpp4mStAD3uGMSECb0Bp9MS2YobdCvLdfJVUQD31zf
         q9aY/iDmWT+ng28aNMBpWp7yUOCFaBFqPXFfD+WGqgUt+2vi2dCH3WipkClnbc5oUOL3
         b2fqJ1gMLajM1ybuNS2IifWXhRAVWjOR92Oz0MGsC1Y7QtS01Y6eHddqgYUMUd2rUN7T
         ynOA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757241657; x=1757846457; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=5bH3pTfdisCwnxVTZSzZP99KHESzcuNKjw+ZteTqq1c=;
        b=QQKDEJjD7a97NgYudZJvUDoFOGTxn1gNE1G70MLsOTEF/wX89ITVBO31Cm5b6puiNb
         Lg6yVvR0pyw3RTcbfWrHgm0Xd8RQzBQUcmkqO986hBTOw13NyHU/2UtDxtLcODBJKzjj
         vBdtN57ru6kjdOBQi91cjnRxY/PKMBPcDdKIL40OcCkDcKHMSfnXRzSgy+8b2J4FFAok
         DxyJAuXZRiu66ZrKreI55cSHDPj5xu1WLcFqed5o8lgSwn47gmEJx8/sOgvs1hWFg8a4
         AVoBhETQlYHcV9+6g2hdRGtZa7dYe9iFn67k2bzuSgQPxxIhtQSsRDTPHtuXZRczQvFi
         wTPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757241657; x=1757846457;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=5bH3pTfdisCwnxVTZSzZP99KHESzcuNKjw+ZteTqq1c=;
        b=HixMd0olVm8738wXWa+evDhiqjRmGV92zJAnWA/tX5e3z2RYH9TeFbGZHUzmTQLGVt
         b5hrQP2P2Rxp4Zxw0WhsNpgqvxL2QguF5iCJL5dQSSWybqh3jU/hm6X3I3MhRsf3WrHQ
         8c0ciDHsbH4ijrkqR8/WLAWp7fD72TYsxfA+dIT8dzmQGQo8QUT5wbq0KBJ6qkZs5yQt
         TS705Ad7ziMbnxBxaKOLEZGKzvvpr90kNpJaIqrSKicqzwgi8bdDP1rrKKcgPnRYx7JU
         DUcyEWh/ayL/QRZA1xJ8o0B+xqWU6TkoEX00EvpqIr08hLXuvwCKP6HzsVDJsRwhKNTa
         6OYg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXNdny/lU7snrg6ZbK/x6+BpA+hoWTvdJOC2pO4SAauiKyPYvnOtBO9D47GEM1LYa7EuMgmDP6iJhj5@gnusha.org
X-Gm-Message-State: AOJu0YwLw0QZWtTjTHksfrQp+PeUzLN369AF64rPfuEAd7pZ0OOUoeFy
	x5X0H8TNFPyiqIf8o6fOGbLlwoVLJA/6KPj+ciRgHgSNNUOF/dwJADR/
X-Google-Smtp-Source: AGHT+IFnP3bBFFBV5w2lWXfar+porLcjoksA+0CLGENrKRFgs0kX94GNtDSJGzynhsKuEaRGllpchQ==
X-Received: by 2002:a05:6830:3590:b0:74b:5bfc:7b6b with SMTP id 46e09a7af769-74c7192d3fcmr2046043a34.13.1757241657482;
        Sun, 07 Sep 2025 03:40:57 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARHlJd7lU+xxP1z9jActAe1AntPf/n8ypZSgdTE66zZq14AxDQ==
Received: by 2002:a05:6871:e4c:b0:30b:b8a1:c8d0 with SMTP id
 586e51a60fabf-3212724a566ls647972fac.1.-pod-prod-07-us; Sun, 07 Sep 2025
 03:40:53 -0700 (PDT)
X-Received: by 2002:a05:6808:1301:b0:438:37fc:1e01 with SMTP id 5614622812f47-43b29a4c365mr1890453b6e.13.1757241653351;
        Sun, 07 Sep 2025 03:40:53 -0700 (PDT)
Received: by 2002:a05:690c:dc7:b0:720:768:1935 with SMTP id 00721157ae682-725df629d01ms7b3;
        Sat, 6 Sep 2025 14:27:56 -0700 (PDT)
X-Received: by 2002:a05:690e:154d:20b0:5fa:b7bf:c5bc with SMTP id 956f58d0204a3-6102135dd37mr2276436d50.4.1757194075775;
        Sat, 06 Sep 2025 14:27:55 -0700 (PDT)
Date: Sat, 6 Sep 2025 14:27:55 -0700 (PDT)
From: jeremy <jeremy.l.rubin@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <7b8f0cba-1f73-4aa8-8c01-4a7170af1424n@googlegroups.com>
In-Reply-To: <CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR+PRGS4ZEJsTQ@mail.gmail.com>
References: <bc9ff794-b11e-47bc-8840-55b2bae22cf0n@googlegroups.com>
 <CAO3Pvs-TMwQuxa2JJq8MY==G0nFsqrTis6sPHLayxZOqPuvBtQ@mail.gmail.com>
 <CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR+PRGS4ZEJsTQ@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] OP_TWEAKADD
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_8652_1814170993.1757194075532"
X-Original-Sender: Jeremy.L.Rubin@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_8652_1814170993.1757194075532
Content-Type: multipart/alternative; 
	boundary="----=_Part_8653_816599844.1757194075532"

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

Laolu,

Let me know if I miss responding to any points:

I think it'd be fine to down-cost the TWEAKADD to something lower, but I'm=
=20
not sure on the exact amount I'd recommend, since there is a link between=
=20
amount of data and number of ops you can do, so perhaps worth thinking=20
(e.g., if a really nice use case we'd want to do 100 of in a row for some=
=20
reason, and it uses 10 script bytes, 10 budget might be good, and it would=
=20
be annoying if we made it 20... OTOH there is a real DoS concern with=20
chaining many of these if too cheap).

Generally IIUC, the reason key generation code has to check this, is=20
because you could be getting entropy from a weird source. It should be=20
difficult to ever hit this with a SHA256 hashed value. E.g., something like=
=20
the current network hashrate dedicated to finding an invalid tweak for 10=
=20
billion years, and you would expect to find a single invalid tweak.

In our case, we'd rather not have a common paradigm have malleability, if=
=20
using an unhashed tweak for some reason.

Cheers,

Jeremy

On Thursday, September 4, 2025 at 8:43:12=E2=80=AFPM UTC-4 Olaoluwa Osuntok=
un wrote:

> > Second, why fail if the passed scalar is greater than the curve order v=
s
> > just reducing modulo the order and using that value?
>
> Thinking about it a bit more, I think this is totally the right decision=
=20
> and
> makes a lot of sense.=20
>
> The probability that a random sha256 output will be greater than the orde=
r
> of the curve is ~1/2^128, and is something that any key generation code o=
r
> other related application needs to deal with.=20
>
> Eliminating all sources of malleability in newly proposed op codes is
> important as it serves to increase the binding of transactions w.r.t=20
> blocks.=20
>
> Stronger binding of transactions to blocks post segwit (otherwise possibl=
e
> to malleate transactions, causing the witness commitment validation to fa=
il
> for an otherwise valid block), helps to mitigate a class of active
> relay impediment attacks and minimizes front-running/extractable value.
>
> -- Laolu
>
> On Wed, Sep 3, 2025 at 7:38=E2=80=AFPM Olaoluwa Osuntokun <lao...@gmail.c=
om>=20
> wrote:
>
>>
>> Hi Jeremy,
>>
>> Cool idea, I had a similar one myself a while back. Shows that great che=
fs
>> think alike ;). Here're some questions that came to mind as I was=20
>> reviewing
>> the doc.
>>
>> First, why accept only x-only keys?=20
>>
>> From the PoV of Bitcoin Script today, they aren't used anywhere within t=
he
>> execution environment. They also add some complexity to protocols that=
=20
>> need
>> to accept them as input for further manipulation. They are indeed used f=
or
>> Taproot output public keys, but those keys don't ever make their way dow=
n
>> into Script as an op code argument.
>>
>> The musig2 BIP originally accepted x-only keys as input, but was switche=
d=20
>> to
>> instead accept normal compressed public keys in version v0.8.0 [1]. The
>> switch over enabled some simplifications in the BIP, as it enabled
>> eliminating one of the accumulator variables. For more details, see the
>> discussion that led to this change [2].
>>
>> This comment from Tim resonates with my experience wrangling with bugs
>> introduced by improper/implicit handling of x-only keys over the years:=
=20
>>
>> > Sigh yeah, x-only keys save a byte on chain but it seems the price we=
=20
>> pay
>> > is a high engineering complexity. I think it's fair to say that noone=
=20
>> had
>> > really anticipated this [1].
>>
>> Second, why fail if the passed scalar is greater than the curve order vs
>> just reducing modulo the order and using that value?=20
>>
>> This would mean that in some cases, the direct value of a hash can't be=
=20
>> used
>> as the scalar tweak. The probability of this happening for sha256 output=
s=20
>> is
>> very low, but it presents developers with yet another thing to keep in=
=20
>> mind
>> in order to use the op code safely.
>>
>> You bring up the point that this allows the side stepping of a new sourc=
e=20
>> of
>> witness malleability, but in the year of Satoshi 16 (2025), aside from=
=20
>> relay
>> nuisance shenanigans, is this something developers still need to care=20
>> about?
>>
>> Third, why allocate a cost of 50 op cost vs something lower to better
>> account for the difference in operation vs normal `OP_CHECKSIG`?=20
>>
>> Validating a BIP-340 signature requires an extra scalar base mult
>> (ignoring the Strauss-Shamir trick for double scalar mult for a sec) vs
>> `OP_TWEAKADD` as it's defined in your draft BIP. As a result, one could
>> argue that the op code should have a lower cost vs `OP_CHECKSIG`.
>>
>> -- Laolu
>>
>> [1]: https://github.com/jonasnick/bips/pull/37=20
>> [2]: https://github.com/jonasnick/bips/issues/32
>>
>> On Sat, Aug 23, 2025 at 10:36=E2=80=AFAM jeremy <jeremy....@gmail.com> w=
rote:
>>
>>> Hi all,
>>>
>>> I've made a draft BIP writeup of an (often discussed) simple opcode,=20
>>> OP_TWEAKADD, deployable as an OP_SUCCESSx upgrade.
>>>
>>> https://github.com/bitcoin/bips/pull/1944
>>>
>>> This opcode is relatively simple. The main design choices are:
>>>
>>> 1) Verify v.s. Push semantics -- Push, for succinctness on-chain
>>> 2) Argument order -- Key on top, for tweak in witness
>>> 3) Plain tweak or something else -- Plain tweak, if hashing is desirabl=
e=20
>>> the user can do it. The most flexible is to do a plain tweak. Future wo=
rk=20
>>> could add TapTree opcodes to construct taproot tweaks.
>>>
>>> Feedback and discussion are welcome.
>>>
>>> Best,
>>>
>>> Jeremy
>>>
>>> [^1] OP_SHA256 in these example prevents key-cancellation.
>>>
>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to bitcoindev+...@googlegroups.com.
>>> To view this discussion visit=20
>>> https://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55=
b2bae22cf0n%40googlegroups.com=20
>>> <https://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-5=
5b2bae22cf0n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>> .
>>>
>>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
7b8f0cba-1f73-4aa8-8c01-4a7170af1424n%40googlegroups.com.

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

<div>Laolu,</div><div><br /></div><div>Let me know if I miss responding to =
any points:</div><div><br /></div>I think it'd be fine to down-cost the TWE=
AKADD to something lower, but I'm not sure on the exact amount I'd recommen=
d, since there is a link between amount of data and number of ops you can d=
o, so perhaps worth thinking (e.g., if a really nice use case we'd want to =
do 100 of in a row for some reason, and it uses 10 script bytes, 10 budget =
might be good, and it would be annoying if we made it 20... OTOH there is a=
 real DoS concern with chaining many of these if too cheap).<div><br /></di=
v><div>Generally IIUC, the reason key generation code has to check this, is=
 because you could be getting entropy from a weird source. It should be dif=
ficult to ever hit this with a SHA256 hashed value. E.g., something like th=
e current network hashrate dedicated to finding an invalid tweak for 10 bil=
lion years, and you would expect to find a single invalid tweak.</div><div>=
<br /></div><div>In our case, we'd rather not have a common paradigm have m=
alleability, if using an unhashed tweak for some reason.</div><div><br /></=
div><div>Cheers,</div><div><br /></div><div>Jeremy</div><div><br /></div><d=
iv class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Thursday=
, September 4, 2025 at 8:43:12=E2=80=AFPM UTC-4 Olaoluwa Osuntokun wrote:<b=
r/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; bo=
rder-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"lt=
r"><div>&gt; Second, why fail if the passed scalar is greater than the curv=
e order vs<br>&gt; just reducing modulo the order and using that value?<br>=
<br></div></div><div dir=3D"ltr"><div>Thinking about it a bit more, I think=
 this is totally the right decision and<br>makes a lot of sense. <br><br>Th=
e probability that a random sha256 output will be greater than the order<br=
>of the curve is ~1/2^128, and is something that any key generation code or=
<br>other related application needs to deal with. <br><br>Eliminating all s=
ources of malleability in newly proposed op codes is<br>important as it ser=
ves to increase the binding of transactions w.r.t blocks. <br><br>Stronger =
binding of transactions to blocks post segwit (otherwise possible<br>to mal=
leate transactions, causing the witness commitment validation to fail<br>fo=
r an otherwise valid block), helps to mitigate a class of active<br>relay i=
mpediment attacks and minimizes front-running/extractable value.<br><br>-- =
Laolu<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Sep 3, 2025 at 7:38=E2=80=AFPM Olaoluwa Osuntokun &=
lt;<a href data-email-masked rel=3D"nofollow">lao...@gmail.com</a>&gt; wrot=
e:<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"><div dir=3D"l=
tr"><div><br clear=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signa=
ture"><div dir=3D"ltr">Hi Jeremy,<br><br>Cool idea, I had a similar one mys=
elf a while back. Shows that great chefs<br>think alike ;). Here&#39;re som=
e questions that came to mind as I was reviewing<br>the doc.<br><br>First, =
why accept only x-only keys? <br><br>From the PoV of Bitcoin Script today, =
they aren&#39;t used anywhere within the<br>execution environment. They als=
o add some complexity to protocols that need<br>to accept them as input for=
 further manipulation. They are indeed used for<br>Taproot output public ke=
ys, but those keys don&#39;t ever make their way down<br>into Script as an =
op code argument.<br><br>The musig2 BIP originally accepted x-only keys as =
input, but was switched to<br>instead accept normal compressed public keys =
in version v0.8.0 [1]. The<br>switch over enabled some simplifications in t=
he BIP, as it enabled<br>eliminating one of the accumulator variables. For =
more details, see the<br>discussion that led to this change [2].<br><br>Thi=
s comment from Tim resonates with my experience wrangling with bugs<br>intr=
oduced by improper/implicit handling of x-only keys over the years: <br><br=
>&gt; Sigh yeah, x-only keys save a byte on chain but it seems the price we=
 pay<br>&gt; is a high engineering complexity. I think it&#39;s fair to say=
 that noone had<br>&gt; really anticipated this [1].<br><br>Second, why fai=
l if the passed scalar is greater than the curve order vs<br>just reducing =
modulo the order and using that value? <br><br>This would mean that in some=
 cases, the direct value of a hash can&#39;t be used<br>as the scalar tweak=
. The probability of this happening for sha256 outputs is<br>very low, but =
it presents developers with yet another thing to keep in mind<br>in order t=
o use the op code safely.<br><br>You bring up the point that this allows th=
e side stepping of a new source of<br>witness malleability, but in the year=
 of Satoshi 16 (2025), aside from relay<br>nuisance shenanigans, is this so=
mething developers still need to care about?<br><br>Third, why allocate a c=
ost of 50 op cost vs something lower to better<br>account for the differenc=
e in operation vs normal `OP_CHECKSIG`? <br><br>Validating a BIP-340 signat=
ure requires an extra scalar base mult<br>(ignoring the Strauss-Shamir tric=
k for double scalar mult for a sec) vs<br>`OP_TWEAKADD` as it&#39;s defined=
 in your draft BIP. As a result, one could<br>argue that the op code should=
 have a lower cost vs `OP_CHECKSIG`.<br><br>-- Laolu<br><br>[1]: <a href=3D=
"https://github.com/jonasnick/bips/pull/37" target=3D"_blank" rel=3D"nofoll=
ow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp=
s://github.com/jonasnick/bips/pull/37&amp;source=3Dgmail&amp;ust=3D17572795=
93493000&amp;usg=3DAOvVaw1dKHd2xHE_k4SeHKaTc4OJ">https://github.com/jonasni=
ck/bips/pull/37</a> <br>[2]: <a href=3D"https://github.com/jonasnick/bips/i=
ssues/32" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https:=
//www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/jonasnick/bips/issu=
es/32&amp;source=3Dgmail&amp;ust=3D1757279593493000&amp;usg=3DAOvVaw3yA3Hh-=
iSvSCcaxCO1l1ft">https://github.com/jonasnick/bips/issues/32</a><br></div><=
/div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Sat, Aug 23, 2025 at 10:36=E2=80=AFAM jeremy &lt;<a href data=
-email-masked rel=3D"nofollow">jeremy....@gmail.com</a>&gt; 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"><div>Hi all,</div><div><=
br></div><div>I&#39;ve made a draft BIP writeup of an (often discussed) sim=
ple opcode, OP_TWEAKADD, deployable as an OP_SUCCESSx upgrade.</div><div><b=
r></div><a href=3D"https://github.com/bitcoin/bips/pull/1944" target=3D"_bl=
ank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Den&amp;q=3Dhttps://github.com/bitcoin/bips/pull/1944&amp;source=3Dgmail&=
amp;ust=3D1757279593493000&amp;usg=3DAOvVaw09hgUqPQbLmypjc_w57kk0">https://=
github.com/bitcoin/bips/pull/1944</a><div><br></div><div>This opcode is rel=
atively simple. The main design choices are:</div><div><br></div><div>1) Ve=
rify v.s. Push semantics -- Push, for succinctness on-chain</div><div>2) Ar=
gument order -- Key on top, for tweak in witness</div><div>3) Plain tweak o=
r something else -- Plain tweak, if hashing is desirable the user can do it=
. The most flexible is to do a plain tweak. Future work could add TapTree o=
pcodes to construct taproot tweaks.</div><div><div><br></div><div>Feedback =
and discussion are welcome.<br></div><div><br></div><div>Best,</div><div><b=
r></div><div>Jeremy</div><div><br></div><div><div>[^1] OP_SHA256 in these e=
xample prevents key-cancellation.</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@googlegro=
ups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"nofollow" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gro=
ups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n%254=
0googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&amp;source=3Dgma=
il&amp;ust=3D1757279593493000&amp;usg=3DAOvVaw21QxH_8Cl132ZUA-pPBnbE">https=
://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf=
0n%40googlegroups.com</a>.<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/7b8f0cba-1f73-4aa8-8c01-4a7170af1424n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/7b8f0cba-1f73-4aa8-8c01-4a7170af1424n%40googlegroups.com</a>.<br />

------=_Part_8653_816599844.1757194075532--

------=_Part_8652_1814170993.1757194075532--