Round initializer incentive Smart-contract

[iameli]

@marczeller commented on Mon Feb 18 2019

What's the problem? (required) Sometime delegators don't call the function initializeRound() or do it quite late. Currently it's a "tragedy of the common" game theory scenario. Everybody benefits from that function being called but no one have the direct incentive to pay gas to call it. the better individual scenario is to wait that another actor assume the cost himself and get the benefits without the cost. Do you have any personal experiences dealing with this problem? (optional) As a user i'd called the function 5 times, that's not my job. Describe a possible solution you've considered (optional) A bounty smart-contract monitoring the blockchain and granting a small reward to the address doing a successful call of initializeRound(). That will create a "winner take all" situation with probably front-running bots trying to collect the reward. Those rewards can be founded by Livepeer Team + Transcorders. Additional context (optional) Objective :

• write a simple and dumb SC with following expected behaviour

1. can collect reward in ETH/LPT/DAI
2. can monitor 0x3984fc4ceeef1739135476f625d36d6c35c40dc3 and check non-reverted; non-out of gas but valid initializeRound() call
3. Check Gaslimit and gas price of initializeRound() call (or just transaction fee paid) and address of the caller
4. send Transaction fee paid + reward amount to the caller ETH address or at least : have a function "collect reward" that can be called with input parameters call address; round
5. have a Failsafe check in that function : "if Txfee > "threshold" then send only reward amount.

it's an open discussion we have to consider : Do we pay in ETH ? In LPT ? in DAI ? a mix ? What is the amount of the reward ? something fixed and hardcoded ? a ratio of the reserves of the smart contract ? what should be the failsafe "threshold" ? if we don't have one, troll caller can use very high gasprice to dry out the smart contract reserves. if it's too high it's ineffective, if it's too low contract will be useless in high gas price market events.

when this issue will be mature enough, i'll issue a bounty on it.

---

@iameli commented on Mon Feb 18 2019

Thanks for this write-up, sounds like a good idea! I'm not sure that this repo is the best place for it, this one doesn't contain any of the smart contract logic — https://github.com/livepeer/protocol perhaps?

[iameli]

(@marczeller I didn't really know what the "move issue" button did. Guess it did this! ¯\(ツ)/¯ You're welcome to keep using this ticket or to close and re-open if you'd like to own the issue on this repo.)

[marczeller]

About the threshold i'll suggest 3000000 gas units at 25 Gwei gasprice as the upper limit "hardcoded" : that's 0.075 ETH should be more than enough in most gas market conditions

about the reward, even something symbolic can work as it's "free money" so 0.01 ETH should be more than enough

having "hardcoded" value have many flaws but can greatly simplify the smart-contract design. in Ethereum dumb and simple is often better than over-engineering.

[dob]

One idea I had was that the contract owner just sets an endRound, and then the contract keeps track of lastCallRound. Whatever the total bounty balance in the contract is in any round, the payout is just proportional to how many rounds are left before endRound. So for example

payout = bounty * ((round - lastCallRound) / (endRound - lastCallRound))

This way anyone can always increase the bounty by sending more ETH or LPT to the contract at any time. The contract would need to be redeployed, or the owner could update endRound after endRound has passed.