Specify location for wallet.dat file

kasperhartwich commented at 9:30 pm on February 13, 2011: none

It should be possible to specify a location for the wallet.dat file.

gavinandresen commented at 1:48 pm on February 19, 2011: contributor

Need to be very careful about accidentally corrupting the wallet.dat file by pointing two running bitcoins at the same wallet.dat file. Berkeley db doesn’t do any automatic multi-process locking.

Right now, a lock file is created in the -datadir Bitcoin is using, but if we allow the wallet to be anywhere in the filesystem that protection wouldn’t work.

grebulon commented at 11:40 pm on March 6, 2011: none

I second that. There should be an option to set the location via GUI. It would also be nice to be able to specify a secondary location, where a mirror of the wallet could be saved, possibly on a network path.

sgornick commented at 9:16 am on April 13, 2011: none

I had suggested a -walletdir parameter here: http://www.bitcoin.org/smf/index.php?topic=2730.0

Would probably also be necessary to start with a -rescan then when switching between wallets, right?

sipa commented at 12:34 pm on April 13, 2011: member

This is useful, I think. You can create an additional lockfile in the walletdir, to prevent multiple processes from accessing the same wallet. Furthermore, it’s relatively easy to detect the “switching back to an earlier wallet” case, by storing the best block index in the wallet as well (suggested by Satoshi somewhere).

gavinandresen commented at 6:21 pm on April 13, 2011: contributor

I wonder if just using wallet.dat as it’s own lockfile would/could work…

sipa commented at 8:51 pm on April 13, 2011: member

Judging from boost::interprocess:file_lock documentation, it should…

grebulon commented at 6:16 am on April 14, 2011: none

Will you also give an option to replicate the wallet to a secondary location?

alexgenaud commented at 1:56 am on May 27, 2011: none

If the wallet were composited of isolated static keys (plain text or as separate files in a wallet directory) then would there be any concern for corruption? Couldn’t every address/key be write-once-never-modify?

sipa commented at 9:26 am on May 27, 2011: member

@alexgenaud: the wallet is much more than a collection of keys - it also contains transactions, accounting information, settings, and information about the block chain

alexgenaud commented at 2:20 pm on May 27, 2011: none

Can most of that information be recreated from the network? Presumably we want to specify different wallet locations because we’ll have many of them, likely stored on different media, backed up, encrypted, etc. If that’s the case, I would think some isolated entities (the keys) should be write-once-never-modify.

TheBlueMatt commented at 9:54 pm on May 29, 2011: member

Yes, the list of transactions can be easily recomputed (and are fairly sanely). The settings, no…but those are just the things in the preference dialog. Accounts, well that also not, but those are so broken anyway…anyway, those are tied to the list of addresses, so that also shouldn’t be a problem

TheBlueMatt commented at 9:54 pm on May 29, 2011: member

Also, this bug should be long closed, we have -datadir=…

sipa commented at 9:56 pm on May 29, 2011: member

I believe this is about a the location of the wallet specifically - that’s useful, and/or is a step towards general wallet management.

TheBlueMatt commented at 10:21 pm on May 29, 2011: member

Ah, well then yea. Is there also a bug for separate -conffile= location, as that falls under the same category.

alexwaters commented at 6:42 am on September 6, 2011: contributor

#220 wallet import and export should resolve this issue, please contribute to that thread.

Edit: reopened per Sipa’s advice

alexwaters closed this on Sep 6, 2011

sipa commented at 8:11 am on September 6, 2011: member

As the author of pull #220, I’m not convinced this is about the same problem.

Having the client manage different (or even multiple) wallets at once would be a very useful think imho, independent from the ability to import/export them.

alexwaters reopened this on Sep 6, 2011

alexwaters commented at 8:23 am on September 6, 2011: contributor

I have added the wallet label so that these issues are grouped. Some of them overlap, and it makes more sense to group them than to condense them.

Cheers Sipa, and kudos on the Wallet work =)

keystrike commented at 6:54 pm on April 1, 2013: contributor

Any work done on this? I read on the forum that since the blockchain doesn’t use BDB it will be easier to add this option now. Thanks!

gmaxwell commented at 6:57 pm on April 1, 2013: contributor

@keystrike it’s likely going to get subsumed by the multiple wallet support.

laanwj commented at 5:45 am on April 29, 2013: member

Does that mean you’re volunteering to do it @APerson241 ? Otherwise, please spare us your judgements as to how easy or difficult something is.

gavinandresen commented at 3:29 am on August 16, 2013: contributor

Closing; 0.9 release has a “-wallet=filename.dat” option. It must still be in the -datadir, though.

gavinandresen closed this on Aug 16, 2013

zathras-crypto referenced this in commit ae848c43f8 on Jul 23, 2014

rdponticelli referenced this in commit bd696ebd3f on Nov 26, 2014

dexX7 referenced this in commit 644fe91882 on May 19, 2015

dexX7 referenced this in commit 4eabf887f3 on Jun 1, 2015

jtimon referenced this in commit 8c323e0acc on Mar 11, 2016

ptschip referenced this in commit ec9cf4f120 on Aug 12, 2016

CryptAxe referenced this in commit 5e2ae147e0 on Mar 11, 2018

CryptAxe referenced this in commit dec54b30be on Mar 11, 2018

effectsToCause referenced this in commit 26945d2f70 on Jun 22, 2018

practicalswift referenced this in commit e5ff37feed on Nov 11, 2018

attilaaf referenced this in commit 6cc9acc7f9 on Sep 20, 2019

Losangelosgenetics referenced this in commit cbdbba993f on Mar 12, 2020

MarcoFalke referenced this in commit 3bcd278aa6 on Mar 29, 2021

rajarshimaitra referenced this in commit 4b418666e6 on Aug 5, 2021

MarcoFalke locked this on Sep 8, 2021

Specify location for wallet.dat file #68