Explore courtesy calls challenges

[mhluongo]

Rather than requiring a courtesy call to use the price feed, consider a griefing-proof mechanism that allows uncontested courtesy calls to avoid using a price feed. Only fall back to the feed in case a call is contested- in which case we need to punish the griefer.

This should save a bunch on gas done properly, since we can only require a populated price feed on challenges.

cc @prestwich

[NicholasDotSol]

I like that, will need to add some restrictions to notifyCourtesyCall() to make sure the caller can be punished.
Challenge is claimGriefedCourtesyCall() will need to retrieve price at the timestamp set bynotifyCourtesyCall()

[prestwich]

This requires management of another bond, which may break assumptions we've made around transfers. Of course, those all need to be reviewed and maybe rewritten anyway.

Suggested behavior: the notifier bond is in ETH. if the challenge proves baseless, the bond is distributed to the signers by adding it to their collateral pool.

Challenge is claimGriefedCourtesyCall() will need to retrieve price at the timestamp set bynotifyCourtesyCall()

this actually is a bigger challenge than it seems, @mhluongo. Do we use the price at challenge time? or the price at response time? If we use response time, the challenger may forfeit the bond despite having behaved honestly. If we use challenge time, we need a retroactive oracle price

[mhluongo]

This seemed like a great idea initially, but an oracle that doesn't submit to the chain but can still prove old times is annoying- eg we'd be creating some sort of off-chain signature relay or hashchain that's optionally provable on challenge. The alternative is assuming a Schelling-based feed which has issues with parasitic interest.

Let's revisit this after mainnet

[mhluongo]

Obsoleted by #254