Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
murchandamus
left a comment
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
|
I think it's fine to come out of draft. |
murchandamus
left a comment
There was a problem hiding this comment.
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.
| - 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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
What is OP_TAPTREE? I don’t think I’ve seen that one before.
There was a problem hiding this comment.
Stand-in for "some opcode that can work with taproot trees".
|
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 |
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
|
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. |
Opening this PR for feedback & discussion on the specification for OP_TWEAKADD.
Mailing list post: https://groups.google.com/g/bitcoindev/c/-_geIB25zrg