mirror of
https://github.com/bitcoin/bitcoin.git
synced 2025-11-15 16:38:23 +01:00
doc: Improve assumeutxo guide and add more docs/comments
Also fixes some outdated information in the remaining design doc.
This commit is contained in:
@@ -1,45 +1,6 @@
|
||||
# assumeutxo
|
||||
# Assumeutxo Design
|
||||
|
||||
Assumeutxo is a feature that allows fast bootstrapping of a validating bitcoind
|
||||
instance.
|
||||
|
||||
## Loading a snapshot
|
||||
|
||||
There is currently no canonical source for snapshots, but any downloaded snapshot
|
||||
will be checked against a hash that's been hardcoded in source code.
|
||||
|
||||
Once you've obtained the snapshot, you can use the RPC command `loadtxoutset` to
|
||||
load it.
|
||||
|
||||
### Pruning
|
||||
|
||||
A pruned node can load a snapshot. To save space, it's possible to delete the
|
||||
snapshot file as soon as `loadtxoutset` finishes.
|
||||
|
||||
The minimum `-prune` setting is 550 MiB, but this functionality ignores that
|
||||
minimum and uses at least 1100 MiB.
|
||||
|
||||
As the background sync continues there will be temporarily two chainstate
|
||||
directories, each multiple gigabytes in size (likely growing larger than the
|
||||
downloaded snapshot).
|
||||
|
||||
### Indexes
|
||||
|
||||
Indexes work but don't take advantage of this feature. They always start building
|
||||
from the genesis block. Once the background validation reaches the snapshot block,
|
||||
indexes will continue to build all the way to the tip.
|
||||
|
||||
For indexes that support pruning, note that no pruning will take place between
|
||||
the snapshot and the tip, until the background sync has completed - after which
|
||||
everything is pruned. Depending on how old the snapshot is, this may temporarily
|
||||
use a significant amount of disk space.
|
||||
|
||||
## Generating a snapshot
|
||||
|
||||
The RPC command `dumptxoutset` can be used to generate a snapshot for the current
|
||||
tip or a recent height. This can be used
|
||||
to create a snapshot on one node that you wish to load on another node.
|
||||
It can also be used to verify the hardcoded snapshot hash in the source code.
|
||||
For notes on the usage of Assumeutxo, please refer to [the usage doc](/doc/assumeutxo.md).
|
||||
|
||||
## General background
|
||||
|
||||
@@ -77,7 +38,7 @@ data.
|
||||
### "Normal" operation via initial block download
|
||||
|
||||
`ChainstateManager` manages a single Chainstate object, for which
|
||||
`m_snapshot_blockhash` is null. This chainstate is (maybe obviously)
|
||||
`m_from_snapshot_blockhash` is `std::nullopt`. This chainstate is (maybe obviously)
|
||||
considered active. This is the "traditional" mode of operation for bitcoind.
|
||||
|
||||
| | |
|
||||
|
||||
Reference in New Issue
Block a user