doc: Improve assumeutxo guide and add more docs/comments

Also fixes some outdated information in the remaining design doc.
This commit is contained in:
Fabian Jahr
2024-03-16 21:36:28 +01:00
parent b29c21fc92
commit e868a6e070
3 changed files with 94 additions and 43 deletions

View File

@@ -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.
| | |