<p><strong>Using Bitcoin means using maximum security</strong></p>

<p>You can cut corners but you need to understand that by doing so you are introducing risk into your business model. These risks include, but are not limited to:</p>

<ul>
<li><a href="http://gavintech.blogspot.co.uk/2012/03/bitcoin-faucet-hacked.html" rel="nofollow">private key theft by malicious administrators</a></li>
<li>cracks through known vulnerabilities in virtual machine implementations</li>
<li>cracks through weak operating systems (use a secure Linux distro)</li>
<li>theft or confiscation of hardware (data centers may take your stuff)</li>
<li>domain name seizure (ICANN can and will)</li>
</ul>

<p>To reduce the risk involved you need to isolate your Bitcoin code from your public-facing web code as much as possible. This usually means having your own dedicated hardware under your physical control. Often this means a machine in your basement with a dedicated VPN and static IP address.</p>

<p>Make sure that only the "float" part of your balance is accessible to the server in a hot wallet. The rest should be in an offline cold wallet requiring manual access to free up the funds. </p>

<p>Remember: Bitcoin is money. Take the same precautions that you think a casino would take then go the extra mile.</p>

CC BY-SA 3.0
2013-06-23T18:37:24.930Z
Hi Gary, thank you for your answer! I have added an alternative approach to the original post that could be better. What do you think?
Mark
CC BY-SA 3.0
2013-06-24T09:24:39.587Z
That alternative (work queue scanner) is a better approach. Your main worries are protecting the private keys and detecting false transactions (compromised server sending/receiving false instructions). Having a supply of pre-generated addresses is a good solution to avoid private keys on the server. When rendering the public addresses ensure no third-party JavaScript is running that could overwrite the values in the DOM. Be paranoid.
Gary
CC BY-SA 3.0
2013-06-23T17:25:02.810Z
2013-06-23T17:25:02.810Z
Gary
<p>To protect your webapp/bitcoin in first place <strong>think like an attacker</strong>. </p>

<p>Then <strong>do what if scenarios</strong>, what happens if an attacker gains access to the webserver, database, or whatever??</p>

<p>Don’t put all eggs in one basket.</p>

<p>Guess the most vulnerable parts of the whole venture might be <strong>webapps/frontends</strong>, <strong>userfail</strong> and finally exploitation on <strong>outdated software</strong>.</p>

<p>Maybe you want to have a look into <strong>IDS</strong> solutions. </p>

<p><img src="https://i.sstatic.net/R81f3.gif" alt="IDS"></p>

<p>For example have a <strong>SNORT</strong> instance in-between (maybe through a VPN construction). (running heavy IDS on the main server is a bad idea, maybe).</p>

CC BY-SA 3.0
2013-06-24T05:48:53.717Z
2013-06-24T05:48:53.717Z
Aurigae
<p>I have written a Bitcoin gambling site and am planning on the best approach to host it/manage it securely.
The site is implemented in Java using the BitcoinJ API and servlets etc are handled via the Play framework.</p>

<p>Here is an overview of what the site does at high level:</p>

<ol>
<li>Communicates to a datastore where "receive/return addresses" inputed by user are stored.</li>
<li>Creates a unique receive address for the user (also stores this).</li>
<li>Stores the answers chosen by user.</li>
<li>Checks for verified transactions and updates datastore with this info.</li>
</ol>

<p>Finally, when the app has a return address to send winnings to and confirmed verified and confirmed winner, the winnings are sent out.</p>

<p>I am thinking about how to best host this application. Would the best way be to proceed to purchase a dedicated server and run the whole app on there? Are there better/more secure ways that this can be done (also cheaper methods i.e. shared hosting?).</p>

<p>Thanks for your help!</p>

<p><strong>EDIT</strong>
<em>Potential alternative option:</em></p>

<ol>
<li>Lightweight app on web which communicates directly to a database.</li>
<li>Database holds a big list of readily created "receive addresses" by a wallet held off server.</li>
<li>Off server process runs on my PC continuously checking the database for "work".</li>
</ol>

