<p>You should generate the keys in a secured environment and then move only the public parts to the server which you don't trust. Keep the private ones secured - you need these for spending.</p>

CC BY-SA 3.0
2013-03-05T16:15:14.473Z
This doesn't allow the insecure server to generate an arbitrary number of addresses without communication with the secure server.
Meni Rosenfeld
CC BY-SA 3.0
2013-03-05T16:03:15.887Z
2013-03-05T16:03:15.887Z
Gigi
<p>Electrum seedless wallets for a desktop <a href="http://electrum.org" rel="nofollow">http://electrum.org</a> and Electrum POS system for servers <a href="https://github.com/kangasbros/electrumpos" rel="nofollow">https://github.com/kangasbros/electrumpos</a></p>

<p>For desktop is really easy to setup, just restore from your Master Public Key and you'll get a seedless wallet without private keys but with the privilege of creating new addresses.</p>

<p>For servers you need to install Electrum pos system, see it in action here <a href="http://acceptbit.com" rel="nofollow">http://acceptbit.com</a></p>

CC BY-SA 3.0
2013-03-06T02:29:10.953Z
2013-03-06T02:29:10.953Z
rdymac
<p>Multisig can be used for it, but is overkill and requires P2SH to be usable as phrased.</p>

<p>What you do need has been sometimes referred to as "EC magic". Both private keys and public keys are a sort of numbers which can be added, and the public key corresponding to the sum of private keys is the sum of public keys.</p>

<p>So in the secure server you'll have a private key d1. The insecure server will have the corresponding public key P1, and for every customer it will generate a private key d2 and corresponding P2. The public key is P1+P2; d2 can be sent to the secure server, which will calculate the private key d1+d2.</p>

<p>Schemes based on multiplication rather than addition are also possible.</p>

CC BY-SA 3.0
2013-03-06T07:23:44.600Z
This is the right way to do this. It works because EC's private key to public key conversion behaves like multiplication and `G(X + Y) = G(X) + G(Y)`. So given `G(X)`, but not `X`, you can pick a random `Y`, and calculate `G(X) + G(Y)` (which is also `G(X+Y)` and thus a public key) but not `X + Y` (the corresponding private key). If you store `Y` and `G(X+Y)`, you have a public key and enough information to compute the private key only if given `X` (which you store on another machine). (Ripple's [account families](https://ripple.com/wiki/Account_Family) work this way.)
David Schwartz
CC BY-SA 3.0
2013-03-05T16:14:26.313Z
2013-03-05T16:14:26.313Z
Meni Rosenfeld
<p>I believe multisig can be used to implement this - keep only one part of the pair on the system, and use it to generate addresses. I don't know whether multisig support exists in the popular packages implementing bitcoin, but it's one direction that would work.</p>

<p>You'll only be able to spend them using both keys, which are stored only on the secure system.</p>

CC BY-SA 3.0
2013-03-05T11:18:34.673Z
2013-03-05T15:16:36.297Z
2013-03-05T15:16:36.297Z
ripper234
<p>Armory enables exactly what you're looking to do with its Watching Wallet.  Because of its deterministic nature, you can generate unlimited public keys which you can assign to each customer while the private keys sit safely on an offline computer somewhere.</p>

CC BY-SA 3.0
2013-03-07T02:04:56.273Z
2013-03-07T02:04:56.273Z
joe
<p>You can play with BIP32 here:
<a href="http://bip32.org/" rel="nofollow noreferrer">http://bip32.org/</a>
With Bitcoin Master Private Key you can generate Derived Private Key(s) and Derived Public Key(s). With Derived Public Key you can generate Bitcoin addresses. With Derived Private Key you can later generate private keys to move Bitcoin from those addresses.</p>

CC BY-SA 4.0
2021-11-13T08:47:56.667Z
2021-11-13T08:47:56.667Z
user2594042
<p><strong>Yes</strong></p>

<p>I love how all the upvoted answers talk about multisig or electrum but the one answer that mentions HD wallets is at -1. </p>

<p>HD wallets allow you to do this. </p>

<p><strong>TL;DR</strong> Derivations per level on an HD wallet use 3 portions in 2 different hashes. 1 hash requires the parent public key and parent chain code (summed together creating the parent extended public key) and the other hash requires the parent private key and the left half of the output of the 1st hash. </p>

<p>Confused? The diagram at the bottom oughta help. At the end of the day, the private keys used to sign are derived from the chain of private keys all the way from the ECDSA key. If you only derive from the extended public key (public key + chain code) then you can derive as many addresses as your heart desires without giving up the private key. Minus the chain code and you're unable to generate many addresses (chain code gives up privacy AKA ability to derive many valid addresses)</p>

<p><a href="https://i.sstatic.net/Q7wjz.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Q7wjz.jpg" alt="enter image description here"></a></p>

CC BY-SA 4.0
2018-08-17T15:19:55.050Z
Indeed! This is the best answer.
ripper234
CC BY-SA 4.0
2018-08-16T15:13:19.427Z
2018-08-16T15:13:19.427Z
arshbot
<p>Suppose you have a possibly compromised system, which you do not trust enough to stores your private keys on.</p>

<p>Is there some process where you can generate unique bitcoin addresses within the system, that does not contain a private key?</p>

<p>To clarify:</p>

<p>You have a web server that clients use to make orders. You want to create a unique bitcoin address per purchase. In addition, you don't want the server to contain your bitcoin private keys - an attacker gaining access to the server shouldn't be able to touch your bitcoins.</p>

CC BY-SA 3.0
2013-03-05T13:05:27.053Z
I've no idea what are you talking about.
o0'.
CC BY-SA 3.0
2013-03-05T14:20:00.493Z
@Lohoris - I was missing the word "without" in the title. Added clarification in the question body.
ripper234
CC BY-SA 3.0
2013-03-05T14:54:32.777Z
Much better now, I'd like to have an answer too.
o0'.
CC BY-SA 3.0
2013-03-05T15:07:39.887Z
@Lohoris - I think my answer is not bad, but I open to other suggestions.
ripper234
CC BY-SA 3.0
2013-03-05T15:11:07.110Z
I was doubtful since you said "I guess", and I was waiting for someone to eventually confirm it can be done, as you guessed ;)
o0'.
<address>
Can you generate bitcoin addresses without storing a private key?
ripper234
# Can you generate bitcoin addresses without storing a private key?

