Topic: ... (Read 1906 times)

Hey,

So what are you using now? (sorry for bumping old thread)

you can buy ready to use code for your dice gambling site
you can find many people selling here on forum

Well it is going away for good reason, hopefully or maybe a couple people (I know I would throw in a couple bucks) for a true enterprise account system to be built not into bitcoind, but on top of it, kinda like bitcoin-cli. This would great for things and would support ACID. Right now the bitcoind accounts technically are not reliable by those standards.

For the non-technical people ACID is the standard by which all database management systems are consider reliable.

So what do you use?

listreceivedbyaddress dumps the entire list of transactions ever received, so you can't really use that except maybe once at startup.
-walletnotify is unreliable, in that it can tell you about the same transaction twice, and tells you about unconfirmed transactions

So what's left?

I like 'listaccounts' and am sad it is going away.

Yes walletnotify should NEVER be the only way to accept payments, I use it so I can run a cronjob every 5mins and still make it snappy. It basically tells my java application that a payment could be on it's way and to track this one.

According to the comment in the source code:

// notify an external script when a wallet transaction comes in or is updated

It is done in CWallet::AddToWallet() which appears to be called when a transaction is seen on the network as a standalone transaction or in a block. It won't be called for the 2nd or later confirmation of a transaction.

I don't see an obvious way of defending against malleability attacks using this. It's quite possible you'll see a deposit to a customer address from an unconfirmed transaction, and then later see a deposit of the same amount to the same address from a transaction with a different txid that made it into a block, where the two transactions are mutually incompatible since they have the same inputs.

In other words, there's -walletnotify to tell you when a new transaction arrived, but there's nothing to tell you when that transaction was overwritten by a new version of the same transaction.

Yes that is why I run bitcoind in tx=1 so I can track the transaction.

What does it mean when a transaction changes? When a transaction changes from 1 confirmation to 2 confirmation? Or does any new transaction count as a transaction change?

Depends on the situation. For me bitcoind over everything, because I have trust issues but looking at the callbacks of bitcoind...

https://en.bitcoin.it/wiki/Running_Bitcoin#Command-line_arguments

You can't beat them, just don't trust them too much, since they are all done with no confirmations.

Thanks gweed

