1. Create a deterministic wallet and a larger number of private keys and associated bitcoin addresses on a safe (e.g. offline) computer.
  2. Backup the seed securely. Store the private keys securely (e.g. on a piece of paper).
  3. Note addresses and send Bitcoins to a number of different addresses. (They are now in cold storage.)
  4. When needed, take one of the private keys and import it from an online wallet (e-wallet, cellphone, etc.) (This includes the risk of the private key getting stolen by malware or the e-wallet operator. However, such a theft would only apply to a small amount, not your total fortune.)

If one private key of a deterministic wallet gets compromised (known to an advisory), are the other keys (and the seed) still secure?

By design, this is not the case for the electrum deterministic wallet and the developers are aware of this. How about other deterministic wallets, e.g. Armory?

  • 1
    Jan, in the comments above/below might have misunderstood why they are doing something that looks like key = seed + hash(sequence). See here for more info: bitcointalk.org/index.php?topic=19137.0 They are basically using a property of ECC keys. The thing outside the hash function is not the seed but a public key when generating public keys and a private key when generating private keys. (note: I don't have commenting karma)
    – Alok
    Commented Apr 28, 2013 at 16:48

5 Answers 5


The proposed standard for hierarchical deterministic wallets (see BIP 32) is designed to allow this (and more).

It is not yet implemented, but several authors of clients have agreed to adopt it, once it becomes final.

  • 2
    Towards the end of your link, they acknowledge "Alan Reiner for the implementation of this scheme in Armory [...]." Does this mean that current versions of Armory do already use this scheme (or something cryptographically equivalent)?
    – Jan
    Commented Jan 11, 2013 at 12:58

Had the same need and could not find easy to use solutions so I ended up rolling my own. I am new to bitcoin and crypto so use with care:



I will assume that you are able to create your own wallet, as you said. Under such circumstance, I would suggest that you follow the logic below.

First of all, let's suppose that someone has coded (as blockchain website released some tools into their API section) a software able to create bitcoin addresses for external users. In such a scenario, if the algorithms contained in such software, hosted in a server, can create a multi-signature wallet for the users, in the meaning that certain user would need both private keys (2 keys per each address) created by the software in order to spend the coins from such a single-address wallet, and if for example the server keeps the private key A and deliver to the user the private key B, then we would have the situation of a "hybrid online wallet" where only the user can use both keys, A + B, in order to create, sign and broadcast transactions related to his bitcoin address. I speak here about the case where only the user is allowed to proceed in order to spend coins.

Such a system would be pretty secure for the user if the software owner would have no knowledge or interaction with private key A (or B) and if the encryption used before storing that private key A would make useless to any third party (even if reaching there) any access to that stored key from the server's database.

Now, on the other hand, the sole way to construct a transaction and to sign it with both private keys might take place only in the server (this being a very important condition, as I will explain later in this scenario).

If the software owner is willing to let the users to leave the server with both keys (for example, just to delete their accounts and establish such addresses as some truly cold wallets), he might employ two options.

One would be to release directly to the user the private key A, thus empowering him to use elsewhere (if and when needed) the keys A and B for signing transactions, or the other (somehow better one) in which the algorithm allow to create a third key, the C key, which could be used in conjunction with key B in order to spend coins from that address. In other words, the user leaves again with two private keys in his pocket, enough for him to use them for depleting the corresponding address (public key). That can be realized either by using a seed (certain "D" private key), unique to the server (or to the user account), or establishing as seed even the key A. If the key A is used as a seed, then practically anyone with access to the source code of software could replicate the entire range of addresses created for the specific user (if the key A is "user-account-specific" and not "address-specific"). I see the last one as impossible to be used by any decent sysadmin (if he has the smallest idea about the risks incurred in such a low level security choice). So let's assume the server creates seeds with higher privileges (aka user-specific). That, again, could have catastrophic consequences for any careless user that would import that key A into any wallet from a device infected with malware. (Maybe that reminds us somehow of the Electrum wallet ? :/ ...)

The last option available which stands is that where the server has an own seed key (with highest privileges) which cannot be accessed by any third party, and that combined with at least another one (server protected with multi-signature, too).

Back to your situation, you should have the key B offering elevated privileges (enabling you to create keys D, and further, but anyone using the D to not be able to create other keys). Because, though, such thing would be a burden to code, I would suggest some simpler option : the one way - one size shot - transaction. Which means that you import in any wallet of your choice the keys after some sweet cleaning of the basic functions. As once said Henry Ford about his cars "you can order any color, as time as it is just black".

The imported address, wherever be it stored, might be coded such as to make possible one single operation: send a payment of precise amount solely toward another address X of you (for example, only can send each time about 0.1 BTC toward your hot wallet -- pocket money). Need something more ? Another fixed tranche of 0.100 BTC, toward the same address. Just that. A perfect tweak. Of course, the X address might be stored in a hardware wallet, fully secure. Other kinds of spending might be made possible only using the server itself (as to unlock the full control over the address balance).


It all depends on how your deterministic wallet was created, if it's somthing hash based it would be secure. What you need is that it is impossible to discover the seed with the actual private keys, so it must use an one way function (i.e. hash function).

And in general compromising a private key in a wallet does not comprise the rest of the wallet.

  • That's what I was thinking. However, after reading the electrum source code, I realized that you have to be wary: They use something like KEY = SEED + HASH(sequence), making it possible in some circumstances to calculate SEED.
    – Jan
    Commented Jan 11, 2013 at 9:29
  • 1
    Just an idea: would KEY=HASH(SEED + offset) work also? That way neither SEED nor the other addresses would be guessable.
    – cdecker
    Commented Jan 11, 2013 at 11:45
  • @cdecker I would think so, but don't take my word for it. Better implement a scheme that has been reviewed by cryptography experts.
    – Jan
    Commented Jan 11, 2013 at 13:00
  • @cdecker Yes this is something that would be secure because you hash the seed along with another parameter, thus changing the whole resultant hash.
    – Gopoi
    Commented Jan 11, 2013 at 22:57
  • 1
    @Jan If electrum use this way I would not recommend it for any use the seed is compromised in all the private key which is awful from my consideration.
    – Gopoi
    Commented Jan 11, 2013 at 22:59

Armory wallet allows this, and it doesn't compromise the security of the wallet at all. It does compromise the integrity of your backups tho. Deterministic wallets are useful because you can make a single backup right at the start (before using it) and it will be a good backup forever.

That is, unless you import addresses from somewhere else. Those new addresses won't be in your old backup, so you have to make a new backup at that point.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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