(Asked by: username_0 on 2013-03-05)

Suppose you have a possibly compromised system, which you do not trust enough to stores your private keys on.

Is there some process where you can generate unique bitcoin addresses within the system, that does not contain a private key?

To clarify:

You have a web server that clients use to make orders. You want to create a unique bitcoin address per purchase. In addition, you don't want the server to contain your bitcoin private keys - an attacker gaining access to the server shouldn't be able to touch your bitcoins.

**Tags:** address

> **Comments:**
> **username_1**: I've no idea what are you talking about.  
> **username_0**: @Lohoris - I was missing the word "without" in the title. Added clarification in the question body.  
> **username_1**: Much better now, I'd like to have an answer too.  
> **username_0**: @Lohoris - I think my answer is not bad, but I open to other suggestions.  
> **username_1**: I was doubtful since you said "I guess", and I was waiting for someone to eventually confirm it can be done, as you guessed ;)  

---

## 7 answers

### Answer by username_8 on 2018-08-16. Score: 4 | Accepted answer

**Yes**

I love how all the upvoted answers talk about multisig or electrum but the one answer that mentions HD wallets is at -1.

HD wallets allow you to do this.

**TL;DR** Derivations per level on an HD wallet use 3 portions in 2 different hashes. 1 hash requires the parent public key and parent chain code (summed together creating the parent extended public key) and the other hash requires the parent private key and the left half of the output of the 1st hash.

Confused? The diagram at the bottom oughta help. At the end of the day, the private keys used to sign are derived from the chain of private keys all the way from the ECDSA key. If you only derive from the extended public key (public key + chain code) then you can derive as many addresses as your heart desires without giving up the private key. Minus the chain code and you're unable to generate many addresses (chain code gives up privacy AKA ability to derive many valid addresses)

[![enter image description here](https://i.sstatic.net/Q7wjz.jpg)](https://i.sstatic.net/Q7wjz.jpg)

> **Comments:**
> **username_0**: Indeed! This is the best answer.  

---

### Answer by username_2 on 2013-03-05. Score: 2

You should generate the keys in a secured environment and then move only the public parts to the server which you don't trust. Keep the private ones secured - you need these for spending.

> **Comments:**
> **username_3**: This doesn't allow the insecure server to generate an arbitrary number of addresses without communication with the secure server.  

---

### Answer by username_4 on 2013-03-06. Score: 2

Electrum seedless wallets for a desktop <http://electrum.org> and Electrum POS system for servers <https://github.com/kangasbros/electrumpos>

For desktop is really easy to setup, just restore from your Master Public Key and you'll get a seedless wallet without private keys but with the privilege of creating new addresses.

For servers you need to install Electrum pos system, see it in action here <http://acceptbit.com>


---

### Answer by username_3 on 2013-03-05. Score: 2

Multisig can be used for it, but is overkill and requires P2SH to be usable as phrased.

What you do need has been sometimes referred to as "EC magic". Both private keys and public keys are a sort of numbers which can be added, and the public key corresponding to the sum of private keys is the sum of public keys.

So in the secure server you'll have a private key d1. The insecure server will have the corresponding public key P1, and for every customer it will generate a private key d2 and corresponding P2. The public key is P1+P2; d2 can be sent to the secure server, which will calculate the private key d1+d2.

Schemes based on multiplication rather than addition are also possible.

> **Comments:**
> **username_5**: This is the right way to do this. It works because EC's private key to public key conversion behaves like multiplication and `G(X + Y) = G(X) + G(Y)`. So given `G(X)`, but not `X`, you can pick a random `Y`, and calculate `G(X) + G(Y)` (which is also `G(X+Y)` and thus a public key) but not `X + Y` (the corresponding private key). If you store `Y` and `G(X+Y)`, you have a public key and enough information to compute the private key only if given `X` (which you store on another machine). (Ripple's [account families](https://ripple.com/wiki/Account_Family) work this way.)  

---

### Answer by username_0 on 2013-03-05. Score: 0

I believe multisig can be used to implement this - keep only one part of the pair on the system, and use it to generate addresses. I don't know whether multisig support exists in the popular packages implementing bitcoin, but it's one direction that would work.

You'll only be able to spend them using both keys, which are stored only on the secure system.


---

### Answer by username_6 on 2013-03-07. Score: 0

Armory enables exactly what you're looking to do with its Watching Wallet. Because of its deterministic nature, you can generate unlimited public keys which you can assign to each customer while the private keys sit safely on an offline computer somewhere.


---

### Answer by username_7 on 2021-11-13. Score: 0

You can play with BIP32 here:
<http://bip32.org/>
With Bitcoin Master Private Key you can generate Derived Private Key(s) and Derived Public Key(s). With Derived Public Key you can generate Bitcoin addresses. With Derived Private Key you can later generate private keys to move Bitcoin from those addresses.


---

