There never has been a single 1e-8 btc lost due to reused/bad K ... in a competent implementation. The places we've seen lossage have been implementations which were horrific in other ways as well (like only having 32..48 bits of randomness total)... ultimately, if you can't generate strong random numbers you're going to be utterly screwed in any case, because your private keys themselves will be predictable. It's more important for embedded/hardware implementations which are more likely to suffer from randomness problems and are easier targets for attack. (e.g. tampering with the supply chain for all server hardware in order to backdoor Bitcoin Core is probably much less attractive than going after the supply chain for a hardware wallet). So while derandomized signing is a good practise because it aids auditability and _maybe_ reduces the space for incompetent implementations to screw up a bit, in someplace like Bitcoin Core I don't generally consider it very important (though, we did it in any case; in part to set a good example).  I had proposed the ecosystem switch to it, back around when BIP 32 was announced, but we hadn't switched to it in Bitcoin Core yet because derandomized signing basically requires replacing what OpenSSL does. (OpenSSL does have a non-standard quasi 6979 implementation in its source repository-- for a long time I'd hoped to pick that up-- but its never made it into production for some reason.)

With respect to the side-channel attacks. It seems to be impossible to convince people of the non-wisdom of running critical cryptographic software on commodity shared-hardware virtual machines; just like it's hard to convince them to stop reusing addresses. Especially when coupled with the fact that the parties doing this are usually handling third party funds, it seems like disaster waiting to happen in a number of respects. With flush+reload boosted side-channel attacks being successfully performed against OpenSSL for our curve with a surprisingly small number of queries, I did consider that fairly concerning.

The distinction is that getting the signing nonces right is a process that can be secured one time for all users by auditing the software; but making sure users don't deploy in a side-channel vulnerable way is something that must be done for each and every user and doesn't really scale. The possitiblity of side-channel attacks is very surprising to people so they don't tend to do much to secure against them. Better to just close the sidechannel.

(also, wtf is with this thread? it seems like five threads merged together. It's impossible to read; I never would have found this post except by pure chance.)