BTCBlink.com - Yet another bitcoin game.

[mem]

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?

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

[AnonymousBat]

Would this before, or after the round finishes?

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

[dooglus]

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.

[mem]

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.

[AnonymousBat]

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.

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.

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.

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).

[dooglus]

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

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.

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.

[ErebusBat]

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.

[dooglus]

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

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.

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.

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.

[ErebusBat]

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.

[dooglus]

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.

[ErebusBat]

An 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.

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.

[ErebusBat]

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.

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

[AnonymousBat]

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.

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.

[AnonymousBat]

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.

[ErebusBat]

I can confirm he stuck to his word.

I hope the site catches on.