UPDATE: Play as a guest WITHOUT owning Minecraft! BitVegas Minecraft - Free BTC

[BitVegas]

Thanks dooglus. I was already aware of this shortly after launch but didn't feel it was necessary to restart the server so soon to fix it. It's fixed now!

[1713556844]

1713556844

[1713556844]

1713556844

[1713556844]

1713556844

[1713556844]

1713556844

[1713556844]

1713556844

[1713556844]

1713556844

[Ryland R. Taylor-Almanza]

Thanks dooglus. I was already aware of this shortly after launch but didn't feel it was necessary to restart the server so soon to fix it. It's fixed now!

I seriously can't wait to use real money on pig racing!

[dooglus]

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"

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

[BitVegas]

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"

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

Ah yes I didn't see you post that part. I will modify the rounding and payouts to be the same

[welliamwallace]

Hey Boss, check out this hand:

http://bitvegas.net/v.php?&g=blackjack&id=9457

It looks like the dealer hit on 16, got a Q, (26), and hit again! for an 9 up to 34

I'm not sure how that happened.

[dooglus]

Hey Boss, check out this hand:

http://bitvegas.net/v.php?&g=blackjack&id=9457

It looks like the dealer hit on 16, got a Q, (26), and hit again! for an 9 up to 34

I'm not sure how that happened.

Hey!  We were keeping quiet about this bug in the hope that we could exploit it! 

But seriously, there's another issue here:

Deck: 2d,6d,9h,Th,3d,7d,Qc, ...
Dealer Cards: 6d,3d,7d,Qc,8h (34)
Player: Cards : 2d,9h,Th (21)

The dealer should get the 2nd and 4th cards, but looks like he got the 2nd and 5th.  The deal typically gives one card to each player, then one to the dealer, then one to each player, then one to the dealer, then the players get to play.

Any finally:

