[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[Carnth]

quick question, what exactly does the 2.5% donation threshold do?  does it mean that stale/invalid blocks get rewarded the same as regular shares?

Yes, this is exactly what it means.
When you donate 2.5% (or more) you get:

• Satisfaction knowing that you are supporting the best pool in the world.
• You get paid for every block found... even if it later becomes invalid.
• You get paid immediately! All estimated rewards skip confirmation and go directly to confirmed rewards when a block is found
• Plus, you get all other donator perks like idle miner warning emails, etc.

[1713856489]

1713856489

[1713856489]

1713856489

[Carnth]

Hey Eleuthria, I've got a general technical question.

Since you said bitcoind wasn't putting much of a load on the server, how come you don't run multiple bitcoinD, each mapped to a separate port?

He just implemented this feature over last weekend.
His mulit-bitcoind back end instances are mapped to the same pushpool server front end, so it uses the same port (for convenience).

[TurdHurdur]

Much miner idling recently... Giving my fallback script a workout.

[Veldy]

Much miner idling recently... Giving my fallback script a workout.

I get a lot of idles with poclbm.exe.  If I use phoenix.exe then I don't get the idles, but I get a LOT of stale shares.  This was as of yesterday afternoon.  This suggests to me that long polling pushes are arriving too late and that the work queue is a bit larger in phoenix which accounts for the stale shares.

[TheMoneyStorm]

Yeah, I've been getting a ton of Problems communicating with bitcoin RPC this morning.
And also a bunch of idles. I'm using poclbm.

[eleuthria]

As the warning on the site says, there is NOTHING I can do about the idles/RPC errors at this time.  The short-term solution is expanding to additional servers, which is happening this week.  The long term solution is either fixing the problems pushpool is having scaling to these speeds, or writing custom pool software, which is a definite possibility at this point.

[TheMoneyStorm]

That's kinda what I figured, Just trying to keep you updated 

[Veldy]

Yeah, I've been getting a ton of Problems communicating with bitcoin RPC this morning.
And also a bunch of idles. I'm using poclbm.

The pool hash rate was in the 450GH/s range this morning, but now it is back up over 600MH/s range.  I suspect that is the cause.  Too much traffic.

[TheMoneyStorm]

Yeah, I've been getting a ton of Problems communicating with bitcoin RPC this morning.
And also a bunch of idles. I'm using poclbm.

The pool hash rate was in the 450GH/s range this morning, but now it is back up over 600MH/s range.  I suspect that is the cause.  Too much traffic.

Yeah, I noticed that too. I can't wait for the new servers. I love BTCGuild.
I think eleuthria has done a fabulous job with the site, He keeps everything
running as smooth as possible considering the load.

[Veldy]

Yeah, I've been getting a ton of Problems communicating with bitcoin RPC this morning.
And also a bunch of idles. I'm using poclbm.

The pool hash rate was in the 450GH/s range this morning, but now it is back up over 600MH/s range.  I suspect that is the cause.  Too much traffic.

Yeah, I noticed that too. I can't wait for the new servers. I love BTCGuild.
I think eleuthria has done a fabulous job with the site, He keeps everything
running as smooth as possible considering the load.

I completely agree.

Unfortunately, at the moment, for whatever reason [probably slightly delayed long polling push], I get a ton of stale shares in phoenix [which I need to use with my 5850s due to the phatk kernel giving me more than a 3% increase].  If I use poclbm as my miner [which I for my 6970], it keeps a smaller work queue apparently and I get idles, but they are short so that the temperture barely blips, but I still get a large number of stale shares; not as bad as with phoenix, but I don't get the 3% of play that I have with the 5850s using the phatk kernel.  So, I am mining elsewhere at the moment.  I went to my old favorite pool for a while last night, but the variance was huge due to somebody putting all that hardware online [obviously running solo or a private pool not monitored by Bitcoin Watch explicitly].  I ended up mining on yet another pool which is working great for me at the moment.  I am REALLY looking forward to taking my miners back over to BTC Guild [I do test runs there ever couple of days for several hours to get an idea of stale rates, idles and communication issues].  I will be back shortly   I suppose some people see more issues than others due to their route on the Internet [and thus latency and/or packet loss which I oddly do not have a problem with either] or maybe many miners just don't care much about their stale share rate (there is something to be said about not looking at the stats often ... but to me, it is a hobby of maximization of ROI).  If I earn enough, maybe I will build a "big rig" IF I see it profitable rather than keeping the cash or using it otherwise [and difficulty increases have remained a more "normal"l 0-10% as designed] and the conditions of Bitcoin in general and pending hardware releases [presumably GPU].

Changing the subject to what I alluded to a little bit above ...

I hope that person/people that brought so much hardware online at once pay for this in difficulty and find that they paid way too much money for the return they are getting and sell their hardware to try to break even and hopefully that won't happen again or very often ... it is unnatural growth in my honest opinion; although it is a free market including the ability to mine.

What would be really cool would be a new video card to come out that simply dwarfs others out there [but likely still expensive] making some of the reckless [meaning many are doing it with debt and/or without forethought about what they are doing to the mining community and how it will end up for themselves] giant rig builders recent investments potentially unable to repay on their investment.  I hate to wish ill on somebody, but clearly greed is driving some people without logic and/or without care.  I broke even a few days ago officially (and then a little ... I was ignoring some costs that I didn't count like the fact that I shorted a new power supply because I thought the last one was bad and it turned out that somehow the case was shorting the mother board AND the power supply ... so I had a cheap [but good] board, power supply and additional CPU [previous was surprisingly incompatible] to account for at about $170 total [-1 case meant one machine I won't be building since I am pretty much out of usable parts other than drives].

Some small cash investments that I could afford into the market also paid off well [essentially, I did some day trading at strategic times and helped fund the ramp up machine by machine without much outlay at all ... I wouldn't allow any money from my main budget to be used other than the initial video card purchase for my gaming PC as a regular upgrade and a small amount of cash I considered "slush" which I have already recovered].

[eleuthria]

I'm pleased to announce an upcoming development for the pool.  After the new servers are put online and the pool is successfully sharded between them, I will be posting a game plan for what steps will be taken should BTC Guild grow to the point where it's influence over the network can be seen as a bad thing (same thing going on with DeepBit currently).  I won't be able to give a clear example until after I've successfully split the pool across multiple servers.

The current load on the pool indicates that BTC Guild will be processing around 750 GH/sec within 24 hours of the new servers come online, and our growth in the past points to 1 TH/sec shortly after that (assuming the 3 servers are stable for a few days).  I'd rather have this plan in place and ready to execute when we reach 30-35% of the network, rather than waiting to look for a solution until reach 45-50%.  Starting early will give us time to discuss the weaknesses or additional transparency that will be needed to pull it off.

[lvlrdka22]

Where be my lucky streak?

Code:

345
129033	2011-06-06 13:14:22	0:16:11	145164	79 until confirmed
View
344
129029	2011-06-06 12:58:11	0:03:48	32895	75 until confirmed
View
343
129028	2011-06-06 12:54:23	0:37:05	327063	74 until confirmed
View
342
129023	2011-06-06 12:17:18	0:37:32	320173	69 until confirmed
View
341
129012	2011-06-06 11:39:46	0:01:03	6225	58 until confirmed
View
340
129011	2011-06-06 11:38:43	0:25:11	225105	57 until confirmed
View
339
129006	2011-06-06 11:13:32	0:27:03	238883	52 until confirmed
View
338
129001	2011-06-06 10:46:29	0:31:34	274791	47 until confirmed
View
337
128996	2011-06-06 10:14:55	0:10:00	81644	42 until confirmed
View

[BitMinerN8]

I'm pleased to announce an upcoming development for the pool.  After the new servers are put online and the pool is successfully sharded between them, I will be posting a game plan for what steps will be taken should BTC Guild grow to the point where it's influence over the network can be seen as a bad thing (same thing going on with DeepBit currently).  I won't be able to give a clear example until after I've successfully split the pool across multiple servers.

The current load on the pool indicates that BTC Guild will be processing around 750 GH/sec within 24 hours of the new servers come online, and our growth in the past points to 1 TH/sec shortly after that (assuming the 3 servers are stable for a few days).  I'd rather have this plan in place and ready to execute when we reach 30-35% of the network, rather than waiting to look for a solution until reach 45-50%.  Starting early will give us time to discuss the weaknesses or additional transparency that will be needed to pull it off.

Thank you for the update and all of your hard work in bringing this plan to fruition.

[Veldy]

I'm pleased to announce an upcoming development for the pool.  After the new servers are put online and the pool is successfully sharded between them, I will be posting a game plan for what steps will be taken should BTC Guild grow to the point where it's influence over the network can be seen as a bad thing (same thing going on with DeepBit currently).  I won't be able to give a clear example until after I've successfully split the pool across multiple servers.

The current load on the pool indicates that BTC Guild will be processing around 750 GH/sec within 24 hours of the new servers come online, and our growth in the past points to 1 TH/sec shortly after that (assuming the 3 servers are stable for a few days).  I'd rather have this plan in place and ready to execute when we reach 30-35% of the network, rather than waiting to look for a solution until reach 45-50%.  Starting early will give us time to discuss the weaknesses or additional transparency that will be needed to pull it off.

Excellent!  I am really curious how one operator can somehow divest from a pool [or pools] of his own creation and authoring.   I am not sure users will want their pool to drop in hashing power if split ... or restricted from growth [if a user can't add an additional worker ...].  You know I want such security to avoid pools from having the potential to be used [abused] for a double spending attack, but I will be very interested [and probably constructively critical unless you really surprise me ] about it.

You are certainly creative, skilled and goal oriented and your work on BTC Guild very much reflects this.  If you didn't have an excellent career in software/web/admin before, you have set yourself up now for it even if bitcoin fades away eventually

[ensign_lee]

I'm pleased to announce an upcoming development for the pool.  After the new servers are put online and the pool is successfully sharded between them, I will be posting a game plan for what steps will be taken should BTC Guild grow to the point where it's influence over the network can be seen as a bad thing (same thing going on with DeepBit currently).  I won't be able to give a clear example until after I've successfully split the pool across multiple servers.

The current load on the pool indicates that BTC Guild will be processing around 750 GH/sec within 24 hours of the new servers come online, and our growth in the past points to 1 TH/sec shortly after that (assuming the 3 servers are stable for a few days).  I'd rather have this plan in place and ready to execute when we reach 30-35% of the network, rather than waiting to look for a solution until reach 45-50%.  Starting early will give us time to discuss the weaknesses or additional transparency that will be needed to pull it off.

That's...so...COOL.

It's nice knowing that your pool operator has the best interest of us all at heart, including bitcoin itself.

[eleuthria]

Excellent!  I am really curious how one operator can somehow divest from a pool [or pools] of his own creation and authoring.   I am not sure users will want their pool to drop in hashing power if split ... or restricted from growth [if a user can't add an additional worker ...].  You know I want such security to avoid pools from having the potential to be used [abused] for a double spending attack, but I will be very interested [and probably constructively critical unless you really surprise me ] about it.

You are certainly creative, skilled and goal oriented and your work on BTC Guild very much reflects this.  If you didn't have an excellent career in software/web/admin before, you have set yourself up now for it even if bitcoin fades away eventually

Obviously I want the users happy, and after seeing the occasional backlash at Tycho for his pool size (through no fault of his own!), I'm working on a way to keep the pool large, but to negate the POTENTIAL for abuse.  My proposed solution is keep the large single pool, but split the work load among multiple pool operators' servers.

My goal, assuming I can make it technically possible without opening it up to fraudulent pool operators, is to create a franchise-type pool.  BTC Guild would remain the front-end for all users, handling payouts, reward calculations, and account maintenance.  However, their miners will be balanced over a network of servers.  Some servers would still be mine, while others would be controlled by third parties.

There would be an authorization process, so I can inspect the hardware their server is running on to ensure that they can handle a reasonable work load.  When rewards are calculated by the main pool, the sub-pools would receive a percentage of the donations generated that round, based on their server's share of the load, less a percent-based franchise fee.

With this setup, the pool could surpass the 50% mark of overall network strength, but it would be split among multiple individuals, rather than a single entity.  It would be equivalent to the risk we have today of multiple pool operators colluding together.

[Sukrim]

I'm pleased to announce an upcoming development for the pool.  After the new servers are put online and the pool is successfully sharded between them, I will be posting a game plan for what steps will be taken should BTC Guild grow to the point where it's influence over the network can be seen as a bad thing (same thing going on with DeepBit currently).  I won't be able to give a clear example until after I've successfully split the pool across multiple servers.

The current load on the pool indicates that BTC Guild will be processing around 750 GH/sec within 24 hours of the new servers come online, and our growth in the past points to 1 TH/sec shortly after that (assuming the 3 servers are stable for a few days).  I'd rather have this plan in place and ready to execute when we reach 30-35% of the network, rather than waiting to look for a solution until reach 45-50%.  Starting early will give us time to discuss the weaknesses or additional transparency that will be needed to pull it off.

You could open an account on other pools and get a few thousand "getworks" from there...! ;-)

If they are 0% fee pools this won't even cost you a lot (it might cost you a bit, as you won't get transaction fees...)

Oooor... you could pool hop in other proportional pools with the entire pool, netting you even more profit than mining yourself!

[Veldy]

Obviously I want the users happy, and after seeing the occasional backlash at Tycho for his pool size (through no fault of his own!), I'm working on a way to keep the pool large, but to negate the POTENTIAL for abuse.  My proposed solution is keep the large single pool, but split the work load among multiple pool operators' servers.

I don't know that there was a backlash at Tycho; I don't believe he lost any share.  There was some discussion and passionate debate, including by me, but at no point did I have negative feelings towards him [other than frustration which probably everybody involved felt].  I did feel he was profit motivated beyond the point of bitcoin network security [rather, blind to it as a possibility]. At the time, it was apparent that stopping slush pool drove everybody to deepbit and thus a two pronged attack, one to disable slush and the other via cracking and hacking deepbit (the more difficult of the two) was proven viable.  Deepbit never hit the size it really needed to be used that way as the market cap MUCH smaller than today and the profit motive versus criminal risks probably weren't there.  To execute it, the faster you can get in and out, the better, which could mean significantly over 50% of the total network hashing rate.  However, I was frustrated and did blast a few messages out on Twitter which drew some attention.  I think several people got the attention of many more people and some of the smaller mines got some migrants and some new people or some users simply added their new hardware to other pools thus mining multiple pools.  Six weeks or so later and and we have four major pools and several more small pools that are known about and I am guessing several private pools.  It would be much more difficult to do now and would take a lot more work for the double spending attack to occur and succeed.  Having said all that; I like and respect Tycho and think he has built a great product and recently told him so.  Your pool is in no small way influenced by his work.

My goal, assuming I can make it technically possible without opening it up to fraudulent pool operators, is to create a franchise-type pool.  BTC Guild would remain the front-end for all users, handling payouts, reward calculations, and account maintenance.  However, their miners will be balanced over a network of servers.  Some servers would still be mine, while others would be controlled by third parties.

There would be an authorization process, so I can inspect the hardware their server is running on to ensure that they can handle a reasonable work load.  When rewards are calculated by the main pool, the sub-pools would receive a percentage of the donations generated that round, based on their server's share of the load, less a percent-based franchise fee.

With this setup, the pool could surpass the 50% mark of overall network strength, but it would be split among multiple individuals, rather than a single entity.  It would be equivalent to the risk we have today of multiple pool operators colluding together.

... and if you have access, to those pools which you just said you would [and obviously, they are all working together on a single round] and you wrote the code, then I don't see that strategy really doing anything other than hindering your development and/or maintenance of the pool.  Even if you don't personally do such a thing, the fact that one person can means a good enough cracker probably can get that very same information and a good enough hacker push modified code to all the installations.  BTW, the double spending attack would occur with the payout mechanism and of course the block shares pushed to the miners.  To have all work from all these pools in one round (which is what a pool's purpose is), that would have to be handled centrally, just as payouts are.  So, one point of attack really.  Constructive?

[Veldy]

Oh, BTW, I bet the Chinese, Russian and U.S. government agencies have already taken notice and already have a plan or are working on a plan of action to completely halt bitcoin at virtually a moments notice should they decide it is a risk to their strategic interests or security.

[CubedRoot]

Hey guys... my best friend whipped up a neat signature .png that shows your stats as well as BTCGuilds stats.  I have it in my sig below.

If you want your own copy, all you need to do is this, just replace YOURAPIKEY with your API key from BTCguild.  Just remember the .png will need to be at the end.

http://gigahype.net/btc/s/YOURAPIKEY.png

If you like it, send him a donataion at this addy: 147mtvWJCWKGgwj4BMJAxBCGT3Ry9wQJe2
He has his GPU's on the way and should be mining within the week, and I'm sure he would like some BTC's regardless of the amount