Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
fix: split state validation status into kernel and rproof updates. #3096
I split out the sync validation status into kernel and range proof validation and added these as extra sync steps. Maybe this is too much information but I feel its nice to see progress being made when syncing and to help understand what's going on.
There are a couple of things I'm not sure about though and could use some help.
In the simple examples above we may have an MMR of size 4 (3 leaves) where we only have a single leaf position in the
Note: outputs can be removed but not yet pruned because we need to support "rewind" in a fork situation where we undo a block and reapply a potentially different set of transactions to the chain state.
Not necessarily because we do not always want to know the number of leaves in the entire MMR. We have many instances where we need to know the number of leaves in a particular subtree or beneath a particular peak within an MMR.
Hope this makes sense. The internals of the MMR data structure are pretty complex. But this complexity is worth it. The immutable, append-only semantics that it gives us though are very well aligned with the data we need to store on disk.
I think this might be broken on master. Seems to be around getting header stats whilst txhashset validating/rebuilding is going on. Looking into a fix.
…imblewimble#3096) * fix: split state validation status into kernel and rproof updates. And fix sync status for these two states * fix: show correct number of leaves for pruned MMR as well as unpruned * docs: better docs for kernel/range proof validation * fix: ordering of kernel and rproofs validation in TUI * fix: typo in rangeproofs api and comments