2
I've modified the r-scan Python code to look beyond the 50 Txs the Blockchain.info API usually returns.
My modifications take all the r values for my address and look for duplicates, but a commented out section of code makes mention of just checking the TxIDs which have more than one input script.
Is it only Txs with multiple inputs that are the problem?
1
Any reused nonce is a problem, it's not restricted to a single transaction.
No competent software will ever reuse nonces accidentally, so using a scanning script like that is just ruining your privacy for no real benefit. Bitcoin Core, Electrum and Armory all use RFC 6979 deterministic nonces so there is no room for RNG failure in these cases, though any software faulty enough to fall at that hurdle will have used the same RNG to make the private keys as well.
1I have to add that reused nonce while signing with differrent privkeys is also a problem. Even in different crypto-currencies – amaclin – 2015-06-28T16:30:06.700
@amaclin I think you're wrong (but please correct me if I'm wrong). Given two signatures with identical
rvalues signed by different privkeys, how can you calculate thekvalue (the nonce)? (Although if you do have thekvalue, you can find the privkey which signs any message using that samek(and therefore the samer) value.) – Christopher Gurnee – 2015-06-28T21:39:21.0471
k = ( digest + r * privkey ) / sIf I know one privkey, I can findkand another privkey – amaclin – 2015-06-29T05:43:45.1831@amaclin Thanks, but I was rather assuming that the privkeys were, well, private. I was trying to say that you need either a compromised privkey or a compromised
k(either of which initially requires two sigs with the same privkeys andks) before you can start looking for related "chains" of privkeys/ks. Still, your point about avoidingkreuse (unless the message/zand privkey are the same) is certainly good advice.... – Christopher Gurnee – 2015-06-29T23:00:34.647