user2077: Most types in Plutus are simply wrappers around BuiltinByteString. For instance the bytes in PubKeyHash are not serialized/deserialized to an actual pubkey hash and checked for correctness. So basically any bytestring can be inserted here. A malicious actor could easily block spending a script utxo by adding an invalid pubkey hash.
Is there a way to enforce this/let the validator check the pubkey hash for correctness?

user2629: You should be extra careful with data that is being provided to smart contracts by the user. You might prevent user errors by using data from the Context that is already provided to you inside the Plutus script.
From the discussion around answers I'm getting a feeling that the malicious actor is only able to "break" the logic in such a way that is unfavourable for him only.
ScriptContext{scriptContextTxInfo{txInfoSignatories}} gives you access to the public key hashes, in this case Person B public key hash when he consumes initial utxo and is creating a new one.

user1130: Hopefully I'm following your question...
I'm not aware of any type checks performed at validation, but I'm also not aware of any situation that a validator/script would need to spend resources preventing this.
In other words, scripts generally operate under the assumption that proper off-chain code is being used in tandem with the on-chain script. The off-chain code does have type checks.
There is always the threat that a malicious actor will go around the expected off-chain code to abuse the script. The onus is on a script developer to write a script that checks for correct values--I am having a hard time thinking of a situation that someone giving the wrong type and that value being misinterpreted as the correct value.

You give the example of a "malicious actor [blocking the] spending [of] a script utxo by adding an invalid pubkey hash." I don't understand how this case is different from the malicious actor sending a random, un-owned pubkey. In both cases it would prevent the spending of the UTxO.
EDIT:
It sounds like at least in the case of PubKeyHash, which by default has no checks on bytestring length, it is possible to submit and validate against invalid pubkeys. Unfortunately, you can't just rely on type check :(.
It is the script writer's responsibility to understand this limitation and include protection for counterparties. For example:

Force a redeemer to use the pubkey that matches the signer of the tx in the context. That way the pubkey always a pre-verified valid pubkey OR
Include additional intermediary datums that can hold funds in escrow for a (potentially invalid) recipient pubkey OR
Check the length of the bytestring to ensure it could be a valid pubkey

Generally, while writing Plutus scripts you try to avoid over-constraining the logic. Since the PubKeyHash type problem isn't obvious, the above solutions might come across as overconstrained or overcomplicated to those outside the know. Documentation is warranted. Hopefully we can get better types for these things in the future to push devs and readers into a pit of success.

2077: <p>Most types in Plutus are simply wrappers around BuiltinByteString. For instance the bytes in PubKeyHash are not serialized/deserialized to an actual pubkey hash and checked for correctness. So basically any bytestring can be inserted here. A malicious actor could easily block spending a script utxo by adding an invalid pubkey hash.
Is there a way to enforce this/let the validator check the pubkey hash for correctness?</p>
 2629: <p>You should be extra careful with data that is being provided to smart contracts by the user. You might prevent user errors by using data from the Context that is already provided to you inside the Plutus script.</p>
<p>From the discussion around answers I'm getting a feeling that the malicious actor is only able to &quot;break&quot; the logic in such a way that is unfavourable for him only.</p>
<p><code>ScriptContext{scriptContextTxInfo{txInfoSignatories}}</code> gives you access to the public key hashes, in this case Person B public key hash when he consumes initial utxo and is creating a new one.</p>
 1130: <p>Hopefully I'm following your question...</p>
<p>I'm not aware of any type checks performed at validation, <strike>but I'm also not aware of any situation that a validator/script would need to spend resources preventing this.</strike></p>
<p>In other words, scripts generally operate under the assumption that proper off-chain code is being used in tandem with the on-chain script. The off-chain code <em>does</em> have type checks.</p>
<p>There is always the threat that a malicious actor will go around the expected off-chain code to abuse the script. The onus is on a script developer to write a script that checks for correct values--I am having a hard time thinking of a situation that someone giving the wrong type and that value being misinterpreted as the correct value.</p>
<hr />
<p>You give the example of a &quot;malicious actor [blocking the] spending [of] a script utxo by adding an invalid pubkey hash.&quot; I don't understand how this case is different from the malicious actor sending a random, un-owned pubkey. In both cases it would prevent the spending of the UTxO.</p>
<h2>EDIT:</h2>
<p>It sounds like at least in the case of PubKeyHash, which by default has no checks on bytestring length, it is possible to submit and validate against invalid pubkeys. Unfortunately, you can't just rely on type check :(.</p>
<p>It is the script writer's responsibility to understand this limitation and include protection for counterparties. For example:</p>
<ul>
<li>Force a redeemer to use the pubkey that matches the signer of the tx in the context. That way the pubkey always a pre-verified valid pubkey OR</li>
<li>Include additional intermediary datums that can hold funds in escrow for a (potentially invalid) recipient pubkey OR</li>
<li>Check the length of the bytestring to ensure it could be a valid pubkey</li>
</ul>
<p>Generally, while writing Plutus scripts you try to avoid over-constraining the logic. Since the PubKeyHash type problem isn't obvious, the above solutions might come across as overconstrained or overcomplicated to those outside the know. Documentation is warranted. Hopefully we can get better types for these things in the future to push devs and readers into a pit of success.</p>
