Bitcoin full node and query server

Aug 6, 2021

View in context in the libbitcoin Slack #general mirror.

P
Phil23:02
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!