đź“… Original date posted:2022-03-04
đź“ť Original message: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
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-07 23:05:28
in reply to nevent1q…n2nt
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 23:05:28Event JSON
{
"id": "29190300fd5ffa1065102f9e94187802c03e9f6115b58e5d0e1d5806610873fd",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686179128,
"kind": 1,
"tags": [
[
"e",
"275d0934503bf4ebbe2fb275caaa5a2fbdf6c86346fca7b0f2bf5d1837954531",
"",
"root"
],
[
"e",
"d9798fe0746b18def6cba98deca8ca9ea66c17e9250a6cf022680caa73f5e21a",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "📅 Original date posted:2022-03-04\n📝 Original message:Good morning Jeremy,\n\nUmm `OP_ANNEX` seems boring ....\n\n\n\u003e 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:\n\u003e\n\u003e 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.\n\u003e 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...\n\u003e\n\u003e But recall that the annex is committed to by the signature.\n\u003e\n\u003e 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.\n\n... Never mind I take that back.\n\nHmmm.\n\nActually 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.\nIt would then be third-party malleable, but suppose we have a \"valid\" transaction on the mempool where the Annex weight is the minimum necessary:\n\n* If a malleated transaction has a too-low Annex, then the malleated transaction fails validation and the current transaction stays in the mempool.\n* 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.\n\nRegards,\nZmnSCPxj",
"sig": "fe8c668e690423fd26bdeb045b0057dc7cf7609950d67aca9a561fdd9737a22fa9e852cead6824e61afc54c34e90fddebc3751089883a4caa1a55925087538d4"
}