path: root/d9/e8bacf611772d1b093ce5d4cdce55a16fe6e97

Delivery-date: Thu, 04 Sep 2025 17:43:20 -0700
Received: from mail-oa1-f58.google.com ([209.85.160.58])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC22FLMMY4FRBHPE5DCQMGQERJBGEYQ@googlegroups.com>)
	id 1uuKXv-0007p7-M6
	for bitcoindev@gnusha.org; Thu, 04 Sep 2025 17:43:20 -0700
Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-319c4251787sf1998968fac.2
        for <bitcoindev@gnusha.org>; Thu, 04 Sep 2025 17:43:19 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1757032993; cv=pass;
        d=google.com; s=arc-20240605;
        b=eW9ARFW4udDrIVk6QY14F1NedF79POsV641tBFH+QDEXjxQVteD4OEoQmvnn+x1CsN
         JU5gkI9UjC7BmbS0zVFlIrdrnEGAuCsquaI7Muz/TTKnXOQCKELaD7ak7jwHmgcJJn/J
         M1yd++BH70PTKkU88ADj/t5TDyYH/DcXdCfqyLCz0vwXTWCZiX2Fdxz72n3uavpYuCQT
         kf/8in4QKoGoG2TGP35uPorq7HTqKx1uh1LIhFmyGxPyUOvmSOM63oKHfVZezA3X+qjr
         h3mPU0PJVgQS5ws4bBZyBPd36kIPk6wh/ghuZnoU7DH5/VdWjcfgvzmMsSHzkylmNBhX
         CHlw==
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=OFHmAo1ae16rWKyj/ahzYeXfnz/ndkPUYyzdL0Uf9Pw=;
        fh=CMNLFIECs+hXmPLLk6ZLqdCiPXvWo+qiS1pyw/VUB9U=;
        b=aDoBqCQDR3St3kPPhRpX4K/gJlGvPN0sUd5EUCipIVe1sOFodRvJYQLEqq9zoIKyfd
         pLGlhs2Az/Y4pOxDugao03HJxHVx2QMYInM/6JqFuV8YfXYbCUWTHrpzDg7W7WbLFdI0
         sZYI98u3IfIv/QOP/tOOz3tyqlP3iS00zpO58lyVty5oSdO9ugV5RJCIv1XXHTyUHC7H
         11mD9P4dYoeHK2TRFrOiNX661m3H41Ajk6ZubHX7aT1ml+Y/9r63ych6UapD3ebqxnw7
         Jb/Z0KV5EPWnNdAG/7fmvoUK4glIS4vUNCz76yaEatC7Ee5tOz3O2miJsn3K4DrWVAmO
         m0Mw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=jLUdrm+L;
       spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b31 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=1757032993; x=1757637793; 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=OFHmAo1ae16rWKyj/ahzYeXfnz/ndkPUYyzdL0Uf9Pw=;
        b=PNxNKCKs5itj44mHin2fxXQrZ/rF2IgjHYEK48rzqOXPv8haiITtuNDUv8Z90eUpsj
         i5sbFTc0EWCsmEMuLyU7D7roWE9cntDqGlG70A+TugUb6uCq2lAO3W3YR5vH8pB6i4L0
         CheslYRnNRklQntvKA28PSLcbH5C5HStRQZbmh9odFyNtqTwTjExUQWWswmxVxS0HB+8
         w5WdmYTLN/sjk33R/Luc+AWcIUxA+BNrt0yl5q2PXUzbqBQgFofvHcy9t5WHcqbKzwCd
         UoKZkoJAbR3+/gSD1q7JiuQQgXe4BYTilzs3XFDahTiQCcDOCd4v2zAUQz2FjUMYfJsr
         ahHA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757032993; x=1757637793; 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=OFHmAo1ae16rWKyj/ahzYeXfnz/ndkPUYyzdL0Uf9Pw=;
        b=Td3eiiXaEBqpSCeZazlHPytKltCN0FP+mgjH8YumJSjW1u1jJ6Mq5axs0CQRKhmAe7
         Ar7xw0rW2TiLHdxkApHQzUMPteEmeQIOH6+nFKVUifOt0a/lgZ+xCInHXPEhdbkoyi08
         +pVL/RFFuci+yXrvu2t/gDfILi4ITx+3sqlc+mxwLIxRehecKf29xPz7EYz08JJh+23X
         kxej3VktNbl8qRfkap3PMH1Y7IzM9m3C/ns+Hkjrjs1MX6Ug+t7mSPvOhmAtYasIvxTX
         DacO4SNi+YKXKaxk89bKx6wc2/K9tPxhv7dJwsLj8e+vWfixGH4WJelc0QqSfCmqwpNk
         4zQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757032993; x=1757637793;
        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=OFHmAo1ae16rWKyj/ahzYeXfnz/ndkPUYyzdL0Uf9Pw=;
        b=P6v8ZPTYOa1GeEUuj64nfVHC1DhZHaAT4bJoR8ONmfsm/F5czJ83knKUapcTSg3jzx
         s6EbK6EUS2J8OLO17aMkOs82ucR+38Zl77mPLUlUa3Fg6RgyIhSiuBqJhhZ5SPAH+xui
         OKCM2WP0RpVpTY8oo5EAhU3+pp7oVxAzqOSWqGVHeyuJ4BfWMSZ0w9SMMCdapa8CJki0
         eNBryLzOG9cLu0Ry+e40HRulA91F3v2dvup4jDDopD+oihP1HKEHlKntp5u1ZDtBzYnG
         Dc+pDFDfVoUmngop+LUNrP6k4+jS8iExSMHVyTIjH0w21ia7ui9TLV3JaurXBTQooLJd
         Af7w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUibxziTabHdBqCGKjAezVxF7ZXcyYZCmj1/dRM6uXXPmLGuXl6Alf7nd4Z1iICdQnjtAzM3bz+u6jH@gnusha.org
