Topic: bitbattle.me - no deposit, instant bets, ZERO waiting! 0-conf accepted! - page 7. (Read 16422 times)
January 12, 2013, 05:34:37 PM
Well, all my current bets are being refunded due to "potential double spend".
January 12, 2013, 05:00:59 PM
- 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.
...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 
January 11, 2013, 07:15:49 PM
I am working on a refine of the double-spend protection mechanism.
The following rules will be in place:
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://bitcointalksearch.org/topic/success-double-spend-against-a-satoshidice-loss-130764 (In general I think people will continue to refine this attack, so it will always be a cat-and-mouse-game anyway...)?
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://bitcointalksearch.org/topic/success-double-spend-against-a-satoshidice-loss-130764 (In general I think people will continue to refine this attack, so it will always be a cat-and-mouse-game anyway...)?
January 11, 2013, 06:50:06 PM
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.
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.
January 10, 2013, 05:34:04 PM
Up again!
January 09, 2013, 09:57:53 AM
January 09, 2013, 05:17:05 AM
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
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/
January 08, 2013, 05:27:21 PM
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
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
January 08, 2013, 04:04:02 PM
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?
January 08, 2013, 03:58:43 PM
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?) January 08, 2013, 12:22:02 PM
Would it be possible to add the risk amount and bet counter on the session page?
January 05, 2013, 09:43:12 AM
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:
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
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
January 02, 2013, 05:03:53 AM
Statistics have been extended today:
@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
- 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 
January 01, 2013, 09:21:40 AM
Argh, it happens so often for me, only on bitbattle. ;-)
December 29, 2012, 07:27:57 AM
Update:
Last point should provide especially Martingale-style player a bit more fun
Edit:
Additional change: Closing a session is now only allowed 30 seconds after the last bet has been placed.
- Fix display bug when other player's bets show up in dashboard
- (hopefully) fix display bug when bets show up multiple times in dashboard
- Increase maximum bet stakes by 50%!
Last point should provide especially Martingale-style player a bit more fun
Edit:
Additional change: Closing a session is now only allowed 30 seconds after the last bet has been placed.
December 29, 2012, 05:43:21 AM
Would it be possible to only see bets placed by the person who's profile you have open? For instance, I have my profile open but it is showing everyone else's bets instead of just mine. Can't we just use the main page for viewing all bets and then when you go in to a user profile it just shows the bets made by that profile?
Especially since the Bet logs while in a user profile have no names attached to the entry
I see that symptom casually coming and going: Suddenly I see other users' bets
on my dashboard, and a refresh later I see again only my own bets.
Ditto the other bug where the latest bet result is shown umpty times, but all's
back to ok after a page-reload.
on my dashboard, and a refresh later I see again only my own bets.
Ditto the other bug where the latest bet result is shown umpty times, but all's
back to ok after a page-reload.
Hmm, obvious bugs! Should be an easy fix on the javascript/template side - Will check that later today.
PS: ceterum censeo automatic session-timeout delendam esse
Hah, you made me lol :-) Will think about that a bit more. If there is no session timeout at all the number of ongoing sessions will increase with increase of userbase and at some point be a ressource problem. But I could increase the session timeout again. With current limit of 50 bets/session most users will eventually hit that limit anyway... December 28, 2012, 09:46:21 PM
Would it be possible to only see bets placed by the person who's profile you have open? For instance, I have my profile open but it is showing everyone else's bets instead of just mine. Can't we just use the main page for viewing all bets and then when you go in to a user profile it just shows the bets made by that profile?
Especially since the Bet logs while in a user profile have no names attached to the entryI see that symptom casually coming and going: Suddenly I see other users' bets
on my dashboard, and a refresh later I see again only my own bets.
Ditto the other bug where the latest bet result is shown umpty times, but all's
back to ok after a page-reload.
PS: ceterum censeo automatic session-timeout delendam esse
December 28, 2012, 09:07:50 PM
Would it be possible to only see bets placed by the person who's profile you have open? For instance, I have my profile open but it is showing everyone else's bets instead of just mine. Can't we just use the main page for viewing all bets and then when you go in to a user profile it just shows the bets made by that profile?
Especially since the Bet logs while in a user profile have no names attached to the entry
December 28, 2012, 09:05:27 PM
Would it be possible to only see bets placed by the person who's profile you have open? For instance, I have my profile open but it is showing everyone else's bets instead of just mine. Can't we just use the main page for viewing all bets and then when you go in to a user profile it just shows the bets made by that profile?
December 23, 2012, 12:34:41 PM
Jump to: