you 2 bring basically the same argument.  We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out.  I say the new clients should implement the restrictions I listed NOW.  Then if the case you bring where the user creates an low-entropy passphrase  then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.

Eventually the new clients will go widestream and security will improve.

Yes, and now calculate the combinations and come back with the number

I have not the math skills to do even this.

1600 * 10 = 16,000  
ok, I'm lost.

I was just wondering if the security level is the same if you change the brute force method in this way or if it decreases at all.

He requested information and I tried to give it to him.

We make it simple. Imagine each word is a character, as you suggested. But now, for every of the 12 characters we type, we can choose out of 1626 characters.

First character (word): 1626 possibilities
Second character (word): 1626 possibilities
....

Now calculate. You can do it. Math is cool.

Since it's open source, everyone knows the dictionary

https://raw.github.com/spesmilo/electrum/master/lib/mnemonic.py

The security shouldn't be based on "secrecy" . It's secure as 12 words from 1626 word choices is equal to 2^128 possible combination.

No.

It's 12 words (not 10), so it's 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626

Thoughts: Implement this ASAP, and sort out the wallet.dat discussion later.

Do not get sidetracked into that discussion and then wait

It may not be *perfect* but it's WAY better than what we have.