Tickets to buy doesnt consider updated balance

[raedah]

Tickets are only queued for purchase once, which seems to be at the beginning of the stake window or when when when the ticket buyer is launched. When the wallet balance changes during the window, the number of tickets to buy is not updated.

[raedah]

This looks to be a strong contributing factor in keeping the price destabilized. It allows funds that could be spent to instead build up in the wallet, and then get spent a few windows down when the amount accumulated is larger. With no dcrticketbuyer being able to steadily place its buys on to the market the price will continue to reflect this pressure build up.

[raedah]

Noting that forced buying with minpricescale does actually use all funds available.

[cjepson]

This is the intended behaviour when mixpricescale is not set. If the price is considered "good" enough, the ticket queue should always be large enough to continuously buy until funds are exhausted, unless maxpricescale is on and limits it.

[raedah]

@cjepson since the ticket queue size is calculated at the beginning of the window, funds received later are not taken into account (from deposits or voted tickets), so the queue is not large enough and does not exhaust all funds. @tuxcanfly's issue #42 does seem to address this.

[alexlyp]

42 was not a correct attempt to fix the problem you described, and as such closed. We will be producing an RFP in near future to make ticketbuyer more intelligent and able to balance self-incentives and market incentives. This applies to your comments concerning #22 as well. But feel free to submit PRs that make it work in the way you describe.

[cjepson]

@raedah I see what you're saying now. That's a little more complicated to solve and probably involves some refactoring of the way the number of tickets to buy is selected.

@tuxcanfly There isn't an easy way to fix this, and triggering the ticket purchasing on balance updates will not help this issue either. You would probably have to try to estimate how many tickets to buy on a per block basis instead of a per window period basis.

[cjepson]

Okay, I think the way to handle this would be to store the penalty and the balance at the start of the ticket difficulty period. If the currentBalance > previousBalance, adjust the number of tickets to buy and, if necessary, rescale based around the penalty. In this way, you could automatically adjust the number of total tickets to buy on a per block basis, accounting for the difference in balances between blocks. The granularity of that should be small enough that it has the desired effect.

[marcopeereboom]

Since there is still bickering on how to do this it won't make 0.4.0.

[tuxcanfly]

Ignoring the change fees, we can track the amount spent in ticket commitments plus fees and get a reasonable estimate of the expected balance. Basing off this, we can check for new credits and use them to update the number of tickets to buy. Working on implementing this.

[raedah]

This issue should be reopened. As of 0.5.1, though it seems to have improved with the new behavior, it still is not accurately tracking available funds. It will reach

[TRC] TKBY: All tickets have been purchased, aborting further ticket purchases

and stop buying, but 'get balance' still shows a balance, and if you restart dcrticketbuyer it will again start buying. After restart, it will buy till the balance of zero, but even then still thinks there are remaining tickets to be bought in the window.