Check out this 65BTC necklace



Some serious bling sported at the LA Bitcoin Meetup (http://www.meetup.com/Los-Angeles-Bitcoin/events/139996962/) last night.

The Los Angeles Bitcoin meetup group is hosting a panel event on October 10 in Santa Monica, CA. If you're going to be in the LA area definitely drop by and meet our group.

Special guests include:
• Tony Gallippi (CEO and founder of BitPay - the largest Bitcoin merchant processor)
• Vinny Lingham (CEO and cofounder of Gyft - a mobile gift card company which just raised $5MM in Series A and gives Bitcoiners a way to spend their coins at major retailers)
• Travis Skweres (CEO and founder of CoinMKT.com - a recently launched Bitcoin exchange) 

Free food and drinks are graciously provided by BitPay.

For more details: http://www.meetup.com/Los-Angeles-Bitcoin/events/139996962/

[Money Tree]

Money Tree

I've just released an open-source Ruby gem for creating Hierarchical Deterministic Bitcoin Wallets. This gem will allow you to generate or import a random seed and create an entire tree of Bitcoin keypairs derived from that seed. So you don't need to backup all of your keypairs, you just need to backup the seed.

This gem follows the spec at https://en.bitcoin.it/wiki/BIP_0032 and passes all test vectors provided there.

Let me know what you think!

You can check out the repo at https://github.com/wink/money-tree

Why would I want an HD 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.

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 controls

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.

[Private child key derivation]

I have been implementing the BIP0032 HD Wallet protocol, and ran into an issue in the documentation at https://en.bitcoin.it/wiki/BIP_0032 which slowed me down for an entire day. Here is the documentation on private child key derivation.

Private child key derivation
To define CKD((kpar, cpar), i) → (ki, ci):
Check whether the highest bit (0x80000000) of i is set:
If 1, private derivation is used: let I = HMAC-SHA512(Key = cpar, Data = 0x00 || kpar || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]
If 0, public derivation is used: let I = HMAC-SHA512(Key = cpar, Data = χ(kpar*G) || i)
Split I = IL || IR into two 32-byte sequences, IL and IR.
ki = IL + kpar (mod n).
ci = IR.

It says you should add IL to kpar(mod n).
In pseudo code, this would be:

Code:

i_left + (kpar % n)

Adding these two values together should always create a new number that is 32 bytes long. However, for some values of IL and kpar(mod n), adding them together can create a number that is greater than 32 bytes long, and is therefore no longer a valid 256bit private key.

It appears the parenthesis are in the wrong place in the documentation. It should read:

ki = (IL + kpar) mod n.

or in pseudo code:

Code:

(i_left + kpar) % n

Changing the parenthesis finally made all of my test vectors pass. I'm posting this to hopefully save someone else a world of trouble. Can we change the documentation?