Change:
This PR revises the parent hash verification section to reflect more recent discussion. Right now, the definition of validity according to the parent hash ties it to the "top-down" validation algorithm, when what really matters is that each parent node has a path to a leaf. This PR changes the definition to that more general version, and mentions the "top-down" and "bottom-up" approaches to checking this property.
cc NAME NAME
Great proposal! It achieves what we want much more directly. One comment: in the description of the "top down" approach, the part "there is exactly one descendant" isn't exactly consistent with being "parent hash valid", because the latter requires that P can be chained to at least one leaf. The bottom up approach is consistent with being parent hash valid. As a result, a malicious insider may be able to craft a tree that is accepted by the bottom up approach but not by the top down approach [1] which may hurt interoperability. I'd suggest either to change "exactly one" to "at least one" in the top down approach or to change "can be chained back to a leaf" to "can be chained back to exactly one leaf" in the definition of parent hash valid (and modify the bottom up approach accordingly). I don't have a strong opinion which is better. [1] An example such tree: the tree has 3 nodes: the root P and its children A and B. Assuming both A and B are malicious, A signs the parent hash of P with copath child B and B signs the parent hash of P with copath child A. (This is possible with the current resolution-hash for parent-hash.)
NAME - I am keen on the "exactly one" framing precisely because you shouldn't have these collisions in a real tree. At least I haven't been able to think up a case; maybe you have a non-malicious case? Given that, I'm inclined to tighten the "bottom-up" so that it fails if there are multiple valid paths to a node.
Just to close the loop here: NAME - thanks for the suggestion, added a sentence NAME - Updated the "bottom up" description to say that each node should be covered by exactly one chain, which is the parallel requirement to exactly one child.
Note that this doesn't completely address the "unease" feeling mentioned in , but I can live it. Other than that, I think it makes the parent hash construct a lot more clear and this PR has a lot of pedagogical value. The section on parent hash in the current document is really difficult to grasp for a newcomer.

Discussion:
8.6.2. <del> To this end, when processing a Commit message clients MUST recompute the expected value of "parent_hash" for the committer's new leaf and verify that it matches the "parent_hash" value in the supplied "leaf_node".  Moreover, when joining a group, new members MUST authenticate each non-blank parent node P.  A parent node P is authenticated by checking that there exists a child V of P and a node U in the resolution of V such that V."parent_hash" is equal to the Parent Hash of P with V's sibling as the co-path child. </del> <ins> Parent hashes are verified at two points in the protocol: When joining a group and when processing a Commit. The parent hash in a node U is valid with respect to a parent node P if the following criteria hold: U is a descendant of P in the tree The nodes between U and P in the tree are all blank The "parent_hash" field of U is equal to the parent hash of P with copath child S, where S is the child of P that is not on the path from U to P. A parent node P is "parent-hash valid" if it can be chained back to a leaf node in this way.  That is, if there is leaf node L and a sequence of parent nodes P_1, ..., P_N such that P_N = P and each step in the chain is authenticated by a parent hash: L's parent hash is valid with respect to P_1, P_1's parent hash is valid with respect to P_2, and so on. When joining a group, the new member MUST authenticate that each non- blank parent node P is parent-hash valid.  This can be done "bottom up" by building chains up from leaves and verifying that all non- blank parent nodes are covered by exactly one such chain, or "top down" by verifying that there is exactly one descendant of each non- blank parent node for which the parent node is parent-hash valid. When processing a Commit message that includes an UpdatePath, clients MUST recompute the expected value of "parent_hash" for the committer's new leaf and verify that it matches the "parent_hash" value in the supplied "leaf_node".  After being merged into the tree, the nodes in the UpdatePath form a parent-hash chain from the committer's leaf to the root. </ins> 8.7.