I can confirm he stuck to his word.
I hope the site catches on.
Topic: BTCBlink.com - Yet another bitcoin game. (Read 4469 times)
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.
Any tickets purchased after this date won't be refunded, but you can always withdraw your balances.
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.
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? 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
I cannot tell if I lost a game currently.
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.
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.
Would this before, or after the round finishes?
I could expose a lot of stats when the rounds finish.
I could expose a lot of stats when the rounds finish.
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.
well I just played several rounds to give the game a trial.
suggestions:
your site needs a FAQ for the players.
suggestions:
your site needs a FAQ for the players.
I'll add one.
each game should show its end time or do you just play until all tickets are sold ?
The game runs until all of the tickets are sold.
As for random number issues, (Im still a bit groggy from my recovery) but I dont see any exposed secrets ?
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?
I made several bets to get the games rolling for you.
Thank you.
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
)
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.
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.
^ 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
)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.
We're still up. =)
The next round to finish, I'm going to be rewarding the winner with a double payout.
The next round to finish, I'm going to be rewarding the winner with a double payout.
First of all, awesome nick AnonymousBat
Second... Has this died... it doesn't look like anyone is playing :/
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.
First of all, awesome nick AnonymousBat
Second... Has this died... it doesn't look like anyone is playing :/
Second... Has this died... it doesn't look like anyone is playing :/
Jump to: