A simple suggestion? I haven't looked at the code for a while but could we simply shorten the ticket price window to half? Shorter price re-targeting should stabilize the ticket price without any other big changes. What do you think? Suggestion: Change "StakeDiffWindowSize: 144" to 72
I'm fairly certain that shortening the ticket window without changing any other factors would exacerbate the swings. There are a few reasons for this, but one of the most notable is that it would allow fewer tickets to be purchased at the lower price than the current one does which would cause even more demand for them. In my opinion, rather than changing the window size, a better approach would be to tighten the retarget factor and make use of a VWAP factor instead of only using a raw EMA. Currently, the retarget factor is 4, which means the ticket price can increase up to 4 times the current value per window or be reduced to 25% (1/4) of the current value per window. To put that into concrete numbers that more closely match the current ticket prices, that means a ticket price of 30 DCR can go up to 120 DCR or down to 7.5 DCR. That is a pretty massive swing. However, there is another extremely important factor here that just talking about the ticket price completely ignores. In particular, the main goal of the PoS ticket price retarget algorithm is to maintain a consistent ticket pool target size. I don't think anyone would dispute the fact that the current algorithm is doing a really good job of keeping the ticket pool size near the target. So, from that aspect, it is in fact doing the job it was designed to do. The main challenge here is to tune the algorithm such that it smooths out the ticket price swings while still performing its primary task of maintaining a fairly consistent target ticket pool size. My gut feeling is that making a factor of somewhere in the neighborhood of 1.2 along with using an additional weighting factor based on the VWAP would help smooth out the swings while still doing a reasonable job of maintaining the target ticket pool size. Using the same starting ticket price as above, for a given window, that would mean a ticket price of 30 DCR could go up to a maximum of 36 DCR or down to minimum of 25 DCR. That said, I would strongly advocate that any such changes to the PoS algorithm must first require the creation of a model using the new factors and actual data collected from mainnet in order to help tune the algorithm using real numbers instead of making the mistake of just guessing at optimal numbers.
Thanks for the excellent clarification. Yes, you are without doubt correct in that the algorithm is very good at keeping the pool size target. I do have some reservations of using the current data to model a changed algorithm. Any model built this way would assume that there is no or little change in purchase behavior... something to keep in mind. People (the market) are the problem not the math. I also agree that with the current purchase behavior the retarget factor could be cut down "a bit". It will probably have no adverse effects (gut feeling). Cutting it too much would potentially cause the pool size to grow too big. In order of priority for the algorithm. 1. Keep pool size constant --> all purchased ticket are likely to win 2. Keep ticket prices in a more tight range --> better "customer experience" Another story is the terminology currently used. I would prefer to have a system where we would not talk about ticket price but interest rate. When I purchase a ticket I have a Excel sheet where I input the ticket price (difficulty), ticket fee, txfee. From these I calculate my monthly interest rate. I can do this with some confidence because I know the pool size is constant! If the interest rate is low, due to either a high ticket price och a ticket price + ticket fee combination I do not make a purchase. I've seen a number of people ask "Would you buy at current ticket price of XX?". Clearly not everyone is good at basic math but hey that's life. For mainstream support of anything we need KISS. Maybe a simple ROI calculation in the GUI wallet would do the trick? Of course nothing is idiot-proof.
Decred's volatility is the same in both the PoS difficulty targeting and the PoW difficulty targeting. They both use the same 12 hour window. So instead of just looking at fixing the PoS volatility, I suggest we fix both PoS and PoW volatility together. If you look at what monero did, they have a large window size, but it retargets every block. It is looking at the last 720 blocks to calculate the difficulty, but it adjusts every block so the effect is that the average is smoothed with the trend. It is a window that slowly shifts, instead of jumping rapidly to the next rung. I see no major hurdle to decred adopting this. Maybe the adjustment happens every block, or even if the adjustment happens every 16 blocks it would still be a huge improvement because volatility in the difficulty would be smoothed. The window size can stay at 12 hours (144 blocks) or it could even be made larger (24h). The larger window size would not have a negative effect because the adjustment is already happening more often. It would just create a longer tail which may be desirable. Dcrticketbuyer can be modified to bid slightly higher then the current price. This will help insure that PoS purchases still get a chance to be mined before the set expiration, and that the purchase still has enough funds as the PoS difficulty adjusts up. As it is, the expiration setting is overly aggressive and should be more smartly tuned to the users needs, as it only matters when they dont have enough available funds.
I think all that's needed is to let the price decay by no more than 20%. It can go up buy a factor of 2 for a maximumly filled price session, but the problem at the moment is it then halves, and if no more tickets are about, halves again, which drops it down to ridiculously cheap levels, causing another upswing. I think what we want is the price to oscillate small amounts, and there not to be filled ticket buying sessions. In order to achieve this, I think simply letting the price decay slower would work better. This happens after the ticket pool size is above target anyway, so letting it dip below target before being refilled would be good.