The Ord instance of MintsRedeemer and the Eq instance of TxSkelOut were implemented as comparing the on-chain representation of the data they describe, throwing away the type information in existential types hidden in their constructors.
For example, with this PR, Pays a == Pays b can only evaluate to true if a and b are of the same type. At the moment, they are considered equal if they have the same TxInfo representation. This means for example that the current Eq instance cannot distinguish between
outputs with different, but isomorphic, data types,
outputs with different reference script types (hash vs. script vs. typed validator),
...
The second case actually happened in the tests for the datum hijacking attack, and I adapted the reference scripts on all of the smart constructors for transaction outputs without explicit reference scripts (like paysScript, paysPK, ...) to be Nothing @(Pl.Versioned Pl.Script) (instead of Nothing @(Pl.TypedValidator Pl.Any) as before). This is the most generic choice and conforms with the return type of txSkelOutOwnerTypeP, which the attack relies on.
The
Ordinstance ofMintsRedeemerand theEqinstance ofTxSkelOutwere implemented as comparing the on-chain representation of the data they describe, throwing away the type information in existential types hidden in their constructors.For example, with this PR,
Pays a == Pays bcan only evaluate to true ifaandbare of the same type. At the moment, they are considered equal if they have the sameTxInforepresentation. This means for example that the currentEqinstance cannot distinguish betweenThe second case actually happened in the tests for the datum hijacking attack, and I adapted the reference scripts on all of the smart constructors for transaction outputs without explicit reference scripts (like
paysScript,paysPK, ...) to beNothing @(Pl.Versioned Pl.Script)(instead ofNothing @(Pl.TypedValidator Pl.Any)as before). This is the most generic choice and conforms with the return type oftxSkelOutOwnerTypeP, which the attack relies on.