<p>I hate to be this guy but if you're struggling with this chances are that you'll struggle to secure the private keys. Those private keys are the keys to your empire in a way you don't even want to think about.</p>

<p>Think very seriously about outsourcing this to a company with insurance for it. Or get insurance yourself. The outsourcing also takes the performance hassle away from you.</p>

<p>If you don't, please don't forget to make (really) cold wallets. Just place that cash elsewhere.</p>

<p>Perhaps more directly, there's several bitcoin daemons out there. You could make your own, too, with something like bitcoinJ. I met the guys behind btcd ("BitcoinD in Go") <a href="https://github.com/conformal/btcd" rel="nofollow">https://github.com/conformal/btcd</a> at Bitcoin2014, their lead coder made a good impression.</p>

<p>I'm afraid there's no shelved answer for this question yet. Perhaps the best advice is "Do it, once you run into trouble you're successful already. Time enough to solve it later.".</p>

CC BY-SA 3.0
2014-06-22T19:00:51.073Z
2014-06-22T19:00:51.073Z
Lodewijk
<p>There were a few more suggestions on an answer to this related question: <a href="https://bitcoin.stackexchange.com/questions/20558/howto-scale-thousands-of-bitcoin-accounts-properly-with-bitcoind-deamon?rq=1">Howto scale thousands of bitcoin accounts properly with bitcoind deamon?</a></p>

<p>Someone has already created a wrapper for the bitcoin daemon in Java: <a href="https://github.com/btc4j/btc4j-daemon" rel="nofollow noreferrer">https://github.com/btc4j/btc4j-daemon</a> - it might be easier to use that instead of the dameon directly and use a database to do what would be inefficient on the blockchain, like handling user accounts.</p>

<p>Ultimately, it all depends on what you're trying to accomplish.  It sounds pretty clear from what you've already read and what I've read that the standard bitcoin daemon doesn't scale.  Thus, your best bet would be to use this or another bitcoin daemon wrapper to create your wallet project.  </p>

<p>If you want to interface directly with the bitcoin daemon (or as close to directly as possible with a wrapper), try using the Java wrapper and use a database for the tasks that the daemon doesn't handle efficiently.  However, if you are wanting to design your online wallet service with security in mind, I would encourage you to use the Armory daemon: <a href="https://bitcointalk.org/index.php?topic=92496.0" rel="nofollow noreferrer">https://bitcointalk.org/index.php?topic=92496.0</a>.  From what I've read, it sounds like this daemon is not quite as full featured as the regular bitcoin daemon, but I haven't tried it out myself, so it's quite possible that it is sufficient to your needs.  Still, it has a pretty big advantage in the realm of security that you can create a watching-only wallet on your web server for the customers' wallet.  </p>

CC BY-SA 3.0
2014-06-22T07:46:05.087Z
2014-06-22T07:46:05.087Z
2017-04-13T12:47:34.187Z
Evan Lynch
<p>I would like to build an online wallet service. I thinks it will be easy to implement all the functionalities if I go with Bitcoind. Here is a possible workflow:</p>

<ol>
<li><p>New user with email <code>bob@g.com</code> can obtain a new account (in Bitcoind) with new address by calling <code>getnewaddress bob@g.com</code></p></li>
<li><p>We can then start polling <code>listsinceblock xxx</code> to get all new transactions. If we receive a new incoming transaction, store <code>txid</code> in database, then iteratively call <code>gettransaction txid</code> on all unconfirmed transactions. When the number of confirmations are bigger than a certain threshold, credit the account in database, then call <code>move bob@g.com safe</code>, just to make the next step easier.</p></li>
<li><p>When <code>safe</code> account exceeds say 50BTC, send them to offline wallet.</p></li>
<li><p>When user wants to withdraw, refill <code>safe</code> if necessary, send the coins from <code>safe</code>, and update user's balance in the database.</p></li>
</ol>

