From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <7b8f0cba-1f73-4aa8-8c01-4a7170af1424n@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 =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 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 >>> >>> . >>> >> --=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
Laolu,

Let me know if I miss responding to = any points:

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

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.
=
In our case, we'd rather not have a common paradigm have m= alleability, if using an unhashed tweak for some reason.

Cheers,

Jeremy

On Thursday= , September 4, 2025 at 8:43:12=E2=80=AFPM UTC-4 Olaoluwa Osuntokun wrote:
> Second, why fail if the passed scalar is greater than the curv= e order vs
> just reducing modulo the order and using that value?
=
Thinking about it a bit more, I think= this is totally the right decision and
makes a lot of sense.

Th= e probability that a random sha256 output will be greater than the orderof the curve is ~1/2^128, and is something that any key generation code or=
other related application needs to deal with.

Eliminating all s= ources of malleability in newly proposed op codes is
important as it ser= ves to increase the binding of transactions w.r.t blocks.

Stronger = binding of transactions to blocks post segwit (otherwise possible
to mal= leate transactions, causing the witness commitment validation to fail
fo= r an otherwise valid block), helps to mitigate a class of active
relay i= mpediment attacks and minimizes front-running/extractable value.

-- = Laolu

On Wed, Sep 3, 2025 at 7:38=E2=80=AFPM Olaoluwa Osuntokun &= lt;lao...@gmail.com> wrot= e:

Hi Jeremy,

Cool idea, I had a similar one mys= elf a while back. Shows that great chefs
think alike ;). Here're som= e questions that came to mind as I was reviewing
the doc.

First, = why accept only x-only keys?

From the PoV of Bitcoin Script today, = they aren't used anywhere within the
execution environment. They als= o add some complexity to protocols that need
to accept them as input for= further manipulation. They are indeed used for
Taproot output public ke= ys, but those keys don't ever make their way down
into Script as an = op code argument.

The musig2 BIP originally accepted x-only keys as = input, but was switched to
instead accept normal compressed public keys = in version v0.8.0 [1]. The
switch over enabled some simplifications in t= he BIP, as it enabled
eliminating one of the accumulator variables. For = more details, see the
discussion that led to this change [2].

Thi= s comment from Tim resonates with my experience wrangling with bugs
intr= oduced by improper/implicit handling of x-only keys over the years:
> Sigh yeah, x-only keys save a byte on chain but it seems the price we= pay
> is a high engineering complexity. I think it's fair to say= that noone had
> really anticipated this [1].

Second, why fai= l if the passed scalar is greater than the curve order vs
just reducing = modulo the order and using that value?

This would mean that in some= cases, the direct value of a hash can't be used
as the scalar tweak= . The probability of this happening for sha256 outputs is
very low, but = it presents developers with yet another thing to keep in mind
in order t= o use the op code safely.

You bring up the point that this allows th= e side stepping of a new source of
witness malleability, but in the year= of Satoshi 16 (2025), aside from relay
nuisance shenanigans, is this so= mething developers still need to care about?

Third, why allocate a c= ost of 50 op cost vs something lower to better
account for the differenc= e in operation vs normal `OP_CHECKSIG`?

Validating a BIP-340 signat= ure requires an extra scalar base mult
(ignoring the Strauss-Shamir tric= k 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/jonasni= ck/bips/pull/37
[2]: https://github.com/jonasnick/bips/issues/32
<= /div>

On Sat, Aug 23, 2025 at 10:36=E2=80=AFAM jeremy <jeremy....@gmail.com> wrote:
Hi all,
<= br>
I've made a draft BIP writeup of an (often discussed) sim= ple opcode, OP_TWEAKADD, deployable as an OP_SUCCESSx upgrade.
https://= github.com/bitcoin/bips/pull/1944

This opcode is rel= atively simple. The main design choices are:

1) Ve= rify v.s. Push semantics -- Push, for succinctness on-chain
2) Ar= gument order -- Key on top, for tweak in witness
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.

Feedback = and discussion are welcome.

Best,
Jeremy

[^1] OP_SHA256 in these e= xample prevents key-cancellation.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf= 0n%40googlegroups.com.

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