Autoprune release notes included
This commit is contained in:
parent
165e323d85
commit
44e1aad500
1 changed files with 67 additions and 0 deletions
|
@ -1,6 +1,73 @@
|
|||
(note: this is a temporary file, to be added-to by anybody, and moved to
|
||||
release-notes at release time)
|
||||
|
||||
Notable changes
|
||||
===============
|
||||
|
||||
Block file pruning
|
||||
----------------------
|
||||
|
||||
This release supports running a fully validating node without maintaining a copy
|
||||
of the raw block and undo data on disk. To recap, there are four types of data
|
||||
related to the blockchain in the bitcoin system: the raw blocks as received over
|
||||
the network (blk???.dat), the undo data (rev???.dat), the block index and the
|
||||
UTXO set (both LevelDB databases). The databases are built from the raw data.
|
||||
|
||||
Block pruning allows Bitcoin Core to delete the raw block and undo data once
|
||||
it's been validated and used to build the databases. At that point, the raw data
|
||||
is used only to relay blocks to other nodes, to handle reorganizations, to look
|
||||
up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or
|
||||
for rescanning the wallet. The block index continues to hold the metadata about
|
||||
all blocks in the blockchain.
|
||||
|
||||
The user specifies how much space to allot for block & undo files. The minimum
|
||||
allowed is 550MB. Note that this is in addition to whatever is required for the
|
||||
block index and UTXO databases. The minimum was chosen so that Bitcoin Core will
|
||||
be able to maintain at least 288 blocks on disk (two days worth of blocks at 10
|
||||
minutes per block). In rare instances it is possible that the amount of space
|
||||
used will exceed the pruning target in order to keep the required last 288
|
||||
blocks on disk.
|
||||
|
||||
Block pruning works during initial sync in the same way as during steady state,
|
||||
by deleting block files "as you go" whenever disk space is allocated. Thus, if
|
||||
the user specifies 550MB, once that level is reached the program will begin
|
||||
deleting the oldest block and undo files, while continuing to download the
|
||||
blockchain.
|
||||
|
||||
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.
|
||||
|
||||
Block pruning is currently incompatible with running a wallet due to the fact
|
||||
that block data is used for rescanning the wallet and importing keys or
|
||||
addresses (which require a rescan.) However, running the wallet with block
|
||||
pruning will be supported in the near future, subject to those limitations.
|
||||
|
||||
Block pruning is also incompatible with -txindex and will automatically disable
|
||||
it.
|
||||
|
||||
Once you have pruned blocks, going back to unpruned state requires
|
||||
re-downloading the entire blockchain. To do this, re-start the node with
|
||||
-reindex. Note also that any problem that would cause a user to reindex (e.g.,
|
||||
disk corruption) will cause a pruned node to redownload the entire blockchain.
|
||||
Finally, note that when a pruned node reindexes, it will delete any blk???.dat
|
||||
and rev???.dat files in the data directory prior to restarting the download.
|
||||
|
||||
To enable block pruning on the command line:
|
||||
|
||||
- `-prune=N`: where N is the number of MB to allot for raw block & undo data.
|
||||
|
||||
Modified RPC calls:
|
||||
|
||||
- `getblockchaininfo` now includes whether we are in pruned mode or not.
|
||||
- `getblock` will check if the block's data has been pruned and if so, return an
|
||||
error.
|
||||
- `getrawtransaction` will no longer be able to locate a transaction that has a
|
||||
UTXO but where its block file has been pruned.
|
||||
|
||||
Pruning is disabled by default.
|
||||
|
||||
|
||||
0.11.0 Change log
|
||||
=================
|
||||
|
||||
|
|
Loading…
Reference in a new issue