BUT what about doing this with BTSX itself, instead of burning fees? Since we have yield implemented for bitAssets, why not implement explicit yield for BTSX? I know in the long term burning is equivalent to dividends, but in the short term explicit dividends are a heck of a lot sexier.
Yes, not just sexier but also I have been recently advocating for this method of paying dividends as a more palatable way of incentivizing people to update their votes (the less palatable way are inactivity fees). But I really don't like the way the current BitAsset yield distribution works. In my opinion it should be a monotonically increasing yield through a linear variable interest rate [1]. Then any additional yield can just stop accumulating for balances older than a year. This provides an incentive to move the balances (and thus provides a great opportunity to propagate vote updates to the blockchain) at least once a year (tiny balances that are so small that the yield is smaller than the transaction fee won't have an incentive to update, but these balances are so small that their voting power can be considered negligible anyway). I want to remind people that this isn't about paying people to vote. I think if the voting is really easy in the client people will update their votes locally for free anyway. My proposal is about providing financial incentives to get users to propagate their vote changes into the blockchain by moving their balances to optimally claim their yields. Otherwise without any yield incentive, users would have to propagate their vote changes to the blockchain at their own cost of paying the transaction fees.
Furthermore the fact that this is linear interest rather than continuous compounding interest does not necessarily need to be a bad thing (the real reason for avoiding continuous compounding interest is due to the technical complexity). The optimal update frequency to maximize yield returns is a function of the balance, yield rate, and transaction fee. Given a fixed yield rate and transaction fee, the optimal update frequency will be more frequent as the balance value increases. I need to do a better analysis someday but from what I remember from what I looked at so far, assuming a 5% p.a. yield rate and 3 cent transaction fee, the optimal update period ranged from 6 months to 2 weeks for a balance value that spanned two orders of magnitude. And there was negligible financial benefit to update much more frequently than 2 weeks (with these interest rates and transaction fees of course) even for balances as large as a million dollars. And finally with the 5% p.a. yield rate, the maximum additional yield rate benefit that a really large balance had over a balance as small as $10 was fairly small (approximately 0.12% p.a. extra). So, I think sticking with simple linear interest is sufficient and fair. In addition, it means the big balances should be updating their votes more frequently which isn't a bad thing. A more proper analysis would also need to include the probability distribution of the size of balances typically kept on the blockchain in order to estimate the average percentage of voting power updated within a fixed period of time like a month.
[1] The idea is to conceptually separate out the reserve fund from the yield fund. When money goes into the yield fund it cannot be taken out for any purpose other than paying out yields to balances. After every N blocks (say N = 30) some amount of assets are moved from the reserve fund to the yield fund. The ratio between the amount moved and the amount of outstanding assets held by users at the time of the fund movement is added to an accumulator. The accumulator and ratio could be rational numbers with 64-bit numerator and denominator, but the intermediate sum could be a rational with 128-bit numerator and denominator which is then reduced (round down) to the rational with 64-bit numerator and denominator that is stored in the database. The accumulator would be stored for each block where a movement from reserve fund to yield fund occurred (so approximately every 30 blocks, or 5 minutes, in this example). When moving a balance the yield is calculated by only counting fund movements which occurred while the transaction existed. So the start point of yield is the accumulator point that came right before transaction was created in the blockchain and the end point is the latest accumulator point right before the transaction has been spent. The difference between these two accumulator ratios is calculated and then multiplied by the balance to calculate the added yield (again round down as appropriate). The reason for N = 30 rather than N = 1 is to reduce the amount of rounding errors introduced. Because of the rounding down errors introduced, some amount of assets will remain in the yield fund and not be capable of being reclaimed as yield. Perhaps some further sophistication can be introduced to deal with that if it becomes a problem. I can see that being useful for BitAssets, but for BTSX it should not be a big deal since any untouchable BTSX could be considered equivalent to the old buyback style dividend on top of the new yield style dividend. Finally, any withheld yields (say due to inactivity over a year) should still be properly calculated during the balance transfer and instead of being added to the balance they should instead be recycled back to the reserve fund.