Exposed / Compromised (must sweep) / Used / Imported (?) flags on addresses #3314

It was pointed out to me that some people have made the mistake of sending coins to addresses which generated by their wallet prior to encryption simply because they're at the top of their address list and they were engaging in the bad practice of reusing addresses.

In GIT the receive interface does a much better job of discouraging reuse, but users still can— and when they do they receive no guidance about which of their prior addresses were exposed by being left unencrypted.

Might it be reasonable to have a set of flags that can show up in the list signifying addresses which are "exposed" meaning that they date from a prior encryption key?

Likewise, I know of at least one incident where a user randomly picked a key they'd imported from a third party as a key to receive funds and the funds were stolen, a flag indicating that the key was imported would have been helpful.

Along these lines, if we ever get around to having a auto-sweeping feature, might it make sense to have a "this wallet is compromised" button that rekeys, forces a backup, and then marks all existing addresses as compromised which flags them for automatic sweeping?

A "generation type" could be added in the key metadata that specifies whether it was generated without encryption, generated with encryption, or imported.

This could be shown in the list of receiving addresses.

We have a key rotation feature in bitcoinj. It just records the rotation time in the wallet. Any funds sent to keys born before that time are automatically forwarded to the first non-rotating address ("swept"). You can't mark individual keys as rotating or not, it's a whole-wallet thing.

However, encrypting the wallet doesn't automatically make previous keys rotate. Perhaps it should, but then it's not guaranteed that previous keys are actually compromised in any way, and rotation has a cost in fees.

Maybe also a good idea would be to allow the user to set a encryption password before a first key gets created. Could also be included in the Bitcoin-Q's first run wizard. I think https://hivewallet.com has such a start-wizard-like-thing.

But a "exposed" flag in the GUI would be nice.

Once we switch to HD wallets, this doesn't make sense anymore since there's effectively one private key for the whole wallet.

The notion of exposure still has value even in an HD world. Consider the case where you have a wallet that doesn't have any password, perhaps because when you got started with bitcoin you only had a dollar or two's worth, then bitcoin got worth more, or you decided to get more into it. Later on you decide to set a password. But the old key is still sitting around on disk, old backup locations, etc. It's easier to just mark the old key hierarchy as "exposed" and create a new one, then move the funds, than religiously scrub everywhere the old key might have been.

I'm currently working on this. The question is where we should show the key-metadata (created unencrypted, created encrypted, imported, etc.). As far as i know we only have getaccountaddress on RPC side which shows addresses. We could add a boolean arg to getaccountaddress that would allow showing the addresses with metadata.

Same question for the UI. Where would it best to add a "unencrypted warning sign"? Very rough designed it could look like this:

I think this issue can be closed, 0.13.0 introduced HD wallets by default, and then recently descriptor wallets by default in 23.0.

I think this issue can be closed, 0.13.0 introduced HD wallets by default, and then recently descriptor wallets by default in 23.0.

I don't think HD wallets sufficiently resolves this issue. We can still import things, reuse addresses, have descriptors be compromised, etc. so having these annotations would still be useful.

Do we still show addresses from the old SPKM(s) in the GUI after encrypting? My understanding was that they were no longer marked as active and so I assumed they would not show there (but I never tested it out).

Do we still show addresses from the old SPKM(s) in the GUI after encrypting?

Yes, the address book is a thing.

Copying my response from #27216

It seems to me the proper solution which we should recommend to our users in such case is to get a new wallet, rather than rotating keys in existing wallet. So the idea is that the whole wallet is compromised, not just some keys in it. We don't have a good separation between UTXOs/addresses within a wallet. On the other hand we already support multiple wallets, which are completely isolated so there are no chances of leaking/mixing UTXOs and addresses.