path: root/cb/d05a00d947563525d2c7eaa6ddd4ec2a8dcd3a

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--