Good morning Jeremy, Umm `OP_ANNEX` seems boring ....
> It seems like one good option is if we just go on and banish the OP_ANNEX. > Maybe that solves some of this? I sort of think so. It definitely seems like > we're not supposed to access it via script, given the quote from above: > > Execute the script, according to the applicable script rules[11], using the > witness stack elements excluding the script s, the control block c, and the > annex a if present, as initial stack. > If we were meant to have it, we would have not nixed it from the stack, no? > Or would have made the opcode for it as a part of taproot... > > But recall that the annex is committed to by the signature. > > So it's only a matter of time till we see some sort of Cat and Schnorr Tricks > III the Annex Edition that lets you use G cleverly to get the annex onto the > stack again, and then it's like we had OP_ANNEX all along, or without CAT, at > least something that we can detect that the value has changed and cause this > satisfier looping issue somehow. ... Never mind I take that back. Hmmm. Actually if the Annex is supposed to be ***just*** for adding weight to the transaction so that we can do something like increase limits on SCRIPT execution, then it does *not* have to be covered by any signature. It would then be third-party malleable, but suppose we have a "valid" transaction on the mempool where the Annex weight is the minimum necessary: * If a malleated transaction has a too-low Annex, then the malleated transaction fails validation and the current transaction stays in the mempool. * If a malleated transaction has a higher Annex, then the malleated transaction has lower feerate than the current transaction and cannot evict it from the mempool. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
