update on the hypothetical zooko scheme

[Imported from Trac: page NewImmutableEncodingDesign, version 3]

NewImmutableEncodingDesign.md

@@ -106,10 +106,27 @@ them). And I'm pretty sure that Rose the readcap-holder can collude with a
 quorum of storage servers to change the contents of the file, since there's
 nothing in K2 that's dependent upon the actual shares.
 
+If SI=H(K2) and K1=CHK(data), then you get protection against Rose+Server,
+but you only get to discover problems after you've extracted all of the
+plaintext, so alacrity is maximally bad (you can't deliver the first byte
+of validated plaintext until you've retrieved the last byte of the ciphertext).
+
+Not having a validated UEB is troublesome, because then you don't know which
+shares are good, so if whatever subsequent validation you have (like a CHK)
+fails, you don't know which shares to throw out. But since all shares are
+supposed to have a copy of the same UEB, there's a workaround: validate each
+share up to its local UEB, sort the varieties of UEBs that you see, start
+with the most popular one, see if a decode matches your CHK. If not, iterate
+to the next-less-popular variant, etc.
+
 If SI=UEBhash, then you've got the integrity checking that you want, but
 there's no way for the readcap holder to find out what the storage-index is,
 so they can neither locate a share (to compute everything else) nor can they
-use the storage-index to validate anything.
+use the storage-index to validate anything. You could imagine a separate
+table, though, that mapped H(K2) to storage-index values, but of course this
+table would have to be stored somewhere, etc.
+
+
 
 ## Mutable readcap plus commitment