diff --git a/NewMutableEncodingDesign.md b/NewMutableEncodingDesign.md
index c46c15a..b9ca28e 100644
--- a/NewMutableEncodingDesign.md
+++ b/NewMutableEncodingDesign.md
@@ -131,11 +131,11 @@ Zooko captured the current leading semi-private-key-using mutable file design
 nicely in the ["StorageSS08" paper](http://allmydata.org/~zooko/lafs.pdf)
 (in Figure 3). The design is:
 
- * (1K) writecap = K-bit random string (perhaps derived from user-supplied
-   material) (remember, K=kappa, probably 128bits)
+ * (K + T) writecap = (K+T)-bit random string, perhaps derived from user-supplied
+   material (remember, K=kappa, probably 128bits)
  * (minimum 2K) readcap = minimum 2*K-bit semiprivate key
  * (minimum 2K) verifycap = public key
- * storage-index = truncated verifycap
+ * storage-index = (possibly truncated) verifycap
 
 On each publish, a random salt is generated and stored in the share. The data
 is encrypted with H(salt, readcap) and the ciphertext stored in the share. We
@@ -150,11 +150,11 @@ signed block that must be fetched anyways).
 
 Like above, but create two levels of semiprivate keys instead of just one:
 
- * (1K) writecap = K-bit random string
+ * (K + T) writecap = (K+T)-bit random string
  * (minimum 2K) readcap = minimum 2*K-bit first semiprivate key
  * (minimum 2K) traversalcap = minimum 2*K-bit second semiprivate key
  * (minimum 2K) verifycap = public key
- * storage-index = truncated verifycap
+ * storage-index = (possibly truncated) verifycap
 
 The dirnode encoding would use H(writecap) to protect the child writecaps,
 H(readcap) to protect the child readcaps, and H(traversapcap) to protect the
@@ -169,10 +169,10 @@ is the pubkey, and that can't be used to protect the data because it's public
 current (discrete-log DSA) mutable file structure, and merely move the
 private key out of the share and into the writecap:
 
- * (K) writecap = K-bit random string = privkey
+ * (K + T) writecap = (K+T)-bit random string = privkey
  * (2K + T) readcap = H(writecap)[:K] + H(pubkey)[:K+T]
  * (K + T) verifycap = H(pubkey)[:K+T]
- * storage-index = truncated verifycap
+ * storage-index = verifycap
 
 In this case, the readcap/verifycap holder is obligated to fetch the pubkey
 from one of the shares, since they cannot derive it themselves. This
@@ -187,7 +187,7 @@ for mutable files.) The verifycap is K+T bits.
 Or, if the pubkey is short enough, include it in the cap rather than
 requiring the client to fetch a copy:
 
- * (K) writecap = K-bit random string = privkey
+ * (K + T) writecap = (K+T)-bit random string = privkey
  * (minimum 3K) readcap = H(writecap)[:K] + pubkey
  * (minimum 2K) verifycap = pubkey
  * storage-index = H(pubkey)
@@ -205,11 +205,11 @@ Since a secure pubkey identifier (either H(pubkey)[:K+T] or the original privkey
 is present in all caps, it's easy to insert arbitrary intermediate levels. It
 doesn't even change the way the existing caps are used:
 
- * (1K) writecap = K-bit random string = privkey
+ * (K + T) writecap = (K+T)-bit random string = privkey
  * (2K + T) readcap = H(writecap)[:K] + H(pubkey)[:K+T]
  * (2K + T) traversalcap: H(readcap)[:K] + H(pubkey)[:K+T]
  * (K + T) verifycap = H(pubkey)[:K+T]
- * storage-index = truncated verifycap
+ * storage-index = verifycap
 
 ## Shorter readcaps (insecure)