Monad attacks

[carlhammann]

This PR defines

newtype Attack a = Attack (MockChainSt -> TxSkel -> [(TxSkel, a)])

and uses the fact that this type is a monad with branching and failure capabilities to rework our attack language. A good first example to see this in action is probably the simplest of the "big" attacks: The token duplication attack.

This is not yet completely finished, in particular:

• [x] I still need to update the tests for the double satisfaction attack.
• [x] The attacks in Cooked.Attack.AddConstraints are heavily biased towards input constraints, because that's what I needed so far. This should be made more symmetric.
• [x] The same holds for Cooked.Tx.Constraints.Optics
• [x] Make cooked export all of the LTL and Attack framework.

However, it's ready for feedback and review!

If merged, this PR will close #143 .

[facundominguez]

I edited my review to add nothing less than the positive feedback. Please, excuse me for the hiccup.

[carlhammann]

So, let me summarise the state of this PR:

• There are several voices that do not like the "attack" nomenclature any more. I guess I'm one of them, by now. There are these ideas at the moment (which are independent):
  • Always import the attack modules qualified, which alllows renaming all functions like xAttack to x.
  • Change the language of the comments from "attack" to "modification" or something similar.
  • Rename the AddConstraints module to PushPopConstraints.
• The role of functions like mkAccumLAttack that rely on optics to build attacks is not clear enough.
  • In particular, what is "left to right"? (It depends on your optic, so is there a better wording?)
• There are some questions about details left:
  • Is the documentation of the doubleSatAttack understandable now? In particular, is it clear what it does with TryCombinations?
  • Do we agree that sameConstraints is a sensible "semantic" equality relation on Constraints?
  • (How) should the functions in Attack.AddConstraints respect this equality?

[carlhammann]

I think that my last question is interesting enough to warrant its own issue, which I opened: #165. For the purposes of this PR, I think we should leave sameConstraints as it is.

[carlhammann]

In my perception, after talking to many of you, all unanswered questions are now recorded as issues, and only these two remain:

• Is the documentation of the doubleSatAttack understandable now? @facundominguez and @lucaspena were the ones who were, rightfully, most unhappy with it.
• Do we have a better word than "Attack"? Both @mmontin and @0xd34df00d were unhappy with it, and I'm as well. I'd like to rename everything apart from the "real" attacks like token duplication, double satisfaction,..., to something else. For our group, it's clear by now that an attack is just something that changes a transaction, but for outsiders, I think that the word comes with too many expectations attached to it. That is, what should the name of the Attack type become? I quite like Tweak: It sounds like a small adjustment, which arguably is what most of the "xAttack" functions do, and a combination of tweaks with malicious intent is an attack.

[facundominguez]

Is the documentation of the doubleSatAttack understandable now?

I think is much better. Thanks.

Do we have a better word than "Attack"?

Tweak is good. Should it be plural? An attack can produce more than one modification, right? A long name would be TransactionModifications which could be compressed to TxMods perhaps.