This reverts commit 0027672c8075d063f376c8c84e1cce77d572d353.
SCRIPT_VERIFY_MINIMALIF is a misguided malleability fix. What it does make sure that the boolean input consumed by an IF or NOTIF is exactly "" or "01" (a minimally encoded zero or one). This is motivated by the fact that many simple scripts allow the spender to choose between two or more alternate pathways by putting a the branching values at the top of the witness stack. Without MINIMALIF, those witness values could be malleated by anyone. Now there are two points to be made regarding this:
First of all, the particular motivating use case is largely going away with the introduction of MAST for alternative spend pathways. Rather than have a single script with two branching pathways chosen by a boolean value on the witness stack, the two alternative scripts are encoded in a Merkle tree and only one is extracted at spend time. In the construction used, these Merkle proofs are not malleabile.
Second and perhaps more importantly, the motivating use case for MINIMALIF does not describe all uses of IF/NOTIF. In particular, the construct "either a signature using key X is provided, or a lock-time of Y is satisfied" can be expressed in script as IFDUP IF <x> CHECKSIGVERIFY ELSE <y> CHECKLOCKTIMEVERIFY ENDIF, or something to that effect. In this script the signature itself is used as the branching condition: if the signature if provided then the IF branch is taken, but if the signature is zero-valued, then the lock-time is validated instead. These and other related use cases are the most common, and indeed primary uses of IF/NOTIF in a post-MAST environment.
So with that in mind, it appears that MINIMALIF is not so great an idea after all. Rather than make it policy and eventual consensus-enforcement as was done with bitcoin's segwit and tapscript, we roll it back. We have no use for SCRIPT_VERIFY_MINIMALIF in Tradecraft.
This reverts commit 0027672c8075d063f376c8c84e1cce77d572d353.
SCRIPT_VERIFY_MINIMALIFis a misguided malleability fix. What it does make sure that the boolean input consumed by anIForNOTIFis exactly""or"01"(a minimally encoded zero or one). This is motivated by the fact that many simple scripts allow the spender to choose between two or more alternate pathways by putting a the branching values at the top of the witness stack. WithoutMINIMALIF, those witness values could be malleated by anyone. Now there are two points to be made regarding this:First of all, the particular motivating use case is largely going away with the introduction of MAST for alternative spend pathways. Rather than have a single script with two branching pathways chosen by a boolean value on the witness stack, the two alternative scripts are encoded in a Merkle tree and only one is extracted at spend time. In the construction used, these Merkle proofs are not malleabile.
Second and perhaps more importantly, the motivating use case for
MINIMALIFdoes not describe all uses ofIF/NOTIF. In particular, the construct "either a signature using key X is provided, or a lock-time of Y is satisfied" can be expressed in script asIFDUP IF <x> CHECKSIGVERIFY ELSE <y> CHECKLOCKTIMEVERIFY ENDIF, or something to that effect. In this script the signature itself is used as the branching condition: if the signature if provided then theIFbranch is taken, but if the signature is zero-valued, then the lock-time is validated instead. These and other related use cases are the most common, and indeed primary uses ofIF/NOTIFin a post-MAST environment.So with that in mind, it appears that
MINIMALIFis not so great an idea after all. Rather than make it policy and eventual consensus-enforcement as was done with bitcoin's segwit and tapscript, we roll it back. We have no use forSCRIPT_VERIFY_MINIMALIFin Tradecraft.