Quote from: HunterMinerCrafter on September 24, 2016, 12:31:43 PM

I think that including the workId (this is derived from the block hash wher the work is published iirc?) probably closes at least one other attack on my list. Prior to this change, a job publisher could also precompute PoW certificates for the work to return those funds to himself immediately after publishing...

Actually, the workId is derived from the transaction (not the block) in which it was published so I guess yes .. your attack would work.
While not interesting for the PoW certificates (you can very well charge back using the work cancellation button) it might become interesting when precalculating bounties, submitting them prior to the closure of a work to get most of the bounty fund payout for one-self (remember, the fund is always distributed among all bounty submissions after the work has been closed).

I am starting to fix that right away!

Quote from: HunterMinerCrafter on September 24, 2016, 12:31:43 PM

This does seem to prevent the basic work stealing problem. If you actually fill the entire memory space it would also mitigate (but not entirely prevent) another attack still on my list.

Actually, I am right now filling the entire 12 integers of "possible input entropy" but not the entire memory space. If required to do so, we could go this way, even though this would increase the overhead noticably. Right now it's pretty handy to have large parts of the memory "nulled".

I am really eager to hear about this attack Wink

Quote from: HunterMinerCrafter on September 24, 2016, 12:31:43 PM

The laundry list is still growing. I'm finding a few new attacks each day, and with the weekend now here I'll have some time to *really* focus again.

I hope (and I really believe) that with your help we can get rid of most (all?) these problems Wink

Also, I am really excited to hear about your next discoveries and start brainstorming about ways to conquer them.
After all, you have my sincere appreciation for your help!!