Topic: How to handle deposits on a turn based multiplayer game (Read 257 times)

It's a game so I assume that your target market would be teens and young adults?
You don't necessarily need to worry about people who didn't want to deposit for the types of persons at that age and "game preferences".

Just make use of the 3rd party service providers that they probably use and trust like Bitpay, Coins or others as a payment channel to buy "game credits/cash/coins".
With this, they wouldn't really need to trust the game, they just practically "bought" points. (every Game Providers do this)

You might wanna change the "betting" into "reward" by not using bitcoins directly as bets.
If it does, this will just look like a gambling app disguised as a game, and the available market will be slim.

Hope this helps.

In theory, you can do it via multisig addresses "2 out of 3"
Players will deposit funds into this address (new one for every game)
In order to send money to winner, you need 2 signatures: Yours and winner's.
Moreover, you are as arbiter will create resulting transaction which pays your fee.

We do it also trough a database. If you have your own token and make a airdrop, 10 tokens when registering or trough refferals. When players play for free you earn there trust.
And also you can convert every currency to your own token to play with and you could buy back tokens with a few currencies... just a tought

Make registering players generates a new adress and just for use by your system. So when players sends fonds to this adress it is send trough to the systenwallet.
And updating the database with fonds to play with. When players whithdrawel. Send from systemwallet to a private wallet and update the database again again.

That's not necessarily true... You don't need to start a new escrow transaction for everybody playing your game... You just need to make sure that the amount in escrow is equal to or bigger than the sum of the amounts you are holding for your active players.
So, a one-time escrow deal of (for example) $500 should cover all your escrow needs for the forseeable future. This will probably cost you $5-$10, and it should be sufficient as long as you're not holding more than $10 for 50 active players at any given time.
This does require a certain level of financial transparancy, so the players know that their deposit is covered by the total sum escrowed by a trusted party.

I guess that escrowing $500 will probably sustain you for several months and thousands of games without the need to make any additional escrow deal (because by the time you're holding more than $10 for more than 50 players at any given time, you should have built enough trust to continue escrow-less)

Thanks for your answer.

The problem with the escrow is:

Send transactions to third party will be:
- Slow and costly, it will be bigger than my margin.  (For bitcoin at least) this could be solved setting up a LN, but this will work only for btc, my idea is to accept a bunch of cryptos,

I'm defenatly not implying you're going to scam your users (far from it... If your intention would be to scam somebody, you probably wouldn't have come to this forum to ask for advice).
The reason for using a provably fair system, signatures and an escrow is to make sure your initial users will have nothing to fear when they deposit to your addresses. You can give them an assurance than an independant escrow will actually be able to issue a refund in case things go sour. This will make your users less afraid to deposit funds to your game, thus allowing you to build a solid reputation.

As for your last question: i guess this forum is the best place to look for some feedback. In my opinion, it would be wise of you to create a beta version running on the testnet, open an [ANN] thread and give some small bounties to people to try out your beta version, and maybe give some bigger bounty's or prices to testers that find improvements or bugs in your beta version. That way a lot of people will try your game while it's on the testnet, and you'll gain some valuable feedback for a small amount of BTC.

Hello, thanks for your answer.

I won't scam anyone, my plan is to earn a small fee on each game (6%-4% depending on bet amount) (only games that wins, if draw I wont earn nothing).

So my last question, since this is a new service where can I do a poll to ask users for feedback, (f they will like it, if they would play it...) it's like testing/studying the market, the problem is there are no competitors, so, i don't know if there is any market.

Thanks all.

The lightning network was designed for cases like this... hundreds of microtransactions between 2 parties could result in only 2 onchain transactions (one opening and one closing the channel). The transactions are off-chain, instant, and nearly free (if you get your users to open a channel directly to your lightning node, you can even make sure their lightning transactions are completely free).

As for your problem, i don't see a real technical sollution... Whatever you do will always require some level of trust. Either you trust your users ( which is a bad idear imho), or your users trust you. I'd personally prefer the second case: you can build trust over a longer period of time, whilst your user's are unknown, faceless individuals whose accounts can even be sold to scammers.

There is a non-technical sollution tough: make your game provably fair, sign every deposit address and escrow a couple hundred (in fiat equivalent) with a trusted forum escrow.
If you ever scam your users, they should be able to provide screenshots of their bets, the seed, the hashes, the signed messages and turn to the escrow provider...
As soon as you've ran your business and processed several BTC, you can eliminate the escrow and just provide signed messages from the hot wallets proving you have processes a lot of BTC and *should* be trustable.

Thanks all for the answers.


So, the first option is the best I think. and for option B how could setting up a node help me?

To be honest: A cautious player won't trust you more because you provide them with the private keys to their deposit address, especially knowing that you store a copy of the private key on your own server anyway. If anything it opens up additional attack vectors for hackers and puts the balances of your players at risk. To make matters worse, even without a hacker attack any player could move their own coins and then throw scam accusations at you for not keeping their coins save. There's no way to solve such a dispute (ie. whether you stole the coins or whether the player moved the coins themselves).


Short of falling back on some of the less widely used alts I'm afraid you'll only have two choices:

a) Accept payments directly on a cold storage address and keep track of in-game moneyflow on an internal database, off-chain. This will require the trust and goodwill of your player, but as mentioned above: Even providing the private key to their deposit address won't replace trust.

b) Become a bleeding edge pioneer and start accepting LN micro transactions. (YOLO!)
https://medium.com/@ismailakkila/bitcoin-setup-your-own-lightning-node-on-mainnet-94337bda09fa

Should not be so complicated... If you're taking a bet and settling it for two parties, then it makes you little different from a casino. If your main problem is people don't like depositing, then approach the challenge as you would if you were a casino attracting gamblers. That trust has to be built over time.

You could always consider escrow services or build one like localbitcoins, but it still requires trust. You could bank on reputations of escrow providers like coinpayments but gamblers won't want to pay the additional fees I can almost guarantee that.

Last option is to consider trustless smart contracts, but not all blockchains have that handy.

Hello, i'm developing a turn based game where you can bet against your opponent, if you win you earn back your money and opponents money, if you loose the opponent gets all. So, I want this project work only with cryptocurrencies, but i'm facing a lot of problems:

1. People need to deposit money to the site, and when the start a game they decide how much to bet and then start to pay:
Problem: People dont like to deposit money on sites.

My solution: Users would deposit money on site on an address, I would give him the ability to download the private key of the wallet, but that comes with another problem:

If a user starts a game and bet 10$, since he has access to the wallet before the game ends he could just send the money elsewhere and scam the system. My solution:

Send bet amount before he starts a game to a newly temporal created wallet only for that purpose, but that's comes with another problem:

Speed, and fees,  bitcoin is slow, cryptos are not that fast.

So how could I solve this problem, giving the user the ability to download his private key but "freezing" the money for a bet.

The easiest solution is to not let the user download the private key, but i won't scam them and I want them to feel comfortable. I just need a form to freeze the money used in a game,

Any advice?