Using the same Bitcoin address more than once

Is it okay to reuse a Bitcoin address (forget about privacy for now)? I’ve come across info saying that if the random nonce k for the ECDSA signature isn’t picked randomly, then it could lead to someone figuring out the private key. Is this something that actually happens in real life? I usually test new addresses by making a small transaction to ensure they’re functioning properly. I’m running Bitcoin Core version 27.1.

You can reuse the addresses as many times as you want. In practice no one is going to be able to derive your private key just because you are reusing the public key that belongs to it. People say to not reuse private addresses for privacy, since they can see how you keep adding funds to the same address. You could always mix the address after you have a considerable amount and want to hide it from public eye.

If you say, you don't care about privacy (privacy excluded), you can use a same address many time. It's address reuse. It practically is not good for your privacy and in order to get better privacy, you need to use Bitcoin change addresses. Some advice is here https://blockchair.com/bitcoin/privacy-o-meter Spending your Bitcoin

Yes. That is true. If your nonce is known, then you can calculate the private key from your signature. However, Bitcoin Core is open source and a simple bug like this would probably be caught on early and should never make it into a stable release. The problem concerning address reuse, which is often blown out of proportion is the possibility of repeated nonce in the signature. When nonce are being repeated, you can calculate the private key from two different signature. This is only in the case where nonce are non-random and being reused across multiple transactions. This is a problem with poorly implemented CSPRNG with certain poorly designed wallets in the past. However, Bitcoin Core uses RFC 6979 to ensure every signature is distinct and deterministic. As such, the chances of repeated nonce is zero.

Yes, that's why clients like Bitcoin Core use pseudo random values that for that reason. Ref: github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L208-L234 Reusing address doesn't necessarily mean that every transaction that you'll create will use the same nonce when producing signatures. An address that you reuse may be a representation of the same script but it has nothing to do with the generation of k value when spending the multiple UTXOs linked to it. Check the reference above for the function Bitcoin Core uses.

Wallets like Bitcoin Core practically force the user to use new addresses every time the receive button is pressed by the user, but as others have said, using new addresses for each receive is a matter of privacy, you are not necessarily vulnerable to changing signatures to exfiltrate your private key. I think they should change the UI/UX of the receive tab in Bitcoin Core, I think they should never have changed the design of the tab, just compare how much more practical it was to receive to a new address or reuse an old one in the old UI, the old addresses were listed in the same tab, we could generate a new QR code from any address (with a new address or reused). Electrum unfortunately followed the same path, adding the name "invoices" for on-chain receiving with invoices with expiration dates. Unfortunately, this only causes more confusion than it helps. For example, newbies mistakenly think that addresses created by invoices with expiration dates will be canceled or invalid.

You got the point of the receiving tab's UI, the goal is to advocate the use of a new address in every transaction for the user's privacy. Think about it, is it better to set a default behavior that results with better privacy for those who don't understand how privacy works; Or set the default to reuse address that could be bad for the user's privacy? People who know its consequences and know that it's reusable will reuse addresses whether their wallet's receive tab is giving then new addresses every time. On the other hand, people who don't know that they can reuse their addresses shouldn't be advised to reuse their address just because it can be reused. For the latest GUI: If the user needs to re-use an address, he can just open one of his invoice and copy that invoice's address, much like in the old version. Or go to his receiving address list in "Window->Receiving Addresses".

If the k is random but reused, it will leak your private key if you create more than one signature using it (that includes message signing, creating and signing more than one transaction that includes address reuse). If the k is not random (is weak), it will leak your private key on first use. It doesn't take reuse in this case to leak the key. Such a problem never existed in bitcoin core though. And these days all popular wallets including core use RFC6979 to deterministically derive the ephemeral key (k) for signing that eliminates that issue altogether.

There shouldn't be a security problem with address re-use on Bitcoin Core because it's not using a deterministic nonce inside the signatures. It's using a completely randomly-generated nonce for all address types. But even the wallets that do use a deterministic nonce most likely use RFC6979, which is still quite hard to break. Not so much if it is using other pseudo-random techniques.

Only if you use a very, very shitty wallet. I remember reading this case (although it was about "R values" instead of "nonce k").

It should be fine if you don't care about privacy, but I would still suggest doing good address management and labeling for all transactions. Fees could be another problem so doing consolidation when fees are low is a good idea. I think Silent Payments is a good alternative for generating new address each time you need to receive payment from someone.

The r values mentioned is actually related to the k nonce, as this topic. You get the r value by multiplying (aka. Elliptic Curve Multiplication) of the k value with the secp256k1 generator point. Hence, the repeated k led to the repeated r. The Android wallet fiasco is another big incident. This wouldn't happen with well known and developed wallets. Bitcoin Core uses deterministic nonce for all the signing as of 0.10.0. Probably as difficult as having to break the nonce without any information. If its correctly implementing RFC6979, then k is generated deterministic by both your private key and your data, which means it doesn't depend on CSPRNG at all.

blockchain.info is probably the most popular shitty wallet in short bitcoin history! I remember at some point they were using random.org to generate k value! And they even did that in the stupidest way possible. The code didn't even check if the http respond was successful or sent the correct reply; so when random.org changed its system and started sending a broken respond, the blockchain.info wallet software used that as the actual respond and computed k value based on that so everyone using their wallet ended up with the same k value!