Data directory - Revision history

NotATether: Windows 8, 10 and 11 all use AppData\Roaming

2024-03-22T10:34:30Z

Windows 8, 10 and 11 all use AppData\Roaming

← Older revision		Revision as of 10:34, 22 March 2024
Line 10:		Line 10:
	Bitcoin's data folder will open. For most users, this is the following locations:		Bitcoin's data folder will open. For most users, this is the following locations:

	C:\Documents and Settings\YourUserName\Application ~~data~~\Bitcoin (XP)		C:\Documents and Settings\YourUserName\Application Data\Bitcoin (XP)

	C:\Users\YourUserName\~~Appdata~~\Roaming\Bitcoin (Vista and 7)		C:\Users\YourUserName\AppData\Roaming\Bitcoin (Vista and later)

	"AppData" and "Application ~~data~~" are hidden by default.		"AppData" and "Application Data" are hidden by default.

	You can also store Bitcoin data files in any other drive or folder.		You can also store Bitcoin data files in any other drive or folder.

NotATether: /* Personally identifiable data [v0.8 and above] */

2022-10-31T06:24:50Z

Personally identifiable data [v0.8 and above]

← Older revision		Revision as of 06:24, 31 October 2022
Line 67:		Line 67:
	*settings.json		*settings.json
	**Contains GUI settings with a similar nature to those in bitcoin.conf.		**Contains GUI settings with a similar nature to those in bitcoin.conf.
			*.cookie
			**Contains temporary RPC credentials in situations where you haven't specified an explicit username & password. Do not share with others.
	*onion_v3_private_key		*onion_v3_private_key
	**Contains your hidden service key if you are running Bitcoin Core through a Tor connection. Do not share with others or they will be able to spoof your .onion address. On older versions of Core this file was called <code>onion_v2_private_key</code>.		**Contains your hidden service key if you are running Bitcoin Core through a Tor connection. Do not share with others or they will be able to spoof your .onion address. On older versions of Core this file was called <code>onion_v2_private_key</code>.

NotATether: /* Directory Contents */

2022-10-31T06:22:37Z

Directory Contents

← Older revision		Revision as of 06:22, 31 October 2022
Line 68:		Line 68:
	**Contains GUI settings with a similar nature to those in bitcoin.conf.		**Contains GUI settings with a similar nature to those in bitcoin.conf.
	*onion_v3_private_key		*onion_v3_private_key
	**Contains your hidden service key if you are running Bitcoin Core through a Tor connection. Do not share with others or they will be able to spoof your .onion address. On older versions of Core this file was called `onion_v2_private_key`.		**Contains your hidden service key if you are running Bitcoin Core through a Tor connection. Do not share with others or they will be able to spoof your .onion address. On older versions of Core this file was called <code>onion_v2_private_key</code>.

NotATether: /* Personally identifiable data [v0.8 and above] */

2022-10-31T06:22:16Z

Personally identifiable data [v0.8 and above]

← Older revision		Revision as of 06:22, 31 October 2022
Line 67:		Line 67:
	*settings.json		*settings.json
	**Contains GUI settings with a similar nature to those in bitcoin.conf.		**Contains GUI settings with a similar nature to those in bitcoin.conf.
	*~~onion_v[2\|3]_private_key~~		*onion_v3_private_key
	**Contains your hidden service key if you are running Bitcoin Core through a Tor connection. Do not share with others or they will be able to spoof your .onion address.		**Contains your hidden service key if you are running Bitcoin Core through a Tor connection. Do not share with others or they will be able to spoof your .onion address. On older versions of Core this file was called `onion_v2_private_key`.

NotATether: /* Personally identifiable data [v0.8 and above] */

2022-10-31T06:21:16Z

Personally identifiable data [v0.8 and above]

