Let's say someone (person A) starts using Bitcoin and in a period of time eagerly publishes some of their randomly generated (eg. by the Satoshi client) receiving Bitcoin addresses on formus, sends some other addresses to some people etc.

The old keys are now associated with person A, and in a couple of years, some people might want to send person A some funds; they might find one of these old addresses (on an old forum post or in an old private Bitcoin address book) and use them.

But by now, A has moved on to using another wallet instead of the original Satoshi client, and moved all their funds there.

Doesn't this mean that A will forever have to keep track of all the original (non-deterministically generated) private keys of all the addresses that he might have sent, or made available, to other people, and keep importing them into new wallets whenever he moves to a new wallet system, and keep backing them up (safely), etc.? This seems very tedious and error-prone.

I know it's recommended to use a new address for each new transaction, but that's in no way enforced, and more importantly, it's out of person A's control -- it's all the other people that might want to send them money.

This problem will be less important in the future (eg. with deterministic key generation that requires only the seed to be backed up), but someone using the Satoshi client extensively and freely in the past might never be able to make a clean cut.

So is this a real problem or do I understand things incorrectly? Maybe there's a simple (and safe) workaround, or maybe this is not so cumbersome after all?

3 Answers 3


I think the core of the problem is that we call base58-encoded public key hashes "addresses", no matter whether people are willing to accept payments to them.

In my opinion, they are just identifiers for a public key - something internal in Bitcoin's technology. Humans shouldn't ever see them, unless they are debugging.

Satoshi originally didn't intend to use the current base58 addresses as "payment destination" - he thought pay-to-IP (where the public key was negotiated on the spot) would be the common way of doing transactions. The pay-to-pubkeyhash-via-P2P was only added later for cases where the receiver was offline. Pay-to-IP had several problems, and became obsolete, but it had a lot of advantages compared to what we have now. I think the solution is going back to something like that, like a pay-to-URI where again keys are negotiated at the time of the transaction. It means you're always sure the key used is still active, private keys don't need to be retained forever, no key is ever reused (better for Bitcoin's privacy model) and you instantly get support for attaching messages or refund information to transactions.

Of course, people will probably keep the private keys anyway, for example in an archive wallet like mentioned in other answers to this questions. But in my opinion, it shouldn't be a disaster when people don't.

  • 1
    Yes the current bitcoin API is a disaster. Keys (if they are to be used at all as payment destinations) should always come with a (preferably short) expiration date. Sep 29, 2012 at 12:56
  • 1
    Good, so I can expect this to improve in the future. The real solution is to have people see and treat addresses as throw-away data, quite unlike e-mail addresses or phone numbers. The fact that most (all?) Bitcoin wallets feature address books doesn't help here...
    – mazi
    Sep 29, 2012 at 15:44
  • "cases where the receiver was offline" aren't a "nice to have" feature. The ability to fire and forget to a given destination without having to worry about whether the recipient is online is an absolute must, I can't imagine Bitcoin working any other way. Oct 1, 2012 at 20:22
  • 1
    @MeniRosenfeld But we don't even have that right now. There is no guarantee that the network will remember your sent transaction until it gets included. That said, I'm certainly not arguing for removing send-to-pubkeyhash-via-P2P (for example for anonymous donations I see no better way), just arguing that in many cases negotiating a payment has advantages. Oct 1, 2012 at 22:20

Mt. Gox is the first to offer it but a wallet sweeping service is what will solve this.

If you wish to (or need to) abandon a wallet, you can either transfer the keys using a bunch a technical steps, or you can upload the wallet.dat to a service that will watch it and if any funds are received, sweep those funds to an account or Bitcoin address in your control.

Until Mt. Gox builds a UI to accommodate it, this wallet.dat upload feature is only possible using the API. You can already import private keys individually using either the API or the browser/UI.

  • 2
    I don't think giving my private keys to any external service (like MtGox) solves the problem I described since I can't know for how long the service will be around in the future. Additionally, it adds the requirement that I trust the service (by having the keys it can, technically if not legally, spend my funds). In other words, importing the keys into an online wallet is no easier or more long-term than into my desktop wallet, and requires additional trust.
    – mazi
    Sep 29, 2012 at 11:52

In theory, you should keep all of your keys that you believe someone could use to send you money. It might be through importing them into a new wallet, or just keeping the old wallet and occasionally checking on it. If you just use a few of the addresses, you might be inclined to just import those into your new wallet.

As this problem is not that major yet, there are few other solutions you can use. It is possible that in the future the clients will have an "archive wallet" option, where you'd dump all of your old wallets and it would keep track if you get any new coins there without cluttering up your main wallet, or some online service functioning akin to an eWallet.

  • Importing them into the new client, is much better than keeping the old client, since you could easily forget your wallet passphrase, or the program could stop working, etc.
    – o0'.
    Sep 29, 2012 at 12:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.