I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.
The client rounds up by 10% via PoDCUpdate because in part, it's only checking your RAC one time a day. So if you were the normal expected user, had one PC on BOINC and decided you could put your spouse's computer on it, then the first day it was up it could very well get enough RAC to push you out of 100% without the buffer. RAC does vary day to day, I've seen swings on an individual computer by as much as 10%, so again, the 10% buffer should protect against that.I would generally agree with your point that 20 should be 20 (even though that was not my vote). Which I guess three ways to accomplish this:
The first would the least work, get close enough to "correct" and that would be use normal rounding, so 4.99% would be 0%, 5.0% would be 10%, 94.999% would be 90%, and 95.0% would be 100%. Really I think this is a good solution as it would simplify the "current less than 5% special case".
The second would be to round everything down to a multiple of 10% (which would either change the 5% special case or require it to be written as en exception.
The third would be to add a 2nd special case and 90% go from 80.1%-99.9% and 100% only trigger at 100%, which doesn't seem entirely unfair, but really seems like far more work than the first idea.
I really don't understand why you wrote all this West, as it doesn't take into account the Snap-to-Grid IT requirement in the actual PODC protocol.
It's sort of confusing everyone, as it's alluding to "a possible change" in the protocol, when we already voted the protocol in.
The UTXO requirement is 20 bbp per RAC. The UTXO breaks chart rounds up to the nearest 10%. Lower than 5% rounds DOWN to zero %.
The only potential recommendation I have is to ask Jaap if he wants to create a 2nd chart in percentages, so people have a chart with a larger scale (maybe they understand percentages better than static BBP amounts per break, thats up to him).
I wrote to explain why the 10% round up in staking occurs. I also agree that the current rounding seems slightly out of correspondence with the vote of 20 BBP per RAC to get 100%.
I am not claiming the system works in any way other than round up to 10% except in the under 5% special case. I trimmed too much of the quote I suppose to keep that part in context. I was merely stating the three possible ways of handling this although I never stated this as a "possible change". Merely as a way to spark discussion on if there were a sufficient number of users that felt the system was in need of a small tweak. And really, if it were up to me (which it's not, short of making a proposal and seeing if it passes) I think rounding to the nearest 10% is easier to explain and eliminates the need for a special case for the 5% rule. But I do think that discussion deserves some consideration if for no other reason than simplification.