← Older revision		Revision as of 06:21, 31 October 2022
Line 62:		Line 62:
	**This should only exist when bitcoin-qt is currently running. It contains information (BDB state) relating to your wallet.		**This should only exist when bitcoin-qt is currently running. It contains information (BDB state) relating to your wallet.
	*peers.dat		*peers.dat
	**~~Unknown whether this~~ contains personally identifiable data. It may be safely deleted.		**It contains addresses and connection statistics of peers, but does not contain any personally identifiable data. It may be safely deleted.
			*bitcoin.conf
			**May contain your IP or hidden service address, paths on your filesystem, and RPC credentials.
			*settings.json
			**Contains GUI settings with a similar nature to those in bitcoin.conf.
			*onion_v[2\|3]_private_key
			**Contains your hidden service key if you are running Bitcoin Core through a Tor connection. Do not share with others or they will be able to spoof your .onion address.


	Other files and folders (blocks, blocks/index, chainstate) may be safely transferred/archived as they contain information pertaining only to the public blockchain.		Other files and folders (blocks, blocks/index, chainstate) may be safely transferred/archived as they contain information pertaining only to the public blockchain.

934: /* Directory Contents */ remove outdated infromation, but retain link to upstream doc

2019-10-10T20:03:15Z

Directory Contents: remove outdated infromation, but retain link to upstream doc

