As there is no rewards, there are no strategies apart from trying to double spend, and the odds that you can do it because you happen to be the preferred staker on the false chain are small.
What about censorship?
I don't see the problem. Why would an arbitrary minter censor you ? And if he censors you, the next one probably won't.
The problem of censorship occurs when an attacker manages to bribe more than 51% of the minters to not include certain transactions and to not mine on top of blocks that contain such transactions.
Who are you going to bribe ? The guy that just minted a block, but if he changes something, he's not the preferred minter any more, but some other dude ?
The idea is that, if the preferred minter order is a random function, depending on every individual bit in the block, you cannot know who will mint the modified block !
Unfortunately, "undercover" minting (as I call it in my own
design) doesn't solve the issue. All you need is offering a reward to those who prove after the fact that they didn't include certain transactions or didn't mine on top of certain blocks, even though they had the chance to do so.
What can help in that context is the sheer size of the minter group. If you need to bribe 10000 (potentially) anonymous/pseudonymous minters (rather than the top 10 whales) to get majority control, the only way to achieve that would be to publicly announce your bribe, which would make defense much easier.
Other defense mechanism against bribing could be...
As iamnotback said, this is just at high conceptual level and not a "design", but essentially, you take a hash function of the block, and you find the Hamming distance between this hash result and the minter's stake address. The one with smallest Hamming distance is the preferred minter. Change one byte in the block, and the preferred minter becomes someone else. Many minters can mint blocks almost simultaneously.
Such a scheme will be prone to stake grinding attacks if not designed with care. My approach to the problem is using massively combined pre-committed hash chains and account activation times.
Another function will tell future minters which chain to prefer to mint upon. This function should be well-designed so that there is almost no way to "orphan" many blocks, by increasing exponentially the preference for the currently longest chain.
Does that imply that a minter would not always choose the longest chain but apply some other (subjective) scoring rules? If that's your idea, you might want to take a look at chapter 3.2 of this
paper.
I'm not doing anything PROPORTIONAL to stake - you simply have to stake a given amount, somewhat like the master node scheme in DASH - but the amount shouldn't be very high - as there's nothing to WIN in staking, you don't care about your probability to mint, you only do it altruistically to keep the network running.
How do you prevent that a user creates several accounts to stake the minimum value multiple times?