Can you elaborate on this point? What nonce can you send that would leak the private key and by whom? At least in my implementation, the nonce is generated by the message sender
who doesn't have the private key and may be malicious. That attack is that the sender picks a nonce which is not on the curve and then attempts to learn something about the point that the receiver has generated using the bogus point— e.g. probing it to see if the 'checksum' fails.
The secret key * off-curve-point is equivalent to performing ECDH on the quadratic twist, and for secp256k1 the twist is not really cryptographically strong. In a trivial cryptosystem where the decrypting party just happens to tell you the secret they derrive compromising their private key is not hard, in practical systems it can be harder to exploit but also hard to be confident if it's never exploitable.
Also, what is the danger to using the same key to sign and encrypt? Just curious.
The classic example is RSA where even deployed systems have been compromised by sending blinded encrypted data, getting them to sign it, and unblinding the result to yield decrypted data with that key. Basically the security assumptions of an algorithm can be broken by doing other things with the key material outside of the algorithm... usually its fine. Sometimes it's not. Figuring out where its fine or not is hard, so it's considered a better practice to just generate separate signing and encryption keys and sign the encryption key to bind them... sometimes there are important reasons to compromise on this rule of thumb, of course. But absent a good reason its good to keep them separate (perhaps doubly so in that there are no strong proofs of ecdsa's security— only ones that make rather broad generalizations, if we can't prove ecdsa secure the being confidence that ecdsa plus a potential additional side channel to the secret key is harder.).
