Change:
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.

Discussion:
An ordered list of "unmerged" leaves (see views) A hash of certain information about the node's parent, as of the <del> last time the node was changed (see parent-hash). </del> <ins> last time the node was changed (see parent-hashes). </ins> Every node, regardless of whether the node is blank or populated, has a corresponding _hash_ that summarizes the contents of the subtree

The "encryption_key" field contains an HPKE public key whose private key is held only by the members at the leaves among its descendants. The "parent_hash" field contains a hash of this node's parent node, <del> as described in parent-hash.  The "unmerged_leaves" field lists the </del> <ins> as described in parent-hashes.  The "unmerged_leaves" field lists the </ins> leaves under this parent node that are unmerged, according to their indices among all the leaves in the tree.  The entries in the "unmerged_leaves" vector MUST be sorted in increasing order.

In the case where the leaf node was inserted into the tree via a Commit message, the "parent_hash" field contains the parent hash for <del> this leaf node (see parent-hash). </del> <ins> this leaf node (see parent-hashes). </ins> The LeafNodeTBS structure covers the fields above the signature in the LeafNode.  In addition, when the leaf node was created in the

8.7. <del> To allow group members to verify that they agree on the public cryptographic state of the group, this section defines a scheme for generating a hash value (called the "tree hash") that represents the contents of the group's ratchet tree and the members' leaf nodes. </del> <ins> MLS hashes the contents of the tree in two ways to authenticate different properties of the tree.  This section defines _tree hashes_, and _parent hashes_ are defined in parent-hashes. Each node in a ratchet tree has a tree hash that summarizes the subtree below that node.  The tree hash of the root is used in the GroupContext to confirm that the group agrees on the whole tree. Tree hashes are computed recursively from the leaves up to the root. </ins> The tree hash of an individual node is the hash of the node's "TreeHashInput" object, which may contain either a

of node.  "LeafNodeHashInput" objects contain the "leaf_index" and the "LeafNode" (if any).  "ParentNodeHashInput" objects contain the "ParentNode" (if any) and the tree hash of the node's left and right <del> children. </del> <ins> children.  For both parent and leaf nodes, the optional node value MUST be absent if the node is blank and present if the node contains a value. </ins> The tree hash of an entire tree corresponds to the tree hash of the root node, which is computed recursively by starting at the leaf

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

updates of P.  This property is crucial for the correctness of the protocol. <ins> Note that "original_sibling_tree_hash" is the tree hash of S, not the parent hash.  The "parent_hash" field in ParentHashInput captures information about the nodes above P. the "original_sibling_tree_hash" captures information about the subtree under S that is not being updated (and thus the subtree to which a path secret for P would be encrypted according to synchronizing-views-of-the-tree). </ins> For example, in the following tree: With P = W and S = Y, "original_sibling_tree_hash" is the tree hash

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

the nodes in the UpdatePath form a parent-hash chain from the committer's leaf to the root. <del> For example, nodes the tree in full-tree might have been populated by full Commits from A, E, F, G, and B (in that order).  These Commits would create the following parent-hash validity relationship (where the value for a node is reset each time it is listed): Commit from A: A - U - X Commit from E: E - Y - Z - X Commit from F: F - Y - Z - X Commit from G: G - Z - X Commit from B: B - U - X After these commits, the tree will have the following parent-hash chains: A B - U - X E F - Y G - Z Since these chains collectively cover all non-blank parent nodes in the tree, the tree is parent-hash valid. Note that this tree, though valid, contains invalid parent-hash links.  If a client were checking parent hashes top-down from X, for example, they would find that Z has an invalid parent hash relative to X, but that U has valid parent hash.  Likewise, if the client were checking bottom-up, they would find that the chain from F ends in an invalid link from Y to Z.  These invalid links are the natural result of multiple clients having committed. </del> 8.9. As described in commit, each Commit message may optionally contain an