Original text:
In particular, MLS maintains the members' views of the tree in such a way as to maintain the _tree invariant_: <del> In other words, if node is not blank, then it holds a key pair, and </del>  the private key of that key pair is known only to members holding leaves below that node. <del> The reverse implication is not true: A leaf below an intermediate node might not hold the private key for the node.  Such a leaf is called an _unmerged_ leaf, since encrypting to the subtree below the node requires encrypting to the node's public key as well as the unmerged leaves below it.  A leaf is unmerged when it is first added, because the process of adding the leaf does not give it access to all of the nodes above it in the tree.  Leaves are "merged" as they receive the private keys for nodes, as described in ratchet-tree- updates. </del>  5.4.

Reviewer comments:
Picking up some comments from NAME that I missed earlier, and fixing examples. Obsoletes
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .*

Revised text:
In particular, MLS maintains the members' views of the tree in such a way as to maintain the _tree invariant_:  <ins> In other words, if a node is not blank, then it holds a key pair, and </ins> the private key of that key pair is known only to members holding leaves below that node.  <ins> The reverse implication is not true: A member may not know the private keys of all the intermediate nodes they're below.  Such a member has an _unmerged_ leaf.  Encrypting to an intermediate node requires encrypting to the node's public key, as well as the public keys of all the unmerged leaves below it.  A leaf is unmerged when it is first added, because the process of adding the leaf does not give it access to all of the nodes above it in the tree.  Leaves are "merged" as they receive the private keys for nodes, as described in ratchet-tree-updates. </ins> 5.4.