Simplify Lovelace type

[dcoutts]

The Lovelace type and operations currently enforce a 45billion limit. This is indeed the limit, but the argument is that this is the wrong place to enforce it.

Just as we concluded that for the specification we should use signed types for currency, and enforce that tx outputs be non-negative, the same logic applied to lovelace suggests that we should not enforce the limits in the type but in the appropriate places in the ledger rules.

We do still have to be careful about integer overflow when checking the ledger rules: if we use 64bit values for tx outputs then the sum of these must not overflow before we compare with the sum of inputs.

Concretely, the suggestion is that we analyse changing the Lovelace type to be a Word64 (as it is now) but without any special upper bound (deriving Bounded). We would eliminate LovelaceTooLarge and LovelaceTooSmall but keep LovelaceOverflow and LovelaceUnderflow. Our QC generators should then also generate maxBound sometimes.

[kevinhammond]

I’d be inclined to do both. A type can always be eliminated in an implementation if it’s known to always be satisfied by the type checker. This avoids issued if there’s a bug in the proof for example . Likewise with the currency. Enforce the constraints in the implementation. There’s no good reason not to and it may save a problem as well as reducing testing.