Is function "isPayToScriptOut" unsafe?

Question

As far as i understood, function "isPayToScriptOut" assumes every output that has a datum hash is a script output. But what if we create new output with datum, assigned to some pub key (for example due to use of: "mustPayWithDatumToPubKey" in off-chain code). So our new output wont be related to script one, but "isPayToScriptOut" will return true in this case? Because datum hash can be attached to any transaction. And that makes "isPayToScriptOut" not safe enough for development.

My deductions are correct?

*Here is considered function's code from plutus library:

 -- | Whether the output is a pay-to-script output.
    isPayToScriptOut :: TxOut -> Bool
    isPayToScriptOut = isJust . txOutDatum

    txOutDatum :: TxOut -> Maybe DatumHash
    txOutDatum TxOut{txOutDatumHash} = txOutDatumHash

Answer 1

Your deductions are partially correct. isPayToScriptOut looks at the credentials of an address (1) and return true if it is a script address, false if it is a public key credential. It thus does not look at the datum, it can deterministically check whether an output is made at a script address.

Here comes the crux, currently there are two types of scripts, native scripts and plutus scripts (V1 or V2). This function and the credential data type do not encode or differentiate between these scripts!

So in conclusion, you do know that that address is locked by a script, but you do not know what kind of script it is. It could be a native script locked by just a single public key.

This might change due to this CIP (2). It aims to add a distinction between the types of scripts we have on the ledger.

EDIT A previous version of plutus indeed did use the datum for this function (3). Note that this haddock host an outdated version of what is available in plutus. I would recommend using a local, up-to-date version. You can build this in the plutus-apps repo by entering a nix-shell and executing build-and-serve-docs.

Luckily, both the new plutus V1 (4) and V2 (5) implementations of these helper functions now implement it via the credentials. But note that the argument about it being unsafe due to not knowing what kind of script belong to a credential still holds.