Looking at recent blocks with a large transaction fee, it has become apparent that the fees go entirely to the PoW miner, while the block reward is split 60/30/10 to the PoW/PoS/DevSubsidy. While this is fine at the moment, in the far future when the reward becomes less significant compared to the fees, this will eliminate the incentive to buy PoS tickets, since eventually the TXFee will become comparable to the reward. Should this be changed? It could be an early issue to vote on for the community. It would have very little effect at the moment, but it seems better to sort the issue before it becomes too economically significant.
Thats an issue. Also as far as I read, the prices of the tickets is also set to fall. So if there in no profit in voting then no one would be there to verify the transactions. And the entire system would fail. Decred cannot be successful in such a scenario. Can a solution be worked out?
Well we (by we, I mean C0) can change the code to require the fee is added onto the block reward before being split, then the PoS voters can vote down any blocks which don't do this. We could add a votebit to declare PoS voters as in favour or not (I can't imagine many would be against?) and then release new software and set the default client to downvote any blocks with the old behaviour. Just requires community consensus!
I vote in ur support. Seems like the right thing to do, It is needed to keep decred going well. But any idea why decred's price is currently falling? nearing the 1.9$ now
Yes, modifying the consensus rules to include the transaction fees in the split has already been discussed and will most likely end up being a PoS vote in the future.
Ah, I hadn't seen that discussion. I think it makes sense, and will be a good test of the PoS vote system,
The easiest way to get it is is just a soft fork where in the coinbase transaction the PoW miner pays outputs to the last round of PoS miners. This wasn't included at start because it produces a lot of dust if fees are low, but it's easy for PoS to enforce as they can just invalidate blocks that do not follow the rule.
This presents an interesting situation with conflict of interest. PoS voters will be voting to give themselves a share of the fees. What PoS voter would not vote for that? What prevents a situation where PoS voters try to propose a vote to claim 100% of fees?
my understanding is that the fees were intended to be split. If I am correct, shouldn't that be considered a defect and not a vote-able issue?
The lottery is insecure without PoW. That is, anyone could choose any subset of the stake voters with their blocks and continue the chain until all the other voters are missed. PoW could also hardfork and disable PoS.
It wasn't a consensus rule in the beginning because of the dust issue. It's trivial to add later, with a rule to skip small outputs like those less than 10000 atoms. I'm guessing the network would easily support the change as PoW currently is dividing the rewards, so will be soft forked in in the future.
Sorry I wasn't more clear. I wasn't meaning 100% of the entire block subsidy, but 100% of the transaction fees.
Doing so would cause the PoW miners to stop mining which would in turn effectively kill the currency. The majority of stake holders simply are not going to vote for something that would reduce the value of all of their holdings to 0. That was effectively the point @ceejep was making regarding PoW. The PoW miners could hard fork and disable PoS completely because then they would get 90% of the block subsidy instead of only 60% with 30% going to the stake holders. Obviously the PoW miners would love to increase their subsidy, but the majority of the network simply would not go along with it because it would also effectively kill the currency and reduce the value of their holdings to 0. Both cases are equally irrational as actors are heavily disincentivized from behaving that way. Both PoW and PoS keep each other in check and rational behavior is incentivized in all cases.
Is it not possible to change the PoS reward and Dev subsidy to include the fee share, rather than as a separate transaction? That would avoid the dust issue, but might involve huge amounts of work to change, I don't know enough of the internal code.
@ceejep @davecgh I believe there should better be a confirmation on setting txfee or ticketfee over 1 DCR in future versions of dcrwallet so as to reduce accidental high fees. Also I think, developers should consider put some high limits on them, especially ticketfee where there is no logical reason for it to be over the vote reward. If I am correct ticketfee isn't returned in case a ticket gets voted, so why someone would set ticketfee over the reward?
This is what happened to me yesterday: https://forum.decred.org/threads/need-confirmations-on-high-tx-prices.2608/ This very issue (which spawned this thread) cost me 135DCR. I thought I had set ticket max price but set the fee instead to 15DCR. Since my current ticket buy price was higher, my wallet happily purchased a bunch of tickets with the transaction fee set to 15. There absolutely needs to be some checks. I'm mad as hell at myself for screwing it up, but it was far too easy to do. The set price options are too similar. I can absorb that loss and as a member of the community I understand that it was unintentional on the part of the devs, but a lot of people can't afford that sort of thing, and couold see it as a sneaky way of being ripped off. I know that's not it of course, but emotion usually trumps logic and I was plenty emotional when I realised I just wasted over 300 Australian dollars. If this was a bank, I could just ask them to reverse the transactions, but that's not possible here. We need to make it safer as well as easier for people to use or it will never see mainstream adoption.
The amounts are signed and it's impossible for the PoS miner to know what transactions (+ fees) are going to be included by the PoW miner in the block. The PoW miner can easily pay out to all the tickets voting on the previous block, so the change in which the payouts are made in the coinbase is not a difficult one. You just don't want to make outputs that cost more to spend than they are worth. Bitcoin has tried to do this (dust) but as the value of Bitcoin floats, so too do the fees. It's hard to say what the dust threshold should be in a soft fork. 10,000 Atoms might be good. The ticket code is not yet optimized. Tickets from a single wallet should only have one input and one commitment except if they are going to a pool. When this is fixed in the next week or so it will also make this soft fork easier.
I'm sorry to hear about this. This is a common issue with Bitcoin. Wallet should have some sort of system to automatically reject transactions which spend too much fees per kb. This will be included in upcoming versions.
Does this mean that tickets set the reward when purchased? So if the reward drops before they vote, they still get the higher reward? I see that it's more complicated than I originally thought!
Reward is based on the block the vote is on, not the block where the ticket is found. The proportionality of the outputs is committed to in the ticket.