Re: [ANN][XEL] Elastic Project - The Decentralized Supercomputer
1. One solution might be to make the bounties regular POW submissions which pay the very same absolute amount per submission from one single XEL fund. This limits the possibilities significantly, because you would be no longer able to set up very large bounties (which could attract some workers) for solving your task.
I suspect that you will eventually end up combining the pools, anyway.... heh.
Quote
2. Otherwise you could stick with the idea of a bounty fund, but pay a fixed portion of it upon submission of a solution. Here, you could only try a race where you submit more bounties than allowed quickly when you see a valid submission online and hope that only yours end up in the block (effectivle all end up in a block but only the first x count). This attack could be further mitigated (not fully eliminated, as the probability of filling the first x spots increases with the number of bounties submitted) by ensuring a pseudo random order in which unconfirmed transactions have to be included in a block. This of course only helps if the attacker is not the forger at the same time. If we went for that solution we lose the funny aspect of people racing each other even after they have submitted bounties with the intention to maintain their percentual amount of bounties amongst all.
It is perhaps worth noting that it seems there will always be opportunity for races. A publisher could submit a refund cancellation as soon as they see a PoW/PoB tx announced and try to race it. One could even immediately submit cancellations as soon as work is published, in hopes of just seeing some "stale" PoW/PoB certificates announced by miners who haven't realized the cancellation yet. (EDIT: Note that while it is assumed that watching for PoW certs should be "pointless" I'm afraid that it isn't, as I'll illustrate later.
)Quote
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.
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.)