bitbattle.me - no deposit, instant bets, ZERO waiting! 0-conf accepted!

[SteamGamesBTC.com]

Argh, it happens so often for me, only on bitbattle. ;-)

[Herbert]

Statistics have been extended today:

• Show player in Biggest Wins, Biggest Losses, Singleplayer and Multiplayer stats
• Show tooltip with number of bets taken into account for Win Percentage stats

@steamgames:
Have a look at your "win percentage" stats. Indeed it seems you had some real bad luck there on the lessthan29491 bet  But on the other hand this means you can expect to start winning there if you continue 

[Herbert]

Spent quite some time hunting down bet processing deadlock that still happens every few days... I think I found the reason, but as it happens so rarely you can never be sure :-)
Changelog for today:

• Rework session close logic to prevent deadlocks
• Add some more crosslinks to blockchain.info for transactions and addresses
• Some more code cleanups in javascript part

Most visible change should be session close logic. Before the update the session details page triggered a reload() when the timers expired. This is now not necessary anymore as the server anyway sends a message to the client when the session is closed.
Please report here if you spot any troubles or delays!


Edit:
While at it I also improved live connection handling with IE. Should be much more stable now using flashsocket connection 

[IXIslimIXI]

Would it be possible to add the risk amount and bet counter on the session page?

[Herbert]

Would it be possible to add the risk amount and bet counter on the session page?

Should be possible, but might need some layout tweaking. Probably would need to decrease overall font size for the tables like on the main page. (You meant to display them in the "Running session" table in the dashboard, right?)

[IXIslimIXI]

Would it be possible to add the risk amount and bet counter on the session page?

Should be possible, but might need some layout tweaking. Probably would need to decrease overall font size for the tables like on the main page. (You meant to display them in the "Running session" table in the dashboard, right?)

You got it. It just would be cool to be able to see everything about the session while you are in it without having to go to your profile to see though, know what I mean?

[Herbert]

Upcoming change of rules for lucky number calculation

I decided to follow the amazingly simple proposal by dooglus (which is also implemented by SDice in the meantime):

They could fix that by using a different 'lucky number' for each bet.  Use the output number as well as the txid to determine the lucky number.  Then they can allow lots of max bets on the same game in a single transaction, without increasing their risk of ruin.

Starting tomorrow morning 1:00 (2013-01-09 01:00 UTC) the calculation of lucky numbers will also take the output index into account. At the same time the bet details pages will also show the new way to verify the lucky number and bet result.

This change is only important for people doing "sendmany" transactions (placing multiple bets in one single transaction). Right now the lucky number is only depending on the transactionID, so each bet of a sendmany transaction will have the same lucky number. This makes it possible for people to effectively avoid the max bet limit, because if the lucky number is low all or most of the bets will win. So there is less statistic variance for me, resulting in a higher risk of needing to do huge payments at once.

When the change is effective each bet of a sendmany transaction will have an individual lucky number. This increase statistical variance, so the risk for me having to do a huge payment is reduced a lot.

Important:
This does not change anything on the win odds or fairness of bitbattle.me! This is just a change to increase the variance of bet results, enabling me to increase the max bet limits and/or reduce the necessary balance of the hot wallet.

I expect the change to go through smoothly. Shortly after this is done also bet limits will be raised and placing multiple bets of the same type within one transaction will be allowed

[ingrownpocket]

Upcoming change of rules for lucky number calculation

I decided to follow the amazingly simple proposal by dooglus (which is also implemented by SDice in the meantime):

They could fix that by using a different 'lucky number' for each bet.  Use the output number as well as the txid to determine the lucky number.  Then they can allow lots of max bets on the same game in a single transaction, without increasing their risk of ruin.

Starting tomorrow morning 1:00 (2013-01-09 01:00 UTC) the calculation of lucky numbers will also take the output index into account. At the same time the bet details pages will also show the new way to verify the lucky number and bet result.

This change is only important for people doing "sendmany" transactions (placing multiple bets in one single transaction). Right now the lucky number is only depending on the transactionID, so each bet of a sendmany transaction will have the same lucky number. This makes it possible for people to effectively avoid the max bet limit, because if the lucky number is low all or most of the bets will win. So there is less statistic variance for me, resulting in a higher risk of needing to do huge payments at once.

When the change is effective each bet of a sendmany transaction will have an individual lucky number. This increase statistical variance, so the risk for me having to do a huge payment is reduced a lot.

Important:
This does not change anything on the win odds or fairness of bitbattle.me! This is just a change to increase the variance of bet results, enabling me to increase the max bet limits and/or reduce the necessary balance of the hot wallet.

I expect the change to go through smoothly. Shortly after this is done also bet limits will be raised and placing multiple bets of the same type within one transaction will be allowed

