Bitcoin Forum

Hey all,

This past week I've been working on a Bitcoin game. The site is still beta, but should function somewhat normally. You'll have to forgive the design since I'm kind of a novice when it comes to web design, this is actually an off-the shelf template which I threw out all of the existing PHP code and built upon it.

Here's how the game works.

The game has 'rounds', each round has a jackpot (for example, 1 Bitcoin). There are then ten tickets. Once all of the tickets are purchased, the game randomly selects a winner and awards them the jackpot. Players can purchase more than one ticket to increase their odds (however, purchasing all of the tickets costs you more than the jackpot).

Right now, the game creates a new round when there are no active rounds.  I’ll eventually set it up to where you can view the past few rounds to see who won them, perhaps even a stats page for each user.

Players always have at least a 1 in 10 chance of winning the round. If people enjoy the game and use it, I intend to make much larger jackpots and different kinds of games.

The website is: http://btcblink.com (http://btcblink.com)

Technical stuff:

Registration just requires a username and an email. A randomly generated password is emailed to you for security reasons, I have not yet implemented the function to change your password, or to retrieve your password. So make sure to put your password in a safe place.

The payments are handled by Paysius, so if there are any known issues with this payment processor that I'm not aware of, please let me know. I'm quite impressed with how it works so I figured it'd be better for me to use that, rather than to re-invent the wheel.

A single unique Bitcoin address is generated on registration to handle payments for the user, I don’t see the point of regenerating new addresses for each user every login for this application, but if there is a reason to I’d love to hear it.

Is there anything that prevents you from buying tickets yourself and then picking yourself as the winner? If not, you may want to set something up that is verifiable so you can show you aren't just picking a winner and that it truly is random.

I think I'd have more to gain by running a legitimate game, rather than another scam. But I would like to resolve this issue if I can.

The winner is selected by the ticket number, and I calculate it the following way:


Are there any trusted third parties where I can obtain a random number from, something that you guys can track?

I have considered making it so you can view a players win history, their ticket purchases, which ticket they purchased and for which round, along with any withdrawals. I could provide the transaction id when they withdraw Bitcoins, so that you know Bitcoins are being legitimately withdrawn.

I have also considered doing away with the username altogether, and making it just a Bitcoin address. Right now when tickets are purchased, it shows the username of the owner. So you can tell if a single person owns most of the tickets.

But I’m totally open to other suggestions.

You could have atleast not copied somer blinks name....

Somer blink didn't come up with the concept of 'blink'.

Hi, you have been added to mems list under pending: https://bitcointalk.org/index.php?topic=75883.msg841129

Once people are satisfied with the random number generation or you modify the random number generation I will shift you to the lotteries section.
The site looks nice and clean - good work and good luck :)

I'm going to be changing the random number generator to use random data from Hotbits in the seed (as well as changing it to use mt_srand/mt_rand). The data from Hotbits will be in addition to microtime() when seeding.

http://www.fourmilab.ch/hotbits/

It's still using the previously mentioned code, but I should have it using Hotbits by tomorrow as the majority of the code has been completed.

Great work, keep it up :D

I've got any idea! :)

Please bare with me here, I'm not a programmer so I don't understand all of this completely but...

You could use a RNG similar to what they are using at bitjack21.com, in there case (a game of blackjack) the PLAYER inputs a 128-bit number, the server uses a hardware RNG and creates a 2nd 128-bit string, and then uses another sequence to shuffle the cards.

So essentially, the player's 128-bit string are the actual cards being used in the deck - combined with the server's 128-bit string and shuffler. Therefore the number the player inputs actually determines the order of the deck! The reason you can't cheat is because their server creates the shuffle order using a hardware RNG.


So, to keep things fair you could employ a similar script where each player (or ticket purchased) could input their OWN string of numbers - then after all 10 tickets have been purchased your server would implement some type of formula based on each players string to create the number 1-10. You could even use the same analogy of blackjack where you are essentially picking a "card" A-2-3-4...10 which therefore determines the winner.

Again, I'm not a programmer and not too sure how hard this would be to implement. However, after each round you could display each player's string and therefore allow the players to verify that their string was used to choose the winner...


Hope that helps! Let me know what you think!

It sounds to me like I could accomplish something quite similar by exposing the seed that was used during a particular round. But the thing is there is no guarantee that you can replicate the number generated from that seed on a different system. If I'm mistaken and someone can in-fact replicate the numbers on another system, I'd be happy to expose the seeds used for each round.

I have updated the random number generator to use data from Hotbits. Every hour or so it will request a fresh data from Hotbits, this data is then used in addition to microtime() when generating a seed.

The code looks like this:

The $Seed[1] is unpacked data from Hotbits. This can be improved in the future, but should be way better than a simple rand().

I've added 3 new rounds in case people want to try it without using as much BTC.

0.5 BTC Jackpot/0.06 BTC Tickets
0.25 BTC Jackpot/0.03 BTC Tickets
0.1 BTC Jackpot/0.012 BTC Tickets

These are manually created rounds, but if these are more desirable I'll code them in so there is always lower jackpot rounds.

I'll give one a try, but how do you know which tickets are sold?

Or has no one purchased any tickets yet, in any of the rounds?

No tickets have been bought yet, once a ticket is bought it will show the username of the owner in the slot. The round ends when all of the tickets are bought.

Still looking for the first testers. Might throw a few bones to the first members for giving it a shot if that'll help.

Looks like we got our first players.