<p>This approach is probably a lot safer and would also remove the need for a dedicated server. The downsides would be having to run a PC 24-7 at home which constantly checks for work.
The off server process would create more addresses when needed and add them to the database (remotely). It would also send out bitcoins to winners and transfer the bulk of BTC to an offline wallet.</p>

<security><server><bitcoinj><gambling><hosting>
Security advise on setting up a gambling Bitcoin site
Mark
# Security advise on setting up a gambling Bitcoin site

(Asked by: username_0 on 2013-06-23)

I have written a Bitcoin gambling site and am planning on the best approach to host it/manage it securely.
The site is implemented in Java using the BitcoinJ API and servlets etc are handled via the Play framework.

Here is an overview of what the site does at high level:

1. Communicates to a datastore where "receive/return addresses" inputed by user are stored.
2. Creates a unique receive address for the user (also stores this).
3. Stores the answers chosen by user.
4. Checks for verified transactions and updates datastore with this info.

Finally, when the app has a return address to send winnings to and confirmed verified and confirmed winner, the winnings are sent out.

I am thinking about how to best host this application. Would the best way be to proceed to purchase a dedicated server and run the whole app on there? Are there better/more secure ways that this can be done (also cheaper methods i.e. shared hosting?).

Thanks for your help!

**EDIT**
*Potential alternative option:*

1. Lightweight app on web which communicates directly to a database.
2. Database holds a big list of readily created "receive addresses" by a wallet held off server.
3. Off server process runs on my PC continuously checking the database for "work".

This approach is probably a lot safer and would also remove the need for a dedicated server. The downsides would be having to run a PC 24-7 at home which constantly checks for work.
The off server process would create more addresses when needed and add them to the database (remotely). It would also send out bitcoins to winners and transfer the bulk of BTC to an offline wallet.

**Tags:** security, server, bitcoinj, gambling, hosting


---

## 2 answers

### Answer by username_1 on 2013-06-23. Score: 1 | Accepted answer

**Using Bitcoin means using maximum security**

You can cut corners but you need to understand that by doing so you are introducing risk into your business model. These risks include, but are not limited to:

* [private key theft by malicious administrators](http://gavintech.blogspot.co.uk/2012/03/bitcoin-faucet-hacked.html)
* cracks through known vulnerabilities in virtual machine implementations
* cracks through weak operating systems (use a secure Linux distro)
* theft or confiscation of hardware (data centers may take your stuff)
* domain name seizure (ICANN can and will)

To reduce the risk involved you need to isolate your Bitcoin code from your public-facing web code as much as possible. This usually means having your own dedicated hardware under your physical control. Often this means a machine in your basement with a dedicated VPN and static IP address.

Make sure that only the "float" part of your balance is accessible to the server in a hot wallet. The rest should be in an offline cold wallet requiring manual access to free up the funds.

Remember: Bitcoin is money. Take the same precautions that you think a casino would take then go the extra mile.

> **Comments:**
> **username_0**: Hi username_1, thank you for your answer! I have added an alternative approach to the original post that could be better. What do you think?  
> **username_1**: That alternative (work queue scanner) is a better approach. Your main worries are protecting the private keys and detecting false transactions (compromised server sending/receiving false instructions). Having a supply of pre-generated addresses is a good solution to avoid private keys on the server. When rendering the public addresses ensure no third-party JavaScript is running that could overwrite the values in the DOM. Be paranoid.  

---

### Answer by username_2 on 2013-06-24. Score: 0

To protect your webapp/bitcoin in first place **think like an attacker**.

Then **do what if scenarios**, what happens if an attacker gains access to the webserver, database, or whatever??

Don’t put all eggs in one basket.

Guess the most vulnerable parts of the whole venture might be **webapps/frontends**, **userfail** and finally exploitation on **outdated software**.

Maybe you want to have a look into **IDS** solutions.

![IDS](https://i.sstatic.net/R81f3.gif)

For example have a **SNORT** instance in-between (maybe through a VPN construction). (running heavy IDS on the main server is a bad idea, maybe).


---

