Oh, but did you notice that you changed your scheme already? From "round to nearest" to "round down". One of those was probably just a silly mistake, the sort that happens to everyone from time to time. Simplicity has a value that is hard to quantify.
Are we
really arguing semantics now? When I said "round to nearest" I meant "round to the nearest integer smaller than the value or equal to it", and I thought it was clear that I'm referring to normal integer division (which rounds down). I'm not as precise in my language in conversation as in formal proposals.
And, with any other rounding method, there's still very little to game. I said it's "immaterial" which implies I couldn't care less how it's rounded, or how people would interpret how I say it's rounded. Energies are better saved for important things.
Also, I'm pretty sure that your idea will create total chaos. Not less forks, but more. Lots more. Like on nearly every block. Not at first, necessarily, but as the subsidy shrinks relative to the transaction fees for sure.
Did I say it will create less forks? I predict that the equilibrium found will be less than 10 minutes, which means more forks.
I doubt it will be "on nearly every block". As I explained, if it comes to that, miners will choose a larger weight which decreases their invalid rate.
Actually, miners will choose the weight based on whether they got the last block or not, and whether they are getting paid kickbacks to support/override blocks from the previous miner. For most miners, I think the best payoff would be prevDifficulty+1, except when they are working on extending their own block, in which case it would be the minimum, or close to it. The exact game theory optimum would depend the acceptable range.
As I said, honest miners will build on the longest (most difficult) branch they know. This is a Nash equilibrium - a miner will want to build on the longest branch, as that improves the chances that their own block will be accepted. Increasing the weight decreases the probability that their block will be rejected in a conflict.
I didn't talk yet about how to handle transaction fees, so you may want to defer judgement until then. Hint: You won't be able to get the entire fee of all floating transactions by creating a very light block.
Oh?
Option 1. You pay "easy" blocks less and put the balance into a fund used to pay extra for "hard" blocks. Equilibrium at 10 minutes, which is what you wanted to avoid.
Option 2. You pay "easy" blocks less, and the remainder carries into the next block. Equilibrium at X minutes, which is no more optimal than 10 was.
Option 3. You pay "easy" blocks less, and the remainder is lost. Equilibrium at 10 minutes.
Option 4. You pay "easy" blocks less, and "hard" blocks more, creating money out of thin air. Equilibrium at whatever the weight cap is.
Did I miss any?
Options 1 and 2 aren't that far off. But seriously, hypothesizing what the equilibrium will be is hard enough when the system is fully specified, trying to deduce it based on guesses on what I want to propose is just silly. I would appreciate the benefit of the doubt that what I want to propose is not totally idiotic and broken.