I came across this quote on bitcoin.it: BIP_0032

elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).

This lead me to read more about some custom wallet implementations, namely pycoin. After looking through the code, I still can't understand how it is possible to generate public keys without giving the server access to the private key.


What i understand of this bip is that it uses a deterministic wallet (or a wallet that only needs the seed key to regenerate key pairs). An example of a deterministic wallet is electrum and also brain waller. These two services i know electrum more than brain wallet. Basically, what electrum does is gives you a 128bit root key in the form of a series of words.From this root key any public key can be hashed out. Part of the ease of refreshing these "old/lost" public keys is because you can not generate more public keys than have already been determined (deterministic) by the length of your seed. How it works is described by Gmaxwell on bitcoin talk

https://bitcointalk.org/index.php?topic=19137.0 Introduction on what has been discussed on IRC

I've discussed this enough on IRC that I thought I ought to put it someplace more lasting.

Bitcoin really ought to offer and default to using deterministic wallets.   The additional security of the current pre-generated ones is fairly small considering how most people use bitcoin and the liability of harm due to insufficient backups and increased pressure to keep a single wallet online is enormous. 

What is a deterministic wallet?  It's a wallet which you can backup once and it stays backed up forever because all future addresses are determined in advance. It can also be stripped down to a very small size which could be easily backed up on paper (e.g. with a QR code). This is in contrast to the current non-determinstic wallets where the keys are random but are precomputed ahead so that you're safe only if you backup at least every 100 get addresses or sends, and which grow large and harder to backup on paper over time.

I've found the backup behavior of the current wallets fairly difficulty to get even moderately technical people to understand. The current system provides enough safety to encourage complacency but not enough to make complacency acceptable.  The positive side of a non-determistic wallet is that it becomes "unstolen" over time but people are frequently reusing addresses and attackers will not act slowly regardless.

So the tl;dr, its hard to back up a current wallet.dat file  because there are way too many private root keys made (as infinite as can be). So the author proposed that a deterministic wallet can only make a certain number of keys because there is one set private key or seed. This deterministic wallet is possible because keys are all hashed the same way (they all use the same root, or base. Or same parent)

There are two types of deterministic wallet I'd like to discuss. I'll call them type-1 and type-2.

Type-1 is the most obvious kind:

The wallet stores a large random seed  S (which can be encrypted if the user uses wallet encryption)

Privatekey(type,n) is then simply set to H(n|S|type)  where H is an acceptable secure hash function and type can be set to different values for change addresses vs displayed addresses (so this distinction is preserved even if new wallet metadata is lost). 

The system would generate some (maybe 1000 of each type) addresses ahead of the furthest it has observed on the network but only bother to store the addresses. The keys can be regenerated as needed.

Tl;dr there are two known way discussed by gmaxwell to make sure you can keep a finite, and easily detected address. Type 1 is where your long seed ( example: dhrhdjidgMdudyemrbyrkandurkur). it is the only base used to hash out keys. since (afaik)bitcoin naturally was built to only use each set of seed keys a few times for change wallets only, those extra associated and generated keys/seeds are only kept locally within the wallet.dat file that is on that local bitcoin instance. Dynamically the original client will assign an incoming address or if its a change address and soon start over again with a new seed.