http://bitbattle.me/game/cf91a9db835341be9997cbb7c9403923/ 

[Herbert]

http://bitbattle.me/game/cf91a9db835341be9997cbb7c9403923/ 

Thanks for testing 

[Herbert]

Need to cleanup some unconfirmed transactions from the wallet. Site will be offline for a few minutes...

Up again!

[Herbert]

I rolled out an update of the payment engine today:
There was one bug that could lead to your session payout including unconfirmed inputs from other players (Your own unconfirmed inputs are always part of the payout). As there have been some double-spend attempts lately there was at least one payout which never confirmed since it contained a double-spent input.
This bug is fixed now, all session payout inputs are now either from your own bets or have at least one confirmation.

[Herbert]

I am working on a refine of the double-spend protection mechanism.

The following rules will be in place:

• If a transaction has fee >= 0.0005, and all inputs are confirmed -> ALLOW
• If a transaction has fee < 0.0005, but all inputs are confirmed -> ALLOW
• If a transaction has fee < 0.0005, and at least one input is unconfirmed -> REJECT
• If a transaction has at least one unconfirmed input but higher fee (>= 0.001) -> ALLOW
• If a transaction has at least one unconfirmed input and fee < 0.001 -> REJECT

Note that "REJECT" means the transaction is immediately sent back to the players payout address. As bitbattle.me is all about realtime there is no point in waiting until the transaction gets confirmed.

Opinions? Can you think of a scenario where I would reject valid transactions? Or not detect double-spend attempts like described in https://bitcointalk.org/index.php?topic=130764 (In general I think people will continue to refine this attack, so it will always be a cat-and-mouse-game anyway...)?

[Herbert]

• If a transaction has fee >= 0.0005, and all inputs are confirmed -> ALLOW
• If a transaction has fee < 0.0005, but all inputs are confirmed -> ALLOW
• If a transaction has fee < 0.0005, and at least one input is unconfirmed -> REJECT
• If a transaction has at least one unconfirmed input but higher fee (>= 0.001) -> ALLOW
• If a transaction has at least one unconfirmed input and fee < 0.001 -> REJECT

Note that "REJECT" means the transaction is immediately sent back to the players payout address. As bitbattle.me is all about realtime there is no point in waiting until the transaction gets confirmed.

These rules are now active on the site. Please report here if you placed a legit bet and it was rejected - I am sure thes rules will need some refinement :-)

...Shortly after this is done also bet limits will be raised and placing multiple bets of the same type within one transaction will be allowed

Multiple same type bets are now allowed. Bet limits still unchanged though - Still need to do some more math to decide which amount is okay without risking going bankrupt 

[IXIslimIXI]

Well, all my current bets are being refunded due to "potential double spend".

[Herbert]

Well, all my current bets are being refunded due to "potential double spend".

Nice I'm checking your transactions now. Which client are you using?

Edit:

• If a transaction has at least one unconfirmed input but higher fee (>= 0.001) -> ALLOW
• If a transaction has at least one unconfirmed input and fee < 0.001 -> REJECT

I changed these two rules so that a tx fee of 0.0005 is sufficient. Let's see how it works. 

[IXIslimIXI]

It varies, sometimes blockchain.info and sometimes local bitcoin app. That particular instance was blockchain. testing...

[IXIslimIXI]

It's working now BUT, what is odd about this previous incident is that I had already placed several bets prior to those failing. 

[IXIslimIXI]

Well, all my current bets are being refunded due to "potential double spend".

Nice I'm checking your transactions now. Which client are you using?

Edit:

• If a transaction has at least one unconfirmed input but higher fee (>= 0.001) -> ALLOW
• If a transaction has at least one unconfirmed input and fee < 0.001 -> REJECT

I changed these two rules so that a tx fee of 0.0005 is sufficient. Let's see how it works. 

Geez, now I'm having a problem with losing... Obviously something is broken again, could you fix that as well?! lol

[Herbert]

It's working now BUT, what is odd about this previous incident is that I had already placed several bets prior to those failing. 

That's correct. The transactions that went through had already confirmed inputs, so they went through regardless of the txfee. The rejected ones had unconfirmed inputs when they came in, so i checked the txfee.

Geez, now I'm having a problem with losing... Obviously something is broken again, could you fix that as well?! lol

[IXIslimIXI]

It's working now BUT, what is odd about this previous incident is that I had already placed several bets prior to those failing. 

That's correct. The transactions that went through had already confirmed inputs, so they went through regardless of the txfee. The rejected ones had unconfirmed inputs when they came in, so i checked the txfee.

Odd, I shouldn't have had any unconfirmed coins in my wallet today. Oh well...