The hierarchy

This web wallet implements the recommended hierarchy from the original BIP32 proposal. As shown on the diagram below, a master extended key is used to create a number of child nodes which will be "Accounts". Each of the accounts have their own extended private and public key. The web wallet uses those extended keys from this frist derivation. Wallet chains and addresses follow as in the diagram.

How to generate suitable BIP32 keys

You can use BIP32.org (either online of offline), or other Bitcoin utilities that implement BIP32, such as the pycoin library. For simplicity, the BIP32.org way is shown here.

On BIP32.org, can use a strong passphrase, or a random string from a trusted source of randomness to generate the "BIP32 Extended Key". Save this key, and protect it well, as it is used to generate all the possible addresses belonging to this account.

Further down the page, find the "Derivation Path" dropdown. Choose "Custom", and type in "m/i'". The prime means "private derivation", which is recommended for these top level accounts as mentioned in the original document. Choose a number for "Keypair Index (i)". It can simply be 0 for the first wallet (and all related addresses) that you want to use, e.g. one of your projects, or one branch of a chainstore, then 1 for the second, and so on. As long as you remember the number, it doesn't matter what do you choose.

From here, save the extended private key, and extended public key. You will have to enter one of these into the web wallet. You can use the extended public key to query the funds in your wallet, without being able to spend it. Keep the extended private key secure, as that gives total access to your wallet and lets on spend the funds within.

Example

The one that should go in is the "wallet/account" level, which is "depth=1" keys (or m/i) accounts. After that the generated addresses are external and internal wallet chains (m/i/0/j and m/i/1/k) respectively.

My testing extended public key is for example:

If you plug it into bip32.org, it will show "depth=1" (meaning it's one of the m/i keys). Then go to the derivation path section, and choose "custom", because we are not working with the "master node", but one of the childs, so this m/i key will be the new m for the purpose of the derivation! So when trying to get the first external address m/i/0/0 becomes m/0/0 because of the change of base.

Then for first receiving address for this public key, m/0/0, can compare both the bip32.org and the webhdwallet to correctly give 16p6ojeBcaELVJrXNmstA2Sv2Koi8zXfds, and for the first change m/1/0 they both give 1D5CKrqtbnsTdSTggr6um5eM17LoMyKdAC.