BIP449: OP_TWEAKADD

[JeremyRubin]

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

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

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

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]

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.

[JeremyRubin]

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]

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

[JeremyRubin]

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

[moonsettler]

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

[murchandamus]

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]

Thanks for the assignment!

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

[murchandamus]

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]

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.