We're assuming that the attacker somehow has your encrypted wallet key. He's trying to guess your password, and he's previously done KDF work for you.
The attacker guesses your password is "bob", now he generates the resulting KDF queries and sees that they match the work you asked him to do. He goes and simulates your full process, looks up his saved kdf results, and can now steal your coin.
Yes you are right. It was written in great haste as I was leaving, figured this out shortly afterwards.
The problem is the network can be expected to cache your correct password result after KDF.
Therefore the only thing this could be good for is a one use signature (eg a big stash that you dont touch except once to sell it).
Or if you have a seed encrypted 1000 times with each different salt and the same password, and you securely delete the respective encrypted seed after each use.
50 choose 100 doesnt seem to help that picture.
The problem there is because the process is deterministic given your password and the wallet seed he can just regenerate the correct queries and ignore the chaff ones. (Unless you have a KDF which has some homomorphism that allows blinding, and I think thats both asking too much of implementors and escaping from the realm of memory hard KDFs that we'd prefer to use)
I think the Rivest & Wagner time-lock puzzle (which I extended with blinding) might be somewhat memory hardenable if one used bigger RSA key than necessary for security. Not really tried to analyse it from that perspective so far, there may also be some parallelization opportunities or TMTOs.
The basic RSA blind signature is rather simple, eg used in the coinjoin protocol right. The blinding variant I use for blinding the time-lock puzzle is quite similar. Maybe it wouldnt be so bad if a simple reference implementation in OpenSSL were provided.
Adam
