You have to provide proof of the conflicting transactions, as two locker signatures approving conflicting transactions. It's specified in the paper, this proof is considered in lieu of the signature of the penalized node's account.
In that case, why isn't it optimal for me to submit nothing but pairs of conflicting transactions in a continuous manor hoping to have two signatures get accidentally signed due to network latency?
Sorry, but what you're describing doesn't really apply, since the locker responsible for signing transaction is the same entity, and won't accidentally sign a transaction conflicting with another transaction he signed anymore than someone can crack a private key from the public key by accident. The case when two conflicting transactions take place in consecutive rounds is more complicate, and there's an analysis for it in the paper, please read it before trying to design attacks.