Author: ZmnSCPxj 2022-03-04 23:33:10
Published on: 2022-03-04T23:33:10+00:00
In this message, the sender initially suggests that banning the use of OP_ANNEX may solve some issues. They argue that if it were meant to be accessible via script, it would not have been removed from the stack and may have been included as an opcode in taproot. However, they note that the annex is committed to by signature, meaning that it may still be possible to use clever tricks to get it onto the stack again. Later in the message, the sender reconsiders their initial suggestion and suggests that if the Annex is only meant for adding weight to a transaction, then it does not need to be covered by any signature. This would make it third-party malleable. They propose that if a malleated transaction has a lower Annex than the original, it fails validation and the current transaction stays in the mempool. If it has a higher Annex, it cannot replace the original in the mempool due to a lower feerate.
Updated on: 2023-06-15T17:39:05.971748+00:00