|
Registration has been temporarily closed to new users until the dedicated server is ready. The pool grew over 30 GH again within the last 24 hours, and the current hardware is not going to be able to support the load of many more users. The current hardware was not expected to scale to a 250+ GH server in less than 3 weeks from being opened.
Sorry for the inconvenience for those who haven't yet signed up. Registration will be enabled the moment the new server is online.
|
|
|
|
Wondering if there is a way to get the generation transaction id from the solution logged to SQL where the upstream result is true. That is, we find a block but I then need a handle to the transaction so I can monitor whether it gets the 120 confirmations.
If you're using a PHP frontend, you can do what I've done with my pool: Changes to pushpool: 1) On startup of pushpoold, run a query on a new table [found_blocks for example], which contains an ID# for each block that has been found, auto increment. Get the highest ID#, increase it by one, store it as a global variable in pushpool. 2) Change the sharelog query to include an ID# in the shares table. 3) When it checks a share and finds upstream_result='Y', increment the block ID counter in pushpool. PHP Frontend: 1) Cron script executing your PHP script every minute (or 5 mintues, 30, your preference), which polls bitcoind for a list of block generations (listtransactions, search for category: "generate". 2) Get the transaction ID from the most recent block generations, and check if those transaction IDs are in the found_blocks table. 3) If they aren't, create a new entry in the found_blocks table, and include the transaction ID from bitcoind for that block. You can now associate all the shares from that block with the transaction ID because they will use the same block_id as your found_blocks table does. 4) Have a confirmations field on your found_blocks table, that gets updated when the script executes. Obviously this is just the quick and dirty implementation to get you started, you'll need to add security checks for invalids (category: "orphan"), and make sure it doesn't have a hiccup if two blocks are found between the checks. |
|
|
|
Bit of bad luck today to make up for all the good luck we've been having. Hopefully with the new dedicated hosting provider this weekend, we can surpass 250 gH/sec by the end of the month. The current hardware will probably stop keeping up around that point.
What type of hardware/bandwidth are you running this on. I would consider hosting the pool on some dedicated hardware in my datacenter (2 GigE of bandwidth). I'll even accept BTC for payment  I have a dedicated server/host lined up, just waiting on them to get the SSD drive I requested. Still hopeful that the server will go online this weekend. |
|
|
|
Nice to see my prediction for 200 Gh/s for Friday was accurate. We are already at 237 Gh/s. I set the new goal at 250 Gh/s by Friday.
I'm more inclined to say 250 GH/s by tonight. Assuming the hardware doesn't explode of course. |
|
|
|
|
0.40/kWh in Fresno, California (top tier usage, which any decent mining operation will be in).
|
|
|
|
|
Just gonna put this out there...2x5870 + 1x5970 will get you more than 1390 mH/sec as well (and of course, as pointed out by another post, you're going to make way more than 0.28 per day @ 420k difficulty).
2x5870 = 420 + 420 (easily achievable, done so on 10 out of 10 5870s) = 840
1x5970 = 330 + 330 (easily achievable) = 660
840 + 660 = 1500 mH/sec.
1500 mH/sec @ 420k difficulty = 3.29 BTC/day x $7 = $23.03/day.
|
|
|
|
Can you predict a date? If so, a bunch of us will RV-up and start crossing the country, spreading the word...  Given the rate of growth, about 12 hours. |
|
|
|
I think I remember eleuthria saying before that 250 Ghash/sec would give us problems.
We're at 231.7 right now. O.o
What's gonna happen I wonder?
If we cross 250, the server will open a portal to another dimension, releasing unspeakable horrors into our world, which will rape and pillage the lands until man kind is extinct. Or it will start giving a lot of RPC errors/idles. I may be mixing up my prophecies. It could happen at 240, it could hold off until 300, but 250 was my rough estimate of where the next bottleneck will occur. |
|
|
|
Looks like pool have no protection from common pool fraud practise - connection to pool in early stages of new block solving and after est. reward reach some constant, reconnect to other pool witch is an early stage of solving new block.
There is no reason that if you submitted 250 shares in the round that your 250 shares are worth less than my 250, just because mine were submitted evenly and yours were submitted in the beginning. It is not fraud, it is a miner trying to maximize their reward. No share should be worth more than any other. Every share had the same chance of being the one to solve the block. |
|
|
|
I have the following MT:G (and other card game) booster packs for sale, all new/sealed: MTG: Mirrodin Besieged MTG: Rise of the Eldrazi MTG: Scars of Mirodin WoW: Scourgewar Icecrown Magi Nation: Limited Edition Magi Nation: Unlimited Edition Magi Nation: Voice of the Storms 1st Edition Dragon Ball Z: Frieza Saga (in both 10 and 11 card variety) Dragon Ball Z: Fusion Saga Dragon Ball Z: Saiyan Saga I've been selling them on eBay, message me by pm or webmaster@btcguild.com if you'd like to negotiate a price in BTC . I have almost a full box of each of the above packs. Shipping will highly discounted for larger orders. |
|
|
|
|
While I don't have direct comparisons of 6990s, I know for my 5870s, brand was essentially meaningless in terms of performance.
I hear that XFX tends to be worth the slight premium due to the double life time warranty, making them have a slightly better resale value, but I don't have any personal experience with the reselling of the cards yet.
|
|
|
|
Has anybody tried Diablominer with BTCGuild from behind a proxy firewall?
I can get diablominer to work with Eligius, but would rather use BTCGuild. Here's my command line that works just fine on Eligius:
There's an update to pushpool I have to roll into the server that should fix the proxy issue. I'm waiting to find out when I can move to a dedicated host to make the switch. |
|
|
|
I have the following MT:G (and other card game) booster packs for sale, all new/sealed: MTG: Mirrodin Besieged MTG: Rise of the Eldrazi MTG: Scars of Mirodin WoW: Scourgewar Icecrown Magi Nation: Limited Edition Magi Nation: Unlimited Edition Magi Nation: Voice of the Storms 1st Edition Dragon Ball Z: Frieza Saga (in both 10 and 11 card variety) Dragon Ball Z: Fusion Saga Dragon Ball Z: Saiyan Saga I've been selling them on eBay, message me by pm or webmaster@btcguild.com if you'd like to negotiate a price in BTC . I have almost a full box of each of the above packs. Shipping will highly discounted for larger orders. |
|
|
|
Keep up the good work! Any chance you'd consider open-sourcing the backend RPC server code?
The server is running a (mostly) standard pushpool, so open sourcing my pool would not accomplish too much  . I think he may have been referencing your PHP code that interacts with bitcoind and pushpool, does the user management, etc. Since that's the one chunk every pool is developing on their own, it'd be great to see someone release the "front half" since pushpool (the "back half") was open sourced. This is exactly what I was referring to. Few problems with that one: 1) I'm a computer hobbyist, not a professional. I'd be embarrassed to release my PHP code . 1a) I'm a procedural style programmer. Separating design from the processing engine is something I'm working on, but they still get mixed together quite frequently. 2) The only major defining feature of a pool is its front-end. On the back end, most pools are fairly similar. If I released my PHP code, there would be nothing my pool offers that couldn't be cut & pasted somewhere else. On the update side of things: I've reworked how the system handles emails, and it is now sending valid MIME emails with both plaintext or HTML. A few users were having their confirmation emails rejected by systems that refused to accept a non-MIME formatted email. |
|
|
|
So you have any idea why its doing this? [24/05/2011 02:42:46] Disconnected from server
[24/05/2011 02:43:01] Result: e9866ea1 accepted
[24/05/2011 02:43:02] Warning: work queue empty, miner is id
[24/05/2011 02:43:02] Failed to connect, retrying...
[24/05/2011 02:43:18] Connected to server
[24/05/2011 02:43:19] Disconnected from server
[24/05/2011 02:43:31] Result: 5ecda2f6 rejected
I haven't heard any other reports of that level of idle/disconnects showing up. What speed is your miner running at, and where are you located geographically? A few idles wouldn't surprise me right now as the pool is growing far faster than the current server can handle it, but constant disconnects are a completely different issue. Feature request: Would you consider having the "My Workers" view flag the worker field "Last Share" that have gone ~300 seconds (5 min) with a yellow background and ~900 seconds (15 min) with red? In your spare time of course This functionality is coming soon, I was waiting to implement it until I had emails & confirmations added, since there is an additional premium service (email alerts) that will be tied into it. |
|
|
|
Seems to be going good, just got a block and 166 gH/s, hopefully 200 gH/s by friday.
Bit of bad luck today to make up for all the good luck we've been having. Hopefully with the new dedicated hosting provider this weekend, we can surpass 250 gH/sec by the end of the month. The current hardware will probably stop keeping up around that point. Payout Lock is now an optional feature of the pool, defaulting to off. If you have not set your preference, you will see an alert on the left side navigation menu until you enable the lock or hide the warning. This feature is highly recommended for users. If your account password (or email) were compromised, the person could access your account, change the wallet, and take your balance for themselves. With this lock, such an attack would require 24 hours to complete, with an email being sent to your confirmed address (if one has been set), and warnings appearing on the sidebar. |
|
|
|
|
There is going to be a change to the 24 hour payout lock when a wallet is changed. Since some people take payouts directly to sites like MtGox which generate a new address for each deposit, the lock would disable that capability.
Later this evening, I will push a change that turns the lock off by default. When you log in to your account, you will see a warning on the left side stating: "Your balance is not protected from a wallet address change, click here for more information.".
On that page will be two options:
1) Turn on balance locking
2) Leave balance locking off.
Turning the balance locking on is a permanent change that cannot be undone. Once turned on, payouts are disabled for 24 hours after a wallet address is changed. This is the encouraged option. Leaving this off creates a potential vulnerability if your system were compromised and somebody logged into your account.
|
|
|
|
Considered setting up some AJAX on the site to automatically update the statistics in the browser? Seems like a logical step since you're already so fancy AJAX and I have a complicated history. Generally when I walk down that road, I don't resurface for a while. Waiting until the site has all the major features and donator perks implemented before I start doing things like that . |
|
|
|
|
Some security features have been added, with a few more on the way:
You can now set an optional email field on your account. This is currently only used for wallet change notifications, but will soon allow password resets and payout notifications.
When your wallet is changed, payouts are disabled for 24 hours to protect your account.
If your email is changed, a copy of all emails will be sent to your previously used address for the following 24 hours.
These security measures will prevent anybody from gaining access to your account, and then changing your email (and then your wallet) without you being notified. Of course, if your own system has been compromised by either keylogging or somebody has gained access to your email, these changes cannot prevent such a person from hiding their tracks, it will only slow them down.
|
|
|
|
|
Was removing what should have been an obsolete field in the database. Turns out the rewards display still used that column, even though it shouldn't have. Actual reward allocations were not affected, and it has been fixed.
|
|
|
|
|
Show Posts
