<p>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:</p>

<p><a href="https://github.com/pavlos-christoforou/bitcoin" rel="nofollow">https://github.com/pavlos-christoforou/bitcoin</a></p>

CC BY-SA 3.0
2013-03-20T23:05:41.803Z
2013-03-20T23:05:41.803Z
Pavlos
<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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).</p>

<p>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.</p>

<p>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 ? :/ ...)</p>

<p>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).</p>

<p>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".</p>

<p>The imported address, wherever be it stored, might be coded such as to <i>make possible one single operation</i>: 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).</p>

CC BY-SA 3.0
2014-09-20T03:03:09.247Z
2014-09-20T03:09:17.663Z
2014-09-20T03:09:17.663Z
Bit-Crowd
<p>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).</p>

<p>And in general compromising a private key in a wallet does not comprise the rest of the wallet.</p>

CC BY-SA 3.0
2013-01-11T09:29:50.673Z
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
CC BY-SA 3.0
2013-01-11T11:45:35.587Z
Just an idea: would `KEY=HASH(SEED + offset)` work also? That way neither `SEED` nor the other addresses would be guessable.
cdecker
CC BY-SA 3.0
2013-01-11T13:00:01.720Z
@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
CC BY-SA 3.0
2013-01-11T22:57:19.510Z
@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
CC BY-SA 3.0
2013-01-11T22:59:23.593Z
@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
CC BY-SA 3.0
2013-01-11T02:40:07.530Z
2013-01-11T02:40:07.530Z
Gopoi
<p>Armory wallet allows this, and it doesn't compromise the security of the wallet at all. It <em>does</em> 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.</p>

<p>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. </p>

CC BY-SA 3.0
2014-09-17T20:30:25.657Z
2014-09-17T20:30:25.657Z
B T
<p>The proposed standard for hierarchical deterministic wallets (see <a href="https://en.bitcoin.it/wiki/BIP_0032">BIP 32</a>) is designed to allow this (and more).</p>

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

CC BY-SA 3.0
2013-01-11T12:58:44.017Z
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
CC BY-SA 3.0
2013-01-11T12:10:37.823Z
2013-01-11T12:10:37.823Z
Pieter Wuille
<p>Scenario:</p>

<ol>
<li>Create a deterministic wallet and a larger number of private keys and associated bitcoin addresses on a safe (e.g. offline) computer.</li>
<li>Backup the seed securely. Store the private keys securely (e.g. on a piece of paper). </li>
<li>Note addresses and send Bitcoins to a number of different addresses. (They are now in cold storage.)</li>
<li>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.)</li>
</ol>

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

<p>By design, this is not the case for the <a href="https://github.com/spesmilo/electrum/blob/45c0880195d2013d7cf64d7d683eb771f9d27a7b/electrum#L282" rel="noreferrer">electrum</a> deterministic wallet and the developers are aware of this. How about other deterministic wallets, e.g. Armory?</p>

CC BY-SA 3.0
2013-04-28T16:48:52.543Z
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: https://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
<wallet><security><private-key>
Can I create a deterministic wallet and export/disclose indiviual keys without compromising the wallet?
Jan
# Can I create a deterministic wallet and export/disclose indiviual keys without compromising the wallet?

(Asked by: username_0 on 2013-01-10)

Scenario:

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](https://github.com/spesmilo/electrum/blob/45c0880195d2013d7cf64d7d683eb771f9d27a7b/electrum#L282) deterministic wallet and the developers are aware of this. How about other deterministic wallets, e.g. Armory?

**Tags:** wallet, security, private-key

> **Comments:**
> **username_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: https://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)  

---

## 5 answers

### Answer by username_7 on 2013-01-11. Score: 8 | Accepted answer

The proposed standard for hierarchical deterministic wallets (see [BIP 32](https://en.bitcoin.it/wiki/BIP_0032)) 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.

> **Comments:**
> **username_0**: 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)?  

---

### Answer by username_2 on 2013-03-20. Score: 3

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:

<https://github.com/username_2-christoforou/bitcoin>


---

### Answer by username_3 on 2014-09-20. Score: 1

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).


---

### Answer by username_4 on 2013-01-11. Score: 0

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.

> **Comments:**
> **username_0**: 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.  
> **username_5**: Just an idea: would `KEY=HASH(SEED + offset)` work also? That way neither `SEED` nor the other addresses would be guessable.  
> **username_0**: @username_5 I would think so, but don't take my word for it. Better implement a scheme that has been reviewed by cryptography experts.  
> **username_4**: @username_5 Yes this is something that would be secure because you hash the seed along with another parameter, thus changing the whole resultant hash.  
> **username_4**: @username_0 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.  

---

### Answer by username_6 on 2014-09-17. Score: 0

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.


---