← Older revision		Revision as of 20:03, 10 October 2019
Line 49:		Line 49:

	An overview of these is in [https://github.com/bitcoin/bitcoin/blob/master/doc/files.md files.md] in the Bitcoin Core documentation.		An overview of these is in [https://github.com/bitcoin/bitcoin/blob/master/doc/files.md files.md] in the Bitcoin Core documentation.

	* .lock
	** Bitcoin data directory lock file
	* bitcoin.conf [optional]
	**Contains [[Running_Bitcoin#Bitcoin.conf_Configuration_File\|configuration options]].
	* blk''xxxx''.dat [Versions prior to v0.8.0]
	**Contains concatenated raw blocks. Stored are actual Bitcoin blocks, in network format, dumped to disk raw.
	* blkindex.dat [Versions prior to v0.8.0]
	**Indexing information used with blk''xxxx''.dat
	* __db.''xxx''
	**Used by BDB
	* db.log
	* debug.log
	**Bitcoin's verbose log file. Automatically trimmed from time to time.
	* wallet.dat
	**Storage for keys, transactions, metadata, and options. <span style="color:red">Please be sure to make backups of this file. It contains the keys necessary for spending your bitcoins.</span>
	* addr.dat [Versions prior to v0.7.0]
	** Storage for ip addresses to make a reconnect easier
	* peers.dat [Versions v0.7.0 and later]
	** Storage for peer information to make a reconnect easier. This file uses a bitcoin-specific file format, unrelated to any database system<ref>[http://bitcointalk.org/index.php?topic=119525.msg1287284#msg1287284 Ultraprune merged in mainline]</ref>.
	* fee_estimates.dat [Versions v0.10.0 and later]
	** Statistics used to estimate fees and priorities. Saved just before program shutdown, and read in at startup.
	~~The data, index and log files are used by Oracle [http://en.wikipedia.org/wiki/Berkeley_DB Berkeley DB], the embedded key/value data store that Bitcoin uses.~~

	~~===database subdirectory===~~
	~~Contains BDB journaling files~~

	~~===testnet3 subdirectory===~~
	~~Contains testnet versions of these files (if running with -testnet)~~

	~~===blocks subdirectory===~~
	~~[v0.8 and above] Contains blockchain data.~~

	* blk*.dat
	** Stored are actual Bitcoin blocks, in network format, dumped to disk raw. They are only needed for re-scanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.

	* blocks/index subdirectory
	** [v0.8 and above] A LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.

	~~===chainstate subdirectory===~~
	[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (150 GB as of Nov 2017) for every output being spent.

	~~===locks subdirectory===~~
	~~[v0.8 and above] Contains "undo" data.~~

	* rev*.dat
	You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganizations.

	===Personally identifiable data [v0.8 and above]===		===Personally identifiable data [v0.8 and above]===

Eklitzke: /* chainstate subdirectory */

2017-11-19T20:12:22Z

chainstate subdirectory

← Older revision		Revision as of 20:12, 19 November 2017
Line 89:		Line 89:

	===chainstate subdirectory===		===chainstate subdirectory===
	[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (7 GB as of ~~may 2013~~) for every output being spent.		[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (150 GB as of Nov 2017) for every output being spent.

	===locks subdirectory===		===locks subdirectory===

934: /* Bootstrapping the blockchain from a snapshot distributed through BitTorrent */ remove bootstrap method for EOL clients

2017-07-31T10:21:14Z

Bootstrapping the blockchain from a snapshot distributed through BitTorrent: remove bootstrap method for EOL clients

← Older revision		Revision as of 10:21, 31 July 2017
Line 96:		Line 96:
	* rev*.dat		* rev*.dat
	You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganizations.		You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganizations.

	~~===Bootstrapping the blockchain from a snapshot distributed through BitTorrent===~~
	There is a [https://bitcoin.org/bin/block-chain/ torrent file that gets updated] every few months that enables a much faster download of the blockchain. Once downloaded, the bootstrap.dat file can be placed in the root of the data directory, and Bitcoin Core 0.7.1 and above will automatically import it. '''NOTE:''' As of Bitcoin Core version 0.10.0 and later, the blockchain bootstrap
	~~torrent is ''slower'' than a direct download using the bitcoin P2P protocol & client.<ref>[https://bitcoin.org/bin/block-chain/README.txt README.txt for bootstrap.dat.torrent]</ref>~~

	===Personally identifiable data [v0.8 and above]===		===Personally identifiable data [v0.8 and above]===

934: /* Files */ external links with single [ ]

2017-07-31T09:03:18Z

Files: external links with single [ ]

← Older revision		Revision as of 09:03, 31 July 2017
Line 48:		Line 48:
	===Files===		===Files===

	An overview of these is in [[https://github.com/bitcoin/bitcoin/blob/master/doc/files.md files.md]] in the Bitcoin Core documentation.		An overview of these is in [https://github.com/bitcoin/bitcoin/blob/master/doc/files.md files.md] in the Bitcoin Core documentation.

	* .lock		* .lock

Theymos: add links to Splitting the data directory article

2017-03-10T11:22:38Z

add links to Splitting the data directory article

← Older revision		Revision as of 11:22, 10 March 2017
Line 123:		Line 123:
	Each node has a unique block database, and all of the files are highly connected. So if you copy just a few files from one installation's "blocks" or "chainstate" directories into another installation, this will almost certainly cause the second node to crash or get stuck at some random point in the future. If you want to copy a block database from one installation to another, you have to delete the old database and copy ''all'' of the files at once. Both nodes have to be shut down while copying.		Each node has a unique block database, and all of the files are highly connected. So if you copy just a few files from one installation's "blocks" or "chainstate" directories into another installation, this will almost certainly cause the second node to crash or get stuck at some random point in the future. If you want to copy a block database from one installation to another, you have to delete the old database and copy ''all'' of the files at once. Both nodes have to be shut down while copying.

	Only the file with the highest number in the "blocks" directory is ever written to. The earlier files will never change. Also, when these blk.dat files are accessed, they are usually accessed in a highly sequential manner. Therefore, it's possible to symlink the "blocks" directory or some subset of the blk.dat files individually onto a magnetic storage drive without much loss in performance, and if two installations start out with identical block databases (due to the copying described previously), subsequent runs of rsync will be very efficient.		Only the file with the highest number in the "blocks" directory is ever written to. The earlier files will never change. Also, when these blk.dat files are accessed, they are usually accessed in a highly sequential manner. Therefore, it's possible to symlink the "blocks" directory or some subset of the blk.dat files individually onto a magnetic storage drive without much loss in performance (see [[Splitting the data directory]]), and if two installations start out with identical block databases (due to the copying described previously), subsequent runs of rsync will be very efficient.

	==See Also==		==See Also==
Line 129:		Line 129:
	* [[Running Bitcoin]]		* [[Running Bitcoin]]
	* [[Securing your wallet]]		* [[Securing your wallet]]
			* [[Splitting the data directory]]
	* [http://bitcoin.stackexchange.com/a/11108/153 What is the database for?] Question on Bitcoin Stack Exchange		* [http://bitcoin.stackexchange.com/a/11108/153 What is the database for?] Question on Bitcoin Stack Exchange