Opening this PR for feedback & discussion on the specification for OP_TWEAKADD.
Mailing list post: https://groups.google.com/g/bitcoindev/c/-_geIB25zrg
Opening this PR for feedback & discussion on the specification for OP_TWEAKADD.
Mailing list post: https://groups.google.com/g/bitcoindev/c/-_geIB25zrg
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/)
Hi @JeremyRubin, is there a link to a recent discussion specific to OP_TWEAKADD? Suggest a new ML post about this draft.
yes sir 🫡
All in a hard days work
32 | + 33 | +Input (top last): 34 | + 35 | +``` 36 | + 37 | +... \[h32] \[pubkey32] OP\_TWEAKADD -> ... \[pubkey32\_out]
I think these backslashes are unnecessary in the preformatted code. At least they render for me in the preview.
<img width="553" height="192" alt="Image" src="https://github.com/user-attachments/assets/0ce8b5f0-604f-4199-80fa-57267bc7a80d" />
34 | + 35 | +``` 36 | + 37 | +... \[h32] \[pubkey32] OP\_TWEAKADD -> ... \[pubkey32\_out] 38 | + 39 | +````
This has one backtick too many, although it doesn’t seem to change the rendering.
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
Please add the missing Copyright section.
You meant at the end of the document right?
Sure, that’s fine.
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).
What does "preferably one which might never be restored in the future" refer to?
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.
assuming this doesn't need more of a note in the BIP?
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.
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
Since BIP3 was deployed meanwhile, the preamble would need a few tweaks:
BIP: ?
Layer: Consensus (soft fork)
Title: OP_TWEAKADD - x-only key tweak addition
Authors: Jeremy Rubin <jeremy@char.network>
Status: Draft
Type: Specification
Assigned: ?
License: BSD-3-Clause
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.
I think it's fine to come out of draft.
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.
The integer h appears to be called t in the specification section.
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.
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.
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.
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
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".
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.
Without any additional opcodes the supported use cases seem to be:
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
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.
Thanks for the assignment! @murchandamus re rationale/motivation, see the email thread. https://groups.google.com/g/bitcoindev/c/-_geIB25zrg
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?
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.
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.
Thanks for the update
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.