(
)
(
)
It seems like this could leave a lot of miners unhappy when their deposits aren't returned because of "natural" cause. (Like a sudden run of "by chance" rapidly forged blocks which do not include their reveal tx, but runs out their "x blocks" counter.)
This sounds like a valid concern, but it seems to me, that this is more a problem of balance, i.e. what "x Blocks" means exactly. You could probably make "X" dynamic, maybe by adjusting it every "Y" blocks, but that might open a whole new can of worms
The more I think about it, the less I am sure miners need to be reimbursed in the first place, but maybe I am missing something. Here is the scenario as i understand it and you tell me where I got it wrong:
- A miner finds a solution for a job/a block (do we have a terminology for this already?)
- They send the hash out, paying the tax for it.
- After a time that is long enough for the network to recognise their hash, they send the block
- They are rewarded for finding the block with the bounty
Since there already is a reward (i.e. the bounty), the miner already gets reimbursed in a way. The tax they paid could go out to a lucky PoS staker instead of returning it.
Now, I have a question about taxed hashes, though: Couldn't I DoS the system by creating doublespends/multiplespends? I mean, if the timeframe in which the taxed hash gets sent out before the block is shorter than at least one block, I could just send out a whole lot of bogus hashes with the same XEL as payment over and over again, couldn't I?
Just a note, that it seems your discussion goes more ad more towards a mining-only solution, but the origin of XEL is/was to make it decentralized supercomputer that is capable of doing various types of computations, ie. distributed rendering (like Golem's current main focus), and potentially scientific applications too.
What I mean is that basically the terminology should be general enough to cover as many as possible potential applications.