I was doing the math on people front-running trades, and concluded that it might be a problem after all. Specifically, a blind strategy of copying nearly-all trades that one sees, doesn't have an edge, but does disrupt expectations of normal users (which is a problem).
Luckily, I think there is a solution in good 'ole proof-of-work, on the transactions themselves. Basic game theory tells us that, to reliably sort people into groups, we need something that is more expensive for members of one group than the other. We then reward people who can "send" that "signal". The solution is simple: assuming that a given hash/second costs the same for everyone (unfortunately, this is a weak (the weakest) part of the algorithm), more hashes in the same amount of time would cost more.
For example, assume everyone can hash 1 per second for free, and buy extra hashes/second for 1$ / hash.
If I start hashing at t=0, and hash 60 seconds, I have 60 hashes at t=60. I spent nothing.
If someone else started hashing at t=20, and hash until t=60, I only have 40 hashes at t=60. To get 60 I need to spend $20.
So the idea is to have individuals build a transaction, and then "store up" a required minimum amount of time in that transaction by hashing it to below a certain value. This at least discourages front-running of trades, as it is now costly.
I'm curious as to how developers would implement this solution. Require nodes to do this (possibly doubling as ddos protection)? It seems overkill to hard-code anything into the block-validation rules.
I doubt specialized ASIC-trader-services would emerge, as they only produce revenues if you can hash quickly AND have actionable trading info. If they do emerge, they'll probably be perfectly competitive "brokerage firms", facilitating trades in a very very cheap way (hashes aren't really differentiable).