This PR implements protection for oracle pack race condition
The oracles currently use "global" state variables to keep track of the last person to call pack successfully, how much they paid, and what token they would like to be rewarded in. There's a potential race condition here:
Alice calls pack, which triggers an asynchronous request to Oraclize for data.
Bob calls pack.
Oraclize calls __callback for Alice's request, but Bob is paid the reward.
Oraclize cals __callback for Bob's request, and Bob is paid again.
This risk is mitigated by the use of a cool down period. The lag state variable is used to keep track of the next valid time a call to pack can be made, and it is intended to be sufficiently long that a request to Oraclize or Chainlink will complete before a subsequent request can be made.
Currently there is a cool down period of 15 minutes. However, no cool down period is sufficiently long to handle failures that may occur (e.g. Oraclize having downtime).
A better approach might be to keep track of this data per request and reward accordingly no matter when the results arrive. Doing this also makes it easy to ensure the same request isn't fulfilled twice.
This PR implements protection for oracle pack race condition
The oracles currently use "global" state variables to keep track of the last person to call pack successfully, how much they paid, and what token they would like to be rewarded in. There's a potential race condition here:
Alice calls
pack, which triggers an asynchronous request to Oraclize for data. Bob callspack. Oraclize calls__callbackfor Alice's request, but Bob is paid the reward. Oraclize cals__callbackfor Bob's request, and Bob is paid again. This risk is mitigated by the use of a cool down period. The lag state variable is used to keep track of the next valid time a call topackcan be made, and it is intended to be sufficiently long that a request to Oraclize or Chainlink will complete before a subsequent request can be made.Currently there is a cool down period of 15 minutes. However, no cool down period is sufficiently long to handle failures that may occur (e.g. Oraclize having downtime).
A better approach might be to keep track of this data per request and reward accordingly no matter when the results arrive. Doing this also makes it easy to ensure the same request isn't fulfilled twice.