X-Gm-Message-State: AOJu0YzcqyjfST/9sX+phvrtZUDvoYpMFiAHnoH4YbUa5nuGF1/yS2fE
	tAluH7UaS567KlIGu23YibPWEBeNNnV/P7EuRwjimjfb0YBhnNgoEEwU
X-Google-Smtp-Source: AGHT+IGaUdF0J3znnNPGJjT5dVhS0fIdKETcRUIffpckTIpBk/uwOJNouEvMsDNzwShmL9x4DFMYuA==
X-Received: by 2002:a05:6870:c693:b0:315:9347:9260 with SMTP id 586e51a60fabf-3196334011bmr10749930fac.32.1757032992751;
        Thu, 04 Sep 2025 17:43:12 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdx3vGCaq/AyyTZFL9nuNouavNGGOwshl7hT4VuKSmiSQ==
Received: by 2002:a05:6871:81d1:10b0:31a:4dac:cdc3 with SMTP id
 586e51a60fabf-32126fe48ebls71464fac.1.-pod-prod-01-us; Thu, 04 Sep 2025
 17:43:09 -0700 (PDT)
X-Received: by 2002:a05:6808:6a89:b0:438:40ff:a8e7 with SMTP id 5614622812f47-43840ffac0fmr2293170b6e.37.1757032989186;
        Thu, 04 Sep 2025 17:43:09 -0700 (PDT)
Received: by 2002:a05:620a:4729:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8111e280b05ms85a;
        Thu, 4 Sep 2025 15:46:39 -0700 (PDT)
X-Received: by 2002:a05:622a:1a82:b0:4ae:f855:77b0 with SMTP id d75a77b69052e-4b31d546bb6mr247441631cf.0.1757025998297;
        Thu, 04 Sep 2025 15:46:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1757025998; cv=none;
        d=google.com; s=arc-20240605;
        b=YezGk+3KhvjPPdGnhwnPqGFixVpESRV1Oo7fwikS2d7d0dBWUjJ0TPK4k/FMOIWV13
         fp/zvm2gH8MqYjEkC8K1aNcsb9TXK64sAiaBNivmBr3uynGyQqxaH9Al8StbCmlPRsN0
         PAJmPQGu73kHGurtAoNL9M723MXwuKL5hpDkkGuKkajDRLaqqyoO3XfVHsyQUKx92u6j
         SNOKMoO2kgmN5U+1cVS3eg+2p/E1JNgRAE3TCyGJVZhkFKhXkE4dAtWEnY50klHaJgNX
         Zn3fTxG/usGZb9tjKA2FcBU2aROARm8Rghw4XnhRrxYmdL7FCP2pjBOI3CN7EC91I24U
         PEVg==
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=dhRev0eP3w9k8HsWOq7RBdNyWe8db5U1Q89VVGfF+Pg=;
        fh=+Duu3Cp77aXfHDD1ma61XeBuViahPkcQ600hmLognUE=;
        b=PWkdF3lHGwXbor3hAX0p4HxJ+f/Vf1pUAIHYw0ezAk3zWPVGctSjNUGAlx5ajLg2e/
         BiZjoS6QUeqLKRnTIJa2WJkfGj5K4M+y3dICxYkowdVNEHEDORK5Ae7jjgMLSsH1Lf/V
         tOF57o34zakzrz+FM5cZkBQeeSUR5/38fSd8Zfnd8mJSJi+DOTJTK/oL3cYH30tr1U+N
         GM4GfU1UoO0yjvCxKzCAongLvbhkNvH4/H8JeEOvb2wJ7FNtkMthp3ulQQY9XS35zZG1
         xfdgcPWJwiiXf6JAdRMIFnwpJ1F5nh75atnIh8NQDLk+3wx1MinXQCBl0KADzjt56WrW
         e4cw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=jLUdrm+L;
       spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b31 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-yb1-xb31.google.com (mail-yb1-xb31.google.com. [2607:f8b0:4864:20::b31])
        by gmr-mx.google.com with ESMTPS id af79cd13be357-80aaa832cdbsi26648085a.7.2025.09.04.15.46.38
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 04 Sep 2025 15:46:38 -0700 (PDT)
Received-SPF: pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) client-ip=2607:f8b0:4864:20::b31;
Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-e9d71a04d78so1291164276.1
        for <bitcoindev@googlegroups.com>; Thu, 04 Sep 2025 15:46:38 -0700 (PDT)
