From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 04 Sep 2025 02:28:06 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uu6GD-0001Xi-MA for bitcoindev@gnusha.org; Thu, 04 Sep 2025 02:28:06 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3199dccf133sf771511fac.2 for ; Thu, 04 Sep 2025 02:28:05 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1756978079; cv=pass; d=google.com; s=arc-20240605; b=gkNfvjiNk4biXmwXmSOgPMpblj5XZJdNwSVDUFJBUECTUqxYh0DlTATbD0347mOP4h qjBqlH5ESf4LrzetLKtlwOHrvwwIGjzXsC4SJT9DsvV7OPmdMmOsEzpjg0m7Jpv/m4u1 HLsw8B0ARHiaoXMpiHl7bQGMI8XgkMYheOZ3Y8jxfZDWjjNQNYc/Krg74u9pMBQ9fRMx XRvwCG5THrPxfRLurfCqmKUbS8KVLS6kbTfpU0vF/O8zVWjTFgdmpJFqpc0peuekNbmA 6qUbtzavYnZQoz4+WHSmvC3LjprVzs2oWHVEuUOd1jpTkDbBre27l+/2UX3ET05Ol6+C TYVA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=CoDt2QjsB22mDnqAgv2enoxl7MijtXMRnaytbSmT7v4=; fh=kQ52vITp0t4oxNTwQjFMKtQVRjzzibB0JHgEa+GbDrM=; b=O4gjmYLK1YXdDdEA7mVt40PAFE0nLzw3ozWK+wyEFOYylyGaL+WoFIekq6q4B2z1Zo dEslwGVWDirWo8s/09zFrm6ng82+b5aOcneCho3m5X0VNeW10Vi5eQESgw4Mk9osg1k8 5ab0/sFNpP1fQea/0FWe97RbEJ3NJc7dH2nQfuJLTvNajEBVsTxO/ZRI2zQzP6RmXH1e 28PRbYB9LJEMjantsUrItnwYmIGRH8q3eujiviq8EcMGQE/ikROfx0aZdotxrLzAVhRI YWqQj0/ZsyT87hqiAmxLLgur7DFo0P8nDXufzbziQC8CpN92FxqxjABV8UPqgYAw+vMm /kcw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=D9LnJS0d; spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::112c as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1756978079; x=1757582879; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=CoDt2QjsB22mDnqAgv2enoxl7MijtXMRnaytbSmT7v4=; b=m645gWYJ82VxCL1Cc6LFqwVrj6JMipbOrJX8xly1d4gI9Q5Ob7ns0Tn0ixMa32xTHr Uw9IhxqscWz+ycsGPkQzoNi3c6T0po0+55r169lBQR03jvGDxmk1Z5d+hw+dtroofjTb PBdMV2QfIbsoTFURnfofUepcP0gXwtomOQtKW8NGho+h/KY3gDeACxIy9h2jtdmlZRgT Z1qCROVjt5FBmzHmcmr/YyKvBF+XGFh1TYIorug1zxDvP8heZ4UaWwXYj+g6qP3cViVy G0aZ7oDOhIyPAKewc874g54ZPqnwB9gZxrtL1qYt4VNM207ZCfJs+0/ZrTyR1Ehbp3Oc IRkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756978079; x=1757582879; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CoDt2QjsB22mDnqAgv2enoxl7MijtXMRnaytbSmT7v4=; b=d3CRNj/Em88d0Ht7V0SErWT5pDyRDdIxSappS0FHouIIVpPPniBbFiEM73mk0dfS2d Hfk1BAY8RPhUVGz5AfoJm1GXOV1XRmJQ9JcMUXDDCY/1MfIoNvm6Rkp70KmXWPHONnyV DYJfBXtk16IA0u0WdcVxu5HtLBAycp3qyDQQq+BssDmgWJbHq3YoTC6Zr8D3MV/WZx3g DOdHw93cQGslPU6dxWCj2p1zm1KqjMWn8VFXD/45P3klG8cE6p8MY8IhfcvyVEHxMbfO dr1aYxagUTbtaqYFQ0J1JjvgkiKXmJuc2ZabV/0K+PoTcpdGGewKgEZwW/hJ7j5tPBQr UNwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756978079; x=1757582879; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=CoDt2QjsB22mDnqAgv2enoxl7MijtXMRnaytbSmT7v4=; b=LT68kl663rDSZNg911wcfmsfTWkU1pqjrc0Ln84tip0fn0h2mBTtUD2yzuQF2HrEMK UH4NnMeBgxj45yhfW3emxmfH7H95CJ/VdTQa4/isME28YKxc8oN5tr5a4gLFqvZ8ZHiA 2qku+IKU9LjnCtWqy/Bb7vfU8sLJxoh1r9hdGL8Dreo36dm9zP6+eiYQj1XYrSRHtKyk Oa3D20p32Ifkd4birhgIM2EqmVRdMNQHeUEzP+/eyFHYUBBrk5dOHtqEuUJ/gnJdPIiN wc7Wf/sGS1PT3lahpNFoeRMC7csNoxb+Wgq/b95B/C4DIIqetsDxarTfx559DpcuAxWp byog== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVwUmLugl9wiOyB9yNlmeHy0f7r4daTR0m99pW82a2GG/E3ElBa6Qw6VcoK3MH9obwv9bcOY5ocOuE8@gnusha.org X-Gm-Message-State: AOJu0YygI/vcfDza/pON0HfBQBwbjk51g+KJwK/UvohhV0HsKuilhXvS sWhyQF18ul9wAscdg7F772b4xizRum2Cn2Y/TzQNpai8ihgwUv41MWm1 X-Google-Smtp-Source: AGHT+IFQIv/LHPOnH9140qJEJjqCvlvYhUwKBsG5AiWxarvnrKNqpgkan1+w/p+nURIfbKN0SLEDOw== X-Received: by 2002:a05:6870:c111:b0:30b:86ed:a23d with SMTP id 586e51a60fabf-3196307ef84mr6907888fac.7.1756978078717; Thu, 04 Sep 2025 02:27:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfK38VkrxrbQ1pB0Ctlo8WSOD1cZV/AzCtIdN+SIS0Ysw== Received: by 2002:a05:6870:600a:10b0:319:b48e:5e1f with SMTP id 586e51a60fabf-319b48e64afls1295089fac.1.-pod-prod-03-us; Thu, 04 Sep 2025 02:27:55 -0700 (PDT) X-Received: by 2002:a05:6808:398b:b0:438:1cea:e487 with SMTP id 5614622812f47-43836e38554mr1913944b6e.29.1756978075635; Thu, 04 Sep 2025 02:27:55 -0700 (PDT) Received: by 2002:a05:6808:3299:b0:438:1a7:d7dd with SMTP id 5614622812f47-4383beac8b5msb6e; Wed, 3 Sep 2025 19:38:19 -0700 (PDT) X-Received: by 2002:a05:6e02:198e:b0:3f0:a48b:151b with SMTP id e9e14a558f8ab-3f4026c300bmr263961985ab.31.1756953498729; Wed, 03 Sep 2025 19:38:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1756953498; cv=none; d=google.com; s=arc-20240605; b=QlcA+oE8XUgkNRIIJ772dugY4z4E4YmO/drwnUoTMP6hHMiwfjAJMnLc+VejVrgToz xjrtcwDKSiPV7I2RNnuEpllcw9xlmH5Go856xA/Y9Hr1paBX15fHeTJjXpPb5+ZpKLPy ZvrVvueOQmpVuCPUHtuLtYZiL6ao7fkytSkFWC7oSwLcTiOb97ZWICn+L4EvVW8gkOuH 799xHkEB5gKYjoyeFk3JSpJ/PiNStjchl4N7dGdkHLCaRFW5m7XlBNu7BgkDFzP05/4f AoufeO6gx4LMMi18yag7BWTcQhQIrjKWuWUo910nctjoA81sqTYYP7JpuAASWYK8EnBy zFNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=bXNNnlFg3B8KxDJYzjI4NK2z4xcTTpv13osc/w+VURo=; fh=+Duu3Cp77aXfHDD1ma61XeBuViahPkcQ600hmLognUE=; b=c/M4hpfkxkdMUKRACvRvumF3pO18dyVLoY0OiK5Wqlr5ubMPVdns46LdUxf+axbHwu gSHMXSI120GrRhd0sGkeyFi2Ljr5TkkQL8cL3TObfS44fP+CzlngLJS7S/Bdwq4MG012 v2GoPys6Ht2ahdENI17hEUNqX75hDTMJVCw4r7fS13b8aRJf37PXpHSM/aaizreN3/JY XZGPi02tkU/0FW0evEVliuXPDLlQyDcOrkUj4jDq2341yslTqAfLM9i8sq15uQ/vndg8 qbhtbsq1BkZQauxXqI7ej+ILQ1jPcJ/tz2dguJWEn7FmLYbP/Llk4f/dH0OnSdR1uGio eRXA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=D9LnJS0d; spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::112c as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com. [2607:f8b0:4864:20::112c]) by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-3f658e97293si3119815ab.2.2025.09.03.19.38.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 19:38:18 -0700 (PDT) Received-SPF: pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::112c as permitted sender) client-ip=2607:f8b0:4864:20::112c; Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-71d71bcab6fso5752757b3.0 for ; Wed, 03 Sep 2025 19:38:18 -0700 (PDT) X-Gm-Gg: ASbGncuOH3Hdeo4rbB/60SZVHXO+ZhFMguM7lGndqZg1eKbiZyvtlj3YgLNoVHbRKDr GM8c+O8TnrlhPd0JXJHQlZHwlQYD+v4qPqfhrvNxrqaD6n9JfDC7cyln8E2xsmvhORp/CvfuOrf lalRrobsNo6ZrGw3PEog4Ltor0JNvTyaN9j+42pueQn8GfpXlIXN8QqM3E79IoG8bDWKvKO5Gwu 0od7lVs X-Received: by 2002:a05:690c:6608:b0:722:7119:313e with SMTP id 00721157ae682-72276512670mr175963477b3.31.1756953497907; Wed, 03 Sep 2025 19:38:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olaoluwa Osuntokun Date: Wed, 3 Sep 2025 19:38:07 -0700 X-Gm-Features: Ac12FXxCtsQDP5YXeFHpjY6gyKloNDTFfBVfByox5PfCOKwbkvOMhFxCh31U7-A Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] OP_TWEAKADD To: jeremy Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000002135c8063df09d3d" X-Original-Sender: laolu32@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=D9LnJS0d; spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::112c as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --0000000000002135c8063df09d3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy, Cool idea, I had a similar one myself a while back. Shows that great chefs think alike ;). Here're some 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 also add some complexity to protocols that need to accept them as input for further manipulation. They are indeed used for Taproot output public keys, 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 t= o 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: > 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 fail 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 use= d as the scalar tweak. The probability of this happening for sha256 outputs i= s very low, but it presents developers with yet another thing to keep in mind in order to use the op code safely. You bring up the point that this allows the side stepping of a new source o= f witness malleability, but in the year of Satoshi 16 (2025), aside from rela= y nuisance shenanigans, is this something developers still need to care 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`? 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 [2]: https://github.com/jonasnick/bips/issues/32 On Sat, Aug 23, 2025 at 10:36=E2=80=AFAM jeremy = wrote: > Hi all, > > I've made a draft BIP writeup of an (often discussed) simple opcode, > 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 desirable > the user can do it. The most flexible is to do a plain tweak. Future work > could add TapTree opcodes to construct taproot tweaks. > > Feedback and discussion are welcome. > > Best, > > Jeremy > > [^1] OP_SHA256 in these example prevents key-cancellation. > > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2= bae22cf0n%40googlegroups.com > > . > --=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/= CAO3Pvs-TMwQuxa2JJq8MY%3D%3DG0nFsqrTis6sPHLayxZOqPuvBtQ%40mail.gmail.com. --0000000000002135c8063df09d3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi= Jeremy,

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

