Sep 19, 2018

In v4 a weak block can be queried by its hash, and of course its txs and ancestors can be as well.

How do I enumerate which weak block children a particular block has 😄

You either read all headers and then monitor for new ones or you don’t do it. There is no scenario in Bitcoin that requires it.

aha you mean, the way to monitor weak block children is simply, listen for blocks as they come in and register their block hashes, and then track which of the previously registered block hashes are not in the main chain anymore - those are the weak blocks. That's the sole way to track them?

Sure, but that’s just the creation of an index. It’s is not at all clear to me what scenario requires this blocktree children (vs blockchain child) index.

wait what do you mean?

What scenario requires this information?

There are an unlimited number of things that could be indexed. The choice to do so implies an important scenario.

wait, by "blockchain child" you mean "blocks within the main chain" and by "blocktree children" you mean "blocks within the main chain or stale chains", right?

The nature of the blockchain is a tree structure where one branch normally grows longer than all the others, and this is the general form in reality, a tree structure is what it is. The question is not what particular utility accessing the tree structure has, but instead, the tree structure is what it is and data structures should reflect that.

The cost of making a stale block is approx 80,000 USD. If someone spent this money to make a block, I like to inspect it. 🙂 Stale blocks are not a DOS vector.

Ok, thank you for your clarification that in the v4 API, a previously recorded block hash (that was the main chain then) can still be queried even when it's stale now! 👍

Blocks form a tree

Actually no, that’s not the question one asks in such a design exercise. You are describing the normal form of the data, not it’s access patterns based on actual use cases. It is never the case that implementation “should” reflect anything but usage requirements.

Then query for it by its hash. But again, what you personally would like is not what drives our design.

Yes, because it is not only useful but is facilitated by the fact that we never delete data (so low cost). This is not the same as navigating children.