Re: [ANN][XEL] Elastic Project - The Decentralized Supercomputer
On the PoW side (again as a consequence of keeping "global" PoW chain statistics, meaning a single embedded PoW chain instead of a distinct chain for each job) you could manipulate difficulty, choke out the tx limit, etc.
On the PoB side, one could do "Trapdoor Verification" as well. It seems that the publisher of work could give a verification expression which accepts either the solution that he is seeking, or any other input values that he PKI signs in a "distinguished" and otherwise-just-nonce input. This would allow him to submit, at will, his own PoB certificates which are not solutions and which no-one else can submit without his key.
This is particularly useful if your work job only seeks 1 solution - as soon as you see such a tx on the network you claim the rest of the bounties for yourself. (Or you claim "the rest + 1" bounties for yourself and try the race.)
I think an effective solution to both cases should be pretty straightforward, though the latter "trapdoor" scenario is a bit tricky, and might resurface in various forms, shortly.
On the PoB side, one could do "Trapdoor Verification" as well. It seems that the publisher of work could give a verification expression which accepts either the solution that he is seeking, or any other input values that he PKI signs in a "distinguished" and otherwise-just-nonce input. This would allow him to submit, at will, his own PoB certificates which are not solutions and which no-one else can submit without his key.
This is particularly useful if your work job only seeks 1 solution - as soon as you see such a tx on the network you claim the rest of the bounties for yourself. (Or you claim "the rest + 1" bounties for yourself and try the race.)
Quote
I am starting to fix that right away!
I think an effective solution to both cases should be pretty straightforward, though the latter "trapdoor" scenario is a bit tricky, and might resurface in various forms, shortly.
I have pushed a fix here: https://github.com/OrdinaryDude/elastic-core/commit/5b4b5fdaaaea586a13e50b59bb70d90102304c87
So now, the blockid is also used to derive the stream of random integers which is then passed to the elasticPL program.
A precomputation of POW/Bounty certificates should no longer be possible.
However, I am at the moment a bit unsure how one would model such trapdoor verification.
Surely, I may add a verification routine that verifies true in many different ways (that also includes asymetric crypto so that I would be the only one - as the private key holder - who is able to calculate a solution that would evaluate to true). But then, again, I cannot chose the input to the ElasticPL program freely. It's more a cryptographically strong, unpredictable stream of input numbers that I have no way of tampering with (be it precalculation, or adjusting the seed in a way so that the random number generator gives back exactly what I want).
So, imho, the only way to verify my "trapdoor" to true is to be "lucky" and "accidently shuffle" the correct input numbers using the cryptographically strong pseudo-random number generator.
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
But after all, this attack is just a "race" where the the "attacker" can merely increase his chances to find Bounty certificates.