2019-09-16 16:34:45 -04:00
|
|
|
Pruning
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
When using assumeutxo with `-prune`, the prune budget may be exceeded if it is set
|
|
|
|
|
lower than 1100MB (i.e. `MIN_DISK_SPACE_FOR_BLOCK_FILES * 2`). Prune budget is normally
|
|
|
|
|
split evenly across each chainstate, unless the resulting prune budget per chainstate
|
|
|
|
|
is beneath `MIN_DISK_SPACE_FOR_BLOCK_FILES` in which case that value will be used.
|
2019-03-29 15:31:54 -04:00
|
|
|
|
|
|
|
|
RPC
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
`loadtxoutset` has been added, which allows loading a UTXO snapshot of the format
|
|
|
|
|
generated by `dumptxoutset`. Once this snapshot is loaded, its contents will be
|
|
|
|
|
deserialized into a second chainstate data structure, which is then used to sync to
|
|
|
|
|
the network's tip under a security model very much like `assumevalid`.
|
|
|
|
|
|
|
|
|
|
Meanwhile, the original chainstate will complete the initial block download process in
|
|
|
|
|
the background, eventually validating up to the block that the snapshot is based upon.
|
|
|
|
|
|
|
|
|
|
The result is a usable bitcoind instance that is current with the network tip in a
|
|
|
|
|
matter of minutes rather than hours. UTXO snapshot are typically obtained via
|
|
|
|
|
third-party sources (HTTP, torrent, etc.) which is reasonable since their contents
|
|
|
|
|
are always checked by hash.
|
|
|
|
|
|
|
|
|
|
You can find more information on this process in the `assumeutxo` design
|
|
|
|
|
document (<https://github.com/bitcoin/bitcoin/blob/master/doc/design/assumeutxo.md>).
|
