BIP449: OP_TWEAKADD by JeremyRubin · Pull Request #1944 · bitcoin/bips · GitHub

JeremyRubin · 2025-08-22T22:43:24Z

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

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

murchandamus

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.

murchandamus

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.

JeremyRubin · 2026-02-28T07:57:18Z

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

murchandamus

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 · 2026-02-28T19:38:58Z

+- Infinity outputs are rejected to avoid invalid keys.
+- Functionality is narrowly scoped to Taproot-style tweaks, avoiding arbitrary EC arithmetic.
+- Push opcode rather than verification opcode for script compactness.
+- Argument order to permit tweak from witness onto fixed key without OP_SWAP.


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.

see the email thread https://groups.google.com/g/bitcoindev/c/-_geIB25zrg

so OP_TWEAKADD can be either be <tweak> <key> or <key> <tweak>.

we use:

<key> OP_TWEAKADD

because we assume that commonly keys will come from the script, and tweaks will come from the witness.

This avoids an op_SWAP in most cases shown in the email examples.

murchandamus · 2026-02-28T19:39:28Z

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


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

Stand-in for "some opcode that can work with taproot trees".

moonsettler · 2026-02-28T22:21:34Z

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

murchandamus · 2026-03-05T16:06:33Z

Let’s refer to this as BIP 449. Please update the BIP and Assigned headers in the Preamble, rename the file, and add a table entry to the README file for your proposal.

JeremyRubin · 2026-03-06T15:13:16Z

Thanks for the assignment!

@murchandamus re rationale/motivation, see the email thread. https://groups.google.com/g/bitcoindev/c/-_geIB25zrg

murchandamus · 2026-03-16T18:18:22Z

You’re welcome. My point was that the relevant information from the email thread and the pull request discussions should be added to your document, so that your document contains the relevant context and is self-explanatory.

Could you please also update the BIP and Assigned headers in the Preamble, rename the file, and add a table entry to the README file for your proposal?

moonsettler · 2026-03-17T10:56:05Z

It's really thin on the motivation.

Enables script-level key evolutions

Is probably the most vague way possible to describe what it does in a practical sense in tapscript and possibly in restored script.

JeremyRubin · 2026-03-23T19:44:31Z

I think I made all the requested edits. I also added a use case on how to use TWEAKADD for PAIRCOMMIT @moonsettler would appreciate your review on that in particular that my design is sound, was a little tricky.

murchandamus

Thanks for the update

moonsettler · 2026-03-24T19:51:28Z

I think I made all the requested edits. I also added a use case on how to use TWEAKADD for PAIRCOMMIT @moonsettler would appreciate your review on that in particular that my design is sound, was a little tricky.

Looks good to me.

jonatack

Looks good AFAICS.

jonatack · 2026-04-24T15:47:37Z