First, why accept only x-only ke= ys?

From the PoV of Bitcoin Script today, they aren't used anyw= here within the
execution environment. They also add some complexity to = protocols that need
to accept them as input for further manipulation. Th= ey are indeed used for
Taproot output public keys, but those keys don= 9;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 t= o
instead accept normal compressed public keys in version v0.8.0 [1]. Th= e
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 resona= tes with my experience wrangling with bugs
introduced by improper/implic= it handling of x-only keys over the years:

> Sigh yeah, x-only k= eys save a byte on chain but it seems the price we pay
> is a high en= gineering complexity. I think it's fair to say that noone had
> r= eally anticipated this [1].

Second, why fail if the passed scalar is= greater than the curve order vs
just reducing modulo the order and usin= g 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 wi= th yet another thing to keep in mind
in order to use the op code safely.=

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

Third, why allocate a cost of 50 op cost vs some= thing lower to better
account for the difference in operation vs normal = `OP_CHECKSIG`?

Validating a BIP-340 signature requires an extra sca= lar 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
[2]: <= a href=3D"https://github.com/jonasnick/bips/issues/32">https://github.com/j= onasnick/bips/issues/32

On S= at, Aug 23, 2025 at 10:36=E2=80=AFAM jeremy <jeremy.l.rubin@gmail.com> wrote:
Hi all,

<= div>I've made a draft BIP writeup of an (often discussed) simple opcode= , 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 twea= k or 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 TapTre= e opcodes to construct taproot tweaks.

Feedba= ck and discussion are welcome.

Best,

Jeremy

[^1] OP_SHA256 in thes= e example 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n%40googlegrou= ps.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/bitcoindev/CAO3Pvs-TMwQuxa2JJq8MY%3D%3DG0nFsqrTis6sPHLayxZOqPuvBtQ%= 40mail.gmail.com.
--0000000000002135c8063df09d3d--