33
By setting the -prune option.
-prune=
Reduce storage requirements by enabling pruning (deleting) of old
blocks. This allows the pruneblockchain RPC to be called to
delete specific blocks, and enables automatic pruning of old
blocks if a target size in MiB is provided. This mode is
incompatible with -txindex and ...
18
Since Bitcoin-Core 0.11.0 you can prune (trim) the blockchain in Bitcoin-Qt.
But not from the UI.
You need to add prune=550 to your bitcoin.conf file and restart Bitcoin-Qt.
Explanation:
-prune=<target in MiB> will tell bitcoin-core to remove blocks which are older than oldest block that can be kept with a chainsize (sum of block-sizes) of <target&...
16
There are more details in the release notes.
To enable block pruning set prune=<N> on the command line or in bitcoin.conf, where N is the number of MiB to allot for raw block & undo data.
A value of 0 disables pruning. The minimal value above 0 is 550.
Where 550 is the size in MB you want the node to occupy in your system.
The bitcoin.conf is in ...
12
Pruning is being considered, in fact, it was taken into account when designing the 0.8 database format. The unspent transaction outputs (which is the only essential piece of data necessary for validation) are already kept in a separate database, so technically removing old blocks is perfectly possible. It'll likely require some small changes to make sure the ...
11
No, pruning will not make the initial sync faster. The information that gets removed by pruning isn't accessed turning the initial sync.
Currently pruning makes the initial sync somewhat slower: more frequent flushes are performed in order to allow pruning to work, and the work of actually deleting things creates its own small slowdown. About the same is ...
9
You cannot skip downloading the blockchain, but you can skip storing it.
If you run Bitcoin Core with the -prune=N or put prune=N in the bitcoin.conf file, only at most N megabytes worth of blocks will be stored on disk. N has to be at least 550 currently.
Pruning does not reduce the validation or security at all, but does prevent your node from serving ...
7
The blockchain itself cannot be pruned.
Each block is verified through hashing all its data and a random nonce to find a hash that has a certain number of leading zeroes. If you even removed a single little bit of data from a block, the resulting hash would be changed. As most likely the new hash would not fulfill the difficulty requirement, the proof of ...
7
If pruning is enabled, old blocks are deleted on the fly while new ones are being downloaded.
With -prune=550 (the minimum value), you're able to run Bitcoin Core v0.12+ with just a few GB of disk space.
6
You can set a limit for blockchain data by starting your node with -prune=<n>.
-prune=<n> gives the target size in MiB to use for block files
This limit will only include the blocks and reorganization data. You also need some space for chain state, block index database, and wallet.
I run my node with -prune=20480 (i.e. 20 GiB) and fully caught ...
6
Full nodes keep all blocks by default, but this is not necessary to achieve full node security. Full nodes validate the complete blockchain and enforce all consensus rules regardless of whether a full history is kept.
Keeping all blocks is a service to the network, as you'll be able to provide all blocks for synchronizing nodes or requests of thin clients.
...
6
Just got help from someone at BitcoinTalk forum, who directed me to bitcoind 0.11.0 changelog (Which pruning was introduced/implemented for the first time in bitcoind)
As indicated there, Block pruning deletes raw block & undo data:
...
there are four types of data related to the blockchain in the bitcoin system: the raw blocks as received over the ...
5
Fully validating nodes ("full nodes") are clients that have validated the whole blockchain self-sufficiently and enforce all of the rules of Bitcoin on any data they receive. Therefore, they cannot be cheated by means of invalid blocks or transactions.
Running your own full node is the most secure, most private, and least trusting way to participate in the ...
5
It turns out that prune=1 is a new special case which enables manual pruning. For values of N from 2 to 549, prune=N shows an error.
Bitcoin Core parses configuration arguments in the init.cpp. Depending on the value of prune=<N>:
N < 0 – returns the error: "Prune cannot be configured with a negative value."
N = 1 – Activates manual prune mode ...
5
From your description it sounds to me that you may have edited your configuration file while Bitcoin Core was already running.
prune=1100 is a startup parameter. It will take effect once you restart the program.
If you add a parameter to the startup instructions, parameters start with a dash (-prune=1100), e.g.:
"C:\Users\<username>\AppData\Roaming\...
5
No, the default behavior of bitcoin core v0.19.0.1 is still the non pruning mod.
You should check your bitcoin.conf file depending on your operating system there is a line about pruning which should be something likeprune=550 in your case, just put a # to deactivate it again like #prune=550.
5
It introduces too much trust into the download source. It's the same thing as just uploading a datadir. You aren't verifying any of the blockchain history; what you download could be a fork of the blockchain. Having such a download completely defeats the point of running a full node.
Furthermore, with downloading a pruned datadir, you will have to download ...
4
The prune value merely sets the limit of how much block data is kept.
If you increase the value and restart, no block data will be deleted for a while. New blocks will be received and validated and stored, and old ones won't be deleted until the new prune value is reached again.
If you decrease the value and restart, the oldest blocks will be deleted at ...
4
Copying .bitcoin folder should work. Make sure bitcoind is not running (try ps -ef | grep bitcoin) before you attempt to copy. Also make sure bitcoin.conf is same in both places
Also, change the bitcoin.conf file with the new datadir , rpcuser and rpcpassword
4
This is called pruning.
From here:
Since Bitcoin-Core 0.11.0 you can prune (trim) the blockchain in
Bitcoin-Qt. But not from the UI. You need to add -prune=550 to your
bitcoin.conf file and restart Bitcoin-Qt.
Explanation: -prune=<target in MiB> will tell bitcoin-core to remove blocks which are older than oldest block that can be kept with
...
4
This seems a lot of effort for absolutely no benefit.
In the Bitcoin pruning model you discard ALL those old blocks anyway, and JUST keep the utxo set. It doesn't matter whether a utxo is in an old block or a new block, you're still keeping it in the utxoset. Any blocks you keep around is merely for convenience and to assist other nodes that request those ...
4
From the Bitcoin Core v0.14.0 release notes:
Bitcoin Core has supported automatically pruning the blockchain since 0.11. Pruning the blockchain allows for significant storage space savings as the vast majority of the downloaded data can be discarded after processing so very little of it remains on the disk.
Manual block pruning can now be enabled by ...
4
Will running a pruned node make my store less secure?
No, not at all.
I was wondering what will be the downsides to me running a pruned node?
With a pruned node you cannot:
Handle (extremely) deep reorganizations (which are in theory possible but in practice would indicate a very serious problem with Bitcoin's security assumptions).
Serve old blocks to ...
4
It is possible to run Lightning (both LND and c-lightning) with bitcoind pruned mode.
There are already packages turning the pruned mode on when disk space is limited: Lightning Power Node Launcher (works with LND) and BTCPayServer docker (works with c-lightnig).
There is a lot of conflicting information online, because it became possible only after ...
4
prune allows you to set the size of blockchain data stored, not downloaded. Therefore prune does not affect bandwidth usage.
4
It will prune as it synchronizes. Disk usage shouldn't ever reach more than a few GB plus what you configured the pruning limit to.
3
From release notes https://bitcoin.org/en/release/v0.11.0 :
For now, block pruning disables block relay. In the future, nodes with block pruning will at a minimum relay “new” blocks, meaning blocks that extend their active chain.
In the current version pruning nodes don't advertise themselves as having any blocks, so they don't upload blocks. So that ...
3
Since Bitcoin Core v0.8.0, the validation database ("chainstate" or "UTXO set", or "account balance sheet") is separated from the blockchain. When a new block comes in, its effects (removing spent inputs, and adding outputs) are applied to the database. This means blocks are still downloaded and verified like before, but they aren't used for validation ...
3
No, you'll need to make space for a full copy of the blockchain somewhere. AFAIK, Armory rescans the blockchain in order to build its own database only after Bitcoin Core has fully synchronized. Therefore, Armory needs access to a full copy of the blockchain which is currently about 118GiB. Armory's database itself then will take more than 20GiB additionally....
3
I've looked through several pages on bitnodes to find some more nodes that show NODE_WITNESS (12). I've noticed a pattern: the number corresponds to the services that a node offers. Nodes advertise the services that they offer by sending a bitmap named nServices. The number in the brackets matches the decimal representation of the service bits that a node ...
3
It depends on the implementation. For Bitcoin Core, the node maintains a database which has the locations of all blocks on disk. If a block is deleted, then it will notice that the location of a block either does not exist or contains garbage or invalid data. If it does notice that a block is missing (or something is corrupted), it will attempt to rebuild ...
Only top voted, non community-wiki answers of a minimum length are eligible
