Added reserve_vote_weight configuration option.

This will allow flexibility when using bots that also vote on other things. It will reserve a specified amount of voting power in each batch. If you specify 10.00 %, then it will calculate the batch starting at 10.00 % utilization. The highest bids will still get the same payout, but lower bids will not be processed.

In this example, you can then use up to 10.00 % per voting window to vote on other things.

Added rake bounce_stream which will return bids immediately, if they are invalid.

If enabled, this task will return bids if they cannot be voted on, for example, if someone bids on an article that is passed payout.

Improved test coverage.

More of the functionality has been added to tests, which guards against regression.

Improved logging.

Logging to the console is now less verbose. Debug messages are now written to drotto.log instead.

Added a guard to prevent overvoting.

Prior to this fix, all bids were being evaluated, even if voting exceeded the batch limit. This would slowly reduce voting effectiveness over time.

Process voting transactions in critical sections.

Voting queues asynchronously, but actual voting only happens one vote at a time. This speeds up performance and reduces memory usage.

The queue is scheduled with staggered threads.

Added rake run_once for better flexibility.

The run_once task votes on each window once, then terminates. This allows admins to use an external script or cron to schedule voting, rather than rely on the run task internal scheduler.

All bounce tasks now avoid the current timeframe; uses a single transaction.

When using bounce tasks, the current timeframe is left unprocessed so that the main run or run_once tasks can work without worrying about a race condition.

All bounce operations are submitted in one transaction per window.

Added bid stacking.

If multiple bids come in for a single post, they are stacked into one larger bid.

---

The biggest reference implementation for Dr. Otto is @booster:

• 2.4 hours voting windows (10 voting windows each day).
• Each window, 100.00 % upvote are split between the highest bidders.
• Unaccepted bids returned.

@booster FAQ

Q: Why vote every 2.4 hours?

A: That is the exact amount of time it takes to recharge its voting power.

Q: What happens if the transfer is sent just before payout?

A: No upvote will happen in that case. The blockchain does not allow upvotes 12 hours before payout.

Q: Can voting only be done on posts or can comments work as well?

A: Both posts and comments are acceptable.

Q: What happens when 2 different accounts vote on the same post?

A: Any transfers by any accounts to the same post within the same timeframe will try to stack (combine) into one bid. Please note, the bot cannot stack bids if a vote has already been cast.

Q: Can I get a refund if I don't get an upvote?

A: Unaccepted bids are returned.

Q: Can @booster be used for downvotes?

A: No.

---

Original Announcement: Dr. Otto: Vote Bidding Bot