Function to decide when two `Constraints` are semanically equal

[carlhammann]

The Constraints type has an Eq instance, which implements a very fine notion of equality. That's good, as we discussed when we defined it. Sometimes, however, we want to compare two Constraints and the question we have in mind is "Do they describe the same transaction?".

In the current reworking of the attack framework, the function sameConstraints tries to answer that question. At the moment, is is only used to make the modified transactions generated by the doubleSatAttack unique. There's also assertSameConstraints, which is based on the same logic and is used in a few test cases.

The function sameConstraints identifies the following:

• Constraints that differ by a reordering of input (i.e. SpendsPK and SpendsScript) constraints: Transactions are supposed to have set of inputs but a list of outputs. See the EUTXO paper (search "for set of inputs").
• Constraints that specify the same validity time range: [Before b, After a] :=>: os and [ValidateIn $ Interval a b] :=>: os are equivalent, for example.
• Constraints that mint the same values with the same redeemers: [Mints a _ (v1 <> v2), Mints b _ v3, Mints b _ v4] :=>: os and [Mints a _ v1, Mints b _ (v3 <> v4), Mints a _ v2] :=>: os are equivalent, where the underscores denote the needed lists of minting policies.

The question is

• whether these identifications really hold, looking at how things are implemented at the moment, and
• whether we could (and should) in fact identify even more.

At the moment, since the use of sameConstraints is still very limited, the worst thing that can happen is the double satisfaction attack generating slightly too many or few cases; for the future I think that we should get some function like sameConstraints right.

[carlhammann]

For the record: The implementation of sameConstraints I linked above is wrong. It identifies, say, [Mints a _ 1, Mints a _ 4]and [Mints a _ 3, Mints a _ 3].

Edit: The mistake is corrected in this commit, but the questions above still stand. Maybe they're even better illustrated....