<p>You don't want to be storing any funded keys server side, there's an almost constant steam of hosts being compromised to steal funds. Most Bitcoin systems use something called a "hot wallet", and move the rest onto individual paper wallets outside of the servers control. It's then the administrators role to move funds back and forth to keep the hot wallet funded. This significantly reduces risk, and means that an attacker can gain at most the amount of funds in the hot wallet. </p>

<blockquote>
  <p>Is bitcoind capable of monitoring thousands of addresses in real-time?</p>
</blockquote>

<p>Yes, but you really don't want to be storing anything more than a small hot wallet on a server. If your security isn't perfect then it's just going to be stolen. If it was used to </p>

<blockquote>
  <p>what is the safest method to automatically unlock the wallet, move funds and then lock it again without the password being possibly compromised?</p>
</blockquote>

<p>You can't be sure. Even if the wallet is "encrypted", an attacker can just sit on the server and wait for you to unlock. Again this is why you need to be using offline storage and hot wallets to mitigate the damage of the server being compromised. </p>

<blockquote>
  <p>Will bitcoind generate a new “change address” every time I move funds from the receiving address to payouts and cold storage?</p>
</blockquote>

<p>Yes. This is why all addresses presented to the client are single-use. You make a new receiving address each time for the hot wallet <code>bitcoind</code>, and never show it to the client again. They don't need to, their funds aren't restricted to any particular Bitcoin outputs. Their balance is just an external value in your database that you happen to hold the funds for. </p>

<p>Ideally the setup looks like this: </p>

<p><strong>Server:</strong></p>

<ul>
<li>A <code>bitcoind</code> hot wallet, makes new receiving addresses and presents them to a client. Using <code>walletnotify</code> or <code>blocknotify</code> it updates the received balances for each user to an external database like Postgres or Redis. </li>
<li>A check script makes sure the <code>bitcoind</code> never stores more than 50 BTC in it's wallet, if the balance goes above 50BTC a script runs that generates a new key with a deterministic public key (the server never has to know the private key to do this) or uses a pre-generated list. It sends the excess off to this address to keep it safe.</li>
<li>If the wallet doesn't have the funds to pay a user when they make a withdrawal request, show a soft effort and notify the administrator that the hot wallet needs to be refilled. Explain this is for the protection of the user. </li>
</ul>

<p><strong>Offline:</strong></p>

<ul>
<li><p>An Armory wallet that holds the private keys of the cold wallet. Ideally this would be completely offline, with a paper backup in a safety deposit box. </p></li>
<li><p>The control is only to the administrator, who knows the address of the hot-wallet refill on the server. When needed they move funds back up to the server as per notifications</p></li>
</ul>

<p>Very involved, but it's roughly how other systems work, and it's got to be that way unless you want to end up like <a href="http://inputs.io/">http://inputs.io/</a> who lost an entire 4000 BTC hot wallet due to negligence. You can never be too paranoid in situations like this. Your maximum loss in this case would be the 50BTC hot wallet, which is better than losing everything. </p>

<p>Play safe.</p>

CC BY-SA 3.0
2013-12-10T13:21:21.933Z
I like this solution. However, let's say a hacker is quietly waiting on the server until some client deposits a very large amount, let's say 1000BTC. If the private key to this receiving address was on the server too, the hacker could quickly send the Bitcoins to himself before the check script was able to transfer it to cold storage?
user10507
CC BY-SA 3.0
2013-12-10T13:43:38.353Z
That's a risk that can be mitigated too, and good thinking for realising that it exists. If you only present Armory generated addresses to the users (you can still see their balance without the private key) then large balances will never be in the hot wallet at all, yet you can still tally them with your external database. That's not to say that you should be lax on the hot servers security, a compromise is still a massive issue for all involved, just using a hot-cold system just makes it a little less financially expensive if you are.
Anonymous
CC BY-SA 3.0
2013-12-10T13:46:34.243Z
@user10507 I should mention that I'm extremely glad that you're thinking about this quite carefully. This is more design work than a lot of services seem to have put into their systems. Think maliciously and work to mitigate.
Anonymous
CC BY-SA 3.0
2013-12-10T05:45:37.057Z
2013-12-10T05:45:37.057Z
Anonymous
<blockquote>
  <p>what is the safest method to automatically unlock the wallet, move funds and then lock it again without the password being possibly compromised?</p>
