I never saw this post originally, ... should have emailed me. :-/
1. For the encryption of values, can you explain how exactly the network verifies that a hash and encrypted value are being stored rather than an unhashed name and unencrypted value? I don't really understand the P2SH^2 thing, possibly due to my lack of experience with Bitcoin internals.
For example— in the hash case you make your hash an iterated hash, like H(H(data))=X. By revealing to you H(data)=Y you can compute H(Y)==X and are convinced that X is a hash. Y may or may not be a hash, but at least it's just ephemeral— you don't store it, you just remember the Y values for blocks near the tip and don't require them for historical block.
Elsewhere I described a number theoretical hash which is provably a hash using pairing cryptography. But since it's slow it may not be of interest. For that you have some paring compatible elliptic curve group which supports an efficient operation to coerce a random value to a point on the curve. You compute point=G*H(data), point2 = to_point(H(point||masked_tx_hash)), proof = point2*H(data). You transmit {point, proof}. The other side computes point2 from point and verify that pairing(G,proof) == pairing(point,point2). This proves that point is a EC curve point for which you know the discrete log. The troof can be omitted from historical blocks (like the P2SH^2 above) to avoid the storage overhead. This also has an advantage that it's replay proof— even if you log proofs you cannot make another transaction reusing the prove hash without knowing the data. The downside of this is the pairing computation probably takes 1ms per transaction.
In either of these cases people could randomly select their data and keep trying until the prefix of the point matches some data they want to send, but this has exponential complexity in the number of bits stored per value.
2. How would hashing names prevent someone from doing a dictionary/bruteforce/rainbow table attack to find most of the names?
It doesn't prevent a dictionary search, but it prevents bulk enumeration: at least they have to guess. If they fail to guess, they'll never know. I don't think better than that is possible in a fully decenteralized system.
Is the lite resolver an SPV client?
Thats the idea: Make it so that a SPV client can do secure resolution. People have been working on some committed utxo stuff for bitcoin but the implementations are not mature yet.
Client privacy can be improved further for ligher-than-SPV resolvers by using information theoretic PIR:
http://percy.sourceforge.net/
