Quote from: wyager on January 11, 2014, 07:23:51 AM

This thread hasn't had a lot of activity recently. Here's what I'd say:

Bloom filter based on SHA(SHA(privkey)) is interesting. Allows for plausible deniability by encoding multiple wallets (different wallets are accessed by using a different password). If OP wants to change the spec to a simple bloom filter, I'd be in support of that.

I guess 2 passwords is sufficient and the collision chance is significantly lower than the 4 password proposal I gave in this thread. However, I would like some more feedback from others before making this change.

Quote from: wyager on January 11, 2014, 07:23:51 AM

English description:
Create a real password P1 and a "fake" password P2. The user can specify P2 if they want a "fake" password that will decrypt to a valid wallet. If the user doesn't want a "fake" password, P2 is to be randomly generated (so all users have a similar bloom filter). For each password P0...Pn:
1. Decrypt the wallet and calculate the master secret key Kn
2. Calculate SHA(SHA(Kn)) and call this Hn (Hn[0:4] is currently used in the spec as a wallet checksum)
3. For each of the first 11 bytes in Hn (let's call each byte Hn_i):
a. Take the lowest 5 bits of Hn_i. Call this number (which ranges from 0 to 31) D
b. Set the Dth bit of the bloom filter to 1

Seems simple enough.

Quote from: wyager on January 11, 2014, 07:23:51 AM

I think the existing date field is sufficient for optimization. It doubt it would be worth the effort to put more detail in the wallet spec. I would like to hear from gmaxwell and other client devs on this, since they're the authority on SPV optimization. Yes, we can optimize scan times by putting restrictions on the order of wallet generation, but I think that belongs in a separate BIP.

I posted a question to the bitcoin-dev mailing list asking for feedback on HD wallet import strategies. I haven't had any replies.