Clarify relationship between synthetic nonces and anti-covert-channel

[jonasnick]

@roconnor brought this up, but I'm not sure what exactly his issue was (perhaps he wants to comment here). Our current paragraph on this is quite general and therefore not too bad imo. Maybe we can make the following improvements:

• Note that in general using synthetic nonces has a negative effect in the malicious hardware wallet model because you can not spot check.
• If you use anti-covert-chan techniques there are tradeoffs with using randomness in the nonce derivation. See link to pieter's summary https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-March/017667.html

[roconnor]

My issue was that if HW wallets internals are usually difficult to audit and if they use synthetic nonces then it won't even be possible to spot check that they are not engaging in covert communications to leak secret material.

However synthetic nonces seem reasonable for software wallets. I think I'm okay with keeping the synthetic nonce derivation inside as long as we recommend that hardware wallets use a different, anit-covert-channel method and refer them to an appropriate document.

I'm even willing to try to write up a document for anti-covert-channel HW signature. I'm just worried that because I don't personally make hardware wallets, no one will use it because I somehow misunderstand some aspect of their design constraints.