Would you ever consider using the websockets API ( https://blockchain.info/api/api_websocket ) with grep to filter out only transactions to the addresses you are interested in?


I'm learning about websockets because I really like the "live" information concept instead of running a script over and over again.

So the flow I did for javaEE, is a couple of checks. One was a cronjob, in tomcat they are not called that, this runs every 5 mins (remember I wait for 1 confirmations anyway, so I don't have to run every 5-10 secs which is probably what you would do for non-confirmed transactions). For my next check, I always run bitcoind in -tx=1 mode so I have access to the entire bitcoin blockchain, and don't have to use a blockchain api. Then using netcat and java socket server, I would have bitcoind send any wallet transactions to the socket server, and put in a queue (any first in first out data structure would work). Remember take this with a grain of salt this transaction, it is usually a non-confirmed transaction, and it can be subject to many attacks. This just alerts my application that a transaction is possible waiting and to track it a bit.

Now that we verified that indeed we have a new balance, I use web sockets to push it to the user. JavaEE is amazing at writing this in a simple class. If you don't want to use websockets, or the the users can't get a good connection, then just simple javascript polling works as well. Then that updates the frontend accordingly. Remember to always check the balance before executing anything server side. This is just a view, and should never be trusted.


Yes it is a big list, but what I usually do with java, is just hold on to it in an array of objects and remove the the ones we have already processed already. I can always build that array at startup from the double entry database, incase of shutdown or restart.

I looked into it - I don't see any way to prevent it returning the entire list of addresses and transactions each time you call it.

That's a huge ever-growing amount of data to parse over and over again.

I'd much rather have bitcoind do all that grunt work for me and just tell me which account has a new confirmed deposit.

How do you get live updates from new deposits. Do I have to check for new deposits for every possible deposit address once per minute? What do you recommend to run so that when a deposit happens there is a event that says "Hey, you got a new deposit" and how do you link this to the site?

Pretty sure listreceivedbyaddress also protects against that.

What do you do if there's a 2 block reorganisation, and the deposit changes its transaction ID?

Would you credit it twice?

That is why you pay someone to look it over, that you trust as a programmer.

The problem with this is that if the programmer isn't experienced enough, which is usually the reason for buying the scripts, they won't know what to look for in terms of insecurities and backdoors.

Make sure their is no backdoors, in the RNG or in the software in general.

Curious, how much does the script cost?

I always wait at least 1 confirmation. I always do a double entry balance and withdrawl, then I use listreceivedbyaddress to get the transactions.

Then how do you keep track of which incoming payments are for which user, and make sure not to credit them twice in the event of a blockchain re-org or transaction malleability?

The account system takes care of all that for you. I wouldn't want to have to reinvent the wheel.

I would advise against the account feature, it isn't meant to be a database, like you are using it. I usually just keep a database table that links addresses to users, I think this system is more robust than using the account feature.


And to be honest I have written dice games in javaEE, which is actually really strong.

Buy the script from other and i think they have the details 

Yes. At Just-Dice I used bitcoind, and simply did getAddressesByAccount() to see if there was already an address associated with a userid, and getAccountAddress() to get one if there wasn't. Then you can listAccounts() to see the balance for each account with the required number of confirmations and move() to move the funds from a player's 'account' to the main hot wallet account so you don't count it twice.

Recently I heard Gavin saying that the 'accounts' feature in bitcoind is likely to be removed soon, so I guess this isn't a good idea to use any more.

I'd reccomend having a number of games. in my opinion that would be your best bet attract more people.  Also a nice looking site goes along way also.  I've liked the Primedice website from the first time I seen it.  That leaves an impression on the user and will most likely play apart in their decision to use your site.

Hey it may not hurt to consider using or accepting more then one coin, who knows.  Good luck with the site.   

I would just open a casino instead of a dice.

I used node.js for Just-Dice and had good experiences with it.


This is a worrying question. Security isn't something you add to a site, it's the absence of insecurity. Just don't mess anything up and you have security.


Another worrying question. I would suggest that you're probably not ready to do this right. Play about with Bitcoin and web application development in general to get a feel for it. Work your way up.

A hot wallet is simply a wallet that the server can interact with, and a cold wallet is a wallet that's not online. You create them both in the normal way. You shouldn't be creating a new wallet for each user. I found that 3 wallets was enough for Just-Dice - one for the server to use, one offline cold wallet, and one which I keep online locally as a buffer between the two so I don't have to keep manually transferring coins from the cold wallet (which is a pain due to its offline nature).


There are as many ways to do this as there are existing dice sites. The basics are:

make all rolls depend on the seeds: one that you pick, and one that the player picks
make sure you pick your seed first, and commit to it (by publishing its hash) before making the player pick
make sure the rolls are completely determined by the seeds

These 3 things together prove to the player that you can't be manipulating his rolls, since he picked a vital part of the input to the roll, and he picked his part last.


If your site is successful, it's going to take over your life. Be ready for that, or don't even start it.

I think you need to rethink your plan the dice market is over saturated. The other 2 that are busy or worth considering are of course primedice and luckynumber.me. I think the others JD and Everydice the latter apparently got scammed by a player but seems like a convenient excuse and JD is having problems with the introduction of new legislation.

If you have no experience at all with developing websites, I honestly think you shouldn't start a bitcoin gambling site. There will be many people trying to hack your website and if you never made a website before I assume they will succeed.

If you really want a website start with something where you don't have to hold other people's money.

The dice gaming market is saturated with too many sites chasing too few players.  There are many sites out there that have had no bets all day.

It's wiser to come up with a new gaming concept rather than be the 50th dice site with no players.

Maybe this would be useful?

https://bitcointalksearch.org/topic/cryptodicescript-now-you-can-buy-a-no-support-version-for-much-cheaper-652563

(II'm not affiliated in any way)

This link is the answer to all your questions.  It's amazing!

http://bit.ly/1qn6tnL

...