I have no idea if this would work, but how about this?
Rather than the anomaly being created based on 1/Difficulty, how about the reward being determined by 1/Network hash rate at declaration of block reward?
You could then trigger the reward based on another factor, such as the last digit being odd, even, the number '3', etc.
The network hash fluctuates rapidly, unlike difficulty. The reward would still be announced at the start of the block, but as it could not be so easily predicted, the Multi-pools would not have as much time to 'swoop in' and steal the block. Similarly, as you can't accurately control the total net Hash rate, you couldn't force it to generate an Anomaly every time.
-T
The block reward is part of the block hash - so you can't use something that fluctuates like crazy...
When you are mining, you are performing a hash on a concatenation of:
Version # (Block version number)
hashPrevBlock (Hash of the previous block header)
hashMerkleRoot (hash of the transactions to be included in the block)
nTime (Current timestamp)
Bits (target [aka difficulty])
nonce (A number you increment or choose randomly)
The reason I am showing this, is that hashMerkleRoot is part of what you are hashing.
hashMerkleRoot is essentially a summary of all of the transactions to be included in the block - the first transaction always being a tx that says "pay me". You MUST know how much you are going to get paid.
If you used nethashrate, the hashMerkleRoot would have to change constantly, and this is simply not possible - miners can't constantly change what they are hashing on... even nTime is only updated every few seconds.
my apologies, to clarify, I was suggesting that you 'snapshot' the net hash rate at the point of the block hash creation, not a continuously changing value. I.e. you wouldn't know what the block hash would be prior to the creation. this would obfuscate the value of the block until it was announced prior to mining.