Thanks bitcoinpool.com for the server upgrade and the free 6870 from the contest! Will upload pics of rig soon, the second card has doubled my hash rate to over 500Mh/s  gahphue9, thank you for mining with us. If you too want to possibly win our monthly giveaway contest, then you should start mining with us sooner than later. |
|
|
|
|
I think your pool speed is off/wrong/lying.
User Id Hashrate
19 79793
Your saying that you have 1 user is running 79GH/s. Then it also says that miner has -2 shares:
User Id Shares
19 -2
Wow, negative shares! That's new.
So when your pool runs @ "83.2 GH/s", the biggest user in the pool is 79GH/s with -2 shares...I don't believe for 1 second that you're really running a 83.2 GH/s.
Nice try though. Please fix your pool speed indicator. People don't like it when you get this type of thing wrong.
|
|
|
|
How are you cooling all of that?
Three servers are not producing that much heat...yet, but it's only 75 outside today. We have two eight inch Vortex fans (industrial, not vortex PC fans) exhausting most the heat from the garage, and a box fan mounted to the front of the 42U rack just to give it some extra air flow. Being 75 outside, the metal on the servers is still cool to the touch, so I don't think we're going to have much a problem. Just incase it is a problem down the road, I got two idle AC units ready to go. |
|
|
|
WTF you're running it out of your house? What are you planning on doing when the grid goes down? What is your SLA on teh business fiber?
About 4 years ago we had a substation blowup. http://www.youtube.com/watch?v=ZNHdW3ZOEWA&feature=relatedAfter the substation blew, PGE redesigned the entire cities power to be able to quickly transfer power to areas that were affected by power outages. So long as it's not this bad, we're usually back up within 15-30 minutes. So get this, I was running this server off of my 20/20Mbps residential fiber connection for 3 months, and my ISP didn't say a word. I guess if it's not torrents, they don't care much.  I did ask them if I could run 1 or more servers from the business line. They said I can run anything I need to for "my business", meaning web and pool servers are approved. *EDIT* but v nice hardware You and your roommate both have a nice rack ROTF LMAO  Thank you?! LMAO |
|
|
|
Users can now have separate passwords for their miners and accounts.
It took you this long to separate miner passwords -- sent unencrypted over the Internet -- from user passwords? Wow. Just, wow. Actually, we've had it for awhile now, but we don't feel obligated to post every little change on this forum when we use our own. |
|
|
|
We've been working hard to bring you a much more friendly web site, more features, and a overall better Bitcoin Pool. After several sleepless nights, we got the entire infrastructure of BitcoinPool.com upgraded. Users can now have separate passwords for their miners and accounts. You can set up different types of notification for when your miner dies or gets below a specified speed. The overall service is running amazing fast now compared to what it was before. We broken each part of the pool processes into it's own server, and connected EVERYTHING with 1Gbps Ethernet. We got a NEW 50/50Mbps FIBER LINE activated, so there is a plenty of bandwidth available. All the infrastructure now has battery backups for all the servers, monitor, and the network switch. Everything could run for about 30-40 minutes if the power goes out. The Fiber Optic connection has about a 4 hour backup battery too. So *if* we we're to have a short power outage, we should be alright. Here's a break down of what we are now using for the pool. Some things have changes from what we originally planned, but it's all good. ========================================================================= ++ SERVER: MySQL ++ Dell 1950 1U Server 2 x Intel® Xeon® Processor E5405 (12M Cache, 2.00 GHz, 1333 MHz FSB) Quad-core processors 8 x 2GB DDR2 (16GB) 2 x 1Gbps NICs 2 x 250GB 7.2K RPM drives in a RAID 0 configuration 2 x 670 PSU for power redundancy ++ SERVER: Pool daemon (for miners) ++ Dell 1950 1U Server 2 x Intel® Xeon® Processor E5405 (12M Cache, 2.00 GHz, 1333 MHz FSB) Quad-core processors 8 x 1GB DDR2 (8GB) 2 x 1Gbps NICs 2 x 250GB 7.2K RPM drives in a RAID 0 configuration 2 x 670 PSU for power redundancy ++ SERVER: Website / Forum ++ Dell 1750 1U Server 2 x Intel® Xeon® Processor 8 x 1GB DDR2 (8GB) 2 x 1Gbps NICs 2 x 250GB 7.2K RPM drives in a RAID 0 configuration 2 x 670 PSU for power redundancy ++ SERVER: NAS Backup ++ 2TB Seagate w/ 1Gbps NIC ++ NETWORK: Switch ++ HP ProCurve 48 Port Gigabit Switch ++ POWER: Battery Backups ++ 2 x CyberPower AVR UPS Battery Backup. Each supports up to 900Watts. 1 x APC 1300 XS ++ POWER: Management ++ 1 x APC Rack PDU Metered 1U, 120V, 20A ========================================================================= PICS The old server. Yeah, not that impressive.  The NEW SERVERS!    A view from the back side of the 42U  Both of the 42U Racks. My roommates is on the left, mine is on the right.  It was already installed, we just needed to get it activate. Yes, this is FIBER OPTIC run to the home, on a business account. The servers are about 30ft of Cat5e away from this box.  And of course we need a speedtest. I couldn't find any servers that would max out the line, but this is the best I could find.  Geebus working...  Myself working...  So that just about sums it up. The servers are doing very well so far. We hope you appreciate all the effort and lack of sleep we've put into getting things up to speed. We're still doing some code updates here and there, and plan on releasing a few more tools on the site as well in the up coming days. We'd also like to say a special THANK YOU to coderman for his help with tuning the DB to being able to handle several million records at any given moment. Stop on by and check it out.HAPPY MINING!  - Bitcoin Pool Staff |
|
|
|
The point is that there is no motive for it.
You really don't think there are some powerful people out there that might have a motive to destroy a decentralized currency? I would say that's a bit naive. The larger Bitcoin grows, the more motive these people have. ++ The banksters are freaking out behind the scene because they know their dollars are about to become worthless in 10 years or less. Bitcoin will be much stronger in 10 years. Hell, right now it's almost the value of silver. That's going to be a BIG DEAL when silver and bitcoins are worth the same amount. |
|
|
|
|
BitcoinPool.com had a service interruption this morning that has since been resolved.
The pool is back online. We apologize for any inconvenience this may have caused.
|
|
|
|
The current system goes something like this:
1. Register for a pool
2. Plug username/pass into miner
3. Miner gets block template from pool, tries random nonces.
4. Miner finds share, sends it to pool. If the share turns out to be a valid block, pool distributes winnings.
But a far better way would be:
1. Register for a pool.
2. Get Bitcoin address for the pool.
3. You run miner on your own local bitcoind.
4. Miner calls getwork on your bitcoind, gets block template YOU create locally! However, it gets the difficulty and generation address from the pool (to allow share-based mining, and to make sure the pool gets paid.)
5. Miner tries random nonces.
6. Miner finds share! Sends it to pool. If the share turns out to be a valid block, pool distributes winnings.
Ta-da. Now, all block generation is done by miners, not by pools, as Satoshi intended. In other words, the pool has /no/ control over the content of blocks! But pools still get block/share based mining, as pools want.
Don't thank me, send me BTC.
I tried this a long time ago....it doesn't work. If you getwork from your local bitcoind, you can't send it to anyone else's bitcoind, and visa-versa. Sorry to burst your bubble. |
|
|
|
|
Hey Jedi95,
Would it be possible for you to have a config file which contains all the information that I would normally specify on the command line? The reason I ask is because (in linux) when I run your miner, my login and password can be viewed by anyone else on the box who runs a "ps -a". If there was a "-config <filename>" option, that would be great and would add a bit more security for those who share a box with someone else.
Thanks for being awesome.
|
|
|
|
|
The BitcoinPool(.com) is working Good at the moment.
|
|
|
|
|
I thought I would drop in and let people know that our pool has resumed normal functionality. We got hit pretty hard yesterday with a DoS attack, but we've been able to muffle it for the time being.
I would also like to point out that just because we had some problems with the site yesterday, we still found 7 blocks and users have been paid for the blocks that are now confirmed.
Thank you all for your understanding and participation.
|
|
|
|
I just wanted to stop in and say that the phoenix miner kicks ass. I'm getting about 20+ Mhash/s more than our miner (poclbm-mod). Again, I'm glad to see that someone else understands the concept of efficiency, and I love that fact that it support long polling with our pool. Anyone using your miner is more than welcome in our bitcoinpool(.com). |
|
|
|
|
Suggestion...
iptables -A INPUT -s <ip> -j DROP
Problem solved. I even blocked a whole ISP because someone was jumping around their IP space.
We've been getting attacked off and on for two weeks now. Looks like someone has it out for the bitcoin pools indeed.
|
|
|
|
I also want to reinforce that most people should not follow FairUser's example. We don't need every client out there connecting to 1,000 nodes.
Mathematically, you don't need anywhere near that many.
++ It's not for everyone. |
|
|
|
Geebus hadn't found the issue yet when I posted about it. But what Geebus found is also very interesting... Out of the last 50 blocks that the pool has found, 4 of them have been invalid. That's an 8% invalid rate over the past 50 blocks!  In the mean time (during basically the same time period), Slush's pool has only had 2 invalid blocks out of the past 500 (0.4%). And Tycho's pool pays 48.5BTC for each block found even if it is eventually found to be invalid. If they are working on a block and there are 2 other pools that are 5x and 8x faster than them, then that wouldn't exactly surprise me. One of the other pools comes ripping through and finds the solution right before bitcoinpool doesn't seem that far fetched. That's not how it works. Invalid blocks are a function of how far away (from an average node distance standpoint) the pool's bitcoind is from the rest of the bitcoin network. A high number of invalid block submissions implies that the bitcoind instance is relatively closer to an edge of the network than the center. The pool is working on a block with a prevhash pointing to the previous found block. But if the pool's bitcoind doesn't have the latest information from the blockchain, then it will be working against the wrong prevhash. The further away the pool is from the center of the network, the longer it will take (on average) for the pool to get blockchain updates. It's all about how many other nodes in the network you are connected to. This is why it's a P2P network, kinda like torrents. The more peers you have, the faster you get information. Currently bitcoin is set to 8 max outbound connections, and 125 inbound connections - MAX_OUTBOUND_CONNECTIONS. Let's explain with the code itself. Line 7:net.cpp static const int MAX_OUTBOUND_CONNECTIONS = 8; This means the maximum number of OUTBOUND connections (from you to someone else) is 8. If you want your bitcoind to connect to more than 8 nodes in the network (which isn't that much), then change this number to something higher than 8. I use 1000. Line 710:net.cpp else if (nInbound >= GetArg("-maxconnections", 125) - MAX_OUTBOUND_CONNECTIONS)This means the max number of inbound connections you can have is the "-maxconnections" option (which defaults to 125) minus the MAX_OUTBOUND_CONNECTIONS (which is 8 by default). By default, you can have 8 outbound (from you to others) connections and 117 Inbound (from others to you) connections. Inbound connections don't work if you're behind a firewall and haven't setup port forwarding or access to port 8333. Line 1132-1133:net.cpp int nMaxOutboundConnections = MAX_OUTBOUND_CONNECTIONS;
nMaxOutboundConnections = min(nMaxOutboundConnections, (int)GetArg("-maxconnections", 125));
This is choosing the smaller number between MAX_OUTBOUND_CONNECTIONS and the "-maxconnections" command line argument, and uses that number for the maximum number of outbound connections. This would be 8. So here's the changes I made for the colo server. Line 7:net.cpp static const int MAX_OUTBOUND_CONNECTIONS = 1000; Line 710:net.cpp else if (nInbound >= GetArg("-maxconnections", 1500) - MAX_OUTBOUND_CONNECTIONS)I also removed line 1133 entirely. Right now the bitcoind on the server has 256 connections to others nodes in the bitcoin network. I intentionally kept this at 256 connections. 1 of those connections is to a server in a colo that was modified to have 1000 max connections. The colo server currently has 923 connections, and an uptime of 53 days. I would say we are very, very well connected to the bitcoin network. If nobody else is doing this, then we might be the node with the most connections in the bitcoin network. It's probably not a good idea for everyone to do this, but since I run a pool, I want to be as well connected to the bitcoin network as possible. You'll probably be interested to know that slush thinks this is a good idea too. I mentioned it to him several months ago. Hi FairUser, I'm responding to your notice in Coop mining thread: BTW, my modified Linux clients can maintain 1024 active connections (yes, I modified the code...452 connections at the moment) to other users bitcoind processes
Is this patch available? Or how much tricky it is? I didn't read bitcoin code too much as I'm not C programmer, but it looks like rising connection limit constant should be enough. Am I right? Rising this limit should improve pool performance a little, because new blocks aren't distributed inside bitcoin network effective enough. Thanks, slush I'm not submitting an official patch because if everyone did this the network would get very, very active with the same information being broadcast through out the entire bitcoin network several hundred times. So back to the point, we just got unlucky with our blocks. Someone else got a better fit answer for the block so the pool didn't get paid, and that's why everyone else didn't get paid. We had code in place to catch when this happens, but we found the typo which caused it to not execute properly. As a result invalid blocks were being treated as valid, which is also the reason everyone's historical earnings were off. We have gone back through and marked the invalid blocks as invalid, and fixed the historical earnings at the same time. Gotta love them bugs. |
|
|
|
Ill weigh in here. Most of the above is true however towards the end they did actually accept slush's challenge right before it was locked out. Also much of the confusion in the thread came from members AND non-members adding nothing constructive to the conversation mostly complaining about long rounds even though the pool was doing fine for its hash rate. There was an awful lot of critisim going on, much more than any other pool and im sure that was frustrating for two pool operators who weren't making a mint off running it like Slush( No disrespect intended. When people even mention Bitcoinpool u imediately get people bashing without giving any good reason other than they dont like their attitude. But the best thing about the pool is its basically like setting up your own private pool and linking it with other people. if ur system crashes or u turn it off for the night u still get what u worked towards for that round and its really simple rules. Im sure i could go to slush or tychos pool and make the exact same but things would be slightly more complicated and i cant look at my stats page and say crap one of my units is down jus by getting on the net. You guys should still try the pool before bashing it despite what you think of Geebus & Fairuser
Thank you for your support FRanz33. I locked the thread because of the trolling and flaming, and I think I made that clear once before. A new forum on our site will be active in the next week. We feel this is necessary to help keep focus on our pool, efficiency, and how it affects mining. Geebus did tell slush to go ahead and try it if he wanted, but we had a few conditions we would like met. 1) Tell everyone your handle. I'll even reserve "slush" just for him. 2) Tell everyone how long he plans on trying this. 3) Use our miner, poclbm-mod. I don't want any more inefficient miners on the pool than necessary. 4) Report your stats somewhere on the forums every 24 hours so everyone can follow along. 5) Establish your baseline or average daily earnings using gribble, before, during, and after the test. I think this is a perfectly fair and open challenge so long as he doesn't try and hide it from everyone. We are still waiting to hear his response... |
|
|
|
For GPUs, it is (at least in theory) better as well, but due to some inefficiencies in the way poclbm switches work (which BitcoinPool's modified poclbm may or may not have solved; I didn't look into it yet) there isn't much benefit to doing so. The -b flag is (mostly) intended for CPU clusters.
Poclbm-mod works through the entire getwork before asking for more. It also support long-polling, which means it opens a connection to the server on a side-channel and waits for the server to send a getwork back (which happens when the block changes). We too noticed that poclbm pulling a getwork every 10 seconds which wasn't efficient. I'm glad to see that someone else also understands this. |
|
|
|
|
Show Posts
