Skip to content

BIP Draft: OP_TWEAKADD#1944

Open
JeremyRubin wants to merge 12 commits intobitcoin:masterfrom
JeremyRubin:optweakadd
Open

BIP Draft: OP_TWEAKADD#1944
JeremyRubin wants to merge 12 commits intobitcoin:masterfrom
JeremyRubin:optweakadd

Conversation

@JeremyRubin
Copy link
Contributor

@JeremyRubin JeremyRubin commented Aug 22, 2025

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

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

kash831

This comment was marked as off-topic.

Copy link
Member

@murchandamus murchandamus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@murchandamus murchandamus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 murchandamus changed the title BIP Draft OP_TWEAKADD BIP Draft: OP_TWEAKADD Feb 28, 2026
@murchandamus murchandamus added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Feb 28, 2026
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
@JeremyRubin JeremyRubin marked this pull request as ready for review February 28, 2026 07:57
@JeremyRubin
Copy link
Contributor Author

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

Copy link
Member

@murchandamus murchandamus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

```
## Abstract

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Suggested change
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.
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.

- 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@murchandamus 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
@moonsettler
Copy link

moonsettler commented Feb 28, 2026

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

  1. prove order of signing (not sure what this can be used for, maybe some penalty based lightning construct?)
  2. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants