Quote from: HunterMinerCrafter on September 25, 2016, 03:58:38 PM

Quote from: Evil-Knievel on September 25, 2016, 08:52:37 AM

However, you are right, the same computation power does not correspond to the same chance to "shuffle" the correct solution.
When I know which input numbers constitute a correct solution *before*, I can screen the entire random number stream without actually evaluating a single line of the program allowing a speedup by a factor of at most WCET. That would be a variant of the "Faster Algorithm Attack" outlined earlier. This is one problem, that would be great to eliminate (somehow) ... I think noone has come up with a solution to the FAA so far Wink

But after all, this attack is just a "race" where the the "attacker" can merely increase his chances to find Bounty certificates.

Correct, without being able to pre-compute it just becomes, on its own, a variant of FAA. It is worth noting that, currently, the ratio by which the publisher can increase his chances is quite significant.

I think in combination with another attack it might still have some implications. I'm still working on a "useful" approach, however.

I was brainstorming with a bunch of guys about this today.
Well, we could not come up with a solution for the bounty fund based FAA attack so far. But this is what we thought of:

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.

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.

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.