Public Key: a7209d83a968a3090b51ed37f13f917c8997251b7c8e0e03f206f633b1a5dd10
Private Key: [2d,6d,9h,Th,3d,7d,Qc,8h,...

Those aren't a public and private keypair.  One's a hash of the other.  I'd call the "secret" and "hash(secret)" or some such to make it clear you're not using private key crypto here.

[welliamwallace]

But seriously, there's another issue here:

Deck: 2d,6d,9h,Th,3d,7d,Qc, ...
Dealer Cards: 6d,3d,7d,Qc,8h (34)
Player: Cards : 2d,9h,Th (21)

The dealer should get the 2nd and 4th cards, but looks like he got the 2nd and 5th.  The deal typically gives one card to each player, then one to the dealer, then one to each player, then one to the dealer, then the players get to play.

Wow, excellent point. OP, would you mind providing some detailed description of how this bug occurred and how you fixed it (When you do)?

It seems like you have both

• A hit vs bust bug (The dealer hit on 26 when it should have registered as a bust)
• A dealing order bug (The dealer should have gotten the Ten of Hearts as their down card)

Which may or may not be related

EDIT: It seems that the software is not dealing the dealer a "down" card (In the case of a a 1 player game, one card up to the player, one card up to the dealer, one card up to the player, one card down to the dealer, all of which should occur before the player is allowed to hit). See this example, or any other game where the player hits at least once: http://bitvegas.net/v.php?&g=blackjack&id=9462

You need to internally deal the 4th card (in a 1 player game) to the dealer, even if you do not display it until after all the players are finished making their moves

[BitVegas]

Great to hear this feedback guys.

The blackjack is intentionally dealing in 'no hole card' rules of blackjack. Which means the dealer does not receive his second card until all the players have finished betting.
This is common to blackjack in Australia but I can change this if the players desire to use a hole card.

The bug with the dealer hitting on 26 is interesting. At first glance this cannot be exploited in any way but it should also be fixed so I will look into this asap.

Also yes you are correct I shall rename 'private key' to 'secret'


UPDATE: I have found the bug.
When a player ends his turn a nextTurn() function is called.
That function then checks if no more turns are to be had and noMoreTurns() is called.
noMoreTurns() then proceeds to first deal the dealer one card and then deal the dealer his cards until he hits hard 17 or higher. The first card was dealt without checking due to using a 'no hole card' system explained above.

Where the bug comes in. nextTurn() is automatically called if you hit 21 (Blackjack or not). It is then called again due to the nature of the system.
(You can check all the problem hands and the player always has 21 in value)
This essentially is calling nextTurn() twice, which is calling noMoreTurns() twice.
The bug was with noMoreTurns() automatically dealing the dealer one card before checking the dealers value.

Two bug fixes were added:
nextTurn() now checks if the game is already over before calling noMoreTurns()
noMoreTurns() now checks the dealers value BEFORE dealing any cards to the dealer.


I haven't pushed this update to the server yet as there's a few other things going in with it when it's ready. This bug had no actual effect on the game but was just weird to see.

[welliamwallace]

Thank you for the detailed reply! I agree, it looks like it couldn't have been exploited anyways. As for the no hole card rules (I was unaware this is how they played in Australia!) With a truly random 8-deck shoe, it shouldn't matter whether the dealer's second card isn't dealt until the players are finished, so I am not concerned if you leave it that way. Again, when you get around to putting up a detailed list of the rule variations, just be sure to include that so people aren't confused.

Thanks again for the follow-up!

[dooglus]

With a truly random 8-deck shoe, it shouldn't matter whether the dealer's second card isn't dealt until the players are finished, so I am not concerned if you leave it that way.

Except from a 'provably fair' point of view it would be better if the players (one of who might have admin access to the server and be able to see the deck) had as little influence on the dealer's hand as possible.

Having the dealer deal his hole card before the players act decreases the amount of influence the players have on the dealer's hand.

At the blackjack tables in real casinos you'll often hear "you took the dealer's bust card!" from players who don't understand that I'm just as likely to worsen the dealer's hand than I am to improve it when I play incorrectly.  But in this case, where one of the players may be able to see the undealt cards it's more of a concern.

[BitVegas]

The new provably fair system is now up for your testing on BlackJack.

It will be added to the other games over the next few days.

We have also added in Jackpots for Minefield

[BitVegas]

Poker is in the works and will be available for play money testing soon!

[BitVegas]

We are now giving away FREE bitcoins just for being online!

[fergalish]

I'm on minecraft chatting with murderscene & dooglas about the provably fair betting. What I'd like to see is the sha256 of each game's "secret" *before* I play.
So, you could shuffle the deck, take the sha256sum, and write it in the blockchain the day before you use it. Then you take the user's lucky words, reshuffle accordingly, and play the game. On the results page (bitvegas.net/....) you can show the whole process which is verifiable.

EDIT: this allows the user to know that the original shuffle was generated before the game was played.

See http://btcmultiplier.com/keys.php for how they wrote a 40 year list (!) of sha256s into the blockchain with a single transaction.

Edit2: I'm just thinking, it would be far better to use a public source of entropy. For example, assuming a 3-player game in which no-one says any lucky words (or some people say predictable lucky words), what's to stop a casino from tending to favor decks with top cards: A,2,5,8,K,4,6,9, so that the dealer gets A & K blackjack! So the deck should be reshuffled with a random number just before the game, but that the random number can be proven to be outside the control of the casino.  e.g. btcmultiplier use the transaction ID.

In short, I'm saying that, assuming bitvegas is using, and not filtering in it's favor, a good random number gen, then the fairness is provable. It would be great if you could also prove the randomness.

Any thoughts?

[dooglus]

In short, I'm saying that, assuming bitvegas is using, and not filtering in it's favor, a good random number gen, then the fairness is provable. It would be great if you could also prove the randomness.

I think I prefer it how it is; it's cleaner, and every player can totally mess up any team of players' attempts to fix the deck by picking his own random words.

I do like the idea of having a pre-published list of house seeds, indexed by game number, and having the game number in the chat before each deal so I don't have to keep clicking on the green checkmark.

But I came here to say:

1) how about having a racecard showing the next few pig races, rather than just the next one.  Let me bet on multiple upcoming races at once rather than having to go back to the betting terminal between every race.

