BIP Draft: OP_TWEAKADD

JeremyRubin commented at 10:43 pm on August 22, 2025: contributor

Opening this PR for feedback & discussion on the specification for OP_TWEAKADD.

Mailing list post: https://groups.google.com/g/bitcoindev/c/-_geIB25zrg

BIP: OP_TWEAKADD b24c5049ed

jonatack added the label New BIP on Aug 22, 2025

BIP TweakAdd: note on commutativity of tweaking and add test cases 04f8c61905

BIP TweakAdd: Invert Argument Order 601d45f16c

BIP Tweakadd: fix typo & add note on even-y tweaking 7602e08769

BIP TweakAdd -- add mailing list discussion 14f28051a7

BIP TweakAdd: Add Alpen and MATT mentions 9415fbc4e4

in bip-XXXX.md:240 in b24c5049ed outdated

235+This proposal extends the Taproot tweak mechanism (BIP340/341) into script, inspired by prior work on scriptless scripts and key-evolution constructions. There has been various discussion of OP_TWEAKADD over the years, including by Russell O'Connor and Steven Roose.
236+
237+## References
238+
239+- [CATT: Thoughts about an alternative covenant softfork proposal](https://delvingbitcoin.org/t/catt-thoughts-about-an-alternative-covenant-softfork-proposal/125)
240+- [Bitcoindev mailing list discussion](https://gnusha.org/pi/bitcoindev/e98d76f2-6f2c-9c3a-6a31-bccb34578c31@roose.io/)

jonatack commented at 11:09 pm on August 22, 2025:

Hi @JeremyRubin, is there a link to a recent discussion specific to OP_TWEAKADD? Suggest a new ML post about this draft.

JeremyRubin commented at 5:40 pm on August 23, 2025:

yes sir 🫡

kash831 commented at 3:37 pm on August 24, 2025: none

All in a hard days work

in bip-XXXX.md:37 in 9415fbc4e4 outdated

32+
33+Input (top last):
34+
35+```
36+
37+... \[h32] \[pubkey32] OP\_TWEAKADD  ->  ... \[pubkey32\_out]

murchandamus commented at 9:31 pm on August 25, 2025:

I think these backslashes are unnecessary in the preformatted code. At least they render for me in the preview.

in bip-XXXX.md:39 in 9415fbc4e4 outdated

34+
35+```
36+
37+... \[h32] \[pubkey32] OP\_TWEAKADD  ->  ... \[pubkey32\_out]
38+
39+````

murchandamus commented at 9:32 pm on August 25, 2025:

This has one backtick too many, although it doesn’t seem to change the rendering.

in bip-XXXX.md:9 in 9415fbc4e4 outdated

0@@ -0,0 +1,317 @@
1+```
2+BIP: TBD
3+Layer: Consensus (soft fork)
4+Title: OP_TWEAKADD - x-only key tweak addition
5+Author: Jeremy Rubin <jeremy@char.network>
6+Status: Draft
7+Type: Standards Track
8+Created: 2025-08-22
9+License: BSD-3-Clause

murchandamus commented at 9:37 pm on August 25, 2025:

Please add the missing Copyright section.

JeremyRubin commented at 2:28 pm on August 27, 2025:

You meant at the end of the document right?

murchandamus commented at 9:28 pm on August 27, 2025:

Sure, that’s fine.

in bip-XXXX.md:29 in 9415fbc4e4 outdated

24+## Specification
25+
26+### Applicability and opcode number
27+
28+- Context: Only valid in tapscript (witness version 1, leaf version 0xc0). In legacy or segwit v0 script, `OP_TWEAKADD` is disabled and causes script failure.
29+- Opcode: OP_TWEAKADD (0xBE, or TBD, any unused OP_SUCCESSx, preferably one which might never be restored in the future).

murchandamus commented at 9:39 pm on August 25, 2025:

What does “preferably one which might never be restored in the future” refer to?

JeremyRubin commented at 11:31 pm on August 25, 2025:

E.g., it’s desirable to not use 0x7f because that’s OP_SUBSTR and if we ever did a soft fork like that, it’s simpler to not change those opcodes.

from bip-347:

We specifically choose to use OP_SUCCESS126 rather than another OP_SUCCESSx as OP_SUCCESS126 uses the same opcode value (126 in decimal and 0x7e in hexadecimal) that was used for OP_CAT prior to it being disabled in Bitcoin. This removes a potential source of confusion that would exist if we had a opcode value different from the one used in the original OP_CAT opcode.

JeremyRubin commented at 2:28 pm on August 27, 2025:

assuming this doesn’t need more of a note in the BIP?

murchandamus commented at 9:42 pm on August 25, 2025: member

I had a first glance at this. Looks interesting. A few sections look still a bit bullet point heavy and I would hope to see them expanded a bit.

BIP TweakAdd Formatting Edits e795d69693

BIP TWEAKADD remove conventions section 3e5044215f

BIP TWEAKADD formatting fix c7540025cd

BIP TWEAKADD Move Vectors to end 4cb0456716

BIP TweakAdd: Condense compatibility section 4500b0ad25

in bip-XXXX.md:9 in 4500b0ad25

0@@ -0,0 +1,315 @@
1+```
2+BIP: TBD
3+Layer: Consensus (soft fork)
4+Title: OP_TWEAKADD - x-only key tweak addition
5+Author: Jeremy Rubin <jeremy@char.network>
6+Status: Draft
7+Type: Standards Track
8+Created: 2025-08-22
9+License: BSD-3-Clause

murchandamus commented at 0:27 am on February 28, 2026:

Since BIP3 was deployed meanwhile, the preamble would need a few tweaks:

0BIP: ?
1Layer: Consensus (soft fork)
2Title: OP_TWEAKADD - x-only key tweak addition
3Authors: Jeremy Rubin <jeremy@char.network>
4Status: Draft
5Type: Specification
6Assigned: ?
7License: BSD-3-Clause

murchandamus commented at 0:29 am on February 28, 2026: member

Hey, this hasn’t seen any activity in a while and is still marked as a draft pull request. What is the status of this? If this is ready for another editor review, please mark the pull request as Ready for Review. It would also be welcome if it got some review from third parties.

murchandamus renamed this:
~~BIP Draft OP_TWEAKADD~~
BIP Draft: OP_TWEAKADD
on Feb 28, 2026

murchandamus added the label PR Author action required on Feb 28, 2026

Update OP_TWEAKADD metadata

Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>

5da11571b3

JeremyRubin marked this as ready for review on Feb 28, 2026

JeremyRubin commented at 7:57 am on February 28, 2026: contributor

I think it’s fine to come out of draft.

in bip-XXXX.md:13 in 5da11571b3

 8+Assigned: ?
 9+License: BSD-3-Clause
10+```
11+## Abstract
12+
13+This proposal defines a new tapscript opcode, `OP_TWEAKADD`, that takes an x-only public key and a 32-byte integer `h` on the stack and pushes the x-only public key corresponding to `P + h*G`, where `P` is the lifted point for the input x-coordinate and `G` is the secp256k1 generator. The operation mirrors the Taproot tweak used by BIP340 signers and enables simple, verifiable key modifications inside script without revealing private keys or relying on hash locks.

murchandamus commented at 7:36 pm on February 28, 2026:

The integer h appears to be called t in the specification section.

0This proposal defines a new tapscript opcode, `OP_TWEAKADD`, that takes an x-only public key and a 32-byte integer `t` on the stack and pushes the x-only public key corresponding to `P + t*G`, where `P` is the lifted point for the input x-coordinate and `G` is the secp256k1 generator. The operation mirrors the Taproot tweak used by BIP340 signers and enables simple, verifiable key modifications inside script without revealing private keys or relying on hash locks.

in bip-XXXX.md:81 in 5da11571b3

76+
77+- Even-Y x-only is consistent with BIP340/Taproot.
78+- Infinity outputs are rejected to avoid invalid keys.
79+- Functionality is narrowly scoped to Taproot-style tweaks, avoiding arbitrary EC arithmetic.
80+- Push opcode rather than verification opcode for script compactness.
81+- Argument order to permit tweak from witness onto fixed key without OP_SWAP.

murchandamus commented at 7:38 pm on February 28, 2026:

Argument order to permit tweak from witness onto fixed key without OP_SWAP

This sentence is not clear to me. Perhaps it could use more context.

in bip-XXXX.md:88 in 5da11571b3

83+## Compatibility
84+
85+This is a soft-fork change which is tapscript-only. Un-upgraded nodes will continue
86+to treat unknown tapscript opcode as OP_SUCCESSx.
87+
88+A future upgrade, such as an OP_CAT or OP_TAPTREE opcode, can prepare a tweak for a

murchandamus commented at 7:39 pm on February 28, 2026:

What is OP_TAPTREE? I don’t think I’ve seen that one before.

murchandamus commented at 7:46 pm on February 28, 2026: member

The Rationale still seems a bit brief to me, but I would expect that it would be backfilled with the responses to the questions and issues raised as this proposal gets more review. Would be great if some other covenant researchers took a look at it. Otherwise the idea generally seems well described.

cc: @brandonblack, @ajtowns, @roconnor-blockstream, @moonsettler, @Roasbeef for some likely candidates to take a look.

murchandamus removed the label PR Author action required on Feb 28, 2026

murchandamus added the label Needs number assignment on Feb 28, 2026

moonsettler commented at 10:21 pm on February 28, 2026: none

Without any additional opcodes the supported use cases seem to be:

prove order of signing (not sure what this can be used for, maybe some penalty based lightning construct?)
reveal private key to a pubkey (user can swap out of a covenant pool by atomically forfeiting a private key?)

Also along with #1974 TA could be used instead of the annex for data availability, by tweaking the internal key with the data required to reconstruct the script for that state.

Something like <sig> <da> | SHA256 INTERNALKEY TWEAKADD TEMPLATEHASH SWAP CSFS

BIP Draft: OP_TWEAKADD #1944