</blockquote>

<p>You want two fundamentally opposed things here, on the one hand you want your wallet accessible to automated processes. On the other hand you don't want it to be available to hackers who compromise the system running said automated processes. Fundamentally you can't have both.</p>

<p>That is why you have a "hot wallet" and a "cold wallet". The hot wallet contains an ammount of bitcoins you can afford to lose. The cold wallet holds bitcoins in long term storage.</p>

<p>On a normal day to day basis money in will usually exceed money out. Your automated system should be designed to move money to the cold wallet if too much builds up in the hot wallet.</p>

<p>Occasionally you may find money out exceeds money in. In this case your system will need to alert you that the hot wallet is running low. You will then need to carefully audit the situation before manually moving money out of the cold wallet.</p>

CC BY-SA 3.0
2016-11-14T15:35:14.913Z
2016-11-14T15:35:14.913Z
Peter Green
<p>Say I want to run a big project, where users can continually request new addresses to deposit Bitcoins in their online account. I suppose I will have to pre-generate thousands of Bitcoin key-pairs and import them into a running instance of bitcoind on my server. Each time a user requests a new address to deposit Bitcoins into his account, I will assign him a new address. Then bitcoind will notify me when any of the imported addresses receive a transaction.</p>

<p>First question: <strong>Is bitcoind capable of monitoring thousands of addresses in real-time?</strong> Should I plan a dedicated machine for this?</p>

<p>Second question: Since I will need to move received Bitcoins to a cold storage and also make payouts automatically many times a day, I will need to store the private keys on the online server as well. I can have wallet.dat password-protected but <strong>what is the safest method to automatically unlock the wallet, move funds and then lock it again without the password being possibly compromised?</strong> I don’t consider it safe if the password appears anywhere in code, config or database. And I don’t want to enter the password manually several times a day.</p>

<p>Third question: <strong>Will bitcoind generate a new “change address” every time I move funds</strong> from the receiving address to payouts and cold storage? I ask because if bitcoind used one of the imported addresses for change, it would appear as if client received Bitcoins.</p>

CC BY-SA 3.0
2014-02-04T13:49:14.003Z
Your question is similar to mine http://bitcoin.stackexchange.com/questions/21496/creating-secure-architecture-and-payout-process. I've read that Cryptsy uses cold wallets, so does it mean that they operates on virtual balances and when payout is made, they move money from cold to how wallet?
spamec
<wallet><bitcoind><address><receiving>
What is the safest method managing a large number of receiving Bitcoin addresses?
user10507
# What is the safest method managing a large number of receiving Bitcoin addresses?

(Asked by: username_0 on 2013-12-09)

Say I want to run a big project, where users can continually request new addresses to deposit Bitcoins in their online account. I suppose I will have to pre-generate thousands of Bitcoin key-pairs and import them into a running instance of bitcoind on my server. Each time a user requests a new address to deposit Bitcoins into his account, I will assign him a new address. Then bitcoind will notify me when any of the imported addresses receive a transaction.

First question: **Is bitcoind capable of monitoring thousands of addresses in real-time?** Should I plan a dedicated machine for this?

Second question: Since I will need to move received Bitcoins to a cold storage and also make payouts automatically many times a day, I will need to store the private keys on the online server as well. I can have wallet.dat password-protected but **what is the safest method to automatically unlock the wallet, move funds and then lock it again without the password being possibly compromised?** I don’t consider it safe if the password appears anywhere in code, config or database. And I don’t want to enter the password manually several times a day.

Third question: **Will bitcoind generate a new “change address” every time I move funds** from the receiving address to payouts and cold storage? I ask because if bitcoind used one of the imported addresses for change, it would appear as if client received Bitcoins.

**Tags:** wallet, bitcoind, address, receiving

> **Comments:**
> **username_1**: Your question is similar to mine http://bitcoin.stackexchange.com/questions/21496/creating-secure-architecture-and-payout-process. I've read that Cryptsy uses cold wallets, so does it mean that they operates on virtual balances and when payout is made, they move money from cold to how wallet?  

---

## 2 answers

### Answer by username_2 on 2013-12-10. Score: 11