<p>However, in all the related questions I've read, most people say Bitcoind won't scale. Even the Bitcoin wiki says so. Now, if we are only to use the JSONRPC to interface the network, I can imagine the following workflow:</p>

<ol>
<li><p>We generate say 1M addresses in database. When user signs up or require new address, we assign one address to them.</p></li>
<li><p>We enable <code>blocknotify</code> to get new block hash <code>blkhash</code>.</p></li>
<li><p>Call <code>getblock blkhash</code> to get all transaction hashes in the new block.</p></li>
<li><p>Call <code>getrawtransaction txid</code> to see whether we received an incoming transaction to our addresses. If so, keep the <code>txid</code> and keep polling <code>gettransaction txid</code> to update the confirmation number.</p></li>
<li><p>Call <code>signrawtransaction</code>, <code>sendrawtransaction</code> to move funds to offline wallet.</p></li>
</ol>

<p>My questions are, </p>

<ul>
<li>Do you think my proposals are reasonable?</li>
<li><p>What are the nuances in the operations above? For example, </p>

<ul>
<li>by moving all funds to one account and then send money, does that count as one transaction or one transaction for each account? Are transaction fees the same?</li>
<li>when doing <code>getrawtransaction</code>, in the <code>vout</code> array, each object represents a destination, but each of them has an <code>addresses</code> array. There are cases where it contains multiple addresses. Does it mean it's a "multisig" transaction? Or is it related to <code>reqSigs</code> field? How do we handle such cases?</li>
</ul></li>
</ul>

<p>I've read following questions, but didn't find my answer: </p>

<p><a href="https://bitcoin.stackexchange.com/questions/19567/does-the-original-bitcoin-client-scale-to-contain-millions-of-addresses">Does the original Bitcoin client scale to contain millions of addresses?</a></p>

<p><a href="https://bitcoin.stackexchange.com/questions/17423/bitcoin-client-api-rpc-efficient-way-to-list-transactions-from-a-list-of-addres">Bitcoin Client API-RPC: Efficient way to list transactions from a list of addresses</a></p>

<p>Please help.. Thank you very much!</p>

CC BY-SA 3.0
2014-06-22T19:59:16.753Z
It's very hard to answer something as broad as the questions you mention. It's mostly more of a software engineering thing than a Bitcoin thing, too. So I answered your question as I see it apply to Bitcoin and Bitcoin software. Most notably make sure your "safe" account can only be transferred from by a human being, and that it is on a separate machine that is usually offline and tightly firewalled.
Lodewijk
<transactions><bitcoind><scalability>
Build an online wallet service with Bitcoind, can it scale? If not, what can be done?
zfei
# Build an online wallet service with Bitcoind, can it scale? If not, what can be done?

(Asked by: username_0 on 2014-01-20)

I would like to build an online wallet service. I thinks it will be easy to implement all the functionalities if I go with Bitcoind. Here is a possible workflow:

1. New user with email `bob@g.com` can obtain a new account (in Bitcoind) with new address by calling `getnewaddress bob@g.com`
2. We can then start polling `listsinceblock xxx` to get all new transactions. If we receive a new incoming transaction, store `txid` in database, then iteratively call `gettransaction txid` on all unconfirmed transactions. When the number of confirmations are bigger than a certain threshold, credit the account in database, then call `move bob@g.com safe`, just to make the next step easier.
3. When `safe` account exceeds say 50BTC, send them to offline wallet.
4. When user wants to withdraw, refill `safe` if necessary, send the coins from `safe`, and update user's balance in the database.

However, in all the related questions I've read, most people say Bitcoind won't scale. Even the Bitcoin wiki says so. Now, if we are only to use the JSONRPC to interface the network, I can imagine the following workflow:

1. We generate say 1M addresses in database. When user signs up or require new address, we assign one address to them.
2. We enable `blocknotify` to get new block hash `blkhash`.
3. Call `getblock blkhash` to get all transaction hashes in the new block.
4. Call `getrawtransaction txid` to see whether we received an incoming transaction to our addresses. If so, keep the `txid` and keep polling `gettransaction txid` to update the confirmation number.
5. Call `signrawtransaction`, `sendrawtransaction` to move funds to offline wallet.

