Author

Topic: Implementing Bitcoin on user accounts (Read 779 times)

legendary
Activity: 2053
Merit: 1356
aka tonikt
November 06, 2016, 12:55:53 PM
#5
more sophisticated system could be to use the real block chain and zero-confirmation payments through multisig.
like 2of2 with your game's master key and the player's private key, kept like a password seeded something.

then it would be like the player deposits certain amount of btc into his profile's btc address.
both signatures (his and the game's master key) are required to spend any money from thet address.
so once they make a transaction, it cannot be double spent again. not without both parties agreeing on it - solves loads of problems.

then, for the player's security, the profile address could be made in a way that after a certain period (e.g 6 months), he can spend these bitcoins with only his signature.
it's the new feature that nobody has really used yet, so suit yourself Smiley
legendary
Activity: 2053
Merit: 1356
aka tonikt
November 06, 2016, 12:33:23 PM
#4
the central wallet where all the bitcoins are kept and you just keep a record of who owns how much of it, is much easier to implement.
but then, people will be more reluctant to put their money there.
and it will be all your responsibility to secure it.

holding separate wallet for each player is possible, but you might just as well assume that they already have their own wallets.
then only implement some kind of system that bases certain actions inside the game on btc getting deposited to certain addresses. on the actual bitcoin blockchain.
but then, this kind of system is probably not very good for a game, because of the confirmation times of the transactions - they may take hours.
legendary
Activity: 3472
Merit: 4801
November 06, 2016, 10:46:49 AM
#3
- snip -
there is one big hot wallet
- snip -

It would be better to receive payments to a addresses from a cold wallet.

Then, have a secure and carefully thought out process for moving a small portion of the funds from the cold wallet to an address in a separate hot wallet.

Once you've chosen a schedule for moving necessary funds from the cold wallet to the hot wallet, the hot wallet should be loaded with just enough funds to make all the payments that you would typically expect to make during that time frame.  If your hot wallet becomes compromised, you'll only lose that small portion of your bitcoins, while keeping the vast majority safe.

Think carefully about your process for moving funds from the cold wallet to the hot wallet.  Think about who will have access to create and broadcast that transaction, think about what safeguards you'll have in place to prevent that person (or those people) from running off with the funds, think about how you'll prevent thieves from tricking that person (or those people) into sending funds somewhere they aren't supposed to, think about what process you'll have in place to override the normal schedule if the hot wallet funds become unexpectedly low.

staff
Activity: 3458
Merit: 6793
Just writing some code
November 05, 2016, 04:11:12 PM
#2
Option 1 is what most services do. You give out a new address for each deposit and just calculate the balances of the user as they deposit and store that somehwere.
full member
Activity: 202
Merit: 101
November 05, 2016, 01:23:38 PM
#1
I am writing the backend of a PVP game which will use BTC transactions. As of now, I thought about some options of implementing all this.

Option 1)
- there is one big hot wallet for all users, and we get how much money an user has by adding up the received balances from his addresses which are used only once;
- alongside, there is a cold 'admin' wallet on a separate machine to which all gaming fees (the profit) are (is) sent.

Option 2)
- there are separate wallets for every user. I don't know how to implement it on one server, considering that there will be lots of users and running bitcoind on different ports is damn stupid.


Maybe you can suggest some other idea how to implement it, or how to regulate the entire system so that it don't become a mess? Thanks.
Jump to: