Importing KNOWN private keys into a wallet

[neilol]

Is there any disadvantage to importing a known private key, or easily crackable private key, into a wallet with other personal addresses that aren't meant to be public.

For example, say I have a web wallet on blockchain with 3-4 personal addresses, and I import the private key that corresponds with the hash of "password". What are the implications here? I'm probably not clear on how change works, could it accidentally be sent to this address?

Does the answer change anything if you are using different wallet clients (web vs local)?

[1715015394]

1715015394

[1715015394]

1715015394

[1715015394]

1715015394

[Stephen Gornick]

Is there any disadvantage to importing a known private key, or easily crackable private key, into a wallet with other personal addresses that aren't meant to be public.

With Bitcoin-Qt the imported key with a prior transaction will show as used and won't then be used for change in the future.   But not all wallets work that way, and could possibly send change to some other address from the wallet (e.g., chosen at random).

So, it is nearly ALWAYS a bad idea to import a private key into your wallet if you aren't sure that you are the only party with control of that private key.

[Dabs]

Imported keys will never be used as change, unless you specify it. It might be used as input in a transaction. Besides, why would you do that? You can always see it in the blockchain.

It's another thing to import a whole bunch of keys for watch-only purposes, but you have PyWallet for that (no need to know private key, or store it.)

[Stephen Gornick]

Imported keys will never be used as change, unless you specify it.

Depends on the client.  Blockchain.info will pick one in your wallet for you.  I don't know how the other clients work.

[DannyHamilton]

Change is really a pretty small risk.  Most wallets aren't going to use an imported address as your change address unless you do something to force the wallet to do so.

The much larger risk is accidentally creating transactions that will never confirm.

Example:

You import a very publicly known private key for address A.
You have your own address B unique to your wallet.

You receive 3 outputs to your address B valued at 1 BTC, 3 BTC, and 0.25 BTC (for a total of 4.25 BTC)

You start to create a transaction to send 3.01 BTC somewhere.

Someone sends 0.03 BTC to address A.

Your wallet uses the 3 BTC output from address B and the 0.03 BTC output from address A to fund the transaction, sending 3.01 BTC to the destination address, 0.0199 BTC to a change address, and paying a 0.0001 BTC transaction fee.

Someone else creates a transaction sweeping the 0.03 BTC from address A to some address they own or paying it entirely as fees or whatever.

That other transaction is broadcast, then moments later your transaction is broadcast.

There is now a double spend of the 0.03 BTC being relayed throughout the network.  It's a race of 0-confirmation transactions, and the other transaction has a head start.

The other transaction gets confirmed since it made it to more peers and miners.  Your transaction gets dropped from the memory pools as a double-spend attempt.

Unfortunately, the recipient of your transaction was willing to accept 0 confirmation transactions, and was one of the few that received your transaction before the other one.

Now that recipient is quite unhappy with you, since as far as they can tell you are a computer hacker that pulled off a double spend fraud against them and stole 3.01 BTC worth of merchandise from them.

Do you really want that sort of headache?

[Abdussamad]

If you are using blockchain.info it is a very big risk. It will reuse any address to send change to.

[DualSignal]

If the address contains many transactions performance may be reduced.

[J35st3r]

If the address contains many transactions performance may be reduced.

You most definitely do not want to import "correct horse battery staple". I'm not going to tempt fate by including the actual address. If your curiosity gets the better of you, then you've only yourself to blame for the resulting snafu.