[bitcoindev] [BIP Proposal] OP_TWEAKADD

[bitcoindev] [BIP Proposal] OP_TWEAKADD

[jeremy]

[-- Attachment #1.1: Type: text/plain, Size: 1052 bytes --]

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-55b2bae22cf0n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1568 bytes --]

[bitcoindev] Re: [BIP Proposal] OP_TWEAKADD

[jeremy]

[-- Attachment #1.1: Type: text/plain, Size: 2912 bytes --]

realized that I accidentally didn't post a few notable examples. I've left 
these out of the BIP largely, but could include more examples as desired:


*Tweak Reveal Scripts:*
OP_TWEAKADD composes, for example, with OP_CSFS and OP_IKEY which have been 
proposed separately in BIP-348, BIP-349.
```
witness: <sig> <msg> <tweak>
program: OP_SHA256^1 OP_IKEY OP_TWEAKADD OP_CSFS
```
or
```
witness: <sig> <tweak>
program: OP_SHA256 OP_IKEY OP_TWEAKADD OP_CHECKSIG
```



*Proof-of-Signing-Order & Transaction "refinement":*

A signs strictly after B, with B's signature fully committed. 

```
witness: <sig A> <sig B>
program: DUP TOALT <B> CHECKSIGVERIFY FROMALT SHA256 <A> OP_TWEAKADD 
OP_CHECKSIG
```

A is bound to B's signature, so B fixes whatever details for A.

N.B. B may use any sighash combination mode, so A *refines* B's signature.

*Delegation:*

Key A signs tweaked by key B, key B signs whatever. 

Key A can use a very limited (e.g. SIGHASH_NONE) sighash mode.

```
witness: <sig A> <sig B> <B>
program: DUP TOALT CHECKSIGVERIFY FROMALT SHA256 <A> OP_TWEAKADD OP_CHECKSIG
```

*Target Tweak:*

proves that <t> is known such that `tG + k1G = k2G`

```
witness: <t>
program: <k1G> OP_TWEAKADD <k2G> OP_EQUAL
```

```
witness: <t>
program: SHA256 <k1G> OP_TWEAKADD <k2G> OP_EQUAL
```
Can be used, if k2G is a Taproot output, to "force" disclosure/presence of 
a TapTweak



*Key Reveal:*

Use Target Tweak to "program" a key reveal contract.

Proves knowledge of discrete log of T = tG.

Take T and compute T+G = (t+1)G.

```
witness: <t>
program: <G> OP_TWEAKADD <T+G>
```

[^1] OP_SHA256 in these examples prevents key-cancellation.


On Saturday, August 23, 2025 at 1:36:44 PM UTC-4 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/c51c489c-9417-4a60-b642-f819ccb07b15n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4916 bytes --]

Re: [bitcoindev] [BIP Proposal] OP_TWEAKADD

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 4158 bytes --]

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 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 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 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 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 AM 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 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-55b2bae22cf0n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAO3Pvs-TMwQuxa2JJq8MY%3D%3DG0nFsqrTis6sPHLayxZOqPuvBtQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5502 bytes --]

Re: [bitcoindev] [BIP Proposal] OP_TWEAKADD

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 5286 bytes --]

> 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 and
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 PM Olaoluwa Osuntokun <laolu32@gmail.com> wrote:

>
> 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
> 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 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
> 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 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 AM 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 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-55b2bae22cf0n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR%2BPRGS4ZEJsTQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 6825 bytes --]