+```
+## Abstract
+
+This 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.


takes an x-only public key

@JeremyRubin regarding the following question by @Roasbeef in https://groups.google.com/g/bitcoindev/c/-_geIB25zrg/m/AlKbHMl9BgAJ, perhaps I missed it but didn't see it addressed in the ML thread, unsure if the BIP was updated somewhat in response.

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

@Roasbeef followed up himself with

https://groups.google.com/g/bitcoindev/c/-_geIB25zrg/m/ypVpdVKZAQAJ

Allowing parity-bearing public keys would not be encoding-malleable for full points, but it would undermine the x-only canonicalization property. If both the point sign and tweak are witness-controllable, (P, t) and (-P, n−t) yield the same x-only result, creating a new witness malleability vector.

Also, depending on how we add the parity argument, we might want to have OP_IKEY compatibility, making this a more sweeping change.

@Roasbeef himself has a separate proposal for EC Ops that better solve for that use case. TWEAKADD attempts to be maximally faithful to what taproot does.

jonatack · 2026-04-24T15:58:27Z

+  Status: Draft
+  Type: Specification
+  Assigned: 2026-03-05
+  License: BSD-3-Clause


Could add the Requires header stating the BIPs that this one depends on (340, maybe 341)

Requires: 340

not sure I understand the Requires header well enough to add it.

I would assume it would be only meaningful with respect to BIPs that are not currently consensus-active?

jonatack · 2026-04-24T16:13:21Z

+[dependencies]
+secp256k1 = "0.29"
+hex = "0.4"
+bitcoin_hashes = "0.16.0"


cargo run worked fine

for info, when I made the suggested cargo updates

-secp256k1 = "0.29" +secp256k1 = "0.31.1" hex = "0.4" -bitcoin_hashes = "0.16.0" +bitcoin_hashes = "0.20.0"

the code looks like it would need to be updated for API changes in secp256k1.

i.e. cargo asked if you'd like to update? but it worked fine without?

Probably need a bip repo wide policy wrt that...

otherwise examples will constantly go stale against cargo suggestions for newer versions.

Co-authored-by: Jon Atack <jon@atack.com>

jonatack added the New BIP label Aug 22, 2025

jonatack reviewed Aug 22, 2025

View reviewed changes

Comment thread bip-XXXX.md Outdated

This comment was marked as off-topic.

Sign in to view

murchandamus reviewed Aug 25, 2025

View reviewed changes

Comment thread bip-XXXX.md Outdated

Comment thread bip-XXXX.md Outdated

Comment thread bip-XXXX.md Outdated

Comment thread bip-XXXX.md Outdated

Randy808 mentioned this pull request Sep 19, 2025

Socratic Seminar 46 (October 2025) Bitcoin-Grove/miamibitdevs.org#25

Closed

murchandamus reviewed Feb 28, 2026

View reviewed changes

Comment thread bip-XXXX.md Outdated

murchandamus changed the title ~~BIP Draft OP_TWEAKADD~~ BIP Draft: OP_TWEAKADD Feb 28, 2026

murchandamus added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Feb 28, 2026

JeremyRubin marked this pull request as ready for review February 28, 2026 07:57

murchandamus reviewed Feb 28, 2026

View reviewed changes

murchandamus added Needs number assignment and removed PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author labels Feb 28, 2026

murchandamus changed the title ~~BIP Draft: OP_TWEAKADD~~ BIP449: OP_TWEAKADD Mar 5, 2026

murchandamus removed the Needs number assignment label Mar 5, 2026

murchandamus added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Mar 16, 2026

Jeremy Rubin added 9 commits March 23, 2026 13:12

BIP: OP_TWEAKADD

8ffa737

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

b349b18

BIP TweakAdd: Invert Argument Order

cd669f4

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

858f801

BIP TweakAdd -- add mailing list discussion

5de43ac

BIP TweakAdd: Add Alpen and MATT mentions

45d62e8

BIP TweakAdd Formatting Edits

46910a5

BIP TWEAKADD remove conventions section

466aac5

BIP TWEAKADD formatting fix

a6f271f

Jeremy Rubin added 3 commits March 23, 2026 13:12

BIP TWEAKADD Move Vectors to end

ae05e47

BIP TweakAdd: Condense compatibility section

76d8bbc

[BIP-0449] Updates post assignemnt

b4a840e

JeremyRubin force-pushed the optweakadd branch from 261453b to b4a840e Compare March 23, 2026 19:36

[BIP-0449] Normalize Metadata

8cf8e3b

murchandamus reviewed Mar 24, 2026

View reviewed changes

murchandamus removed the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Mar 24, 2026

jonatack self-assigned this Apr 24, 2026

jonatack reviewed Apr 24, 2026

View reviewed changes

Update bip-0449.md Link Text to point to OP of ML Thread

f291fb6

Co-authored-by: Jon Atack <jon@atack.com>

Conversation

JeremyRubin commented Aug 22, 2025 • edited by jonatack Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

This comment was marked as off-topic.

Uh oh!

murchandamus left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

murchandamus left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JeremyRubin commented Feb 28, 2026

Uh oh!

murchandamus left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

moonsettler commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

murchandamus commented Mar 5, 2026

Uh oh!

JeremyRubin commented Mar 6, 2026

Uh oh!

murchandamus commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

moonsettler commented Mar 17, 2026

Uh oh!

JeremyRubin commented Mar 23, 2026

Uh oh!

murchandamus left a comment

Choose a reason for hiding this comment

Uh oh!

moonsettler commented Mar 24, 2026

Uh oh!

jonatack left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

JeremyRubin commented Aug 22, 2025 •

edited by jonatack

Loading

murchandamus left a comment •

edited

Loading

moonsettler commented Feb 28, 2026 •

edited

Loading

murchandamus commented Mar 16, 2026 •

edited

Loading