That sounds like a complex solution. Sometimes a dumb solution that works good enough is better than a complex solution that _probably_ can't be exploited.

It's complex on one end to reduce complexity on the other -- the trading companies wouldn't have to worry about millisecond optimizations if they trading batches were 200ms windows. So the wire lengths wouldn't matter but also not mattering is the processor, memory, software, etc. for the trading companies. Seems like a good tradeoff.

And honestly the wire thing probably isn't real. Light moves 30cm in a nanosecond. The wire lengths could be 3 meters different and only make a 10ns difference. Not sure that would matter all that much.

I used to work in HFT. I promise you that companies would still try to exploit randomized batches. There is an advantage to being the very last entrant into a batch (most up to date information). Truly random batches are not trivial to implement and any statistical pattern in the batching could be exploited.

"Truly random batches are not trivial to implement and any statistical pattern in the batching could be exploited."

If an HFT manages to exploit a correctly implemented entropy-pool random number generator using AES-256 to extend the stream as needed, they're welcome to pick up a few more bucks as far as I'm concerned.

Yes, problems have existed before but I'm sure in this case we can assume high-assurance and careful programming, not some fresh grad being assigned the problem and thinking linear congruential generators sound really cool.

A robust solution is, wait for it, proof of work.

Wait, come back, I'm serious! Finding an arbitrary hash of adjustable complexity is a scalable solution to batching transactions across multiple servers with a consistent throughput.

I think it just moves the goal post of the problem. If I now have a 200ms window, then I need to optimize for that 200ms cutoff. I want to do as much work as possible while _still reaching the cutoff_ and so minimization of "non work" still matters. Not only that, but now you incentivize filling up that 200ms with 200ms of analysis.

Isn't that where the randomness of the trading interval comes in? How do you optimally fill out a time interval with a length that is unknown to you?

Ah, I didnt interpret the comment as being a variable delay. I think the point still holds though that you would still optimize for the lower bound.

You could, but then if say the delay is 439ms, then you'll sit idle for 239ms. It would make more sense from a game theory perspective to simply process for as long as necessary and then place the order.

the wire thing is definitely real for IEX

it's part of the exchange's license

and they have several videos of the rather large wire

there's even a tom scott video on it: https://www.youtube.com/watch?v=d8BcCLLX4N4

I don't think I get how that solves the issue: you would have set a fixed cutoff time, where you switch from one window/batch to the next. It doesn't matter when you arrive within the window. But statistically, even for random window lengths, if you have a smaller latency, you will make the cutoff for the earlier window more often.

But because of the random ordering within the windows, it won't matter. In most cases you wouldn't hit the cutoff.

If the window is as large as 500ms then anyone can hit that most of the time, provided they have a good enough clock and decent network.

I don't think this actually solves the problem.

Say I know exactly when the window ticks over. I still want to put my order through immediately anyway since it's to my advantage to get it in the earliest possible window. There's no advantage in waiting for the next window to start.

So I put in my order, and my closer competitor puts in their order at the same time, and they get in the current window, while I have to wait for the next one. And now my disadvantage is even bigger because my order is delayed on top of my base latency by the remaining time until the next window ends.

-----

Even if we remove the window idea entirely and just add a random 100-500ms delay to every command immediately, being closer still has an advantage since 10 + Rand(100,500) is still lower on average than 100 + Rand(100,500).

this is called a periodic auction and has been common on European exchanges for nearly a decade

(though the matching algorithm varies)

That's the same problem, you're just trying to get into the earliest window

Ok but you don't know the window size for any given batch, so game theory-wise your best bet is to just process as fast as you can and then place your order.

2-500 ms latency for games is atrocious. That's an order of magnitude higher than what this tournament was targeting.

This thread is about HFT.

So it is. I somehow managed to miss that at the top of the thread. My bad!

You would use an external source of randomness, which you can definitely prove is sufficiently random.

You could do something like this:

• Pre-publish, for each time batch, a public key. You could publish lists of these well in advance.

• Let everyone submit, alongside each order, a number arbitrarily selected by them. It does not matter how they select the number, but it would be simpler if everyone chose distinct numbers.

• When order processing is done, do it by the order of closeness of the submitted number to the private key. Publish the private key after order submission is closed.

• Everybody can now verify that the order of processing is indeed by the order of the previously secret private key, and everybody can verify that the private key corresponds to the previously published private key.

Something very similar is done on smart contracts to introduce randomness (at least to the practical extent) on blockchain. Good thought experiment nevertheless to provably inject randomness into a system with untrusting parties.

Oh, there are trust-less coin flip protocols.

Edit: see https://en.wikipedia.org/wiki/Commitment_scheme#Coin_flippin...

Alternatively, just do what Cloudflare does (did?), and have some cameras pointed at lava lamps[0].

[0]: https://www.youtube.com/watch?v=1cUUfMeOijg

That seems unnecessary. Today the traders have to trust the exchange to process fairly and in order -- there is no verifiability. The verifiability would be nice, but unnecessary.