Fake it till you make it.. how would we catch this hard-coded committedValue with only a single healthyCommitTx?
import qualified Hydra.Contract.Commit as Commit
import Ledger.Typed.Scripts (TypedValidator, ValidatorTypes (..))
import qualified Ledger.Typed.Scripts as Scripts
import Plutus.V1.Ledger.Ada (adaValueOf, fromValue, getLovelace, lovelaceOf, lovelaceValueOf)
import qualified PlutusTx
import PlutusTx.IsData.Class (ToData (..))
checkOutputValue
where
checkOutputValue =
traceIfFalse "checkOutputValue" $
valueProduced txInfo == initialValue + committedValue
traceIfFalse "commitLockedValue does not match" $
traceIfFalse ("commitLockedValue: " `appendString` debugValue commitLockedValue) $
traceIfFalse ("initialValue: " `appendString` debugValue initialValue) $
traceIfFalse ("comittedValue: " `appendString` debugValue committedValue) $
commitLockedValue == initialValue + committedValue
initialValue =
maybe mempty (txOutValue . txInInfoResolved) $ findOwnInput context
committedValue = valueLockedBy txInfo commitValidator
committedValue = lovelaceValueOf 8_000_000
commitLockedValue = valueLockedBy txInfo commitValidator
debugValue = debugInteger . getLovelace . fromValue
-- | Show an 'Integer' as decimal number. This is very inefficient and only
-- should be used for debugging.
Other small changes include: * Added a trace event `TDBInitialisingFromLMDBDone`. * Initialisation from an existing LMDB database does not rely on the default `LMDBLimits` anymore, and is passed a limits argument instead. TODO: We should decide whether we want to hardcode these limits to a a substantially large one, or possibly we could link these limits to a versioning number?
add cwbtc
attempt implementation
Other small changes include: * Added a trace event `TDBInitialisingFromLMDBDone`. * Initialisation from an existing LMDB database does not rely on the default `LMDBLimits` anymore, and is passed a limits argument instead. TODO: We should decide whether we want to hardcode these limits to a a substantially large one, or possibly we could link these limits to a versioning number?
![iohk-bors[bot]](https://avatars.githubusercontent.com/in/17473?v=4&s=80)
Updated crypto exchange rates chapter. I tried my best to address @rdlrt concerns. I would like to add that English is just my 3rd language, so I hope it is not too bad.
Previously, the sequence number of the database is written to disk as part of the on-disk database settings on every flush/write. Conceptually however, the settings of a database should not change on every flush or write. Instead, we make a dinstinction between on-disk database "settings" and "state", where the state can be updated in every write/flush, but the settings should generally be left untouched after database initialisation or node start-up.
Fixes #217.
This works because (a) JavaScript is ultimately single-threaded, (b) there's no execution preemption happening between a 'send' and a 'wait'.
This was using the raw Show instance of queries, which looks real bad for constructors with arity > 1 like HasTx.