First of all, awesome nick AnonymousBat

Second... Has this died... it doesn't look like anyone is playing :/

I think it's just a matter of time before people start to trust it. I'm wondering if I should cut it down to maybe 5 tickets rather than 10 tickets, but I wanted the tickets to remain fairly cheap.

If in a few months nothing really changes I'll refund the ticket purchases and send back all of the bitcoins. I'm constantly watching it along with this thread.

We're still up. =)

The next round to finish, I'm going to be rewarding the winner with a double payout.

well I just played several rounds to give the game a trial.

suggestions:
your site needs a FAQ for the players.
each game should show its end time or do you just play until all tickets are sold ?


As for random number issues, (Im still a bit groggy from my recovery) but I dont see any exposed secrets ?
That aside - on small rounds like this for me at least its not a large concern.

my suggestion for picking a winner.

sha512 (public secret * player 1 nick * player 2 nick * player 3 nick * etc ) then pick a slice that determines your random number.

^ Im not a crypotologist though, someone else here can weigh in on this.
edit: Im an idiot, the last player to play could determine which number wins. (still groggy ok :P )

another option is just like bitlotto

lotto numbers (we have weekly ones here, it would be a non issue to find a regular public pseudo random source).
sha512(public secret * lotto numbers);

anyway good luck :)
I made several bets to get the games rolling for you.

I'll add one.


The game runs until all of the tickets are sold.


Not quite sure what you mean by an exposed secret, but im assuming a piece of data to confirm that the random number generated wasn't pre-selected?


Thank you.

Thats it yes, it gives players that warm fuzzy feeling inside.

Would this before, or after the round finishes?

I could expose a lot of stats when the rounds finish.

Before the round starts, pick a 64 digit number, and publish its sha256 hash.

Each player picks a digit 0 through 9 when they buy their ticket.  Publish each player's number alongside their entry.

When all the tickets are sold, put the 10 player digits on the end of your 64 digit number, re-hash it, and use that hash to decide the winner.  (For instance, take the first 4 bits of the hash.  If they are in the range 0 through 9, you have a winner, else add one to your 64 digit number and repeat).

Publish the 64 digit number and the 10 player digits.  Then each player can verify that you didn't cheat.

There's still a slight problem in that you could buy the last ticket.  Since you know the other 9 players' digits and the 64 digit number, you can try all ten possibilities for the your own choice of digit and probably find one that makes you win.  I don't see a way around that at the moment.

Another issue with these style raffles - there is no end date. Raffles usually sell the most at the start and just before closing.

I cannot tell if I lost a game currently.

Doesn't sound like it would be too hard to implement, also when a player buys a ticket that number is locked in, I can't pick that number. If someone has ticket #5 I can't also buy ticket #5.



They end when all of the tickets are purchased, I could set expiration dates but not sure how to handle the money on the spent tickets, since there isn’t enough to do a payout.

I guess I could return the coins (minus a fee perhaps).

Note that the digit they pick can be different than the ticket number.

"I'm buying ticket #5 and my 'lucky digit' is 8.  The idea is that you as site operator don't know which 'lucky digit' each player is going to pick, so you can't predict in advance which ticket will win.  The result depends on the individual choice made by every player.

The problem is that the last player decides who wins - and if he also knows the 64 digit secret he can probably chose a 'lucky digit' such that he himself wins.

You could use the TX ID of the last solved block.

Or better yet:  don't have an account, just have unique addresses for each ticket.  The you can use the TX IDs for the bets, which are not knowable nor controable.

Do you mean the hash of the block?  Blocks contain lots of transactions, each of which has a single ID.  This could potentially be gamed by miners if they had sufficient incentive to do so, but is a lot safer than anything else I've seen proposed so far.  Use the hash of the block containing the payment for the last ticket in the computation of the winning ticket number.


Not really.  Transaction IDs are knowable to the person making the transaction before you send the transaction.  It would be trivial to modify the satoshi client to say "transaction ID is xxxx - really send?" before sending each payment.  Probably there's a way of doing this using something like Armory's offline wallet system already without having to change any code at all.

It doesn't really matter if the user can see it, if they are mixed together this would be dependent on all others.

I guess the last person to bet may be able to do something, I am not really sure how much influence a user has on the TX id.

As far as the miners incentive....  While accurate I don't think it is a practical worry for the amount of BTC we are talking about.

Any change to the inputs or outputs of a transaction changes the tx id completely.  So all I need to do (as site operator) is keep changing the 'change' address of the tx that buys the last ticket until I get a tx id that makes me the winner.  It doesn't give any more security than just letting each user pick a single 'lucky digit' salt.

And you're right about mining.  Until the prizes get bigger than the block rewards it's not worth messing with your mining code.

Seems like this might be like mining itself... you may find a winner immediately or in 3 weeks.  Could be alleviated by using a pre-selected mixer, which I think you suggested earlier.

I guess I am biased to the idea of using the blockchain for as much data as sanely possible due to the availability and distribution.

Doesn't really look like this has gotten traction.  Any updates?

The tickets have been refunded and you should be able to withdraw your bitcoins. I'll refund them manually when I get the chance but you should be able to login and get them now if you don't want to wait.

I just noticed a new player. I'm not going to be shutting the site down (since it doesn't cost anything to run), but I'm just going to honor the ticket refunds I promised earlier (which has happened).

Any tickets purchased after this date won't be refunded, but you can always withdraw your balances.

I can confirm he stuck to his word.

I hope the site catches on.