[bitcoindev] Re: [BIP Proposal] OP_TWEAKADD

[jeremy <jeremy.l.rubin@gmail.com>]

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