I would rather it was something that I can confirm for all players.  For example, if you take the last thing said by each player who bet, and show that on the webpage, I can check that you have the right thing for all players.

If a player hasn't spoken, use the empty string for them.  Then I can say "go number 3!" before the off, and actually have it influence the outcome.  If a player doesn't care to change their seed (by talking) they don't have to, and they contribute the same to the seed for each event until they happen to speak.  Just a simple sha256(player1string|player2string|...) would do for the 'client(s)' seed.

What do you think?

Sometimes they would just publish the binary, as a hex dump, and you had to type in the hex characters.  That was really painful.  At least while typing in source code you could get an idea of what was going on.  But hex just looks like hex...

Yes.  The same goes for pig racing and roulette too.  Some players will tend to bet more on long-odds pigs, others will more often back the favourites.  Some players favour red, some always bet on zero, etc.  But if the player plays randomly, there's no "bad deal".  In blackjack there is.

One thing that occurred to me about the provable fairness:

For roulette, minefield, and pig racing, there's no such thing as a "bad deal" for the player.  You pick the result in advance, publish the hash, and the user can verify after the event that you chose the result before they bet, so you can't be cheating.  (Well, if a player is playing red over and over again you could deliberately pick black over and over, and publish a hash of you picking black before the player places his bet).

With blackjack however, there is such a thing as a "bad deal".  When you're playing against a single player you can deliberately pick shuffles which give the dealer blackjack more often than he should.

The way most provably fair blackjack sites (all 2 of them?) work is that they allow the player to provide part of the random seed, publish the server half of the random seed before the game, and publish the shuffle algorithm.  That way the casino has no way of picking preferable shuffles.  bitZino has this great writeup about how it works.

Currently your blackjack doesn't appear to be provably fair.  All you seem to be proving is that you picked the (possibly rigged) deck before the players played, rather than during or after.

Comments?

xubuntu-desktop or lubuntu-desktop will work too.

You told us previously you didn't have any record of the client's games:



That sentence like totally parse error.


Can you clear up for us what happened?  How was a customer able to think he had won thousands of dollars whereas you couldn't find any record of his play?

That's what I took away from it too...  SatoshiDice pays out 64000 times a player's stake without missing a beat.  The 'bottom line' is making good progress on recovering from the big payout, too (which is the sudden drop 2/3 of the way through Feb 24th):

Notice that when I win a 1 BTC bet on a 3.5x payout, I expect to get 3.5 BTC, not 3.4975 BTC.

I expect that's a rounding error somewhere, but you should try to make rounding errors work in the player's favour.  Never give them less than you promised them.   If you're rounding 3.4975x up to 3.5x when displaying the promised odds, you should also round it up to 3.5x when paying out...

When I win a 1 BTC hand of blackjack, it tells me I won 2 BTC.  That includes my original stake, not just my profit.

When my pig wins at 2x multiplier on a 1 BTC bet, it tells me I won 1 BTC.  That's just my profit, and doesn't include the stake.

I think you should pick one of the other and be consistent across all games.  I think the blackjack way is better, because then you don't have to take the stakes into account.  Currently if I bet 1 BTC on 2 different 2x pigs and one wins, it tells me I won 1 BTC, which isn't true at all.  I won 2 BTC in total, and bet 2 BTC, so my net profit is 0 BTC.  If you're going to subtract the stake you should subtract all the stakes, not just the winning one.

A real example:

I had 3.8195 BTC.  Bet 1 BTC on 3 different pigs, then had 0.8195 BTC.
One of my pigs won, with a 3.5x payout.
The game told me I had "won 2.4975", and then my balance was 4.317 BTC.  So I was up 0.4975 after winning 3.4975.
There's no 2.4975 anywhere.

It's probably easier to read here: http://www.satoshidice.com/lookup.php?tx=1catvhe since it's tabulated.

In summary, he has:

221 losing bets, betting 11.36 and getting 0.00817712 back, making a loss of 11.35182288
28 winning bets (other than the big win) betting 2.816 and getting 11.22561029 back, making a profit of 8.40961029
that's a net loss of 2.94221259 BTC if we don't count the lessthan 1 win.

http://blockchain.info/charts/blocks-size shows that the current blockchain size is 5167 MB.



By my calculations it's in fact around 5648 MB.

How is the size calculated for that chart?

Edit: I just added up the individual block sizes:


and got a grand total of 5,921,583,854 bytes for the first 222,968 blocks.  That's 5,647.26 MB.

It's not the first time someone's rolled a zero, but it is the first time someone has rolled a zero when playing "lessthan 1".

In 6.5 million bets we'd expect to see something of the order of 100 zero rolls.

There have only been 88,000 "lessthan 1" bets, so 1 is the most likely number of winners.

A deck rich in face cards is good for the player.  Card counters increase their bet when there are more than the average number of face cards left.  So if (and I very much doubt it) more face cards are showing up than should, I wouldn't complain about it!

I'm out in the sticks in Canada.  It's a huge country, and seems to only have cell coverage in the populated areas and along the highways.  I don't have any other services either, like electricity, water, etc. so it's not just cell service I'm missing...


Well, that variable is only used to tell 'jacks' (the C program that works out which cards to hold) what the payout for a royal flush is.  'jacks' only knows the payouts for 5 chips, and so I tell it the royal is worth 4000 chips if the progressive pot isn't available.  It doesn't need to know how many chips we're playing for.  I could tell it how many chips are being played for, and have it multiply all the payouts by that number of chips, but it seems simpler to just have it always use the same payouts.

I'll add monthly profit, expected dividend, etc. to the report soon.

Someone hit 'lessthan 1' for the first time yesterday: http://www.satoshidice.com/full.php?tx=a874d43fb31c3a0785a6828006136c6d3a3cb79c3c19fe4c7caf770f42c6a3c7

Bet Amount: 0.02000000
Outcome: WIN
Payment: 1279.99950000

Just wow!  Bet $0.60, win $38,400.

Someone hit 'lessthan 1' for the first time yesterday: http://www.satoshidice.com/full.php?tx=a874d43fb31c3a0785a6828006136c6d3a3cb79c3c19fe4c7caf770f42c6a3c7

Bet Amount: 0.02000000
Outcome: WIN
Payment: 1279.99950000

Just wow!  Bet $0.60, win $38,400.

I guess the increasing interest in bitcoin as a whole outweighs the effect of old players getting bored of the game.

Here's today's update, including the chart showing raw number of bets.  It's pretty much a straight line, oddly enough.