04/19/14

Why would I want an HD BIP32 Wallet?

Why would I want an HD BIP32 Wallet?btc-wallet-HDW_02

WHY I’M DESIGNING A BIP32 WALLET- Hierarchical Deterministic (HD) Bitcoin Wallets offer several advantages over traditional Bitcoin wallets.

One of the problems with traditional Bitcoin wallets is that the wallet may hold a whole bunch of keypairs, each with Bitcoins attached to them. When you want to back up your wallet, you backup all of the current keys that you control in that wallet. However, if you later generate a new key, you need to make a brand new back up of your wallet. In fact, you need to back up your wallet every time you generate a new key.wallet-605_02

Easy backups

HD wallets allow you to create a huge number of Bitcoin keys (keypairs) that all derive from a parent master key. This means that if you control the master key, you can generate the entire tree of children keys. So instead of needing to make repeated backups of your wallet, you can create a single backup when you create the wallet, and from then on to the end of time, you will never need to make a new backup, because you can just recreate ALL of the child keys from your master key.

Safely store your private keys offline

Additionally, HD wallets introduce cool new features to wallets, like being able to derive the entire tree of public keys from a parent public key without needing ANY private keys. For instance, let’s say you have your master private key backed up on a paper wallet and stored offline in a safe somewhere, but you have the master public key available. Using just this public key, you can generate an entire tree of receive-only child public keys.

For instance, let’s say you wanted to open a Bitcoin ecommerce website. With HD wallets, you can keep your master private key offline, and only put your public key onto the public webserver. Your website can then use that key to generate a receiving address for each and every product on your site, a unique address for each one of your customers, or even a key unique to each customer/product combo. (The uses are left up to your imagination.) And since the private key is stored offline, nobody will ever be able to hack your site and steal your Bitcoins.

Access controls67mathmoneyfx-01

One bonus feature of HD Wallets is that they give you a lot of control over who in your organization has access to which keys. Like an organizational chart for a business, HD wallets are arranged in a tree formation. You could create whole branches of keypairs for each department in your organization, and by giving each department only the private key at the top of their department branch, each department will only be able to spend the coins on their branch. However, since you hold the master key, you can watch and spend ALL coins in the entire tree.

Accounting

Want to give your accountant access to view all transactions, but you don’t want to give her access to spend any of your coins? No problem. You can simply give her the public key at any level in the tree that you desire, and she will be able to view transactions below that key in the tree, but won’t be able to spend any of the coins.

Usage

These instructions assume you have a decent understanding of how Bitcoin wallets operate and a cursory knowledge of how a Hierarchical Deterministic Bitcoin Wallet (HD Wallet) works.

Create a Master Node (seed)

To create a new HD Wallet, we’re going to create a tree structure of private/public keypairs (nodes). You’ll first want to start with a master node. This master node should be seeded with at least 16 random bytes but preferably 32 random bytes from a cryptographically secure PRNG (pseudo-random number generator).

DO NOT use a user generated password. Keep in mind that whoever controls the seed controls ALL coins in the entire tree, so it should not be left up to a human brain, because humans tend to follow patterns and patterns are subject to brute force attacks. Luckily, our software includes the seed generation by default so you don’t need to create this on your own.

Usage

These instructions assume you have a decent understanding of how Bitcoin wallets operate and a cursory knowledge of how a Hierarchical Deterministic Bitcoin Wallet (HD Wallet) works.

Create a Master Node (seed)

To create a new HD Wallet, we’re going to create a tree structure of private/public keypairs (nodes). You’ll first want to start with a master node. This master node should be seeded with at least 16 random bytes but preferably 32 random bytes from a cryptographically secure PRNG (pseudo-random number generator).

DO NOT use a user generated password. Keep in mind that whoever controls the seed controls ALL coins in the entire tree, so it should not be left up to a human brain, because humans tend to follow patterns and patterns are subject to brute force attacks. Luckily, our software includes the seed generation by default so you don’t need to create this on your own.

Import a public-key only node

You can also import a node using only a public key. Keep in mind that this node will only be able to generate other public-key only nodes. You will not be able to derive child private keys using this node.

@node = gAtO::Node.from_serialized_address(“xpub6AvUGrnEpfvJJFCTd6qEYfMaxryBU8BykimDwQYuJJawFEh9BiyFdr37Cc4wEKCWWv7TsFQRUMdezXVqV9cfBUbeUEgNYCCP4omxULbNaRr”)

=> gAtO::Node instance

@node.to_serialized_address

=> “xpub6AvUGrnEpfvJJFCTd6qEYfMaxryBU8BykimDwQYuJJawFEh9BiyFdr37Cc4wEKCWWv7TsFQRUMdezXVqV9cfBUbeUEgNYCCP4omxULbNaRr”

@node.to_serialized_address(:private)

-> raises gAtO::Node::PrivatePublicMismatch error

Values of i and i-prime

Earlier we discussed the use of an index value i to represent the sequential ordinal index of a child in relation to its parent. That is, i=0 would be the first child, i=1 would be the second child, and so forth up to (i-1) as the i’th child. This index value is very important in the child key derivation process because it allows us to create a whole bunch of subnodes (child keys) for a given node, just by incrementing the i value. In fact, i is a 32-bit unsigned integer which gives us the ability to create up to 4,294,967,296 addresses for one node.

When choosing i values, the BIP0032 spec calls for using a reserved set of i values to denote a node that should use private derivation and another reserved set of i values to denote public derivation.

The way this breaks down is:

0 through 2,147,483,647 (i < 0×80000000) should use public derivation

2,147,483,648 through 4,294,967,295 (i >= 0×80000000) should use private derivation

Yikes, that’s a lot of detail to remember. Luckily, there is a simple notation in the path strings that allow us to easily tell the difference between a node that uses public derivation and a node that uses private derivation. We use either ” ‘ ” (prime symbol) or “p” at the end of a node path part to denote private derivation.

For instance: “m/0′/1″ and “m/0p/1″ are equivalent and they translate to the “the second publicly derived child 1 of the first privately derived child 0 prime of the master key m”. But since we know that the “first privately derived child” is in the i value range above 0×80000000, the very first possible i value in this range is actually 0×80000000, or 2,147,483,648. Therefore when we say “m/0p/1″, what we really mean is “m/2147483648/1″. Thus:

“m/0′/1″ == “m/0p/1″ == “m/2147483648/1″

They are all equivalent ways of saying the same thing, but the first two are just a more human readable shorthand notation. You are free to use whichever notation you prefer. This gem will parse it.

To add just a little more confusion to the mix, some wallets will use negative i values to also denote private derivation. Any i value that is negative will be processed using private derivation by this library. e.g. “m/-1/1″.