SatoshiDICE.com - The World's Most Popular Bitcoin Game

[evoorhees]

UPDATE November, 2012:  The new SatoshiDICE site is launched!  

UPDATE AUG 19, 2012: SatoshiDICE has released paying shares
https://bitcointalk.org/index.php?topic=101902.0

Hi all,

SatoshiDice.com is the world's most popular Bitcoin betting site. Over 1,000,000 BTC has been won and over 1,500,000 individual bets placed (as of November 2012). Bet options are available with up to 64,000x multiples and a house edge of only 1.9% (and bet results are mathematically provably fair). To play, you just send coins to any of the listed addresses based on the odds you want.

To see how easy it is, try sending 0.01 btc to 1dice9wcMu5hLF4g81u8nioL5mmSHTApw
(That address gives you a 73% chance of winning)

Payout is sent almost immediately (doesn't need to wait for confirmation). Super fast, easy, and fun Remember to do this only from wallets that let you receive coins from the address you sent them from (standard wallet, or blockchain.info wallet, both work great - if unsure about your wallet, test with a tiny amount and if you never get a payment back, then your wallet is incompatible).

Many other bet odds available at the site.

Enjoy SatoshiDICE!

[1714201841]

1714201841

[1714201841]

1714201841

[1714201841]

1714201841

[HostFat]

nice idea

[danieldaniel]

W00T!  I just won the less than 12000 bet and got 5.417 times my bet of .2!  
http://satoshidice.com/full.php?tx=de6c683de63275362119a34465ade7b317bf6b49d8d34586a8329c95f87adf5e

[Stephen Gornick]

I've got a question.

The secret is associated with calendar day. But there is no authority for date and time with bitcoin.

This gives some leeway to the service as to which secret the operator chooses.

For instance, at the beginning of each new day an evil operator could determine that one of the first transactions seen would end up a winner and thus instead treat it as if it were still under the previous day's secret, thus denying the prize the transaction should have deserved.  Or at the end of a day it could ignore transactions that would win, and wait until the next day (and a new secret) to process them.

[wachtwoord]

Fun game for a lottery, honest drawing, low house edge and getting to pick your own odds (max variance is the best tactic when playing a game that is inherently -EV). I never play real lotteries because of all the very low prices I don't want to win (next to the negative EV thing which would stop me from playing more than once a year even with max variance).

You should increase your price pool though, at 65k multiplier you are only allowed to wager 0.0013 BTC lol.

[danieldaniel]

Confirmed!  Thanks!

[evoorhees]

I've got a question.

The secret is associated with calendar day. But there is no authority for date and time with bitcoin.

This gives some leeway to the service as to which secret the operator chooses.

For instance, at the beginning of each new day an evil operator could determine that one of the first transactions seen would end up a winner and thus instead treat it as if it were still under the previous day's secret, thus denying the prize the transaction should have deserved.  Or at the end of a day it could ignore transactions that would win, and wait until the next day (and a new secret) to process them.

Hey Stephen, you're absolutely correct. It's possible we could play some games with which date we process transactions on.  I don't see a way around that without using some trusted third party to assign times to transactions but that would involve taking a hard dependency on something external like blockchain.info

Do you have any recommendations?

[evoorhees]

My winnings still haven't confirmed?  Any problem? 

It will confirm, give it some time. You received the funds, correct?

[evoorhees]

Fun game for a lottery, honest drawing, low house edge and getting to pick your own odds (max variance is the best tactic when playing a game that is inherently -EV). I never play real lotteries because of all the very low prices I don't want to win (next to the negative EV thing which would stop me from playing more than once a year even with max variance).

You should increase your price pool though, at 65k multiplier you are only allowed to wager 0.0013 BTC lol.

The max bet is based on an algorithm of funds available (so that all bets are sure to be backed by available funds). As we grow or add more capital, so too will that limit grow.

[ccliu]

won a little less than 2x with a 0.01 bet, awesome game

[bitlotto]

Hey Stephen, you're absolutely correct. It's possible we could play some games with which date we process transactions on.  I don't see a way around that without using some trusted third party to assign times to transactions but that would involve taking a hard dependency on something external like blockchain.info

Do you have any recommendations?

Why not just use the blockchain to determine date? Since the tx is broadcast with no confirmations as soon as it gets 1 confirmation you know the date was based on the block prior to that confirmation.

[danieldaniel]

I got them.  Thanks!

[Stephen Gornick]

Why not just use the blockchain to determine date? Since the tx is broadcast with no confirmations as soon as it gets 1 confirmation you know the date was based on the block prior to that confirmation.

Because they don't know which block it will end up in, and if they waited until 1 confirmation it would no longer be an instant payout (which is the real attraction here,  along with knowing the "proof is in the blockchain" as far as being able to verify that there is no cheating).

The thing is, the player doesn't care which secret is used, they just want to verify that the secret that was supposed to be used when the wager was placed is the exact same one that truly was used in determining the result.

So currently the criteria that determines which secret to use is simply the date that the service first sees the transaction.  The reason that there is a new secret every day is that the secret is revealed only after one full day after the deadline has passed (e.g., the secret for wagers processed on the 10th of the month is kept secret until the end of the 11th of the month, and then revealed at the start of the 12th of the month.

There are two other variables that could help.  The address that the wager is being sent to, and the amount.  That's it though.

So one approach would be to have a different wager address for every day.  That's not very good for usability.   Even limiting that, like toggling between two addresses day-to-day, might be something to help with this situation, bit it wouldn't be ideal.

The other approach would be accommodate an optional signal indicating which secret is to be used by encoding that into the wager amount.   Take a list of secrets numbered sequentually, there is odd and even numbers.  Adding a Satoshi to the wager amount (e.g., a 0.1 wager would be 0.10000001) would require that when determining the result  the closest odd-numbered secret must be used.  Then the a 0.10000002 wager would require that the closest even-numbered secret is used.

Neither of these is useful to the person playing by manually doing a copy and paste of the wager address -- you don't want them to be thinking of time of day, etc.  But I foresee the day there is an iPad app, for example, acting as a gaming terminal with a local wallet.  This device provides a dead-simple user interface to the game.  The logic in that app would automatically handle whatever is necessary to eliminate the risk where it is ambiguous as to which secret should be used.   And I suppose, of the methods above, having a different address for each secret would be the most correct approach.  Since it is a piece of code determining which address to use it really doesn't matter that it changes day-to-day then.

So, there's the solution.  

Keep the existing list of addresses which are used when doing manual betting.   Those wagering manually extend trust that the service is not cheating on the end-of-day wagers.  Then for the the automated systems a set of addresses that are associated with each secret are created ahead of time.  If there are any wagers sent after the address expires then those wagers get returned.   Since the addresses are known well in advance, the device could start using the following day's address an hour or so earlier just to ensure to not get too close to the expiration to prevent submitting any bets that would get returned.

This issue regarding being able to specify which secret a bet is against probably isn't necessary to address right away.  A player can avoid the risk by simply not betting near when the time switch occurs.  But the site should consider making an API that will allow an automated gaming termine to send a calendar date + bet choice (e.g., under 48,000) request.  The response will be the return the hash of the secret that will be used for that day as well as the bitcoin address for that specific wager (e.g., for the under 48,000 bet) on that day.

[evoorhees]

Wow Stephen, you're a smart dude   Thank you for your excellent thoughts, I'll keep hold of these.

[danieldaniel]

Cuz I'm just this cool: http://satoshidice.com/full.php?tx=3f6c4656638f5db1da10d00d701e980fea2080b0f874093d35c92e13adbded41

TL;DR:
Bet Amount: 0.48000000
Outcome: WIN
Payment: 5.20000000

[mem]

Wow Stephen, you're a smart dude   Thank you for your excellent thoughts, I'll keep hold of these.

+1 that, Stephen is a treasure of this subforum along with bitcoinlotto

[bitlotto]

+1 that, Stephen is a treasure of this subforum along with bitcoinlotto

Who is bitcoinlotto?

[evoorhees]

Cuz I'm just this cool: http://satoshidice.com/full.php?tx=3f6c4656638f5db1da10d00d701e980fea2080b0f874093d35c92e13adbded41

TL;DR:
Bet Amount: 0.48000000
Outcome: WIN
Payment: 5.20000000

Little do you know... I poison the Bitcoins that people win from the site. Then, once the owner is dead, I collect them back. This is my revenue model, and I think it's pretty sound.

[mem]

Cuz I'm just this cool: http://satoshidice.com/full.php?tx=3f6c4656638f5db1da10d00d701e980fea2080b0f874093d35c92e13adbded41

TL;DR:
Bet Amount: 0.48000000
Outcome: WIN
Payment: 5.20000000

Little do you know... I poison the Bitcoins that people win from the site. Then, once the owner is dead, I collect them back. This is my revenue model, and I think it's pretty sound.

Sounds like a good business model, need an investor ?

[Stephen Gornick]

I wanted to go back and manually go through the motions of verifying a previous transaction, but I see it has rolled off the "recent' page.

There are 200 rows on that page, and my wager was about 28 hours prior. 

In other words, that method wasn't built to accommodate the level of activity the site has already.

I know I can get the trx # from my client and build the URL for that manually, but clicking on a page is more convenient.

Is there anything that can be done so that the past N days (e.g. 10 days) of wagers are retained for review?

(or given and index with sequential numbering and an API to retrieve these at our leisure?)