Change:
8.8.1. <del> The Parent Hash of P appears in three types of structs.  If V is itself a parent node then P's Parent Hash is stored in the "parent_hash" field of the structs "ParentHashInput" and "ParentNode" of the node before P on the filtered direct path of U.  (The "ParentNode" struct is used to encapsulate all public information about that node that must be conveyed to a new member joining the group as well as to define its Tree Hash.) If, on the other hand, V is the leaf U and its LeafNode has "leaf_node_source" set to "commit", then the Parent Hash of P (with V's sibling as copath child) is stored in the "parent_hash" field. This is true in particular of the LeafNode object sent in the "leaf_node" field of an UpdatePath.  The signature of such a LeafNode thus also attests to which keys the group member introduced into the ratchet tree and to whom the corresponding secret keys were sent. This helps prevent malicious insiders from constructing artificial ratchet trees with a node V whose HPKE secret key is known to the insider yet where the insider isn't assigned a leaf in the subtree rooted at V.  Indeed, such a ratchet tree would violate the tree invariant. </del> <ins> In ParentNode objects and LeafNode objects with "leaf_node_source" set to "commit", the value of the "parent_hash" field is the parent hash of the next non-blank parent node above the node in question (the next node in the filtered direct path).  Using the node labels in parent-hash-inputs, the "parent_hash" field of D is equal to the parent hash of P with copath child S.  This is the case even when the node D is a leaf node. The "parent_hash" field of a LeafNode is signed by the member.  The signature of such a LeafNode thus also attests to which keys the group member introduced into the ratchet tree and to whom the corresponding secret keys were sent.  This prevents malicious insiders from constructing artificial ratchet trees with a node D whose HPKE secret key is known to the insider yet where the insider isn't assigned a leaf in the subtree rooted at D.  Indeed, such a ratchet tree would violate the tree invariant. </ins> 8.8.2. Parent hashes are verified at two points in the protocol: When joining a group and when processing a Commit. <del> The parent hash in a node U is valid with respect to a parent node P </del> <ins> The parent hash in a node D is valid with respect to a parent node P </ins> if the following criteria hold: <del> U is a descendant of P in the tree </del> <ins> D is a descendant of P in the tree </ins> <del> The nodes between U and P in the tree are all blank </del> <ins> Any nodes between D and P in the tree are all blank </ins> <del> The "parent_hash" field of U is equal to the parent hash of P with </del> <ins> The "parent_hash" field of D is equal to the parent hash of P with </ins> copath child S, where S is the child of P that is not on the path <del> from U to P. </del> <ins> from D to P. </ins> 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

Discussion:
Depends on Conflicts with The diff here is messy because it includes . The biggest change is the extended example, for which you can just scroll to the bottom.
Regarding the Tree Hash Including the parentnode in the tree hash which is supposed to be computed from the leaves, makes the definition appear circular to a new reader. Since the situation when you have blank nodes in the middle of a tree but not at the root is a rather complicated, the situation when you could calculate a tree hash using the parentnode is non-obvious. In the description of Tree Hash the document says that the ParentNode object is optional "depending on whether the node is blank or not." This isn't clear specification language. Saying the parentnode object is present if the node is blank or present if the node is not blank would be clear. What if the parent node is also blank? What if the root is blank? I think an example with and without blank nodes would be appropriate. Explaining the reason why the parentnode is included will help the reader establish a better mental model. Regarding the Parent Hash I still find this section super confusing. A few points Using a tree hash (siblingtreehash) inside the parent hash is non-obvious. There should be some explanation about what property this is providing and that it is a tree hash and not a parent hash. (Honestly it was the third time I read the section that I realized that it was really the tree hash and not the parent hash of the sibling.) Using P, V, and S for Parent, target node, and sibling node is introduced here and never used anywhere else in the document. P for parent and S for sibling make sense. I can't tell what V is supposed to stand for, and it unfortunately could cause people to confuse the vector notation used throughout, but shortly after introducing V for the target node. I propose using "N" for node or "X" instead. There is one reference to the filtered direct path of U. Perhaps this is V, or a child of V? The calculations are sufficiently complicated that I think this warrants a complete, non-trivial, worked example (possibly in an appendix). At some point we should consider providing test vectors in a future document, and this would be an ideal candidate.

Regarding the Tree Hash To be clear, the that is included in the tree hash is the node whose subtree is being hashed. The tree hash doesn't include only the leaves, it includes all the nodes in the tree. If you mean , then yes, I agree the connection is a little subtle. I've tried to explain this a little better. Updated this to be clear that the ParentNode is omitted if and only if the node is blank. Not clear what situation you mean here. I think the specific computations are pretty clearly specified for these cases. Something like this was added in : URL I extended the example and put it in an appendix. Assuming you mean here, hopefully this is addressed by the above notes. Added a note to clarify that this is the tree hash and why. Changed to "D" for "direct path", and explained the semantics. Actually it's the leaf, which is now called "L". I think the example linked above does a pretty good job. Feedback obviously welcome. Agreed that a test vectors document will be a useful follow-on.
This is a huge improvement. While I still prefer "path hash" to "parent hash", the new language in this PR is clear and I think will be straightforward for new implementers to read.