We solve the wallet backup problem by keeping a copy of the private keys in the database. For now, we're using the account system with thousands of accounts and tens-of-thousands of transactions without issue. We have a secondary ledger than uses walletnotify and blocknotify to stay in sync. We still use the bitcoin account system as the place of record, but our side-by-side tests have been perfect so far. We could move off of the built-in account system if we needed to. But you asked the easiest way to do some testing - not the most robust
FWIW, this is also our cold-storage strategy. When a user logs in, we push funds from the holding account into their account so they can play. When they logout, we move it back to the holding account. Then, we only keep a percentage of the total funds in teh holding account to support the numebr of people on the site at any given time. This means if we got a rush of users, we would need to turn some away. If only that would happen
You're right that I should worry only about the minimum viable product and the easiest way to process bitcoins. Just out of curiosity though, what do you plan to do when you get thousands of customers?
When you get a rush of users, then I assume that this becomes an issue only if they all want to withdraw bitcoins. I assume that if your holding account runs out of bitcoins, then you can tell your users to wait as you manually move some bitcoins from your cold (which I assume is the same as offline) storage?
That sounds about right. Note that you can do all of that without writing any software. *notify can just be echos to a text file. Also, bitcoind is a commandline version of the api, so you can do bitcoind getinfo, or bitcoind listtransactions, etc. to test out the api.
That's good to know.
We user sendFrom so they funds are removed from the users account, rather than the wallet.
According to tgerring's posting at
https://bitcointalk.org/index.php?topic=300632.0:
Use Gavin's contrib/spendfrom script, never the `sendfrom` command
I don't know why he wrote the above. I assume that you haven't had any problems with sendfrom.
Pretty close. We create a new account for the user, then use walletnotify to watch for deposits. When a deposit comes in, it's "unverified".
We then use blocknotify to watch for new blocks. When a block comes in, we check the balance of the users account with 0 confirmations, then again with 4 confirmations. The delta is their "unconfirmed" balance.
We don't do the sweep currently on the live site, but that's how we handle cold storage.
I don't understand what you mean by: "We don't do the sweep currently on the live site". Can you explain or elaborate?
It's not obvious.
You can call getbalance and pass in the number of confirmations you want. So if a user has 10 confirmations on their first 1btc deposit, and 2 confirmations on their second 5btc deposit:
getbalance 0 confirmations = 6btc
getbalance 4 confirmations = 1btc
From that, we can calculate that they have a balance of 1btc, and an additional 5btc unconfirmed.
So then blocknotify is only used to say, "A new block was received, and users' confirmations may have changed."
We just use it to trigger a re-check of the users that have unconfirmed funds. If the confirmed and unconfirmed balances are the same, we can stop checking their account with each new block.
Let me reiterate what you wrote above to fully understand what you are doing. You keep track of users (in your database) who have unconfirmed funds. When a blocknotify comes in, you call getbalance for each and every one of your users who have unconfirmed funds, to find out if these users still have or no longer have unconfirmed funds. For users who no longer have unconfirmed funds, you write into your application database to indicate this, so that your application can tell your user that he has more bitcoins to play with. Do I have this right?
Don't the blocknotify come in quite often, especially if you have thousands of users? I'm assuming that blocknotify will run every time there is a confirmation on each and every transaction for every one of your users. There could eventually be thousands of confirmations on a transaction. Here's a possible number of blocknotifies:
1,000 confirmations X 5 deposits X 1,000 users = 5,000,000 blocknotifies. For each of these blocknotifies, you are checking all of your users with unconfirmed funds. This means you can be running getbalance 2,500,000,000 times (5m X 500) if you have 500 users with unconfirmed funds. This seems like a lot of processing. Do I have this wrong?
Only run on testnet. There's no need to run on mainNet until you're getting close to launch.
I'm happy to answer questions. Just know that you're only getting one team's opinion. There are a million ways to do things
When we launch, do we need to run SSL on mainNet (assuming mainNet refers to regular bitcoins)? Why is SSL needed? What data needs to be encrypted?
Virtual Keyboard and Mouse. A well known bitcoin casino had their data center's maintenance site hacked. Someone put in an order to have a VKM installed. The machine rebooted and the attackers attempted to use the vkm to get console access. Thankfully, the casino used full-disk encryption, so reboots required a manual password step.
Attackers in this space are really, really clever.
It's amazing how much less productive and wealthy our economies are due to all of the extra work and money we have to spend to protect ourselves from hackers, criminals, etc. Also, the adoption of bitcoin would be much more widespread if it wasn't for these hackers and criminals.