You don't want to be storing any funded keys server side, there's an almost constant steam of hosts being compromised to steal funds. Most Bitcoin systems use something called a "hot wallet", and move the rest onto individual paper wallets outside of the servers control. It's then the administrators role to move funds back and forth to keep the hot wallet funded. This significantly reduces risk, and means that an attacker can gain at most the amount of funds in the hot wallet.

> Is bitcoind capable of monitoring thousands of addresses in real-time?

Yes, but you really don't want to be storing anything more than a small hot wallet on a server. If your security isn't perfect then it's just going to be stolen. If it was used to

> what is the safest method to automatically unlock the wallet, move funds and then lock it again without the password being possibly compromised?

You can't be sure. Even if the wallet is "encrypted", an attacker can just sit on the server and wait for you to unlock. Again this is why you need to be using offline storage and hot wallets to mitigate the damage of the server being compromised.

> Will bitcoind generate a new “change address” every time I move funds from the receiving address to payouts and cold storage?

Yes. This is why all addresses presented to the client are single-use. You make a new receiving address each time for the hot wallet `bitcoind`, and never show it to the client again. They don't need to, their funds aren't restricted to any particular Bitcoin outputs. Their balance is just an external value in your database that you happen to hold the funds for.

Ideally the setup looks like this:

**Server:**

* A `bitcoind` hot wallet, makes new receiving addresses and presents them to a client. Using `walletnotify` or `blocknotify` it updates the received balances for each user to an external database like Postgres or Redis.
* A check script makes sure the `bitcoind` never stores more than 50 BTC in it's wallet, if the balance goes above 50BTC a script runs that generates a new key with a deterministic public key (the server never has to know the private key to do this) or uses a pre-generated list. It sends the excess off to this address to keep it safe.
* If the wallet doesn't have the funds to pay a user when they make a withdrawal request, show a soft effort and notify the administrator that the hot wallet needs to be refilled. Explain this is for the protection of the user.

**Offline:**

* An Armory wallet that holds the private keys of the cold wallet. Ideally this would be completely offline, with a paper backup in a safety deposit box.
* The control is only to the administrator, who knows the address of the hot-wallet refill on the server. When needed they move funds back up to the server as per notifications

Very involved, but it's roughly how other systems work, and it's got to be that way unless you want to end up like <http://inputs.io/> who lost an entire 4000 BTC hot wallet due to negligence. You can never be too paranoid in situations like this. Your maximum loss in this case would be the 50BTC hot wallet, which is better than losing everything.

Play safe.

> **Comments:**
> **username_0**: I like this solution. However, let's say a hacker is quietly waiting on the server until some client deposits a very large amount, let's say 1000BTC. If the private key to this receiving address was on the server too, the hacker could quickly send the Bitcoins to himself before the check script was able to transfer it to cold storage?  
> **username_2**: That's a risk that can be mitigated too, and good thinking for realising that it exists. If you only present Armory generated addresses to the users (you can still see their balance without the private key) then large balances will never be in the hot wallet at all, yet you can still tally them with your external database. That's not to say that you should be lax on the hot servers security, a compromise is still a massive issue for all involved, just using a hot-cold system just makes it a little less financially expensive if you are.  
> **username_2**: @username_0 I should mention that I'm extremely glad that you're thinking about this quite carefully. This is more design work than a lot of services seem to have put into their systems. Think maliciously and work to mitigate.  

---

### Answer by username_3 on 2016-11-14. Score: 0

> what is the safest method to automatically unlock the wallet, move funds and then lock it again without the password being possibly compromised?

You want two fundamentally opposed things here, on the one hand you want your wallet accessible to automated processes. On the other hand you don't want it to be available to hackers who compromise the system running said automated processes. Fundamentally you can't have both.

That is why you have a "hot wallet" and a "cold wallet". The hot wallet contains an ammount of bitcoins you can afford to lose. The cold wallet holds bitcoins in long term storage.

On a normal day to day basis money in will usually exceed money out. Your automated system should be designed to move money to the cold wallet if too much builds up in the hot wallet.

Occasionally you may find money out exceeds money in. In this case your system will need to alert you that the hot wallet is running low. You will then need to carefully audit the situation before manually moving money out of the cold wallet.


---

