Quote from: wyager on April 23, 2014, 02:39:39 AM

The false positive rate with two keys in the filter is about 1 in 40,000. A bit better than the false positive rate of two 16-bit filters, which is about 1 in 33,000 (if my reasoning is correct).

Sounds good. Yes, it would be ~1/65536*2. I was about to suggest something where you need N of M of even smaller checksums and then realized that the bloom filter is basically the limit case of that. If you don't want to support more than two values, you could specify having more than 11 extra 1s is also regarded as a false match. E.g. if this key only sets 8 ones and there are 20 set in the filter (including these) then then also regard it as a false positive (because there is no possible single second value which would result in more than 11 bits being set).

Quote

Even in the way we have it set up now, if an attacker can get their hands on strongH as well as the encrypted wallet, they can skip the first 8192 rounds of PBKDF2, hence the last 2048 rounds. Basically just extra safety against a dictionary attack on both strongH and the wallet.

The structure I gave has the same property.

If you have StrongH and the encrypted wallet you still need the whole output of the initial KDF, which means you need to know or guess the password and grind the initial KDF.