|
1 | 1 | (note: this is a temporary file, to be added-to by anybody, and moved to
|
2 | 2 | release-notes at release time)
|
3 | 3 |
|
| 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 | + |
4 | 71 | 0.11.0 Change log
|
5 | 72 | =================
|
6 | 73 |
|
|
0 commit comments