Type 1 uses a long set of numbers/letters Which are all generated from that seed (dhrhdjidgMdudyemrbyrkandurkur). This seed will always be hashed with the same function (lets for ease say sha). This hash function can only generate a finite amount of keys (i believe this is because your seed key is not infinity characters long, the potential number addresses are limited to the key length of the seed ).  So for as long as both dynamic wallet clients are coded to  hash/check the key the same way, they will always find the addresses through process elimination. Which is not too hard. it will hash to find if any coins are available at those addresses. If the address was never used, that address is ignored and left to use later.  (its like entering a vault with a key code and stored right on the floor is every last bitcoin you own. Those bitcoins are assorted in to plain old boxes. Since it is your vault, its tiny, and private you have only these number of boxes on the floor, they were premade boxes. Where as you neighbors keeps creating a new vault for a new set of boxes. It sounds a little silly for them to create so many vaults with different entrance codes, and so many boxes that are never used. But thats how bitcoin works. It makes a vault and in that vault are boxes empty and ready to be filled with coins or anything left over.  It makes it harder though for a thief to break in because he needs to open every last and sort through these boxes.  But anyway you take The seed (your valts keycode) and decrypt it(enter the vault password). That key It always tells you what boxes of bitcoin are in the vault (so say that  your vault password is JOESVAULT) well you know that there are only so many boxes that can fit inside that vault, and you know the name of each box (address) in there too. So, you can look in those boxes without having to guess which vault it is in. Since you only have one vault, you can eventually guess the names of the boxes in there. And thats because each box name(address) is derived from the vault key(seed)

Type-2 is a bit less obvious and understanding it requires you to know about a property of ECC keys, roughly:

A_public_key = A_private_key*point

Which means you can do:

B_public_key = A_public_key+B_secret*point and have a new key which has a private key: B_private_key = A_private_key+B_secret

So a type2 wallet stores: Master_private_key A large Random_seed S.

and keys are given by

Privatekey(type,n) = Master_private_key + H(n|S|type)

which works just like a type-1, the advantage of the type-2 is that you can separately secure the Master_private_key, but still generate new addresses with Publickey(type,n) = Master_public_key + H(n|S|type)*point

This means that a e-commerce site could have the front end webserver with access to the public key and S, and someone who hacked the server could violate the confidentiality of the addresses in use (because he could enumerate all past and future addresses based on an infrequently changed public key) but couldn't actually steal any of they money sent to the addresses because he would have no access to the private keys.

This could also be used to allow getaddress to work in the client without having to provide a key (access to the TXN data in the wallet means that access to the wallet, even with private key encryption, screws your confidentiality)  which would avoid the problem of backups being endangered due to address depletion from hitting getaddress a lot between entering in the key.

Type two: So this is like running a bank,you have one vault that is enormous. In side of this bank vault are lock boxes. Since the banker knows the  bitcoins needs to go in to the vault(in his big master key wallet which is finite as well), he now knows there are only so many lock boxes inside. But, because you as the receiving hot wallet holder only have the key to the individual lock box("public" key) you wouldn't be able to get it out (that sucks you're stuck there to rot and get arrested).  The vault keycode (the master key) is needed to get out of the vault with money and only the head banker knows what that code it is. However because you know that the lock box goes in to that bank, you use that lock box(once again the lock box is the server receiving the coins). your banker assigns you that lockbox and you use that lock box for all your addresses and funds. and put all your coins in to little  pockets(each address you own is a pocket inside this lock box) every thing is safe sound and secure.  These bank lock boxes are kinda magical though, as i said you can walk in to the vault at any time, you can walk through this vaults walls to put the lock box in the vault. But if someone else steals your lock box key (woopse, i forgot the key in my purse and now my purse was stolen!) they can get your lock box(your receiving server private key) and can sort around in to your lock box, but they don't have the key code to exit the vault with the lock box. So even though a "private" key exists on the remote hot wallet (lock box key you left in your purse) the banker wont give your attacker entry in to the vault because he does not recognize the attacker as the person who the lock box belongs to. So, unless the attacker gets the bankers vault password, they cant get your keycode... BUT remember the bankers keycode works on your lock box. As well as anyone else's. so if the bankers keycode (master key/master seed) is discovered its game over.

So basically you are putting your lock box in a valult. The vault and the lock box each only have finite space. But they both have different keys. As long as your bankers master key is not stolen. no one can really get your money (almost like a two step auth). But rhe banker always knows the keys to his lock boxes even if you forget.

Its kinda inceptionish/matrixy "box in a box", two finger print min, two keys to launch a nuke.... That kinda thing. But not...

Anyway, that is how i understand it. Please let me know if I'm right, wrong, not understandable or what not. I would rather edit an answer than make another

Thanks for your support and kindness. Thanks in advance for the respect of not flaming me


Web servers might be using an export tool to get all the public keys into a database.

The other way, as you mention in the quote, is to create the public keys deterministically with a Master Public Key, that can only derive public keys and not the private key pair, resulting in watch-only wallets.


A simpler approach is this: a private key is always associated with a public key, and normally you need the private key in order to calculate its corresponding public key. However, due to the Elliptic Curve Cryptographic nature of the private and public keys used in Bitcoin, you can perform basic mathematical operations on keys independently on the private and public parts.

For example, suppose you have two private keys P and Q. The public key for P is A, and the public key for Q is B (you'd need P to calculate A, and Q to calculate B).

Now watch this:

  • You can do R = P+n*Q (for any integer n) which results in a new private key R.

  • You can also do C = A+n*B and now C is the public key for R!

So you only need to have public keys A and B on the server, and you can generate infinite public keys like A+n*B, without using any private key. To later calculate the private key (in order to spend the money) you can do P+n*Q on another, independent (possibly offline) environment.


What is probably happening is that the web server is really generating both parts of the pair (public and private) but is immediately discarding the private part without storing it anywhere on the server. Since no private keys are stored on the server (perhaps not even on any computer connected to a network) any attack will not result in private keys being compromised.

However since the the wallet is deterministic, another computer that is offline (not connected to a network) can generate the identical sequence of key pairs. That offline computer is used to actually store the private keys.

Periodically the offline computer could be used to "sweep" all the receiving addresses to consolidate the funds in a single address (also offline) to simplify things. This is done by well known offline transaction generation procedures.

  • 1
    The method you describe is a possible solution to the problem, but represents a security risk (i.e. monitoring memory and capturing keys) and is not used in this case. The Child Public Key is derived from the Parent Public Key. This process uses math beyond my ability to really understand, but if you check out the Child Key Derivation Functions section you will notice that the private key can be derived 2 ways, one from a parent private key and chain code, the other from the public key (and chain code?) – CoinEnablers Oct 17 '13 at 19:15
  • I think that what @CoinEnablers (never heard of those names you mentioned) could be similar to what we know as Master Public Key, that derive the public keys of a deterministic wallet making watch-only wallets. For example, Electrum supports this kind of keys and you can use an addresses generator. – rdymac Oct 18 '13 at 0:52
  • 1
    @RentFree This answer is not correct as the quote says the public keys are derived without knowing their private key pairs. – rdymac Oct 18 '13 at 0:56
  • How would this approach help? Instead of the private keys, an attacker could just take the input data from which the private keys are deterministically generated. There is no difference in security risk between storing actual private keys, or storing data from which you can generate those private keys. – RocketNuts Mar 2 '16 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.