Skip to content

Commit 2b2d5b9

Browse files
committed
Merge pull request #6189
44e1aad Autoprune release notes included (mrbandrews)
2 parents c608b6d + 44e1aad commit 2b2d5b9

File tree

1 file changed

+67
-0
lines changed

1 file changed

+67
-0
lines changed

doc/release-notes.md

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,73 @@
11
(note: this is a temporary file, to be added-to by anybody, and moved to
22
release-notes at release time)
33

4+
Notable changes
5+
===============
6+
7+
Block file pruning
8+
----------------------
9+
10+
This release supports running a fully validating node without maintaining a copy
11+
of the raw block and undo data on disk. To recap, there are four types of data
12+
related to the blockchain in the bitcoin system: the raw blocks as received over
13+
the network (blk???.dat), the undo data (rev???.dat), the block index and the
14+
UTXO set (both LevelDB databases). The databases are built from the raw data.
15+
16+
Block pruning allows Bitcoin Core to delete the raw block and undo data once
17+
it's been validated and used to build the databases. At that point, the raw data
18+
is used only to relay blocks to other nodes, to handle reorganizations, to look
19+
up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or
20+
for rescanning the wallet. The block index continues to hold the metadata about
21+
all blocks in the blockchain.
22+
23+
The user specifies how much space to allot for block & undo files. The minimum
24+
allowed is 550MB. Note that this is in addition to whatever is required for the
25+
block index and UTXO databases. The minimum was chosen so that Bitcoin Core will
26+
be able to maintain at least 288 blocks on disk (two days worth of blocks at 10
27+
minutes per block). In rare instances it is possible that the amount of space
28+
used will exceed the pruning target in order to keep the required last 288
29+
blocks on disk.
30+
31+
Block pruning works during initial sync in the same way as during steady state,
32+
by deleting block files "as you go" whenever disk space is allocated. Thus, if
33+
the user specifies 550MB, once that level is reached the program will begin
34+
deleting the oldest block and undo files, while continuing to download the
35+
blockchain.
36+
37+
For now, block pruning disables block relay. In the future, nodes with block
38+
pruning will at a minimum relay "new" blocks, meaning blocks that extend their
39+
active chain.
40+
41+
Block pruning is currently incompatible with running a wallet due to the fact
42+
that block data is used for rescanning the wallet and importing keys or
43+
addresses (which require a rescan.) However, running the wallet with block
44+
pruning will be supported in the near future, subject to those limitations.
45+
46+
Block pruning is also incompatible with -txindex and will automatically disable
47+
it.
48+
49+
Once you have pruned blocks, going back to unpruned state requires
50+
re-downloading the entire blockchain. To do this, re-start the node with
51+
-reindex. Note also that any problem that would cause a user to reindex (e.g.,
52+
disk corruption) will cause a pruned node to redownload the entire blockchain.
53+
Finally, note that when a pruned node reindexes, it will delete any blk???.dat
54+
and rev???.dat files in the data directory prior to restarting the download.
55+
56+
To enable block pruning on the command line:
57+
58+
- `-prune=N`: where N is the number of MB to allot for raw block & undo data.
59+
60+
Modified RPC calls:
61+
62+
- `getblockchaininfo` now includes whether we are in pruned mode or not.
63+
- `getblock` will check if the block's data has been pruned and if so, return an
64+
error.
65+
- `getrawtransaction` will no longer be able to locate a transaction that has a
66+
UTXO but where its block file has been pruned.
67+
68+
Pruning is disabled by default.
69+
70+
471
0.11.0 Change log
572
=================
673

0 commit comments

Comments
 (0)