Gas cost benchmarks for cashing winning tickets

Nobody has claimed this yet.

Cashing winning tickets will require a fixed number of cryptographic operations (i.e. hashing, signature checks, etc.). Thus, the gas cost for a transaction to cash a single winning ticket should be constant. This information will be important to recipients as the gas cost along with the current average gas price on Ethereum will affect how tickets should be parameterized - during times of higher gas prices, the face values of tickets will need to be higher in order for recipients to profitably cash winning tickets on-chain (since the Ethereum transaction cost will also be higher).

The initial implementation does not need to worry about gas usage optimizations and should be solely focused on implementing the correct logic for winning ticket validation (along with the other required contract functionality). Subsequent iterations can explore the use of Solidity inline assembly to decrease the gas costs of operations within the contract (the last I checked Solidity has a good amount of overhead that can be shaved off when dropping down to assembly). We should eventually have gas cost benchmarks for both a regular implementation (this is the first priority) and an optimized implementation.

- [ ] Gas cost benchmark for cashing a single wining ticket with a regular non-optimized implementation
- [ ] Gas cost benchmark for cashing a single winning ticket with an optimized (i.e. Solidity inline assembly) implementation

The issue names no files or tests. Start by locating the contract logic that validates and cashes a winning ticket, then measure gas for one winning-ticket cashout in the regular implementation. Done means recording benchmarks for both the regular and Solidity inline-assembly implementations.

Written by the indexing model from the issue text.