previous change to statement about readcap length in the 'pubkey in cap' scheme was incorrect. also the advantage is only simplification, not speedup, because the signature verification can be in done concurrently

[Imported from Trac: page NewMutableEncodingDesign, version 22]

NewMutableEncodingDesign.md

@@ -178,8 +178,8 @@ requiring the client to fetch a copy:
 The hash to obtain the privkey is necessary because directly using a (K+T)-bit
 exponent would allow meet-in-the-middle attacks. ECDSA or Ed25519 pubkeys are
 slightly more than 2*K long, so this would increase the length of the readcaps
-because 2*K > T. The advantage would be simplifying/speeding up the download
-process. It is highly unlikely that there is any public key algorithm
+relative to the scheme above whenever K > T. The advantage would be simplifying
+the download process. It is highly unlikely that there is any public key algorithm
 with keys shorter than 2*K for a K-bit security level. Since we can use shorter
 hashes than public keys, the H(pubkey) design above gives us shorter read caps,
 although they are not shorter than using semi-private keys.