Looks like the cost is dominated by a size-3 elliptic curve MSM per guess. The work should be ~the same order of magnitude as edDSA signing operations. So on the order of 100k guesses per second on consumer hardware.

I don’t see how a hash existence oracle could be more useful than a username existence oracle, which already exists. The pedersen proof thing was implemented so it may just come down to “proof of knowledge of the actual username+discrimination” is easier to reason about/ harder to fuck up

The current implementation code limits the discriminators to a 64-bit representable value

I guess the question is: What kind of adversary knows H(username, discriminator) but not username and discriminator?

I had considered that it also forces Alice to prove that the hash was constructed properly, but * I don’t know why that would be important * It doesn’t actually prove the discriminator is in the correct range, nickname is valid, etc

Yeah, I get that this system ensures Bob knows the hash input, but don’t see why that lends any security over knowing the hash output. Maybe they intend to use the hash for something else, and might leak it? But that could just be solved with domain separation.

Right, but I guess the question is “why do we want a Pedersen commitment to the nickname” Maybe some fun future feature that needs it for more zk proofs? Given the desire for a pedersen commitment, the design makes sense (hash prevents brute-forcing the nickname and discriminator independently)

Any idea why they use this pedersen hash nickname*G1 + discriminator*G2 + H(nickname, discriminator)*G3 rather than just H(nickname, discriminator)*G along with a simple Schnorr proof? I can’t think of any properties the former gives over the latter