Topic: Questions Regarding Gmaxwell's Namecoin proposals (Read 763 times)

I never saw this post originally, ... should have emailed me. :-/

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.

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.

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/

side --babel tower
-- ACK

So I'm aware that Gregory Maxwell posted some proposals for improving Namecoin a while back: https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less

Unfortunately the proposals are kind of vague (I assume he was writing them in a hurry and not for a general audience).  I'm hoping Gregory is willing to comment on some of them, as the Namecoin dev community has shown some interest in implementing them.

So, here are a few questions.  (I might follow up with more.)

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.

2. How would hashing names prevent someone from doing a dictionary/bruteforce/rainbow table attack to find most of the names?  Presumably there are dictionaries out there with most of the ICANN domains, which might be an effective starting point.  Is the goal just to give the miners and full node operators some level of plausible deniability i.e. "we choose not to do this attack" rather than actually make the attack very difficult?

3. The provided link on a committed UTXO set doesn't really provide much context, and I don't have enough knowledge to infer the context.  Is the lite resolver an SPV client?  I can't tell from the provided description.  What actually would get done (including crypto) by the full client to get this functionality working?  Is this functionality also proposed for the Bitcoin client?

Thanks!