Change:
5.5. <del> The members of the group need to keep their views of the tree in sync and up to date.  When a client commits a change to the tree (e.g., to add or remove a member), it transmits a handshake message containing a set of public values for intermediate nodes in the direct path of a leaf.  The other members of the group can use these public values to update their view of the tree, aligning their copy of the tree to the sender's. </del> <ins> After generating a Commit as described in the prior section, the generator of the Commit must broadcast this update to other members of the group, who apply it to keep their local views of the tree in sync with the sender's.  When a client commits a change to the tree (e.g., to add or remove a member), it transmits a handshake message containing a set of public values for intermediate nodes in the direct path of a leaf.  The other members of the group can use these public values to update their view of the tree, aligning their copy of the tree to the sender's. </ins> To perform an update for a path (a Commit), the sender broadcasts to the group the following information for each node in the direct path

Discussion:
This PR does the following: Adds a lead-in sentence describing how this section builds on the prior. Differentiates between public keys for nodes and public keys for leaves (users) Clarifies when secret key material needs to be deleted. I also wanted to make a couple other changes, but wanted feedback first. This section describes the private value corresponding to a node's public key as 'ns[0]' (or node secret), whereas the prior section referred to it as 'np[0]' (or node_priv). It would be better to have these terms be consistent. On line 773, it says that the client "...transmits a handshake message containing a set of public values" and on line 776 it says that "other members of the group can use these public values to update". However, this values seems to be contradictory with the value listed on line 785. The current terminology is unclear regarding 1) a Commit to the tree, 2) an update to the tree, and and 3) a handshake message. I think these are very similar but using the same language consistently would be better (such as defining a Commit as what updates the tree, and then describing how the handshake message is different from a Commit message, which is described earlier in the spec).
Thanks for looking through this, NAME There's a lot of historical baggage here, so it's good to get it cleaned up. I'll review the diff in a moment, but to respond to your points: Just to confirm terminology here, there are three values in play, (1) a symmetric secret, (2) a KEM private key derived from the secret, and (3) the corresponding public key. It should be the case that you only need to store the latter two in the tree (priv+pub), since the secrets are used transiently: For deriving the tree key pairs, for deriving the commit secret, and for initializing new members added in an epoch. stores the node secrets to simplify these operations, but it feels like it should be possible to arrange things so that this isn't necessary. So I think the right answer here is to just refer to node private keys. Line 785 is correct, the Commit contains a public key and encrypted copies of the path secret for each node. So the text should refer to public and encrypted private values as necessary.

The right taxonomy here is: "Handshake message" encompasses and . Processing the Commit is the thing that causes an update to the tree; more specifically, applying a DirectPath. So we should only talk about handshake messages when we want to cover both Proposals and Commits, and most instances of "update" should probably refer to either Commit or DirectPath.