2) maybe add some copies of the existing games but for real-money players only.  Now that the casino is teeming with life (thanks to the millibit faucet) the minefield games are often occupied by playmoney players.  It would be nice if there were rooms which the playmoney players couldn't tie up.

3) did you say you added poker?  I didn't find it yet.

[fergalish]

In short, I'm saying that, assuming bitvegas is using, and not filtering in it's favor, a good random number gen, then the fairness is provable. It would be great if you could also prove the randomness.

I think I prefer it how it is; it's cleaner, and every player can totally mess up any team of players' attempts to fix the deck by picking his own random words.

But you still could. Look at it this way. On Friday the house shuffles all the card decks for the week's games (it has to be some time before the decks are used). For each game, it performs SHA256 of the deck, resulting in files like this:

Decks.txt:
MondayGame1Deck: KingSpades,AceDiamonds,4Clubs,..........
MondayGame2Deck: ......
...
SundayGame1000Deck: ....

Hashes.txt
MondayGame1Hash: sha256....
MondayGame2Hash: ......
...

So, you publish Hashes.txt on the preceeding Friday, and burn *it's* hash into the blockchain somehow.

Now at the start of each game, the players say their magic words, and these magic words shuffle the deck according to some fixed algorithm, and the game is played.

Now, in the event that no player says any magic words, or that JohnDoe is a regular player and he *always* says "abrekadabra", we need to prove that the house is not somehow filtering their decks (i.e. on Friday, the house shuffles their decks, applies "abrekadabra" and checks to see if the deck is favourable to them, given that JohnDoe comes in to play every Tuesday evening at 8pm). This would require an extra source of random shuffling from an externally verifiable source of entropy. e.g., the blockchain. So the shuffling algorithm need only insert an extra "lucky phrase", which is the block hash, or the merkle root, of the latest block in the block chain. Given that the house can't possibly know this value on Monday morning when they shuffle all their decks, this would absolutely prove that the house is not pre-filtering their decks.

After the game is played you allow the players to view:

1. the hash of the initial shuffle which is burned into the blockchain via the file Hashes.txt
2. the initial shuffle
3. the players magic words, the latest block|merkle hash, and the shuffling algorithm
4. the new shuffled deck
5. the play
6. the winner(s)


Oh... gosh, if we wanted to be *really* paranoid, the house *might* technically have a choice over which blockhash to use - the latest one, or maybe the one before that. If one or the other turn out to be more advantageous (again assuming the players say nothing, or say something entirely predictable), the house could claim they hadn't received the latest block at the time of the game. This would be solved by putting a visible blockchain counter in each gaming room though, or maybe writing it into the chat.

Hot damn, I should build myself a casino!

[mornaner]

Interesting, I will try this when I get home.

[dooglus]

[...] This would be solved by putting a visible blockchain counter in each gaming room though, or maybe writing it into the chat.

It's a tradeoff between covering absolutely every way the house could cheat, and not flooding the chat with too much information.

Instead of "the most recent block's hash" they could just use "the next block hash after the block containing the hash of the pregenerated shuffles".  That's both unpredictable and fixed.

[fergalish]

[...] This would be solved by putting a visible blockchain counter in each gaming room though, or maybe writing it into the chat.

It's a tradeoff between covering absolutely every way the house could cheat, and not flooding the chat with too much information.

Instead of "the most recent block's hash" they could just use "the next block hash after the block containing the hash of the pregenerated shuffles".  That's both unpredictable and fixed.

That would do fine too. I like it.

[dooglus]

they could just use "the next block hash after the block containing the hash of the pregenerated shuffles".  That's both unpredictable and fixed.

That would do fine too. I like it.

I'm dumb.  Why not just use the hash of the block containing the hash of the shuffles?  That's unpredictable too, unless he mines the block himself.  And if he can mine arbitrary blocks whenever he wants then nothing's safe...