I've thought about this a bit more and it's a hard problem to address. I also realized witnesses don't need to be grinding their Steem Monster purchase transaction but instead could grind something related to the block composition that is difficult to detect, such as transaction ordering (i.e. the suspected method used for covert AsicBoost).

I think lookahead is probably better than lookbehind, in terms of creating a randomness beacon that cannot be controlled by a single witness. But just a single block lookahead is probably insufficient. For example, a witness could submit their transaction one block before they were scheduled to mine. Then they would be able to engineer the lookahead block to yield a flush Booster Pack.

I am not sure if there is a perfect solution, but raising the bar to require two colluding witnesses most of the time would be a start. Perhaps this could be done by having each block hash following a transaction delay the settlement by 0, 1, 2, or 3 blocks. Perhaps the following pseudo-algorithm:

1. purchase transaction occurs in block 0
2. use block 1 hash to derive a settlement block in 1, 2, or 3 blocks
3. when the settlement block is reached, use this block hash to delay the settlement 0, 1, or 2 blocks. If the delay is 0, pack is opened using current block as the randomness beacon.

This seems overly complicated and only partially effective. Maybe there is a way to get a randomness oracle on Steem, that say posts the NIST Randomness Beacon for the timestamp of the previous block. Then you could do a lookahead that takes transaction id, transaction block id, and randomness beacon from the oracle for a lookahead block.

I'll look a bit into some existing literature such ast Proofs-of-delay and randomness beacons in Ethereum.