August 2021

What is LB’s policy actually: LB will *not* store to persistence a block header for which the parent is not known on the persistence, is it? What about blocks, can LB store to persistence a block where the *block header* of the parent is on persistence but *not* the block of the parent?

Please define exactly what you mean by ‘visible branch’?

What do you mean, for there to be an association between one block header and one transaction (and associations are by nature bidirectional), the whole block structure for the said block must be represented in persistence i.e. either ALL or NONE of the transactions belonging to one block are in the persistence?

the entire chain is retained by the _THREE_ headers->transactions tables.

Yep

Hi Eric, so I have now carefully re-read your description above of how v4's header+block sync process works. I fully understand that in the context of the full_node class/namespace/problem domain, a “header” and a “block” (generally and especially in the context of subscribe_headers() and subscribe_blocks()) have very specific meanings: * Header means a header for which the whole header chain back to the genesis block is already known by the full_node. (This applies both for a header in the ‘candidate chain’ and a header in the ‘strongest chain’.) * (In respect of a block during the syncing process internally!:) Block means a block where the whole header chain back to the genesis block is already known by the full_node * (In respect of a block that is transitioned from being candidate chain to being strongest chain AND in respect of a block that is part of the strongest chain:) Block means a block where the whole BLOCK chain back to the genesis block is already known by the full_node *and* has been validated Further, I understand LB v4's sync process roughly has these steps: 1. Node asks network for headers. Organizes them into a chain. Track the strongest header chain. -> 2. As soon as the header chain qualifies as being “current”: Parallell-download all blocks for the block headers in the strongest header chain. -> 3. For requested blocks, store such blocks that are received to persistence. 4. Perform validation on the strongest contiguous chain of blocks available???? The candidate chain is defined as strongest contiguous validated chain available. 5. When the candidate chain is stronger than the current strongest chain, then define as strongest chain, this candidate chain. So in the process above, I presume subscribe_blocks() callbacks are really when step 5. trigs. That is, previously there was one given strongest chain and now it’s another one. Can you please explain, where in the process above are subscribe_headers() callbacks made? And now I can explain what I want to do: I want to listen for “header reorgs” defined as, any change to the “strongest header chain” as defined in 1. above. Is exactly that what subscribe_headers() does? If not, what does subscribe_headers() do actually and, what I want to achieve, how do I do that? The reason I want to track the strongest header chain is both to operate an SPV wallet, and also to gauge the full node’s synchronization process as in “Syncing is 12.5% done, ETA 2 days”. Thanks!

Step 5 is a block reorg, and that is the source of block notifications. When a header is added to the candidate chain (reorged), that chain is now stronger than the confirmed chain. That triggers a header (reorg) notification. There is actually a third (partial tree) data structure that maintains branches until they are stronger than the persistent candidate chain. The header reorg occurs from the header tree to the candidate chain. The header tree has a configurable maximum depth constraint.

Other statements are correct.

@evoskuil, thanks for the great description. Just curious, what is the function that translates natural hash to hashtable hash (“foreign key” as you call it)? Also why is it much faster, is it because it’s much smaller than 256 bits?

DJB2 (not merged yet), formerly std::hash<T>. It’s faster because it’s a 64 bit non-cryptographic hash (ie for hash tables). It targets even distribution, not irreversibility. Much, much faster.

“Candidates are validated (and therefore connected) headers and confirmeds are fully validated blocks.” - wait what is “confirmeds”?

Confirmed headers.

I see. Great! 😃

Hi there!

Hola @nopara73

Hey there. Please @evoskuil, can you confirm to me how the bn.cfg parsing works. If I got it right, the parser::load_settings() function is responsible for adding the options. For the example:

(
    "bitcoin.retargeting_factor",
    value<uint32_t>(&configured.bitcoin.retargeting_factor),
    "The difficulty retargeting factor, defaults to 4."
)

The first line is the name of the option. Here retargeting_factor must be under a [bitcoin] flag. Then the second line tells boost which time the option is and where to store it. Third seems to be just a description. Ok, if I add my custom option here, the only other change that I absolutely need to make is to create the actual variable that will store the option. Following the example, retargeting_factor is declared in the file: libbitcoin-system/include/bitcoin/system/settings.hpp. Is this all I need to add a new option to bn.cfg?

I don’t recommend editing libbitcoin code to build your own projects. It will change over time, sometimes significantly. It is a library, it has public interfaces.