Party on! I am still totally overwhelmed by this amazing technology. Looking forward to all the great stuff that is going to happen  |
|
|
|
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  |
|
|
|
Yep, just above your post :-) At 2013-01-03 00:00 GMT (In about an hour) the logic for calculating the bet hash which was hmac512(secret, bet_transaction_id) will be changed to hmac512(secret, bet_transaction_id + ":" + bet_output_index)
This means that each bet inside a single transaction will get a different lucky number. With this change, we will be relaxing some of our max check logic so that players will be able to make multiple bets to the same address in a single transaction.
Currrently, if a player sends a transaction of:
{
250 BTC -> 1dicec9k7KpmQaA8Uc8aCCxfWnwEWzpXE
250 BTC -> 1dicec9k7KpmQaA8Uc8aCCxfWnwEWzpXE
}
The first one will be processed normally, the second one will be considered above max.
At the switch over at 00:00 the same transaction will be processed as two separate bets with two separate lucky numbers and won't be considered above max.
I'll be updating the docs to reflect this as well.
|
|
|
|
Okay, now it's clear - I will definitely go for a specifc string! Thank you all for the explanations  |
|
|
|
Thanks for your answers so far! it probably shouldn't just be a random string, because someone may suspect that you want them to sign your public key. Hmm, I don't get it. Why would I want someone to sign my public key? And which public key do you mean? |
|
|
|
|
I'm working on a webapp which requires that a user proofs ownership of an address.
Current idea is that user has to sign a random string with his address. On the server I can use the rpcmethod "verifymessage" with the bitcoin address, same random string and signature.
Does this make sense / Is there a better or alternative approach?
|
|
|
|
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  |
|
|
|
Update: - 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. |
|
|
|
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.
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... |
|
|
|
PS.... check your email Done |
|
|
|
Just deployed some improvements which should either fix the problem of stuck bets or help me fix it when it appears again. As expected it is some kind of concurrency problem  |
|
|
|
Last night the handling of incoming bets was stuck. Affected players were "SlickTheNick", "Sluice", "slim", "ConnorCG", "Doomed" and "avl42". System has catched up now and all your bets have been placed. I am really sorry for the delay and looking hard to find the root cause, as this is now the second time this has happened  How about a way to see if there are any open multiplayer sessions open that arent currently playing? like a session that just has one person so we dont have to try and enter a room. I bet more people will play them if you could see that
You can already tell by the label of the "Start Multiplayer" button in your dashboard. As soon as someon starts a multiplayer session, the button label changes to "Join Multiplayer". But I agree this is not very prominent/visible - I try to improve that |
|
|
|
|
Just had an idea about the "close session" button:
How about enabling the "close session" button only when no bet has been place for something like 1 minute? This way the "vandalism problem" of somebody closing your running session just to annoy you could be at least reduced.
|
|
|
|
Site will be down a few minutes for some updates - Stay tuned!Update: - You can search for bets by transactionID (Button "Lookup Tx" on main page)
- Rejected bets now have tooltip on mouseover which states the reason for being rejected
- Refund payments now have a tooltip on mouseover which states the reason for the refund
- Some additional minor fixes
Note that the reject/refund reasons will only be there for new entries. |
|
|
|
System is up and running again, currently catching up missed transactions. But, guys, please stop monitoring of 1dice... Addresses! This creates such a high number of notification events that the current hardware is at its limits. And at the moment I have no ressources (time and money) to scale up and move to bigger hardware. So for now i removed all Satoshidice addresses from the system. I hope I don't need to implement a bitcoin address blacklist |
|
|
|
|
Site is having some serious troubles at the moment. Had to do a hard restart and waiting for it to come up again...
|
|
|
|
|
Is there some way to tell with the standard client / rpc interface if a new backup is necessary, i.e. when the keypool was exhausted?
|
|
|
|
|
There was a problem this morning. Somehow the notification for incoming transactions was stuck while all services in general kept running fine. So no monitoring alert was triggered and the transactions just ignored :-(
@Carlos: Your bets have been placed now.
@All: If you are missing any bet please provide me the transactionIDs so I can double-check that they have been handled in the meantime.
|
|
|
|
Okay, changes regarding session and bet timeouts are now online! - No more bet timeout for singleplayer sessions
- Increase session timeout to 10 minutes
- Added "close session" button to session details page
- Increase bet timeout in multiplayer sessions from 75 to 90 seconds
- Decrease bet limit to 50 bets/session
As discussed this has the drawback that anybody can close your running session, but in the end it still might be more comfortable for the player. Give it a try and let me know what you think! |
|
|
|
anyone else have a full-time job, 2 3 demanding kids and trying to work on a multiple bitcoin projects?  FTFY ^^ |
|
|
|
|
Show Posts