X-Gm-Gg: ASbGncuib0z+6jukNiyQOJCRqBQON65+CPYZbgdQhfvASp8KHRi5MILmZBzYgyL/opo
	7JiUWv4vCJrVlPAdSz6FBkEoiq5na+cb9KVqijvIBbIbr9BoxWu0EL9pDwOQaWjlQHtVuB4954x
	SFcjAwMAIl3JEd2HUeccqRBkacsIzLFatvMKYO3o+B93jOqQ9OoXMv8pMKyIdSLKi0OTMoVirPi
	F//a1QEK4k4W/i5uls=
X-Received: by 2002:a53:d005:0:b0:5fc:2f89:8892 with SMTP id
 956f58d0204a3-601780cc565mr4332651d50.27.1757025997493; Thu, 04 Sep 2025
 15:46:37 -0700 (PDT)
MIME-Version: 1.0
References: <bc9ff794-b11e-47bc-8840-55b2bae22cf0n@googlegroups.com> <CAO3Pvs-TMwQuxa2JJq8MY==G0nFsqrTis6sPHLayxZOqPuvBtQ@mail.gmail.com>
In-Reply-To: <CAO3Pvs-TMwQuxa2JJq8MY==G0nFsqrTis6sPHLayxZOqPuvBtQ@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Thu, 4 Sep 2025 15:46:26 -0700
X-Gm-Features: Ac12FXwQQWuW-XNDbXk7ZFVeK1fniWOH-bSEvGYfROHmC3O-K1YcNvZaRv8vbM4
Message-ID: <CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR+PRGS4ZEJsTQ@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] OP_TWEAKADD
To: jeremy <jeremy.l.rubin@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000711ab3063e017e61"
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=jLUdrm+L;       spf=pass
 (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b31 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: <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 (/)

--000000000000711ab3063e017e61
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Second, why fail if the passed scalar is greater than the curve 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 an=
d
makes a lot of sense.

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

Eliminating all sources of malleability in newly proposed op codes is
important as it serves to increase the binding of transactions w.r.t
blocks.

Stronger binding of transactions to blocks post segwit (otherwise possible
to malleate transactions, causing the witness commitment validation to fail
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 <laolu32@gmail.co=
m> wrote:

>
> Hi Jeremy,
>
> Cool idea, I had a similar one myself a while back. Shows that great chef=
s
> think alike ;). Here're some questions that came to mind as I was reviewi=
ng
> the doc.
>
> First, why accept only x-only keys?
>
> From the PoV of Bitcoin Script today, they aren't used anywhere within th=
e
> execution environment. They also add some complexity to protocols that ne=
ed
> to accept them as input for further manipulation. They are indeed used fo=
r
> 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
> 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:
>
> > Sigh yeah, x-only keys save a byte on chain but it seems the price we p=
ay
> > is a high engineering complexity. I think it's fair to say that noone h=
ad
> > 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
> 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 mi=
nd
> 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), aside from
> relay
> 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 <jeremy.l.rubin@gmail.com=
> 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 wor=
k
>> 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 Group=
s
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b=
2bae22cf0n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55=
b2bae22cf0n%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/=
CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR%2BPRGS4ZEJsTQ%40mail.gmail.com.

