https://blockchain.info/tx/bbf4f419e99b41571427e8f726dd91486f74b9ef6b6df6685da5f7ca3d6c1fa0

My first 50 entries.   Thanks!

I say Conor wins 9 times out of 10 assuming we are talking about an MMA fight.   If we are talking boxing only, mayweather wins 100% of the time. 

Mine is out for delivery today.  Any winners yet?   I have my fingers crossed.  Good luck. 

I am super happy to announce that I have implemented a provably fair system in the script as many people have asked about that.

It currently functions like this:

Use an hmac hash function using the server seed and Clientseed-BetID

Take the first 5 characters and convert from hex to decimal.

Apply a modulus of 10,000

Divide by 10,000 to get a random number between 0 and 1,

The result will be matched up to the paytable in the database.

Server hashes will be displayed and seeds will be revealed at 00:00 UTC.  Click on any bet you have made to display the provably fair data, or pass a get parameter to the bet API.

http://satoshibitco.in/

http://satoshibitco.in/slots/checkBet.php?bet=1232

I disagree.  They are one of the few legit sites there.  I have had many other dealings with Tommy and can tell you with 100% certainty that the actually have the hash power they claim as opposed to many other sites.   They cannot control the rise in Bitcoin difficulty. 

I am in the process of adding a provably fair system to the slots script.  If anyone is interested it will be complete in 1-2 weeks. 

I bid .02

I bid .008

Because I am selling it.  Feel free to buy it.

You seem to be confused, if you bought it for .09, it wasn't from me.   And I most certainly am not going to help you install it.

And FYI, my script is about 7mb zipped.  So you probably got ripped off.

Thanks Danny!   This actually seems like the perfect solution.

As far as reorgs, I won't pay out until 4-6 confirmations, however I just need to know that the transaction was confirmed in or before the target block.   It does not need to get calculated at the time of the target block.   It can happen just before payout.   Any opinion as to what a safe time to do that is?   I was thinking 6, but would 4 confirmations be enough to calculate the results?

Having the correct block height and hash for the target is crucial as each team will have a chance of winning proportional to the amount each team has wagered and since it is provably fair, I will be using a blockhash + server secret method.


EDIT: Looks like I need to build a tx index with this method.   Will report back.   Thanks again Danny.

I guess I would have to do something like $currentblock - $numConfirmations to be sure it was confirmed in time. 

So, I am in development of a Lotto type game.   It is round based, and the rounds end on a certain block number.

I only want to count transactions that have 1 confirmation by the time the target block hits.    However I am not sure how to accomplish this given the current list of Bitcoin RPC commands as shown here: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

It is team based as well, so each team will have a new address for each round.

I know it is possible to do using the blockchain API but I would really like to figure out a way to do it with the daemon so I can expand to other coins in the future.

Any suggestions?

You didn't find anything.   Because there aren't too many people that have this script.    So anyone that buys from a satoshi box link is just asking to get ripped off.    I think I'm going to be mentioning this to the manager of your sig campaign.

bump

I'll take the last slot please.   Thanks!

Are you still here actually trying to sell the script that you refuse to prove you even own?  You figured you would give up by now. 

Do you know of any programs that allow adjusting of the gap limit so that I can continue using this method?   Id like to not have to recode the payments receiving function in the script.   The v1 API was fine.   I didn't even mind paying the Tx fee. 

So, I am wondering if anyone has faced this issue before or if anyone can think of a solution or alternative as I am slightly stumped.

I am using the blockchain.info receive payments API V2 for a script of mine.   It uses a BIP32 xpub key to generate receiving addresses.   However, it seems like blockchain.info uses the standard gap limit of 20.   There are a lot of addresses generated for the site that uses the xpub key, so having 20 addresses in a row where there is no payments, is not all that uncommon.   Once that magic number of 20 passes, addresses are still generated but they are no longer monitored for payments. 

Currently, I work my way back and send a small amount of BTC to an earlier address to get it to "see" payments to later generated addresses.

Other than programatically sending dust when there have been x number of receiving addresses without payments, is there any other way to make this more manageable?

At this point, 3 people have contributed a good amount of code to the script.  The slots engine is this: http://slotmachinescript.com/

But the accounts, bitcoin integration and other features were my team.

I have been coding the patches and updates personally.  I just updated the deposit system to the receive payments API V2 as the V1 API was deprecated.  I also released a fix this week for the email based password resets.


As I do have provably fair on the agenda, it is still a while away from being released.  There are currently 2 slot machine scripts that I know of, neither are provably fair, and this one is 1/3rd of the cost of the other.  But, it is in the works.