Bad news: Somehow i managed to break the interesting part of multiplayer - Currently the risk score is not taken into account for payout calculation. Will fix that ASAP and then start on the other topics  Fixed! This was just a display issue - accidently I showed the calculated payout also in the "win" row. Example: http://bitbattle.me/game/bfacdfc7e530466cab55a3756290e26d/a little chat feature inside the multiplayer session would be cool
This is the top item already on my multiplayer TODO-List  Groovy... Will be interesting how you accomplish this without registered user accounts. Well, maybe I should rename TODO into WISH then |
|
|
|
Up and running again with the heavily improved payment engine! Noteworthy changes: - TxFee calculation now follows the same rules like the official bitcoin client. All payouts and refunds should now have an appropriate transaction fee, meaning your payouts will always be confirmed fast and no more coins are wasted due to excessive fees!
- The issue of too little confirmed balance in the hot wallet ("Wallet depleted" error) should not occur (so often) anymore. (Yeah, sometime i will increase the balance of the hot wallet to get rid of this issue for good. But I still need to build more confidence )
- Completely switched to using rawtransactions API (before I sometimes had to fallback to using the normal "sendtoaddress" command. And combining both methods is dangerous when something happens in parallel...).
- Payments are now handled asynchronously. You will notice that all payment start in state "pending" and after a short time (<1 second) switch to status "paid"
Bad news: Somehow i managed to break the interesting part of multiplayer - Currently the risk score is not taken into account for payout calculation. Will fix that ASAP and then start on the other topics a little chat feature inside the multiplayer session would be cool
This is the top item already on my multiplayer TODO-List |
|
|
|
|
Site will be offline for a few minutes. Stay tuned...
|
|
|
|
Herbert, is there a reason you do not want to use accounts? I think it would be cool to have some account features. Like each person could customize their experience to his or her liking. For instance, end session buttons, constant sessions, hiding your account activity, things of this nature. All easily accomplished with accounts. So, just curious what brought on that decision to have no accounts? Don't take this as a request or something I see as a problem, just options and curiosity. I still think your site is number 1 out of all the Dice sites (even though I've lost about 800 bucks there. lmao)
Main reason is that requiring registration on a website is a major turn-off for many people, including me :-) Currently it is really easy to get started on bitbattle.me: Enter a name and your payout address and you're set! No need to provide any more details, no need to click on a confirmation link etc. I think this is a very important part to get new players aboard. But I also see your points here, having an account would make it possible to adjust stuff like timeout etc. Maybe best thing would be to make registration optional, so the site stays fully functional without registration, but when you register you can adjust some settings. Why does the payout even need to be tied to a session? There's no concept of a session in dailybitcoins.
It just knows, how much it "owes" to each address, and on request pays it out.
Thanks in advance for the promised change!
Well, i prefer to not hold the users money longer than necessary. Hot wallets are always at stake - The longer I keep users funds in my hot wallet, the bigger it gets and the more I have to compensate in case it gets stolen Another thing is that I like the "all automatic" approach. Right now you can just open your dashboard in the browser and start betting with your preferred client. No need for any interaction on the website, you just use it to watch your bets. Btw I am still busy with the payment engine rework. This includes refactoring of the way transaction fees are calculated and handled on the site. Right now payouts are either taking several hours to get a confirmation or have such a high TxFee that my house edge gets completely eaten up  When this is done I'll do the session changes discussed earlier... |
|
|
|
Problem is that I don't want to add an "end session" button on the website - As the site works without accounts this button would be visible to everybody looking at your session. So anybody could close your running session - I don't understand the problem with that. There's no way that "offender" could change the address, and the only "damage" would be causing an earlier payout, but that is by default already ways too early e.g.: dailybitcoins also offers delayed payouts, and everyone could trigger payout for any address, but it's not really a problem. Hmm.. True, but still it would annoy the hell out of me if my sesssion would be closed by someone else. But i think we can just give it a test. With one of the next updates I will add the end session button and increase the bet and session timeouts. |
|
|
|
Is there a way to keep a session of single-player bets open for more than about a minute? I'm talking about hours or even a day...
During a minute, I hardly get to play more than a single bet, and there's practically no saving on blockchain bloat and miner-fees if I get each win paid out "almost immediately" and thus separately.
Currently the bet timeout is 75 seconds. This could be increased, but of course this means if you want to end a session early you have to wait longer. Problem is that I don't want to add an "end session" button on the website - As the site works without accounts this button would be visible to everybody looking at your session. So anybody could close your running session - Probably not what we want to have. So the current value of 75 seconds is somewhat of a compromise. I am happy to adjust this in one or the other direction - I agree the if using the standard client or blockchain.info wallet for each placed bet you have to perform several mouse clicks, so the timeout is quite small. What is your opinion? Having sessions last hours or days will probably not happen. To protect me from double-spends I am trying to make the win payout contain as much as possible "coins" (actually OutPoints) from your bets placed in the session. If a session would run for such a long time this could lead to huge transactions with several hundred InPoints, resulting in huge transaction fees. Besides UI issues that is another reason why I introduced the bets per session limit. |
|
|
|
The play today was a lot smoother. I emailed you about the only issue I noticed today which was, session would not close by timeout until you actually opened the session. This probably won't be an issue for most because I imagine they stay in session while playing. However, I like to stay on my dashboard while playing so, for people like me, this will happen. It doesn't necessarily make much of a difference to keep the session open as far as I'm concerned but, wanted to alert you.
I'll check out the problem with the session closing today. This happened already once when the task scheduler had a hickup and did not work on new tasks, but this time it seems something different... To everyone else... This game is really great. If you used to be a fan of SD but hate the lag, lost bets, and spam getting in the way, this is the perfect place. You are in a session all by your lonesome and it is EXTREMELY fast.
Thanks for your feedback Slim :-) Btw, you are now by far leading the payout charts, you are close to hit the 1000 BTC mark: http://bitbattle.me/statistics/payout/But the title for "most active player" is still with Carlos: http://bitbattle.me/statistics/active/Edit: Session closing fixed. What a stupid bug  - Someone please tell me to stop coding in the middle of the night... And what is my bounty for 1000btc? I need about 30btc to cover my losses! lol UPDATE: Make that 50btc. lmao No worries, I'll setup another bounty as soon as I have the payment engine update live to give it some stress testing :-) |
|
|
|
The play today was a lot smoother. I emailed you about the only issue I noticed today which was, session would not close by timeout until you actually opened the session. This probably won't be an issue for most because I imagine they stay in session while playing. However, I like to stay on my dashboard while playing so, for people like me, this will happen. It doesn't necessarily make much of a difference to keep the session open as far as I'm concerned but, wanted to alert you.
I'll check out the problem with the session closing today. This happened already once when the task scheduler had a hickup and did not work on new tasks, but this time it seems something different... To everyone else... This game is really great. If you used to be a fan of SD but hate the lag, lost bets, and spam getting in the way, this is the perfect place. You are in a session all by your lonesome and it is EXTREMELY fast.
Thanks for your feedback Slim :-) Btw, you are now by far leading the payout charts, you are close to hit the 1000 BTC mark: http://bitbattle.me/statistics/payout/But the title for "most active player" is still with Carlos: http://bitbattle.me/statistics/active/Edit: Session closing fixed. What a stupid bug - Someone please tell me to stop coding in the middle of the night... |
|
|
|
Launched some updates today: - The lucky number is now displayed in the session log
- The number of bets per session is now limited to prevent huge sessions like Carlos produced ;-).
- When a game is closed the reason for closing is displayed (bet limit reached, time limit reached etc.)
- Fix: Pending Payment issue caused by huge sessions
- Fix: Refunds in multiplayer sessions caused an internal error and were stuck
- Fix: After a bet is rejected due to insufficient wallet balance you had to open/close a multiplayer session in order to be able to bet again
Slim was playing cat and mouse with my hot wallet the last 2 days, repeatedly causing the site to go into "Wallet depleted" mode. I need to rework the strategy here a bit while still making sure not to accept any bet that could not be paid from the hot wallet... |
|
|
|
Somehow the wallet got corrupted, resulting in most part of the balance being unspendable Right now restarting bitcoind with -rescan option - let's see if all comes back again... The rescan seems to have helped. To be sure all is fine I did a more or less complete exchange of the hot wallet - Transferred all funds to my local wallet and back again to the hot wallet - Went through without a problem. The pending payments also have catched up already - So you can roll again :-) |
|
|
|
Somehow the wallet got corrupted, resulting in most part of the balance being unspendable Right now restarting bitcoind with -rescan option - let's see if all comes back again... |
|
|
|
wow. I mean, WOW. Some people are really going nuts. If it weren't for the shareholders I would also have thought the play against themselves just for PR. But this will result in huge shareholder payments, so very unlikely. Over $130,000. I think some real competition to satoshidice might be coming soon.
Indeed But for sure not yet ready for THAT kind of volume. Im still blown away. |
|
|
|
Hah, you managed to screw the stats also: http://bitbattle.me/statistics/lucky_numbers/As you always placed multiple bets in one transaction and for the graph i take the lucky numbers of the last 1000 bets there are a lot of bets with the same lucky number, resulting in a graph that seems to contain much less dots than before :-) |
|
|
|
I'll get back to you with the advertising "Running sessions" -> Once a session is closed, remove it from the list.
Well, it should already do that. Do you mean the running sessions on the front page or on the player dashboard? Show the lucky number in the list (main page and user page) Yep, sounds good! Once the session has >100 bets it starts to get slow, and after 200 bets it really gets slow What exactly got slow? The website updates or the processing of the incoming transactions? I could limit the number of bets that can be placed within one session - When the limit is reached the session gets closed and paid out. As you proofed a script/bot can easily create hundres of bets per session which is not really considered in the UI... Show the total bets and payout in the user page, so we can see the net profit Also good idea! API for betting bots, in SatoshiDice the bots can see if the user won the bet or not with the returning txid, it would be nice for you to have something similar with using API, or create an option to send a callback for a given page once the lucky number is calculated. Yeah, betting API is on my TODO-List, but somewhere with lower priority. I think it could be fun to have bots bitbattle each other in multiplayer mode  But this will take a lot of thinking and also improvemnt of the multiplayer sessions... This is only a display problem - closing, payout and last bet all happened in the same second, and the sorting of session events is done via timestamp which has a resolution of only one second. Definitely also have to change this :-) Also the payment engine had some trouble, you probably noticed that some payments were in state "pending" for several minutes. I also will have a look there what was the problem. Thank you for your feedback, and i hope you come back soon with a few thousand more bets (maybe with some higher stake?) |
|
|
|
Gratulations! You put some stress to my system which is exactly what a wanted to see :-) Bounty has been paid (txID 78b276cac6b7f086dc25707d4e71269131a9b29329a87c0524ee6b287b44c1be). |
|
|
|
|
Invitation sessions are back!
On your player's dashboard you will find a new button "Start Invite Session". Click it to start an invitation multiplayer session. The new session will start in waiting mode and display an invitation link to share - Whoever gets to click this link will join your session!
Another small change is also live:
The "Start Multiplayer" link will now change to "Join multiplayer" when another player started a multiplayer session. This should make it a bit easier to have a multiplayer session as you immediately see when one is started...
PS:
Bet count is still low at around 1600, so still some more to go to claim the bounty!
|
|
|
|
Watching! |
|
|
|
BOUNTY RUN - Get 10 BTC to place bet #5000!Right now (2012-12-08) there are 1477 bets placed. If you place Bet number 5000 you will get a bounty of 10 BTC - no strings attached! Only condition: The bet must be valid (i.e. not a refund). In case Bet 5000 is a refunded one due to any reason, the next valid bet will get the bounty! The bounty will be paid to the payout address of the player placing the bet. The bet number is the first number in the Bet log. Both single- and multiplayer bets can win. Note that the bounty will not be paid automatically, so please allow for some hours until you get your bounty in case i sleep, am offline etc.
|
|
|
|
This is epic news! For those of you (and I know you are not insignificant in number here) who think of Bitcoin as a weapon to be used in the war against the establishment I can see that Bitcoin-Central's move may be seen as fraternising with the enemy. I which case I can see that this is not a service for you.
However, for the rest of us it's a means of potentially integrating Bitcoin more into the normal lives of normal people and in terms of more widespread adoption I can't see (if it really does survive the potential attacks that are being pointed out) that being a bad thing. To the contrary it will be doing a lot to broaden the userbase and consequently strengthen the project - and we all benefit from that regardless of whether we choose to use the service ourselves.
+1 |
|
|
|
|
I also don't see a chance that demurrage will be part of bitcoin protocol.
But could this not be handled somehow on clientside?
Ideas:
-> When generating transactions try to use more of the small outpoints, if possible exact so no new change is needed
This will still have the problem of increased transaction fees, but maybe some tradeoff can be found.
-> Don't generate new change addresses when the change is small, instead "fill up" existing addresses
Privacy risk, so should only be done when the user understands/requests it.
|
|
|
|
|
Show Posts
