<p>If you only need receiving addresses, then you need only a table for those along with a column that flags to prevent it from from being used a second time.</p>

<p>Keys can be generated in bulk:
 - <a href="http://bitcointalk.org/index.php?topic=101708.0" rel="nofollow">http://bitcointalk.org/index.php?topic=101708.0</a></p>

<p>Now just because you aren't saving the private key on the web host doesn't mean security can be lax.  If a host were compromised, the attacker could replace the Bitcoin addresses in the table with addresses under the control of the attacker.</p>

<p>For situations where the Bitcoin client needs to send transactions, a cold wallet / hot wallet method will help lessen the damage should  the system become compromised. </p>

<p>Here's additional information for Securing online services:</p>

<ul>
<li><a href="http://en.bitcoin.it/wiki/Securing_online_services" rel="nofollow">http://en.bitcoin.it/wiki/Securing_online_services</a></li>
</ul>

CC BY-SA 3.0
2012-08-26T07:44:40.003Z
2012-08-26T07:44:40.003Z
Stephen Gornick
<p>Generally, the public keys are generated from a public generator and the private keys are generated from the corresponding private generator, stored on a highly-secure machine. No communication is permitted to the machine holding the private generator.</p>

<p>You do have to know that Bitcoin keys can be generated by generators. The public generator generates a series of public keys and addresses while the corresponding private generator generates the corresponding series of private keys. There is no way to determine the private generator given the public generator.</p>

<p>The flow goes like this:</p>

<ol>
<li><p>A new public address is needed.</p></li>
<li><p>The next public address is assigned, using the public generator.</p></li>
<li><p>The machine holding the private generator is already watching every payment and will detect any payment to a key generatable from its private generator.</p></li>
<li><p>When a deposit is made, the private generator machine detects the deposit and issues a transaction to transfer the funds to an appropriate hot or cold wallet. (Or waits until the hot wallet is low, or whatever it's programmed to do.)</p></li>
<li><p>The regular machine also notices the deposit (because it knows the public keys) and credits the user.</p></li>
</ol>

<p>The math is (oversimplified!):</p>

<p>Private generator: <strong>P</strong> (a random 256-bit number)<br>
Public generator: <strong>GxP</strong> (P times the generator constant, an EC point)<br>
Account ID: <strong>I</strong> (an incrementing number)<br>
Account public key: <strong>GxHash(I) + GxP</strong> (EC point)<br>
Account private key: <strong>P+Hash(I)</strong> (256-bit number)<br></p>

<p>This works because <strong>Gx(P + Hash(i))</strong> = <strong>GxHash(I) + GxP</strong><br>
So the account private key is the private key corresponding to the account public key. The account public key can be generated from the account ID and the public generator. The account private key can be generated from the account ID and the private generator. No private keys can be generated without the private generator.</p>

CC BY-SA 3.0
2012-08-27T05:28:46.493Z
2012-08-27T05:34:17.190Z
2012-08-27T05:34:17.190Z
David Schwartz
<p>Most web apps that accept bitcoin (whether it's an exchange, a gambling site, etc) provide the user with a public address for depositing bitcoins into their account.</p>

<p>How are these web applications storing the private key associated with the deposit address? What is the best practise for the storage of the private keys from a security standpoint? What is the best storage procedure for web developers looking to create large quantities of key pairs for their web applications?</p>

<private-key><public-key><ecdsa><database>
Storage of Private Keys
Jordan Arsenault
# Storage of Private Keys

(Asked by: username_0 on 2012-08-26)

Most web apps that accept bitcoin (whether it's an exchange, a gambling site, etc) provide the user with a public address for depositing bitcoins into their account.

How are these web applications storing the private key associated with the deposit address? What is the best practise for the storage of the private keys from a security standpoint? What is the best storage procedure for web developers looking to create large quantities of key pairs for their web applications?

**Tags:** private-key, public-key, ecdsa, database


---

## 2 answers

### Answer by username_1 on 2012-08-26. Score: 3 | Accepted answer

If you only need receiving addresses, then you need only a table for those along with a column that flags to prevent it from from being used a second time.

Keys can be generated in bulk:
- <http://bitcointalk.org/index.php?topic=101708.0>

Now just because you aren't saving the private key on the web host doesn't mean security can be lax. If a host were compromised, the attacker could replace the Bitcoin addresses in the table with addresses under the control of the attacker.

For situations where the Bitcoin client needs to send transactions, a cold wallet / hot wallet method will help lessen the damage should the system become compromised.

Here's additional information for Securing online services:

* <http://en.bitcoin.it/wiki/Securing_online_services>


---

### Answer by username_2 on 2012-08-27. Score: 1

Generally, the public keys are generated from a public generator and the private keys are generated from the corresponding private generator, stored on a highly-secure machine. No communication is permitted to the machine holding the private generator.

You do have to know that Bitcoin keys can be generated by generators. The public generator generates a series of public keys and addresses while the corresponding private generator generates the corresponding series of private keys. There is no way to determine the private generator given the public generator.

The flow goes like this:

1. A new public address is needed.
2. The next public address is assigned, using the public generator.
3. The machine holding the private generator is already watching every payment and will detect any payment to a key generatable from its private generator.
4. When a deposit is made, the private generator machine detects the deposit and issues a transaction to transfer the funds to an appropriate hot or cold wallet. (Or waits until the hot wallet is low, or whatever it's programmed to do.)
5. The regular machine also notices the deposit (because it knows the public keys) and credits the user.

The math is (oversimplified!):

Private generator: **P** (a random 256-bit number)  
Public generator: **GxP** (P times the generator constant, an EC point)  
Account ID: **I** (an incrementing number)  
Account public key: **GxHash(I) + GxP** (EC point)  
Account private key: **P+Hash(I)** (256-bit number)

This works because **Gx(P + Hash(i))** = **GxHash(I) + GxP**  
So the account private key is the private key corresponding to the account public key. The account public key can be generated from the account ID and the public generator. The account private key can be generated from the account ID and the private generator. No private keys can be generated without the private generator.


---

