Having an easily portable, easily writeable and even memorisable seed* is an often requested issue and I think there would be benefit to have a cross implementation compatible standard, specially because there's a lot of space for pain if you implement it the wrong way. The end goal should not an "easy to memorize" but rather a "easy to write down/possible to memorize", since the value isn't so much on keeping the wallet 100% on your brain, but rather the extreme portability.

* Sometimes called a Brain wallet, but usually when referring to a human picking the random phrase, which is not the goal here

1. Ask for a Salt: Email address

It doesn't matter how hard is your password to guess, if you don't have a unique part of it, then an attacker could continuously generate a giant table of passwords, that would allow him to steal wallets that are yet to be created for any users. A salt doesn't need to be secret it just needs to be unique, if an attacker knows your salt they can try to guess your password but then they would be using all that hash power against one specific user, so the potential gains are limited.

An email address would be a perfect salt: it's instantly memorable by the user and is unique enough to add security. A client could also use the email to send a message with instructions, which allows a few interesting uses:

• the user could make an email on the form of username+randomstring@gmail.com to add more uniqueness, but they could still search their inbox for it
• it could be used as an invitation. You add someone emails address and the client will send them instructions on how to redeem the ether (of course the full seed would not be sent on the email, that would require the invitee to contact the inviter)
• Users are used to the pattern email + password as a login on social networks, so while the way this works is different, they might feel more at ease

2. Random seed generator

The user should never pick his own random seed. Humans are terrible sources of randomness and that should be provided for them. The user could be presented with the following choices:

1. The level of security they want. This could be presented as "safe to secure up to X amount" and should reflect on the size of the seed. All clients should provide a minimum maximum security that should be in trillions of trillions of possible seeds. Not all use cases need to have complete unbreakable encryption, for transfer of small amounts of pocket money, a password that would take thousands of dollars to break should be enough.
2. The option to generate a new seed if they want. In a typical use case the user should not have to see more than 10 seeds before settling on one, so that this wouldn't decrease the entropy by much.
3. The option of selecting between string generation scheme. The user should pick the one that feels more comfortable with his culture or input device. Some examples would be:

• Word List. BIP39 has an excellent word dictionary of words in multiple languages. Those were picked up to be common words yet all of them can be unambiguously distinguished by just the first 4 letters.
• Pseudo-words. Using syllables to generate pseudo-words can be as strong and easier to write down. For example these three alien words: "fakpug temvuw jorzul" have the entropy equivalence of 6 random words (from a 1024 word list). Another example: "uffu wojtij ewiome wu cajreg hajkut mar" is the equivalent of 12 seed words.
• Symbols. If you have a pen input or have knowledge of chinese, then an ideogram is a great seed. There probably a use case for an emoji based seed generation.
• Security questions. An interesting way to transmit a brain wallet securely to someone would be to generate a series of questions that the user needs to answer on the other side. The questions could be sent via email and the hash would include both the question and answer. This would be much less secure but could be useful in a case where the user simply wants to send a small amount of ethers just so that the user can execute a contract
• A mix of the above?

3. Multiple hashing rounds and multiple account outputs

Instead of a single round of hashing, the seed should be generated by hashing the password multiple times. The number should be standard, based on something that would take an average laptop/mobile phone in 2016 an average of 1 second or so. This means that even with a specialised computer and taking moose's law in consideration, testing millions of passwords would still take a considerable time and cost for the attacker.

Another layer of security can be added by generating not one, but an indeterminate amount of accounts for the user, by repeating the same hash amount. The user could be presented with 10-12 accounts to choose from whenever they generated a brain wallet, and could even choose them by picking a memorable and aesthetic pleasing icon. The attacker would then have to choose between testing a thousand passwords for 1 account or testing 10 accounts for 100 passwords. Since the user can be using the 12th account, there's a chance the attacker would have his salt, try his password combination and still not find his private key.

Interface Mockup

The following is just a mockup on how a brain wallet could look like in the Wallet. Once a user selects an ethereum address field, a pop up would appear asking them to select a field from their contact list, recently used addresses or a new brain wallet. Once selecting the brain wallet, the user would fill the email, passphrase and then they could select from multiple addresses. Each address would take about a second to appear, and the user could select any page they want.

Creating a new brain wallet:

#### Loading an existing brain wallet