My questions are,

* Do you think my proposals are reasonable?
* What are the nuances in the operations above? For example,

  + by moving all funds to one account and then send money, does that count as one transaction or one transaction for each account? Are transaction fees the same?
  + when doing `getrawtransaction`, in the `vout` array, each object represents a destination, but each of them has an `addresses` array. There are cases where it contains multiple addresses. Does it mean it's a "multisig" transaction? Or is it related to `reqSigs` field? How do we handle such cases?

I've read following questions, but didn't find my answer:

[Does the original Bitcoin client scale to contain millions of addresses?](https://bitcoin.stackexchange.com/questions/19567/does-the-original-bitcoin-client-scale-to-contain-millions-of-addresses)

[Bitcoin Client API-RPC: Efficient way to list transactions from a list of addresses](https://bitcoin.stackexchange.com/questions/17423/bitcoin-client-api-rpc-efficient-way-to-list-transactions-from-a-list-of-addres)

Please help.. Thank you very much!

**Tags:** transactions, bitcoind, scalability

> **Comments:**
> **username_1**: It's very hard to answer something as broad as the questions you mention. It's mostly more of a software engineering thing than a Bitcoin thing, too. So I answered your question as I see it apply to Bitcoin and Bitcoin software. Most notably make sure your "safe" account can only be transferred from by a human being, and that it is on a separate machine that is usually offline and tightly firewalled.  

---

## 2 answers

### Answer by username_1 on 2014-06-22. Score: 2

I hate to be this guy but if you're struggling with this chances are that you'll struggle to secure the private keys. Those private keys are the keys to your empire in a way you don't even want to think about.

Think very seriously about outsourcing this to a company with insurance for it. Or get insurance yourself. The outsourcing also takes the performance hassle away from you.

If you don't, please don't forget to make (really) cold wallets. Just place that cash elsewhere.

Perhaps more directly, there's several bitcoin daemons out there. You could make your own, too, with something like bitcoinJ. I met the guys behind btcd ("BitcoinD in Go") <https://github.com/conformal/btcd> at Bitcoin2014, their lead coder made a good impression.

I'm afraid there's no shelved answer for this question yet. Perhaps the best advice is "Do it, once you run into trouble you're successful already. Time enough to solve it later.".


---

### Answer by username_2 on 2014-06-22. Score: 1

There were a few more suggestions on an answer to this related question: [Howto scale thousands of bitcoin accounts properly with bitcoind deamon?](https://bitcoin.stackexchange.com/questions/20558/howto-scale-thousands-of-bitcoin-accounts-properly-with-bitcoind-deamon?rq=1)

Someone has already created a wrapper for the bitcoin daemon in Java: <https://github.com/btc4j/btc4j-daemon> - it might be easier to use that instead of the dameon directly and use a database to do what would be inefficient on the blockchain, like handling user accounts.

Ultimately, it all depends on what you're trying to accomplish. It sounds pretty clear from what you've already read and what I've read that the standard bitcoin daemon doesn't scale. Thus, your best bet would be to use this or another bitcoin daemon wrapper to create your wallet project.

If you want to interface directly with the bitcoin daemon (or as close to directly as possible with a wrapper), try using the Java wrapper and use a database for the tasks that the daemon doesn't handle efficiently. However, if you are wanting to design your online wallet service with security in mind, I would encourage you to use the Armory daemon: <https://bitcointalk.org/index.php?topic=92496.0>. From what I've read, it sounds like this daemon is not quite as full featured as the regular bitcoin daemon, but I haven't tried it out myself, so it's quite possible that it is sufficient to your needs. Still, it has a pretty big advantage in the realm of security that you can create a watching-only wallet on your web server for the customers' wallet.


---

