Dcrticketbuyer Default Settings: High Ticket Fees

Discussion in 'Proof-of-stake Mining' started by jy-p, Oct 25, 2016.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. jy-p

    jy-p Sr. Member

    Jan 2, 2016
    Hello folks, a number of users and devs have brought to my attention the situation wherein tickets are purchased with very high fees, e.g. >0.5 DCR, during ticket windows with low stake difficulty / ticket price. Our best suspect for the cause of the high fees is users of dcrticketbuyer not specifying a maximum ticket fee and setting a low maxticketprice, e.g. 20-25 DCR. This leads to extreme competition for tickets during low sdiff windows and correspondingly high fees.

    The issue that occurs as a result of high fees, sometimes as high as just under 1 DCR, is that it is effectively makes the ticket more expensive. An example would be a 20 DCR ticket with a fee of 0.9 DCR and a voting reward of 1.6 DCR - since the voting reward is reduced to 0.7 DCR, due to the high fee, it reduces the effective rate of return from voting from 1.6 / 20 = 8% to 0.7 / 20 = 3.5%. The whole point of buying "cheap" tickets is to maximize your rate of return, but when there is excessive competition for tickets, it has effectively driven up the ticket price - in this case, from 20 DCR to ( 1.6 / 0.7 ) x 20 = 45.7 DCR.

    I am interested to hear feedback from the community on the kind of behavior they consider acceptable for dcrticketbuyer defaults. Our first idea is to reduce the maximum ticket fee from a default of 1 DCR to something lower, to prevent runaway competition for tickets at low sdiff leading to tickets that effectively much more costly. Second, it may make sense to have dcrticketbuyer make decisions on buying tickets based on the effective price of a ticket instead of only the sdiff, e.g. use fee data to calculate [ voting reward / ( voting reward - ticket fee ) ] x sdiff and use that instead of just sdiff. Let us know if you have any ideas or opinions on these proposed changes or any other ideas that occur to you.

    NOTE: dcrticketbuyer functionality will be migrating into dcrwallet in the near future. However, this discussion applies to the ticket buying logic that will be in wallet as well.
    chappjc likes this.
  2. BoMBeR

    BoMBeR New Member

    Jan 17, 2016
    If you are going to set a default maximum rate rather then having it be the maximum allowed just put it right in the middle of .5 which in my opinion is still kind of high but isnt unreasonable. However not everybody upgrades with each new release so it will take awhile for this problem to dissipate anyways.
  3. Halestorm

    Halestorm Jr. Member

    Jan 22, 2016
    Data Center
    Texas, USA
    I like the idea of changing it to look at the effective cost of the ticket versus just the current difficulty. There was absolutely no reason to buy a bunch of tickets at 21.32 if you had to pay basically 1 DCR per ticket in fees. That coupled with a lower default fee (I also think .5 is reasonable) should bring a bit of sanity back to ticket buying over time as people update.
    raedah likes this.
  4. Kandiru

    Kandiru Member

    Feb 21, 2016
    I think a better option would be a parameter for minimum rate of return. Then that would dynamically adjust the fee depending on the difficulty?
    raedah and jy-p like this.
  5. root

    root Member

    Feb 3, 2016
    As mentioned above, a parameter for the low bound of the monthly(yearly) return of interest would make more sense. E.g. the lowest expected return I am willing to accept while buying tickets. I have simulations made some time ago, I believe the results can be used still as long as the ticket price algo stays the same. Some predictive filtering can be incorporated as well (Kalman,...) and with future releases containing a good default value of the monthly return, the purpose of the dcrticketbuyer stays as originally stated - to stabilize ticket prices.
    jy-p likes this.
  6. Johnshpon3

    Johnshpon3 Member

    Dec 25, 2015
    Maybe we should not forget that main feature of voting is not return of investment, but voting about important questions concerning Decred. At later stages it will be much more important decision than ticket price or fee. If somebody is willing to pay 1 DCR fee, so be it.
    I'm also not so sure that decredbuyer should be integrated in the wallet. It should be up to user if wish to use automatic buying or prefer manual buying with much more control than automatic.
  7. BoMBeR

    BoMBeR New Member

    Jan 17, 2016
    I agree with you johnshpon3. However what if the user does not know they their spending that much. Default max fee can be changed to whatever the user wants down the road however upon installation I think it should be placed in the middle if it is untouched.
  8. jy-p

    jy-p Sr. Member

    Jan 2, 2016
    The notion of having a minimum average rate of return is roughly equivalent to having a maximum effective ticket price, up to voting subsidy decreases that occur every 6144 blocks. I think that having a maximum effective ticket price makes things more tangible from the voting perspective, in that users can be confident they get at least X votes for Y DCR locked in tickets. However, if your main interest is in accumulating rewards from voting, specifying a minimum rate of return would be a better fit. In both cases, the decision of whether or not to buy tickets should be based on the effective ticket price and not the sdiff by itself.

    Perhaps it would make sense to allow users to specify via either route - a maximum effective ticket price or a minimum average rate of return.
  9. jy-p

    jy-p Sr. Member

    Jan 2, 2016
    Yeah, the goal here is to allow people to purchase tickets without a hassle, not feed PoW miners tons of extra coins via ticket fees. I would argue for a much lower maximum ticket fee, say 0.1 (~5.9%), or potentially force dcrticketbuyer users to set their own maximum ticket fee.
    Halestorm likes this.
  10. karamble

    karamble Member

    Feb 19, 2016
    Just lower the default fees and the maximum fees, but keep the allowedhighfees parameter alive. Don't introduce any 'rate of return' parameters please, this is suggesting wrong key-note. I like it as it is, and when somebody wants to spend 1DCR Fee he will still do it in the future, too. If this happens unintentionally, you fixed the problem by just adjusting the default values. Integration of the ticketbuyer into dcrwallet is also something i do not want to see, this should stay seperated, but this is just a feeling.
    Johnshpon3 and jy-p like this.
  11. raedah

    raedah Jr. Member

    Mar 6, 2016
    There are way too many settings in dcrticketbuyer, and it does not work to set and forget it because every time the ticket price changes, if you want it to be anything like optimized you have to change your settings again. dcrticketbuyer should be able to make sensible decisions on its own without the user needed to watch over it. It also needs to do a good job at stabilizing the market. Volatile ticket price is a losing game for all PoS miners, and just directs the high fees to PoW miners. There is no reason for PoS miners to want a volatile ticket price. My opinion is all the current algos dcrticketbuyer uses need to be thrown out and redesigned from scratch.

Share This Page