--000000000000711ab3063e017e61
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; Second, why fail if the passed scalar is greater=
 than the curve order vs<br>&gt; just reducing modulo the order and using t=
hat value?<br><br>Thinking about it a bit more, I think this is totally the=
 right decision and<br>makes a lot of sense. <br><br>The 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 ap=
plication needs to deal with. <br><br>Eliminating all sources of malleabili=
ty in newly proposed op codes is<br>important as it serves to increase the =
binding of transactions w.r.t blocks. <br><br>Stronger binding of transacti=
ons to blocks post segwit (otherwise possible<br>to malleate transactions, =
causing the witness commitment validation to fail<br>for an otherwise valid=
 block), helps to mitigate a class of active<br>relay impediment attacks an=
d minimizes front-running/extractable value.<br><br>-- Laolu<br></div></div=
><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Wed, Sep 3, 2025 at 7:38=E2=80=AFPM Olaoluwa Osuntokun =
&lt;<a href=3D"mailto:laolu32@gmail.com">laolu32@gmail.com</a>&gt; wrote:<b=
r></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"ltr">=
<div><br clear=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signature=
"><div dir=3D"ltr">Hi Jeremy,<br><br>Cool idea, I had a similar one myself =
a while back. Shows that great chefs<br>think alike ;). Here&#39;re some qu=
estions 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 also ad=
d some complexity to protocols that need<br>to accept them as input for fur=
ther manipulation. They are indeed used for<br>Taproot output public keys, =
but those keys don&#39;t ever make their way down<br>into Script as an op c=
ode argument.<br><br>The musig2 BIP originally accepted x-only keys as inpu=
t, but was switched to<br>instead accept normal compressed public keys in v=
ersion v0.8.0 [1]. The<br>switch over enabled some simplifications in the B=
IP, 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>This co=
mment from Tim resonates with my experience wrangling with bugs<br>introduc=
ed 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 tha=
t noone had<br>&gt; really anticipated this [1].<br><br>Second, why fail if=
 the passed scalar is greater than the curve order vs<br>just reducing modu=
lo the order and using that value? <br><br>This would mean that in some cas=
es, the direct value of a hash can&#39;t be used<br>as the scalar tweak. Th=
e probability of this happening for sha256 outputs is<br>very low, but it p=
resents developers with yet another thing to keep in mind<br>in order to us=
e the op code safely.<br><br>You bring up the point that this allows the si=
de 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 someth=
ing developers still need to care about?<br><br>Third, why allocate a cost =
of 50 op cost vs something lower to better<br>account for the difference in=
 operation vs normal `OP_CHECKSIG`? <br><br>Validating a BIP-340 signature =
requires an extra scalar base mult<br>(ignoring the Strauss-Shamir trick fo=
r 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 hav=
e a lower cost vs `OP_CHECKSIG`.<br><br>-- Laolu<br><br>[1]: <a href=3D"htt=
ps://github.com/jonasnick/bips/pull/37" target=3D"_blank">https://github.co=
m/jonasnick/bips/pull/37</a> <br>[2]: <a href=3D"https://github.com/jonasni=
ck/bips/issues/32" target=3D"_blank">https://github.com/jonasnick/bips/issu=
es/32</a><br></div></div></div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Sat, Aug 23, 2025 at 10:36=E2=80=AFAM jer=
emy &lt;<a href=3D"mailto:jeremy.l.rubin@gmail.com" target=3D"_blank">jerem=
y.l.rubin@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" 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 dr=
aft BIP writeup of an (often discussed) simple opcode, OP_TWEAKADD, deploya=
ble as an OP_SUCCESSx upgrade.</div><div><br></div><a href=3D"https://githu=
b.com/bitcoin/bips/pull/1944" target=3D"_blank">https://github.com/bitcoin/=
bips/pull/1944</a><div><br></div><div>This opcode is relatively simple. The=
 main design choices are:</div><div><br></div><div>1) Verify v.s. Push sema=
ntics -- Push, for succinctness on-chain</div><div>2) Argument order -- Key=
 on top, for tweak in witness</div><div>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.</div><div><div><br></div><div>Feedback and discussion are =
welcome.<br></div><div><br></div><div>Best,</div><div><br></div><div>Jeremy=
</div><div><br></div><div><div>[^1] OP_SHA256 in these example 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=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.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">https://groups.googl=
e.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n%40googlegrou=
ps.com</a>.<br>
</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/CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR%2BPRGS4ZEJsTQ%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR%2BPRGS4ZEJsTQ%40ma=
il.gmail.com</a>.<br />

--000000000000711ab3063e017e61--