Bitcoin Forum

Let's say I were to make a copy of my wallet to a usb or cd. If i take that copy and install it on an extra computer will the original wallet still be useable on the first computer? If I make a transaction on one computer will it update on the other? Sorry if this is a stupid question. I'm asking due to me traveling a lot my desktop having my wallet is somewhat inconvenient, so I had came with the idea to install it to my laptop as well. Is this possible? Is it a bad idea?

Anyone...?

Yes.  Once.


Not automaticly, at least not yet.


Possible, yes.  Still a bad idea, generally.  If you travel much, mybitcoin.com is likely the best balance of convience and security.  Having an unsecured bitcoin wallet.dat file on a laptop is the worst of worlds; not only could you get hacked into while trying to surf at a public hotspot, a snatch-thief could take off with your actual laptop.

If you intend to have bitcoin running on more than one computer, it's better to just have two independent wallets, and send a small amount of funds to the mobile one from the more secure home PC.  You can share wallet.dat files, but neither is aware of the other, and so once one of them were to send coins anywhere, the other wallet.dat file would be functionally void and then you would have a case wherein you would have to be copying your wallet.dat files back and forth.

Based on my understanding of the way wallet.dat works, this might work awhile theoretically, but complications would sooner or later cause trouble, and I'd say it wouldn't be recommended.


Let's try this:

At time zero, you duplicate your wallet.dat and run two independent clients, A and B.

If you receive anything to addresses already given out before time zero, obviously both clients will see the income, assuming you don't do any spends.

For awhile, depending on the state of the wallet.dat's keypool at the instant it was forked, If you do a spend on client A, and ensure the client B has caught up with the blockchain before doing anything with it, you'll see the spend you made with client A and your balances on both A and B will remain consistent.

Eventually, your keypool will be exhausted and the client will replenish it with fresh keys. These keys will differ between the two clients. I think then, at this point, a spend on client A will show up in client B in an interesting way. It may show up as two spends, one matching the transaction you remembered making on client A, and the other as some other amount to an address you don't recognize. And, the balances between the two will become inconsistent.

What's happened there was that client A gathered up sufficient bitcoin from unredeemed inputs to make the indicated spend, and spent out the remainder to the next "hidden" address in client A's wallet.dat. But over on client B, it's wallet.dat doesn't contain this key. So it lends the appearance that "someone" reached inside and stole some bitcoin.

Worse, I think, is that if the two clients are not kept rigidly in-sync with the blockchain before new transactions are attempted, you might inadvertently double-spend some bitcoin from one of the clients. And I think this might be possible even if the balance figure seemed to show you had plenty to spend. So you'd get some transactions that would stick in the blockchain unconfirmed, as the chain adopts one or the other of the spends.

This stuff would either start to wreak general havoc, depending on how much transacting you do with your clients. It might be difficult to get the balances back into agreement, as some bitcoin would be held under keys only on client A, some under keys only on client B, and some under keys in common to the wallet.dat's of both A and B. A fine mess!

A better solution is to maintain independent wallet.dats, and spend a necessary balance between them as required. Leaving a home client for a mobile client? E-mail yourself a receive address from the mobile client, and spend a desired balance onto it from the home client. Then travel on.

Or, you could use an intermediary like a Mt. Gox account you own (assuming you trust them). From the home client, spend all or a desired amount into your Gox account. Then, from the road, withdraw the BTC from the Mt. Gox account to your mobile client. Do the reverse when you're back home and ready to use the home client again.

Be sure to have a backup strategy for the wallet.dats of each client!

As I finish writing this, MoonShadow makes a very excellent point about the theft potential for the mobile client. It's a similar risk as having you physical wallet stolen while out on the town. And, perhaps still more reason to start considering my not-yet-fully-formed-but-important notions I make in the rant below, and have elsewhere on this forum a number of times already.


<potentially misguided evangelistic rant>

To me, this exposes yet another way the architecture of wallet.dat and its notions of keys and keypools can get users innocently into serious trouble. You never know precisely what's going on under the hood of your wallet.dat. To me, it would be better if there was an option to make this internal system of keys which testify to the network about your ownership of bitcoin values, more like the way standard public-key crypto works in systems a-la OpenPGP. The client could have switches to allow users to choose the behavior they wished to use.

If wallet.dat were instead replaced with something a bit more like OpenPGP-style keyrings, you could choose to create a single static key for yourself. Your balance would accrue to this single key, and be spent away from this single key. You could copy this key from client to client and have access to the same balance (assuming the blockchain is up-to-date on the client). You could vault-away this key upon creation and not have to worry about making periodic backups of wallet.dat. You lose anonymity. Your transactions become more easily traced back to you, because "you" always show up under the same key in the blockchain. It's a tradeoff I think a lot of folks might be happy to make. This is an issue with the current official client. If the official developers have no interest, it certainly wouldn't preclude some other motivated devs to create a compatible client which introduces this operational difference.

</rant>

<rant>
Oh, I forgot, also this private key is always stored encrypted. With a slow key scheduling cipher like blowfish preventing effective brute-force attacks on the passphrase used to lock it. This eliminates most, to effectively all, of the risk in the snatch-and-grab scenario of a having your key on a mobile client, and having a thief make off with the key file, or jack your laptop at the Starbucks.
</rant>

Thanks for the responses guys. Very insightful.

Yes it will, since 0.3.21.