(
)
3. All ideas that include first submitting the hashes of the bounties and revealing them after they have been included in a block (at a good position so they count) are tricky as we cannot verify such bounties for correctness. This would open all work packages for a broad variety of DOS attacks through the submission of illegitimate bounties. So we would have to use "penalty" here: it could be possible to mitigate the DOS attacks by the requirement to attach a "bounty submission deposit" of x XEL to each unrevealed bounty submission and receiving it back (along with the actual reward) when the solution is revealed within the next x blocks and evaluates correctly. Otherwise the deposit is forfeited. Not sure if we want to go this way though.
I'm biased, but I think sending hashes first and taxing them somehow is a valid idea. Could you elaborate on why you don't want to go that route?
(
)
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