How many bets have you made to that address since June 25th, and how many won?

SatoshiDice is provably honest - they use a publicly known mathematical function to decide whether you won or not, using secret numbers decided before the game started.  A hash of the secret numbers was also published before the game started, so they can't change it.

Looking at the blockchain since June 25th (I started counting at block 186101), I can see that they have processed 3808 bets to that address. 1 was refunded for being over the max bet, 3 haven't yet been paid out either way, and of the remaining 3804, 885 won.  That's 23.26% of them that won (1:4.298).  We would expect 24.41% to win in the long run (1:4.096), so that's pretty close.  It's certainly nowhere near the 1:7.91 that you saw.

I first heard about bitcoin here:

  http://identi.ca/notice/61926764

on Monday, 10-Jan-2011.

That's bad.  You're using connections that other users could be using.  How about opening up a port instead.  That way you help improve the network rather than harming it.

That's pretty impressive.  50k hands in how many days?  If it's since you posted about your site in this thread, that's about 1 hand every 20 seconds, 24/7.

She didn't.  It was quite a relief because she's been dead since 1996.


Oh, I was close then.  I found myself at http://en.wikipedia.org/wiki/Binomial_distribution yesterday when I was trying to work out how to do this, but didn't have enough confidence that I had the right distribution to proceed.

Thanks a lot for doing the maths.


So a combined probability of 38.71 * 12.23 / 100 = 4.73%, or about 1 in 21.


If you look at blockexplorer you see that at 2012-06-01 08:34:55 he received 100 BTC which he lost (lose 50, win 60, lose 50, lose 71) and then at 2012-06-01 21:27:22 he received the 100 BTC which went on to win lots.

It strikes me as unlikely that he would lose the whole of his first bankroll if there was anything suspicious going on.  Perhaps this was just poor bankroll management on SatoshiDice's part.  The only refunded bet I saw was 3 days after this guy started on his winning streak.

It's really hard to put your finger on, but if you try the PokerStars client, and then try the Seals one, you'll see what he means I think.  The PokerStars client just feels slick.  The games flow smoother, the user experience is just somehow better.  Maybe part of it is that PokerStars is a native app, and Seals is stuck in a browser tab, faking a multi-window environment inside a flash app.  Even running the Windows version of PokerStars in Linux using WINE feels better than the Seals flash app.

Look how they lost over 3000 BTC ($15,000) in a 7 day period (June 2nd to June 9th):



It looks to me like a large amount of those losses stemmed from a single bet:

  http://blockchain.info/tree/7470279

Follow that bet, its winnings, and the various change outputs, and you find a sequence of large bets with unusually high win rates.  I found 45 "lessthan 32000" bets with 26/45 winning (58%) when it should be 48%, and 19 "lessthan 48000" bets with 15/19 winning (79%) when it should be 73%.  The bets are mostly 50 or 100 BTC each.

My knowledge of statistics isn't good enough to work out whether this is reasonable variance, or whether it's suspicious but I suspect that I don't have enough data points to draw any safe conclusions.

Unforgivable!   


But you don't need to find someone's public key.  You only need to find a public key with the same 160 bit hash as theirs.  This will take a classical computer 2^160 guesses, but it will take the QC 2^80 guesses, for all the same reasons you used in the argument with Death & Taxes.


And so the "1 quadrillionth" should be reduced to "1 thousandth".

Sum typoes:


before


player's


'paid' is more commonly accepted as correct


winner's


progressive?


eavesdrop is a single word

That's an interesting attack.  I'll check and see if there are any duplicate transaction IDs with SatoshiDice bets in them.

I looked at just the bets during the period of heaviest losses for SatoshiDice, the 800 blocks 182800 through 183599, and found the following.  My theory of it being double-spent longshot bets is clearly wrong.  The vast majority of the losses were from "under 32000" bets - pretty much coin tosses.  "under 4000" had the highest RTP, but much smaller losses, due to smaller volume of bets:


(I'm ignoring bets which weren't paid out within the 800 blocks in question, though they count in the 'bets' column, and am also ignoring fees paid)

sha256(secret) has been published for all the secrets that will be used in the next 10 years, and the full output of HMAC is shown.  See this 'recent bet':

Not very.  More likely is that they could double-spend their losing bets using pre-mined blocks, and only let their winning bets confirm.

If I control a lot of hashpower, I make sure that every block I mine contains a spend to myself.  Each time I find a block, I double-spend that transaction in the form of a "less than 512" bet at SatoshiDice.  I wait a few seconds to see if I win.  99% of the time I'll lose, but if I win, I throw away the block I mined and let my winning bet confirm, otherwise I submit it to the network as normal, causing the lost bet to never be confirmed.  By waiting to see if I win the bet, I risk my block being orphaned, but my expected win is enough to cover that risk so long I can bet high enough at SatoshiDice.

Is there any flaw in that system?  Have any steps been taken to stop it happening today?

If you let me know when the reimport has finished, and what block was the newest when you ran it, I'll let you know if any transactions are outstanding after that.

Here's the same thing but with dates instead of block numbers on the X axis:

The first 3 have weird input scripts (one paid to a pubkey, and two paid to anyone who could find an address with the correct 160 bit hash).  The last 5 look pretty vanilla.

Here's a graph of how the profit for the site has been at the end of each block since it started.  I don't know if it's bad luck, or if someone is cheating.



There was a reasonably big loss overnight.  Someone bet 5 BTC twice in the same transaction: 5 BTC on "under 1500" and another 5 BTC on "under 6000".  Both bets won.  This seems like a good way of partially evading the low maximum bet limits, since the same random number will be chosen for all bets in a single transaction.

I'd suggest removing Gareth Nelson from 20th in the list.  He's nowhere near as interesting as the Gareth Nelson in 5th place.  And interviewing both of them could confuse people.

There are 8 bets which are more than a week old and which haven't yet been spent in a block.  Every bet should be used to fund (part of) the transaction that's sent back to the bettor.  What happened to these 8?

I just noticed that the script that generates the statistics doesn't know that you can send 0.0054321 BTC to an address to set the payout address for your winnings.  Around 10,000 bets have used this feature.

Making the script aware of this rule changes the output as follows.  Note that the 'Unreturned' amount is now much smaller.  The script was previously considering all bets which had their payout address set manually to be "unreturned".

Update: StrikeSapphire's maximum bet on blackjack is now $15 for new players and $25 for 'silver star' players (ie. players who have attained a certain number of 'player points').  It used to be $5 for new players, but was increased a few weeks ago.  There are now two types of blackjack table available to new players: one with bets from 10c to $5 and another with bets from 25c to $15.  Players with a silver star also have access to $1-$25 blackjack tables.

There's also talk of a 'gold star', but since nobody ever achieved one of those, it's unclear what that gives you access to.