Hi Eric, thank you very much for your extensive response on this one.
I am running the LB Node in my own OS process, so I am not suffering a risk that the RPC from embedded LB Client to LB RPC Server would be MITMed/hijacked.
In my own OS process/C++ program, I want to query the Bitcoin blockchain according to the convention of a consistent view. Just in case LibBitcoin does *not* implement this, I will smartly emulate it myself.
I want to describe my usecase to you however, to avoid traps and be clear.
so in a given moment, I will make a batch of queries to the blockchain.
Logically, at the **START** of my queries, the Node will be at one given head block that we can call H or HEAD.
The fact that the Node is at HEAD, means all blocks between and including GENESIS and HEAD are queryable.
I want to do the operation:
var myConsistentView = node.chain(); // or node.chain().giveMeConsistentView()
printf( “The node is at ” + myConsistentView.headBlock().blockHash “\n”);
myConsistentView.getBlock(“1928309182309812093182”) <- this one should succeed if said hash is within GENESIS ... HEAD, and fail otherwise
myConsistentView.getConfirmedTransaction(“18329837498239832094820934823") <- same here, this one should succeed if said tx hash is within a block GENESIS ... HEAD, and fail otherwise
finally regarding UTXO:s, so a UTXO within one chain (GENESIS ... HEAD) is introduced at one block , and then optionally spent at a future/higher block in the chain.
So to get to my higher level question:
Does LibBitcoin implement a consistent view, or do I need to emulate it myself in the way that ANY of the query operations I do, MAY be such that a reorg happened BEFORE it, meaning that the GENESIS .. HEAD chain is **NO LONGER queryable** , and so I need to rinse-repeat by picking up the now-latest HEAD, and then query against that one instead?
(For clarity, I understand that there are transactions that are not in any block, also I understand one transaction can be in more blocks on different forks - i understand all that and that LB does very sophisticated and efficient handling of the same. What I’m doing now is more like a very consistent comprehensive approach to ‘clean’, correct, best-practice blockchain queries so my questions related to that rather than to other LB design aspects / internals.)