Clearly, after ≈2⁶⁴ attempts, an attacker will succeed. So applications where signatures are flying left & right should likely not use such a low κ.
Attackers have a max window of 12 seconds to make those 2⁶⁴ attempts, and ~4 seconds in practice for their attestations to be included. It is not practical to make 2⁶⁴ attempts signature forgery attempts within 4 seconds over the network. That’s 2.56 x 10¹⁶ attempts per second. Assuming a 5GHz CPU can do 1 attempt per cycle, that’s only 5 x 10⁹, so you would need 10⁷ cores for this.
In reality, networking is way way slower, 10000x slower (latency numbers every dev should know Latency Numbers Every Programmer Should Know · GitHub). And this assumes no hop between your 10⁷ cores and the victim.
Furthermore, the random 64-bit coefficients are resampled at each batch verification attempts, so unless the verifier doesn’t use a cryptographic RNG, the attacker has no way to adjust the scaling factors to the verifier.
Lastly every single node that listen to the attestation channel need to be fooled, a single wrong signature will blacklist you from the peer pool.
So for all intent and purpose, you only get one shot to fool a single peer that somehow leaked their RNG or blinding factors, and in this one shot you will in the process be blacklisted by all the other peers that seeded their blinding factors differently.