cooked-validators-4.0.0
Safe HaskellSafe-Inferred
LanguageHaskell2010

Cooked.Attack.DoubleSat

Description

This module provides an automated attack to try and perform double satisfaction on a contract.

Synopsis

Documentation

type DoubleSatDelta = (Map TxOutRef TxSkelRedeemer, [TxSkelOut], TxSkelMints) Source #

A triple of transaction inputs, transaction outputs, and minted value. This is what we can add to the transaction in order to try a double satisfaction attack.

doubleSatAttack Source #

Arguments

:: (MonadTweak m, Eq is, Is k A_Traversal) 
=> ([is] -> [[is]])

how to combine modifications from caused by different foci. See the comment at combineModsTweak, which uses the same logic.

-> Optic' k (WithIx is) TxSkel a

Each focus of this optic is a potential reason to add some extra constraints.

As an example, one could go through the paysScript outputs for validators of type t with the following traversal:

txSkelOutsL % itaversed % txSkelOutputToTypedValidatorP @t
-> (is -> a -> m [(a, DoubleSatDelta)])

How to change each focus, and which inputs, outputs, and mints to add, for each of the foci. There might be different options for each focus, that's why the return value is a list.

Continuing the example, for each of the focused paysScript outputs, you might want to try adding some spendsScript inputs to the transaction. Since it might be interesting to try different redeemers on these extra spendsScript inputs, you can just provide a list of all the options you want to try adding for a given paysScript that's already on the transaction.

###################################

ATTENTION: If you modify the state while computing these lists, the behaviour of the doubleSatAttack might be strange: Any modification of the state that happens on any call to this function will be applied to all returned transactions. For example, if you awaitTime in any of these computations, the doubleSatAttack will wait for all returned transactions.

TODO: Make this interface safer, for example by using (some kind of) an UtxoState argument.

###################################

-> Wallet

The wallet of the attacker, where any surplus is paid to.

In the example, the extra value in the added spendsScript constraints will be paid to the attacker.

-> m () 

Double satisfaction attack. See the comment above for what such an attack is about conceptually.

This attack consists in adding some extra constraints to a transaction, and hoping that the additional minting policies or validator scripts thereby involved are fooled by what's already present on the transaction. Any extra value contained in new inputs to the transaction is then paid to the attacker.

Orphan instances