Yeah, the attack barely work without the lock, as you would have to rely on pure luck on getting the port delta small enough.
Because of the lock, the first request you make after you get the lock was likely garbage, and then you have 250ms to get as many requests as you can. Performance here was key, since you couldn't easily do simultaneous requests so you ere limited by the number of round trips you could do in that time.
Some people managed to do simultaneous requests, but you had to do more book keeping since the delta on the first responding webhook contained all the information (eg, for a failed first chunk on N requests, you would expect a difference of 2*N). You would also have to synchronize with the lock, which isn't easy.
Due to load on the servers, SSL negotiation was extremely slow, so using a Keep-Alive connection was required for decent performance.
My final Python implementation managed to eliminate about 4 candidate chunks/sec even under heavy load. I managed to finish #90.
Because of the lock, the first request you make after you get the lock was likely garbage, and then you have 250ms to get as many requests as you can. Performance here was key, since you couldn't easily do simultaneous requests so you ere limited by the number of round trips you could do in that time.
Some people managed to do simultaneous requests, but you had to do more book keeping since the delta on the first responding webhook contained all the information (eg, for a failed first chunk on N requests, you would expect a difference of 2*N). You would also have to synchronize with the lock, which isn't easy.
Due to load on the servers, SSL negotiation was extremely slow, so using a Keep-Alive connection was required for decent performance.
My final Python implementation managed to eliminate about 4 candidate chunks/sec even under heavy load. I managed to finish #90.