> There aren't many in-the-wild timing attacks because constant-time is table stakes for cryptography implementation, and has been for decades. That is one the

> There aren't many in-the-wild timing attacks because constant-time is table stakes for cryptography implementation, and has been for decades. That is one theory and plausible, but another plausible theory is the conditions to setup a timing attack is usually infeasible due to requiring high precision timing, a very large number of samples/measurement, and requiring probes in an ideal situation. AES in software is still a good example of an algorithm where timing attacks are still possible. Take for example djb paper on cache timing [1], it requires 4 million samples before key recovery. The reality is that kind of attack is highly unlikely to occur, and there's been opportunities where non timing safe AES has been used. I'd argue the more pragmatic stance of an attacker is that that timing attacks aren't really practical unless attacking a protection mechanism of a piece of hardware like the Xbox 360, at least for network services it is really low on the list. As for the ECDSA attack, again impressive feat, but only 773 wallets which isn't real cause for concern. I think the bigger concern is using amateur 3rd party implementations of bitcoin that doesn't do nonce generation properly when signing, it really isn't that hard, but I agree it can be a footgun. The reality is this is still a negligible concern compared to real attacks happening everyday draining crypto wallets due to malware threat. [1]: https://cr.yp.to/antiforgery/cachetiming-20050414.pdf https://cr.yp.to/antiforgery/cachetiming-20050414.pdf