tasty-plutus: excessive type safety could hide bugs

[AriFordsham]

Since 6.0, TestData has encoded the token-minting instructions as a (list of) MintingPolicyTask which is constructed with separate functions for burn and mint, which cannot be passed negative values. This ensures the correct action is always performed.

However, forgetting to account for the wrong sign is a understandable source of bugs with potentially devastating scope. It would be more useful if property testing by default tested with positive and negative numbers to ensure these are caught.

[kozross]

What do you mean by 'forgetting to account for the wrong sign' here? I'm not quite following what kind of issue you're expecting to catch.

[AriFordsham]

Naively allowing e.g. liberal permissions for token burning while forgetting to check that the quantity is not positive.

[AriFordsham]

I kind of just ran into this.

[sergesku]

@AriFordsham I`m not sure what you mean.

Blockchain MintingPolicy doesn't have separate actions for minting and burning. It works with positive and negative Integers.

When constructing we specify a MintingPolicyTask with a MintingAction and a Positive amount of Tokens

data MintingPolicyTask = MPTask MintingPolicyAction Tokens

data Tokens = Tokens TokenName Positive

data MintingPolicyAction = BurnAction | MintAction

When we create a ScriptContext we process the MintingPolicyTask and specify an Integer sign

processMPTask :: MintingPolicyTask -> (TokenName, Integer)
processMPTask (MPTask action (Tokens tn pos)) =
  let i = case action of
        MintAction -> getPositive pos
        BurnAction -> negate $ getPositive pos
   in (tn, i)

If I missed something, could you provide a detailed example.

[AriFordsham]

I just wrote a minting policy which had restrictive mint conditions, but liberal burn. I accidentally omitted the sign check on the burn action, allowing basically unrestricted minting. If the testing default would be to test positive and negative numbers I think I would have caught it faster.

[sergesku]

I still believe, that our implementation covers all cases.

As I understand it, by mint conditions you mean something like (AssetClass, 5), and by burn conditions something like (AssetClass, -5).
And it doesn't make sense to check the sign of the burn action because it's always negative. If the action has the positive sign, it is a mint action.

I can be very wrong. Therefore, please give a detailed example (code) of a MintingPolicy with a description of which case we cannot cover with our model. Catching abstract bugs is very difficult for me.