I think it's interesting to compare other situations where signatures get used a lot on keys. A good one might be lightning: in that case, they use a noise-based transport protocol to encrypt the actual tx messages etc, as well as onion routing. however, channel counterparties by definition will see a lot of messages on the same key; just not, 1000s, usually it'll be more like 10s (but that can be enough for lattice attacks to work). Another example is TLS, it's been years since I studied it but iirc it starts with a diffie hellman exchange, not a signature; signatures are used for the PKI part (that is, the certificates presented by the server (not usually client) to the client are signed by an authority in a tree structure; i guess technically this can result in a lot of signatures on single authority keys, so there could be conceivably attacks there).
I'm certainly not sure but I think the continued use of RFC6979 is a tremendous bastion of defence against all these attacks (and the algo is changed in BIP340 signing but it's just a simpler version, it should give the same result - no nonce bias). The area of concern might be more likely the cooperative protocols where deterministic nonces can't be used (see the MuSig bip for some discussion).
quotingI sadly somewhat agree. I had a discussion ~ 1.5 yrs ago on here with someone where we both had the same thought: what saves bitcoin users from slightly weak nonces being dangerous to their funds is non-address reuse. (I recommend the paper "biased nonce-sense" by Tanja Lange et al on this). If you use nostr keys as bitcoin keys then even 1 or 2 bits of bias in your nonce generation could be enough to lose the funds.
nevent1q…l5x3