clout, I agree.
Fox, I had a similar proposal to buy the BitUSD from the market using newly created BTSX in order to pay delegates (and other workers). Actually it was one part of many different proposals in
this post including other less elegant but easier to implement solutions.
An even less elegant but even easier to implement solution I described in more detail recently (
here and
here) is one in which the delegates still get paid in BTS but use the one hour average price from the BTS/BitUSD market to convert their salary denominated in BitUSD into the BTS the delegates get paid per block. Bytemaster seems to still prefer to not bother implementing that and instead rather rely on trusting delegates to overcharge the pay rate and just burn the necessary excess BTS to maintain the BitUSD value of their salary that stakeholders think is fair. I think that just puts unnecessary extra burden on stakeholders to check up on yet another thing that the delegates are entrusted to do correctly.
I should note that I discovered a change that is likely to be beneficial for the proposal I laid out
here and
here. The change wouldn't be necessary if there was a proper worker pay system and prioritization list decided through delegate proposals ratified by enough shareholder votes as I have previously described and would ideally prefer. But since the worker pay system is shoehorned into the delegate system for implementation simplicity, this change to my proposal which I will describe shortly becomes very beneficial since it is so easy currently for a delegate to get into the top 101 with little approval. This means that with my original October 31st proposal, an attacker with enough stake to get his delegate into rank 101 with a requested salary that is orders of magnitude bigger than everyone else's requested salary could essentially saturate the dilution rate to its maximum cap and take nearly all of it for himself to the detriment of all other delegates. Although this would ideally inspire stakeholders to vote for other good delegates to raise 101 good delegates to an approval rating above that of the attacker, there is a risk that voter apathy could keep that evil delegate in the top 101 for a little bit too long causing undesirable dilution to stakeholders and financially hurting the good delegates.
The change only applies to the case where the total requested BitUSD salary for all delegates in a round is above the current BitUSD price of the 5050 BTS limit and thus some scaling is required. The block reward for each of the 101 active delegate in a given round would be determined as follows:
- Calculate the appropriate one-hour average price, P, from the BTS/BitUSD market, where P is in units of BTS/BitUSD.
- Calculate the budget in BTS for the round, BUDGET. This is usually just a fixed number like 5050, but it can in addition include any BTS that was allocated to be received by the delegates in the previous but was not because the delegate missed the block.
- Determine the basic pay, in BitUSD, for each delegate for just signing blocks (call it BASIC_SALARY). This is likely just a fixed number like 0.03 BitUSD (which works out to $937 per year per delegate).
- Calculate BASIC_BUDGET = sum of P*min(REQUESTED_SALARY_{D}, BASIC_SALARY) for all D in the set of the top 101 delegates.
- If BASIC_BUDGET >= BUDGET, then calculate R = BUDGET/BASIC_BUDGET, otherwise R = 1.
- Set active delegate D's block reward to BLOCK_REWARD_{D} = R*P*min(REQUESTED_SALARY_{D}, BASIC_SALARY) for all D in the set of the top 101 delegates.
- If BASIC_BUDGET < BUDGET, calculate REMAINING_BUDGET = BUDGET - BASIC_BUDGET, and then iterate through the sequence of the top 101 delegates in descending approval rating order:
- If REQUESTED_SALARY_{D} <= BASIC_SALARY, continue to the next delegate in the loop or exit the loop if D was the 101th delegate.
- If REMAINING_BUDGET <= P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set BLOCK_REWARD_{D} = BLOCK_REWARD_{D} + REMAINING_BUDGET and exit loop.
- If REMAINING_BUDGET > P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set BLOCK_REWARD_{D} = BLOCK_REWARD_{D} + P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set REMAINING_BUDGET = REMAINING_BUDGET - P*(REQUESTED_SALARY_{D} - BASIC_SALARY), and continue to the next delegate in the loop or exit the loop if D was the 101th delegate.
The above solves the problem of an attacker delegate stealing the pay of other delegates by saturating the dilution cap with a huge requested salary. However, if total requested salary of good delegates is much less than the dilution limit, the attacker could still take over the entire difference if he can get himself into rank 101, which still causes stakeholders unnecessary dilution (although thankfully no longer to the financial detriment of other good delegates). Ideally the stakeholders would fix this by replacing the bad delegate with better delegates by voting with more of their stake, but to further improve on this we might have another limit on the requested salary that is a function of the approval rating. For example if the approval rating of a delegate is less than the median approval rating, the X = DELEGATE_APPROVAL_RATING/MEDIAN_APPROVAL_RATING ratio could be used to determine a salary limit of max(BASIC_SALARY, SALARY_LIMIT*f(X)), where f(x) is a monotonically increasing function over the domain [0,1] with f(0) = 0 and f(1) = 1, and SALARY_LIMIT is some sensible limit such as the median requested salary of the top 50 delegates. Other limits can of course be considered, but the idea is that if you cannot get enough approval to get above the median approval rating, you should not be able to just get any salary you want but you are at least guaranteed to be able to get the BASIC_SALARY.