Jul 15, 2021

Dear Eric, So LB offers a subscribe_headers() and a subscribe_blocks(). (accessible by full_node.chain(). ) - Note that the subscribe_header name is totally illogical as really what it does is header reorg listening, it is not just dispatched at the full_node’s reception of just any header. This is also reflected in the fact that the callback gets the arguments “outgoing” and “incoming” which denote a reorg - So these are for listening for two distinct events, we can call them “header reorg” and “block reorg”. Please explain to me how full_node’s “header reorg” and “block reorg” processes are correlated. Especially, i want to understand, the header reorg callbacks are made *when* in the chain syncing process, and the block reorg callbacks are made *when* in the chain syncing process? Especially then “when”s in the chain sync that I am interested in is, what if a full_node technically has two HEAD blocks on different forks: the header sync process may use as HEAD the header of block X. meanwhile the block sync process may use as HEAD the block Y which is on a different chain from X. this discrepancy would arise when the full_node has full blocks downloaded for genesis ... Y, BUT, it does not have blocks downloaded for genesis ... X yet! (or anyhow in the genesis ... X chain up to a total amount of work bigger than that of Y). (Please note: subscribe_headers should be renamed to subscribe_header_sync_reorg , the current name is confusing and not relevant.)