Change:
8.8. <del> The "parent_hash" field in ratchet tree nodes carries information to authenticate the information in the ratchet tree.  Parent hashes chain together so that the signature on a leaf node, by covering the leaf node's parent hash, indirectly includes information about the structure of the tree at the time the leaf node was last updated. Consider a ratchet tree with a non-blank parent node P and children V and S. </del> <ins> While tree hashes summarize the state of a tree at point in time, parent hashes capture information about how keys in the tree were populated. When a client sends a commit to change a group, it can include an UpdatePath to assign new keys to the nodes along its filtered direct path.  When a client computes an UpdatePath (as defined in synchronizing-views-of-the-tree), it computes and signs a parent hash that summarizes the state of the tree after the UpdatePath has been applied.  These summaries are constructed in a chain from the root to the member's leaf so that the part of the chain closer to the root can be overwritten as nodes set in one UpdatePath are reset by a later UpdatePath. As a result, the signature over the parent hash in each member's leaf effectively signs the subtree of the tree that hasn't been changed since that leaf was last changed in an UpdatePath.  A new member joining the group uses these parent hashes to verify that the parent nodes in the tree were set by members of the group, not chosen by an external attacker.  For an example of how this works, see ph- evolution. Consider a ratchet tree with a non-blank parent node P and children D and S (for "parent", "direct path", and "sibling"), with D and P in the direct path of a leaf node L (for "leaf"): </ins> The parent hash of P changes whenever an "UpdatePath" object is <del> applied to the ratchet tree along a path from a leaf U traversing node V (and hence also P).  The new "Parent hash of P (with copath </del> <ins> applied to the ratchet tree along a path from a leaf L traversing node D (and hence also P).  The new "Parent hash of P (with copath </ins> child S)" is obtained by hashing P's "ParentHashInput" struct. The field "encryption_key" contains the HPKE public key of P.  If P is the root, then the "parent_hash" field is set to a zero-length octet string.  Otherwise, "parent_hash" is the Parent Hash of the <del> next node after P on the filtered direct path of U.  This way, P's Parent Hash fixes the new HPKE public key of each node V on the path from P to the root.  Note that the path from P to the root may contain some blank nodes that are not fixed by P's Parent Hash. However, for each node that has an HPKE key, this key is fixed by P's Parent Hash. </del> <ins> next node after P on the filtered direct path of the leaf L.  This way, P's Parent Hash fixes the new HPKE public key of each non-blank node on the path from P to the root.  Note that the path from P to the root may contain some blank nodes that are not fixed by P's Parent Hash.  However, for each node that has an HPKE key, this key is fixed by P's Parent Hash. </ins> Finally, "original_sibling_tree_hash" is the tree hash of S in the ratchet tree modified as follows: For each leaf L in

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.