I am getting again +80% invalid or stale hashes. Why does this happens?
Do you have overclocked GPU? Try to lower clock a bit. Do you use newest miner software? Old versions had troubles sometimes... |
|
|
|
I'll restrain my twitchy finger, promise. ;-) But please google 'jquery comet'.
I considered something like this, but data are changing with every submitted shares (expected reward, for example). And I'm working on mining server, not on news distribution. When you check profile page every half of hour, you don't miss anything ;-). |
|
|
|
Today I implemented new pool features. 1. User's daily reward graphAfter login, every user can check his daily reward and his seven days moving average. Everybody can visually check if daily rewards are adequate his hash rate. 2. System daily reward graphShows how many bitcoins pool mined every day. 3. Cummulative distribution function of sharesShows generally overall pool success rate. Blue line shows long-term teoretical share distribution, yellow line is pool reality. Yellow above blue ==> pool is more successful than it should be, yellow under blue ==> otherwise. From collected data you see that currently pool perform little better than it should be in long-term, so hard blocks (with many shares in round) will come, surely :-). Show CDF for pool users was the main goal of this release. CDF is not calculated from entire pool history, because system has correct data from block 101165 up to now. Page with graphs is here. 4. Hall of fameAdded page with the most powerfull miners in pool (actually top20). It is stub for another interesting user stats, I hope. 5. Total rewards on profile pageFew users asked me to add unconfirmed+confirmed rewards together to profile page. Personally I don't see much the point, because unconfirmed reward is something what you shouldn't count in (yes, we already had invalid block in pool). And in the end, my personal appeal to coldbot: Stop pressing F5 for hours and let's do something useful. There won't happen anything magical in your profile page when you download it 10x per second. |
|
|
|
Dang... I'm writing a wrapper app for some Bitcoin stuff (multiple wallets, encryption, backups, pool mining) and I'm parsing out the output to determine hash rate, accepted/rejected etc. I was hoping to be able to keep track of number of blocks found, but oh well.  Well, I can provide some API to retrieve info about user account (with provided login/password, of course). PM me if you are interested. |
|
|
|
Perhaps it would be better to update the in-memory credentials for just that worker at the same time as you update the password in the database. Then you don't need the periodic reload.
Not so easy. getwork processes are completely independent from website itself. Implement credential timeouts in getwork processes is the simplest way to do it. I still hope it will be enough. By the way, I looked at your location on the bitcoin map as you suggested. I used to stand right there regularly waiting for the tramvaj home to Strasnicka.
Yes, Vodickova street is quite good address, it is in the heart of Prague itself . Maybe after few months, you spend only 1BTC for ticket Canada-Prague, we will see  . |
|
|
|
Those 128 bits refer to the key-length of the symmetric cipher (e.g. AES, arc4), which is quite secure and actually controlled by the webserver. The asymmetric cipher (e.g. RSA) has a much greater key-length, typically a multiple of 1024. An RSA key with length 1024 or greater is widely considered secure, although more people are going to 2048. SSL, OpenPGP, etc are considered hybrid cryptosystems since they use both types of algorithms in a complementary way.
Oh, thanks gene for explanation. I'll consider startssl certificate again. |
|
|
|
I tried changing the password for one of my workers. The new password is displayed on the website, but the original password is still required when running the miner.
Oh, I'm surprised that nobody ask for this before. Unfortunately, this is 'by design'. I mean, once worker ask for his first getwork, application load his settings to memory and keep them until application restart; it is performance optimization, because it's not possible to ask databaase 100x per second to check worker's login/password. So I plan to add periodic reload of those credentials, but even then it will take some time until credentials loaded in memory expire... Also, is it possible to change my account password, as opposed to the worker passwords?
Now it is possible, you can reset password from login page. Still not comfortable, because you have to confirm email even if you know old password, but it works. |
|
|
|
Hey slush, weird question, but does the server give a response to the client when they find a valid block?
No, when miner report 'found block', it is only found pool share (block with difficulty 1). You have to check website, if you workers have some number in 'blocks' column. |
|
|
|
1) Am I correct that the username/password of my workers don't actually have to be "secure", as the most that one could do with them is submit shares for me, right? And they're passed unencrypted by the miner, right?
Yes, with worker login/password, nobody can do something wrong (change wallet, login to profile or so). But you still should keep this secret (I mean don't post it to forum or so), because somebody can sabotage your miner's work in this way. Pool have memory for last 12 getwork requests per worker to validate submitted share later. So when somebody will request getworks using your worker credentials during your miner's work and your miner submit valid share, it can be rejected because attacker pushed out this job from pool queue already. So, nothing strange, but simply don't spread your credentials to other people. 2) Are there any plans for SSL for the web management interface? If not, it seems that an attacker could learn my account password (as opposed to a worker's password) or impersonate my session (as it seems to remember me via a cookie),
There is SSL enabled, but only with self-signed certificate. Currently I don't plan to change it to, because startssl.com offer only weak, 128bit certificates and classic certificates are quite expensive. But if you care, you can write down certificate fingerprint... and then change the bitcoin address that rewards get sent to. If I'm vigilant I might notice, but an attacker may steal quite a few bitcoins from me before I notice. I do understand that I'm getting exactly what I'm paying for here, but as the pool becomes a bigger and bigger part of the bitcoin mining system, it may be a good plan to look at as it may start to become a target.
I agree that security IS the concern here. Firstly I was oriented mainly to security of pool algorithm, but it looks pretty good, so I can work on frontend improvements. Today I implemented CSRF protection, which improve security against javascript attacks. |
|
|
|
Today pool update: - Added protection against CSRF to account page.
- Password reset feature (follow link on login page)
|
|
|
|
|
Hey, crunching whole nonce space is useless. With your hash/s, you are crunching old blocks for 10% of time.
Edit: Sorry, I see your config has final nonce only 0xffff. Still, I see in logs you are working on one job more than 50 seconds, so you waste ~10% of time for crunching old jobs.
|
|
|
|
Block of 50 coins that I generate for the pooled miner was signed with the key of the pooled miner.
Yes, something like this. Job received by miner contains transaction for 50BTC to pool wallet. |
|
|
|
Okay, I'll try to keep it simple. When I generate a valid block worth 50 bitcoins as part of the pool, how do you prevent me from keeping the block for myself when I find it?
If you mean 'steal it for myself and make own 50 BTC' - it is technically not possible. If you mean 'steal it for myself and sabotage cluster' - it is possible, but you cut yourself for reward, so it is economically unsuitable for you. It was also heavily discussed on forum before, please read it before new posts on this topic. |
|
|
|
Well, nothing is for 'free'. But I won't judge this. around 50G hashes per day per mobile phone number.
Which is 11 pool shares per day from whole GAE cluster, so average 0.033 bitcoins (or 0.01 USD) daily. Wow! (GAE is great tool and I also use it. But it's purpose is different than crunching hashes.) |
|
|
|
maybe i am wrong
Yes, you are, completely. Current average speed for ~50 last blocks is faster than long term average for corresponding Mhash/s is (approximately +10% faster). You cannot pick short-term peaks from last days, where we found many blocks in a row. We have still only 8% of bitcoin network (so in long term pool should find every 12th block in network. When you look at last 47 blocks, eight of them are from pool, so 5,8 average (which is significantely less than 12). |
|
|
|
Boy, I muddled that last question. It should have read "does the security to prevent this ...". I guess what I'm asking is if the work you send to my computer is any different than the work my own bitcoin server would send to me. I'm guessing so.
If not, I was assuming that the security scheme for assigning the block to the miner must lie somewhere on my PC and could have interfered with my own mining. I'm hoping a bunch of people jump on here and say, "No way. You just don't understand how it works."
Hey, sorry, but I completely don't understand what's your question...? When you want to solve blocks standalone, simply connect your miner to your local bitcoind. Several days ago I hit upon a block while mining on my own and it did not go through.
It is sometimes possible, you can find a block, but anybody else (maybe the pool :-) send valid block just a second before your own solution. Then your block is not counted... I like pooled mining, but I'd also like to try again on my own and I began to wonder whether the pooled mining had somehow gotten in the way of mining
If you connect your miner directly to own bitcoind, there is no way how can pool interfere with your mining effort. (if this is core of your question) |
|
|
|
|
I'm involved in BOINC for many years, so I can compare. The biggest problem with Bitcoin@BOINC is that boinc is not realtime. You need actual data to work on block (in the absolutely worst case new job every minute), but BOINC is designed for long running, offline computations (clients ask for new job after many hours).
|
|
|
|
So, could happen. Did happen, I guess.
Yes, time to time this happen. And 76000 shares per block is only 5x more than average, so nothing impossible. Just out of curiosity, though, is there anything that could malfunction on the mining server that would not be apparent to me as a client, where I'd just be running calculations and submitting potential blocks?
Server problems can happen, of course. In this situation your miner will receive error status that share was not processed (HTTP status 400 or 600 and error message). |
|
|
|
Lost account password. What to do now?
I hope the reset password feature will be ready today... |
|
|
|
|
Show Posts
