Site will be down a few minutes for upgrading...


The upgraded payment engine is now rolled out. With this change I am confident that the site will not run out of confirmed balance again (at least not due to long confirmation time ). I put a lot of time in testing this, but as always please let me know when something seems not correct!

There was a bug in multplayer payment code that could lead to not paying out all players of a session 
So far only one session was affected by this bug (http://bitbattle.me/game/31a91d4518b14139bbe1091356ea9488/). Player SHatschiM did not receive his 0.094 payout when the session was closed. The bug is now fixed and the payment has been made (you can see it now in the session log, the latest payment was issued several hours after the session was closed).

SHatschiM, if you read this: Please accept my apology for the late payment!

Thought this might be worth sharing with you :-):
Here is a snapshot from my balance tracker at that time (Red is unconfirmed, blue is confirmed balance):

Each downwards step on the blue line is the payout of a session with positive outcome, so in addition to the unconfirmed coins that came in during the session confirmed funds had to be used for the payout.
The first part is what i usually see: After a relative short time the incoming bets get confirmed, so the amount of confirmed coins jumps up and down, but overall keeps quite stable. But then at 5:59 the confirmations just stopped and the confirmed balance started tumbling down...

Good news - I think i found a possibility to decrease the amount of confirmed coins necessary for filling up a payout while keeping my strict rule of using unconfirmed coins only if they were received by the same player. This requires some code change and testing, but seems totally doable .

Good question. For now I increased the hot wallet balance, but I don't think it will be enough to cover a situation like this morning where it took 4 hours to confirm the inputs. I am still trying to understand exactly how this situation evolved - Hope I can come up with a strategy different from "just put ten times more into the hot wallet"...

Not broke, but same situation like this morning. Site is sitting on a pile of unconfirmed inputs from your bets, so the confirmed balance is too low to accept new bets.

Which client do you currently use? Because I was more or less assuming that all clients will prefer confirmed inputs to unconfirmed ones when initiating a transaction. I looked at some of your bet transactions and am quite surprised that seemingly all your bet's inputs are consisting of my previous payment outputs, yet unconfirmed. This is generating huge chains of unconfirmed transactions - I can understand that these transactions are not preferred by miners even if they all have txfees set.

In case you wonder/noticed:
This morning there was a somehow strange situation. Starting from 5:59 until 10:15 not a single incoming bet transaction got confirmed. As Slim was quite active in this timeframe the available amount of confirmed coins gradually decreased until it hit the safety limit. Therefor the site went into "Backend Down"  mode, not accepting any new incoming bet and immediately refunding it. Then came Block #216886 at 10:15 including all missing transactions at once

I really did not expect that no confirmations come in for such a long time. I almost started panicking about a new/unkown type of double-spend attack . But as Slim really seems to be a nice person as far as I know him I knew it must be something else.

So, Lesson learned? Hot wallet balance needs to increase to have more confirmed coins available any time And obviously more players are needed, so that if one player/wallet has this kind of problem there are enough other transactions that still go through fine. (I suspect the main problem is quite long chains of unconfirmed transactions being built up between bitbattle and Slims wallet. Unconfirmed win payouts were immediately again coming in as new bet, again ending up in the next unconfirmed payout...)

Functionality/Security update:
Starting immediately bitcoinmonitor.net agents will NOT trigger 0-confirmation notifications on transactions which have a locktime set. Notifications for transactions with locktime will only trigger when the transaction gets a first confirmation.
The change is fully backwards-compatible: If you have an agent setup to notify on 0 confirmations you will get 2 notifications as soon as the transaction gets a confirmation: First for status "unconfirmed", followed by "one confirmation".

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.

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

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

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 :-)

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 

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

Which client are you using? Maybe there is a problem with the coinselection...

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.

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

Up again!

Thanks tjohej :-) I'm glad you like the service!

Thanks for testing 

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):


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

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?)

Looks funny. TL;DR? Have no idea what I'm doing