So, I'm not an expert on bitcoin, but I've been writing software professionally for 14 years... and if you're planning on making a website that handles peoples money, you need to be rock solid with your dev skills. You sound sound like you're having some difficulty with some of the basics, so maybe start with something a little less ambitious? I'm really not trying to be mean, just trying to be helpful and realistic.
The way I would imagine most gambling websites work is, you deposit coins into one of their addresses. After they are confirmed (no website should let you use coins before they're confirmed), they record your tally in a row in the DB. From this point on, your "balance" is entirely virtual and has no relation to any real wallet. Wins and losses are recorded in the database (likely there's a transaction log so they have accountability if someone says their account is wrong), and they update a boring old account_balance for you. You don't need to calculate the value based off the transaction log, that's processor and database-heavy and unless you have a bug, should never be different than the constantly-updated balance.
You have to be really really careful not to let people spend more than they have.... it'll almost certainly be a common occurrence that people will bet down to their last satoshi, and might be participating in multiple games at the same time. You have to make sure that they can't bet .5btc on two different games at the same time if they only have .5btc left, you know?
Making a gambling website is a lot of work, you're dealing with someone's actual money, so you have to be super extra careful not to mess anything up. I admire the spirit and ambition, but it's probably not something one person should try to write by themselves.
Topic: how to keep a correct user balance on a gambling website (Read 2447 times)
hi,
what algorithm should a bitcoin based gambling website follow to keep a correct user balance without running some weird cronjobs that iterate over the whole database? maybe i'm just too stupid to enter the right search terms in google but this question kept me buys for days now. came up with two approaches but feels like i am overcomplicating a simple issue. so how do they do it?
my thoughts:
goal:
- on a website, a user can deposit bitcoins.
- through certain activities on the website the user can win or lose coins.
- the user is always displayed the accurate coins balance which is: total balance = total deposits - total withdrawals + total winnings - total losses.
- the user can withdraw the coins from his total balance.
- the system can transfer coins from the user accounts to another wallet in order to have them in a safe(r) place outside the server.
pre-conditions:
- number of confirmations does not matter for deposits. as soon as a transaction comes in the transferred coins are available as deposit. the user can only withdraw his balance once all deposits are confirmed.
- no third party api is used. only bitcoind and jsonRPCClient.
approach 1 - absolute balance
1. create 4 tables:
1.1 user_balance: one row per user, holds the current balance
1.2 transactions_unprocessed: new transactions are added to this table
1.3 transactions_processed: holds transactions that were processed
1.4 transactions_history: old processed transactions are moved here
2. run bitcoind with walletnotify which calls a script which adds the reported transaction to the table transaction_unprocessed
3. run a cronjob every 30 seconds:
3.1 take all transactions from table transactions_unprocessed
3.2 remove duplicate transaction_ids from the dataset
3.3 take all transactions from table transactions_processed which are also in the unprocessed dataset
3.4 remove the allready processed transactions from the dataset
3.5 loop through all remaining unprocessed transactions and update the user_balance accordingly
3.6 add the now processed transactions to table transactions_processed
3.7 remove all initially reported transactions (step 3.1) from table transaction_unprocessed
4. run a cronjob once per day which moves all transactions which are older than x days from table transactions_processed to table transactions_history
5. if user wins or loses or withdraws coins, the table user_balance is updated accordingly
6. total balance = the value in table user_balance
approach 2 - relative balance
1. create a table additional_balance with one row per user. columns: user, balance
2. update additional_balance: losses are deducted, winnings are added to the balance value
3. total balance = coins in the wallet as reported by bitcoind->getbalance + balance value in table additional_balance
4. if coins are moved out of the users account by the system (e.g. to fulfill withdrawal requests or store them offline) -> add the transferred coins value to additional_balance to keep to total balance the same
5. if the user withdraws coins from his balance -> deduct them from the value in the additional_balance table (taking the coins in the actual account to perform a transfer is covered by 4.)
what algorithm should a bitcoin based gambling website follow to keep a correct user balance without running some weird cronjobs that iterate over the whole database? maybe i'm just too stupid to enter the right search terms in google but this question kept me buys for days now. came up with two approaches but feels like i am overcomplicating a simple issue. so how do they do it?
my thoughts:
goal:
- on a website, a user can deposit bitcoins.
- through certain activities on the website the user can win or lose coins.
- the user is always displayed the accurate coins balance which is: total balance = total deposits - total withdrawals + total winnings - total losses.
- the user can withdraw the coins from his total balance.
- the system can transfer coins from the user accounts to another wallet in order to have them in a safe(r) place outside the server.
pre-conditions:
- number of confirmations does not matter for deposits. as soon as a transaction comes in the transferred coins are available as deposit. the user can only withdraw his balance once all deposits are confirmed.
- no third party api is used. only bitcoind and jsonRPCClient.
approach 1 - absolute balance
1. create 4 tables:
1.1 user_balance: one row per user, holds the current balance
1.2 transactions_unprocessed: new transactions are added to this table
1.3 transactions_processed: holds transactions that were processed
1.4 transactions_history: old processed transactions are moved here
2. run bitcoind with walletnotify which calls a script which adds the reported transaction to the table transaction_unprocessed
3. run a cronjob every 30 seconds:
3.1 take all transactions from table transactions_unprocessed
3.2 remove duplicate transaction_ids from the dataset
3.3 take all transactions from table transactions_processed which are also in the unprocessed dataset
3.4 remove the allready processed transactions from the dataset
3.5 loop through all remaining unprocessed transactions and update the user_balance accordingly
3.6 add the now processed transactions to table transactions_processed
3.7 remove all initially reported transactions (step 3.1) from table transaction_unprocessed
4. run a cronjob once per day which moves all transactions which are older than x days from table transactions_processed to table transactions_history
5. if user wins or loses or withdraws coins, the table user_balance is updated accordingly
6. total balance = the value in table user_balance
approach 2 - relative balance
1. create a table additional_balance with one row per user. columns: user, balance
2. update additional_balance: losses are deducted, winnings are added to the balance value
3. total balance = coins in the wallet as reported by bitcoind->getbalance + balance value in table additional_balance
4. if coins are moved out of the users account by the system (e.g. to fulfill withdrawal requests or store them offline) -> add the transferred coins value to additional_balance to keep to total balance the same
5. if the user withdraws coins from his balance -> deduct them from the value in the additional_balance table (taking the coins in the actual account to perform a transfer is covered by 4.)
Jump to: