Bitcoin Forum

This mitigation plan is no longer in effect.  The first step was already done in May of 2013.  If the pool becomes a valid 51% threat again, a new plan will be put forward.

This is being posted in a new thread so that it stands out to people who do not frequent the primary pool thread, since this is about more than just the pool.

---

A lot of noise in the IRC, reddit, and forum yesterday related to "BTC Guild dangerously close to 51%" due to a large amount of luck yesterday - https://slotsonlinecanada.ca/ (https://slotsonlinecanada.ca/).  The pool found ~30% more blocks than expected at its given hash rate.  According to the last 2016 blocks, BTC Guild is still shy of 40% (36.61% as of this post).  Obviously I can't wait until the pool is 49.9% to start taking measures, even though a 51% attack is only a true threat if the person controlling it uses it.

This is the outline for measures that will be taken.  I will not be using 24-hour pie charts from blockchain.info to base these decisions due to how much luck influences the charts (either good luck by BTC Guild or bad luck on the rest of the network).  Figures will be pulled from http://blockorigin.pfoe.be/top.php which accurately grabs each block for BTC Guild, and also uses a 2016 block window to determine percentages.


If Pool Speed is Over 40% of Network
BTC Guild will begin limiting the creation of new accounts.  Additionally, the fee on PPS will be increased from 5% to 7.5% on all new miners, and will be moved to 7.5% on old miners after the difficulty changes.  PPLNS will remain at the 3% + tx fees rate initially.


If Pool Speed is Over 45% of Network
BTC Guild will remove all getwork based pool servers within 24 hours.  This is expected to reduce the pool by about 3.5 TH/s, or roughly 15% as of this post.


If Pool Speed is Over 45% of Network After Getwork is Removed
PPLNS fee will be raised to 4%, and new registrations will be completely closed off until speed drops back under 40%.



Suggestions are welcome if you can think of a better way to make miners willingly leave the pool.  The only thing I will not consider is kicking miners off entirely (outside of getwork).

Looks like I jumped in just at the right time then.

Thanks for doing this, I'm glad we have plenty of level-headed people with the communities interest in mind.

Have you considered increasing your fees if your speed stays higher than your target?

User # [<1000] here.

If anyone wants to buy my OG (original guildster) account send me a PM.   :D

Why not just pay less per share? That way the economic incentives lines up with the result we'd like. win:win!

I've considered raising fees, but Guild already charges reasonable fees (3% and paid for orphans+tx fees or 5% straight PPS).  It's a good spot, and it's made me enough to be worth the 16+ hour work days when a crisis happens.

Raising fees is just penalizing users who stick around.  I might make more, I might make less, but it's at the cost of the users that don't leave.  It also leaves a bad taste in people's mouth when a pool raises fees.  Pools have always had a strong leader, and it's changed hands a few times in the last two years (Slush -> Deepbit -> BTC Guild -> Deepbit -> 50BTC -> BTC Guild).  I'm trying to come up with a solution that doesn't damage the pool long term if the lead changes again.  I don't want to be in the position of 51%, but I also don't want to cut off the legs of my business in the long run.

I've been a bit too defensive (which turns into aggressive) in IRC the last 24 hours about this, and I apologize to those that were on the receiving end when they raised the concerns.  This is something that has been on my mind a lot for the last month.  Everybody expected the network speed to explode once ASICs delivered.  But I don't think anybody expected a single pool to get such a disproportionate amount of the first batch.  The pool has increased to 6x more GH/s than what was there at the start of February.



EDIT/UPDATE:  After a lot of input (mostly in IRC), the above statement no longer applies to the new plan.  Quite simply, raising fees is the only effective way to make users consider choosing another pool and willingly leave.  I'm giving a large amount of warning now with this post, and it's also referenced on the pool website news page.  I hope it's not required, but it really is the only method that we've come up with to make users leave without arbitrarily kicking them off the servers.

How about the PPS fee raises by 10% of the amount mined for each 1% above 45%?  In other words, at 50%, the users are paying a 53% fee to mine there?  That way, you're not penalizing the users until they refuse to switch over, and only then.

The biggest problem with raising fees is miners do not keep constant check on the website/forum thread.  If you have automatic payouts and self monitoring, there is very little reason to even look at the pool website.  Even less reason if you use the pool API.  Raising fees, in my opinion, requires significant warning time.  Users will feel cheated if they log in after a week and see the last few days they were being charged more than they signed up for.  Lowering fees is easy, nobody complains about extra money, but the other way around just leads to a lot of headaches.  The switch to PPS with BTC Guild had a lot of warning, and users still emailed me complaining -weeks- after the switch.

What about splitting the pool up into two or more?

One for merged mining via getwork, one for GPU stratum, and one for (20+GH) ASIC stratum?

people will think you're being so reasonable and committed towards the Bitcoin project by putting in place these preemptive countermeasures that it will only attract more people to mine on BTCGuild.  You need to be more... more... BFLish, and push people away :)

Good job though!  I might mine on BTCGuild!  Oops I mean er.. I'll stay elsewhere... damnit!

Will

why do all the above and close registrations until TH cools off?

One way to easily mitigate this would be for someone to release some sort of generically configured Bitcoin Mining Pool application or packaged archive that is easy to install and get running to help grow the mining pool community.  ::) Even with your mitigation efforts, the true problem lies in the fact that there are only a few large mining pools. The more other mining pools that spring up the better for the decentralization of the overall Bitcoin network.

That doesn't matter if all split off pools stay under the control of the same person or group. It would just make the problem less obvious to the general public.

Are you talking about just shutting off the GW servers, or turning them into a proxy pool that would mine on other pools?

It would be turning them off.  I have no intentions of even attempting to run a proxy pool.

How about an increasing graduated fee for newly registered users?    This will encourage new users to look else-ware for another pool.

Once BTCGuild's relative hash rate drops below X% you can then lower the fees for new users that decided to stick around and pay the higher fee.

This rewords your hard work with some extra coin and encourages a free market approach to controlling your hash rate.

How about you screw externalities, keep on adding users and let the free market sort it out?

This is part of the "free market sorting it out":
Having a single entity with blind control over even 25% of the network blocks is a threat that devalues everyone's bitcoins (including their own).
Therefore, it makes economic sense for BTCGuild to try to deter this from occurring.

Too bad they won't allow miners to audit their block data by supporting GBT.

I have updated the plan a little bit to proposals that include increased fees to push some miners out to other pools, rather than relying on registrations being cut off.  Cutting off registrations will not prevent old miners from turning on ASICs they receive, and with over 80,000 accounts on BTC Guild, it's far more likely for the new hash rate to come from old users than new ones at this time.

Thank you, I know it's not easy turning down customers (miners) when you have aqquired them by clearly offering a superior service. But it is the right thing to do. Veterans of these forums undoutably understand that a 51% attack serves no ones interest, especially the entitys who controlls the hashrate, but the masses who are just discovering and experementing with bitcoin do not. This serves a preemtive measure against Fear, Uncertanity and Doubt.

In case you're claiming the risk of "51% attacks" is FUD, let me assure you it isn't.
If there were no risk, then you might as well be using PayPal.

Thanks. I see the dilemma involved with raising fees. However it's also very important to align economic incentives with the goals of the bitcoin project as a whole otherwise the whole thing will never work. I like the updated plan - hopefully the threat of increased fees alone will be enough to re-balance the pools without any operators having to go through with it.

The last thing the Bitcoin needs to do is start subsidizing Pool startups.  Pools should only be done by folks who are interested starting real business and who understand both the risks as well as the benefits.  Each new pool needs to earn their own income and respect in the community by their own hard work and investment.  That is why we can have a pool approaching 50% and not really worry about it too much, because BTCGuild has proven itself to be trustworthy.
Sam

Darn the devalueing of my bitcoins they are only worth $143.  What will I do?

I think this actually hurts more than it helps.  We used to see new pools opening up every other week in 2011 for a while, because somebody made a frontend (SimpleCoin and MFCE(might be wrong on spelling)) for pushpool.  What you ended up with was a lot of pool ops who were "hacked", disappeared, or didn't have a clue how to configure and manage servers.  I think it ended up driving people even harder towards the largest pools because they were obviously more prepared and capable.

But But... BTC has such a web interface... The others are just fugly and slow!

If you or any pool operator will make a virtual machine pool that can be downloaded for a fee , you will see some users  go solo
the virtual pool will bring also some income for the service and  provided there will be regular update/support for it a mantenance fee
at least 100 avalon users that might go solo .
is not that the users can`t make a solo server, the problem is that it may take some time to make it online and properly workin

Thorvald

Raising fees for people that made the pool a success in the first place is a slap in the face :( but I guess its your sandbox and your rules.

There isn't much alternative.  Most of this speed is not coming from new users, but users that already have accounts since most people who ordered ASICs were already involved in mining.  The only solution is encouraging users to move off voluntarily.  The options are to either kick people off or make it so they are encouraged to look at other options.  This isn't like raising fees just to increase how much the pool makes, it's to make it less desirable, thus reducing market share.

Perhaps you could hold the extra % cut you decide to take and then distribute it later?  (Say PPS is only 80% right now, and that you'll get your extra 15-17% in one month). People still get their money, but they are deterred from mining because of the wait to get their coins out during this period of high volatility.

Any chance to discuss with friedcat to move his ASICMINER out of this pool (and setup its own)?

+10000

If it's true that Stratum is not as transparent re: miner visibility to the work then, yes, I would agree.

+1

ASICMINER and BTC guild are operating transparently...this is what we want.  If you move ASICMINER off even the raw speculation that a single private entity would own enough hashpower to overwhelm the network would be massively destabilizing.  However, it would be nice if their power were more evenly distributed.

If possible, it would be a nice feature that if your account is going to be subject to a increase in fees, that there is a clear indicator on the Dashboard. Example:
"Your current fee using PPS payout method is: 5%, an increase to: 7% will go into effect in: 1043 blocks at network difficulty: 8874695"

So the plan is to solve the problem with your own get rich quick scheme......
at the current rate of $160USD per bitcoin@ 7%

[sarcasm]
Yeah, I think 7% is too low, most people won't bother. Make it 10%, that should really motivate people to leave.  :o
[/sarcasm]

I believe Eleuthria is all ears when it comes to ideas on how to balance the load among the other pools in the community. Since he has time and time again shown he is very trustworthy pool op, a get rich quick scheme is not his intention.

I'd love to hear your idea of how to get users to leave the pool willingly.  Kicking them off entirely is not an option since not all miners have backup pools defined.  Not accepting new users is not an option since the vast majority of speed being added comes from pre-existing accounts.

I'm giving users advance warning of what will happen if the pool continues to grow too fast.  They also have time to move before fee increases actually effect them.  The whole point is trying to make other pools seem more attractive so that users will re-distribute more evenly, not try to lock in users and then jack up fees.

- Start off by disabling new accounts.
- Have a warning pop-up when a new miner gets added, that fees have to rise, in order to prevent the 51% issue. (and that any new miner added, gets a PPS rate penality, depending on how big the pool is at that time)
- Not sure how much things your API can do, but if somebody is monitoring their rigs off your emails, you should be able to send a mass-email in the same way explaining/warning users.
- When hitting above 45% start daily emails on everyone you have emails on.
- Start hourly warning on active miners. (you might alert some of your users, that catch these alerts, that you wouldn't alert otherwise)
- Make sure to explain that the moment the pool drops enough again, fees will go down again.

(extra add) - Would it be possible, to deny new miner connections to the pool, once you hit a certain % / Gh? Don't have much knowledge about the stratum protocol, but if you can deny new connections and just keep existing connections alive, you would be golding imo.

In sort, any feature that gets used to alert miners are down, or is used to announce other important messages, get it out there. (PPS rate increase, is just as hurt-full as down miner for most people)

But yes, beyond making sure you get the message is out there as widely as possible, and giving it enough time. There is nothing you can do but increase PPS rate, once again keep spamming the message and some people will leave. Whether it is for the PPS rate, or to help prevent the 51% issue.

When Guild goes over 51%, let's fork the blockchain, re-distributing all coins ever mined to Guild members on a proportionate basis.

Bitcoin shall henceforth be known as Guildcoin...   8)

I think this is a good option to pursue, if possible, as well.

User 67117 has almost 7 times the number of submitted shares than even the 2nd highest contributor to the pool, and that account has been hashing how long compared to some who probably have been mining with BTC Guild solidly since you started in April 2011?

I have emailed the ASICMINER team about their plans for the distribution of hash rate.  They are supposed to be deploying a significant amount of hash power soon.  Depending on where that hash power is pointed, this entire problem may be gone very soon (at least for the BTC Guild part...ASICMINER may be the new threat though if BFL doesn't get their act together after screwing around for 9 months).

I'v joined BTCguild as one of the first thousands (few weeks before you got that cute kitten ;D) and haven't increased my few MHash over the time (i don't have to pay for power, i hold shares of a small hydroelectric plant 8))

I would favor a way to penalize those powerful miners by an increasing fee. All the small miners would still be on 5% 'til they reach 50MHash, next step could be 250MHash with 6.5%, all over 500MHash 8% for example.

Fee depending on the number of shares you put in on the last 24hrs/block compared to the small scale miners (like me) would be an option, too.

Goal should be to encourage the big ones to point some of their power to another pool, not scare them away and make them leave!

I think the best is don't allow new accounts in next few weeks, and reduced block found on that way.

I just wanted to say thanks to eleuthria for this. It takes someone seriously committed to the projects future to start turning away new customers. This kind of thing makes me think, you know what? Maybe we actually have a chance of success with this crazy adventure :)

Miners with a protocol supporting automatic switching by pool request? Only need 10-15% of BTC Guild hashpower running it to make a difference.

Maybe el could work with another pool op, where he maybe splits the normal fee 50/50 when miners need to be re-routed. Offer users a slight bonus when they're switched during "overage" to promote use of miners supporting the protocol. BTC Guild & another pool would need software to communicate when users need to be routed (and which), as well as when they can be safely switched back over. El would have a pooled account set up at the other pool to do this, where instructions on where/how to re-route are provided by the pool with the overage.

This could keep BTCGuild at an "ideal" 40% or lower while not punishing users, not totally ruining el's revenues, and without miners needing to know everything going on. Dunno if it's feasible, just throwing ideas out.  ???

I've received a response from the ASICMINER team.  They are aware of BTC Guild's growing share of the network, and have told me that their next batches of power will be split among more pools or even solo mining to avoid a pool reaching 51%.  They have also identified that selling hardware is on the table if their own share of the network approaches the 51% level.  This doesn't mean the 51% plan in place will change, but it hopefully means the pool will not hit the 45% stage, and any increases in fees if we hit 40% should only last for 1-2 weeks.

a long read but worth it.

I started mining in a pool in 2011, and after using 5 or 6 services, settled with BTC GUILD.

BTC Guild was my prefer choice because of the simple easy to understand UI and the fact the payments were consistent and fair. 

Your success is not for any other reasons in my opinion. (I might add I never received my Stratum Beta Rewards balance and I lost some coins when you transition to a new platform way back, so not a perfect track record)

I see Mining much like I see politics, a democracy it starts out with democratically elected representatives in an House of Representatives (in this case Miners are representatives), they then Group together to form political parties to push forward there common interests (and So Mining Pools are born).

You should not squander and punish users for your success; this is a perversion of free market thinking.

I would like you to start a real Bitcoin Miners Guild  (http://en.wikipedia.org/wiki/Guild) the Guild should then become a member of the https://bitcoinfoundation.org/  I propose you employ a part time representative someone with a Austrian background in economics to work with the BTC Foundation (put all the applicant to a vote by all BTC Guild Members). This representative will then dumb down all sorts of considerations and put it to a vote for Guild Members - that will be his mandate.
(i belong to the CFIB here in Canada and they do a great job of getting members input this way)

By doing this you keep miners in controlee, and keep the free market principles alive. 

I propose you also (radical I know) open source your platform and web API and compete with it privately.  Either invests your good fortune in making the Bitcoin backbone open and stronger or give some back as profit.

@eleuthria your motives are good you need to change your game and play with the new tools you have been given.

My big frustration as a miner in a mining pool is I have no say in how the blockchane evolves, if you raise fees, use it for something related get involved with the BTC foundation, start a Google summer of code type program, find out what your miners want, you won't keep the opportunity if you do something wrong, you will only keep the power if you use it, don't throw it away.

+1 thanks for being responsible and responsive about this issue.

BTC Guild is currently my favorite ASIC mining pool, because it is the most stable and has the most features.

Just switched to Eligius (2nd favorite) until hash rate gets down a bit.

It sounds odd, but:  if BTC Guild hash rate comes down, I will definitely switch back.

Great website UI and very reliable service.

If over 45%, start pointing the excess hash rate to another pool and warn miners. Problem solved.

It's good to see someone who cares about the community and bitcoin!

Keep up the good work! :)

Not as simple as it sounds. How will the miners get paid for their shares?

I dont know if it has been sed or not by why not just make a difrent pool


pool1.btcguild.com:4575   pool2.btcguild.com:5452

and combine them on the websites frunt end

You still have to trust same guys...

They don't want to have 51%+ of hashing power, EVER.

Could you not redirect the "surplus" hashpower to another pool of your choice (P2Pool springs to mind) until the "threat" has passed?

Details around fees might be problematic but I'd imagine there might be a smaller pool or two out there that might be happy to get the boost from time to time and forgo fees for a super miner like BTCGuild overflow.

Problem is having control of such hashing power in the first place. Distributing it around really doesn't help on that. There is still potential to grab it and use it.

They go and distribute the hashing power. Now, if they were to stop this at one point and try something like double spent attack? There is nothing to prevent this, apart from not gaining the power in the first place.

Well it all comes down to who got what blocks right?

If BTCGuild is not stamping out more than 51% of the blocks there is no threat ... it doesn't matter how that hashpower got directed towards the blocks.

Who directs that hashpower? And can you trust them not to abuse the power at any point? 

Getting the blocks isn't really the issue. It's the fact that they have potential for it. And this should be avoided.

You must be overlooking the point of why the pools were set up in the beginning ... to reduce variability. People already implicitly trust the pool when they direct their own mining power to it. As a miner, if you are really worried about the pool operator "abusing your hash power" why would you point your miner at it?

All Eleutheria is trying to achieve is to show to the bitcoin network he is beyond reproach, clearly his miners already think this or else how does he achieve > 51% in the first place?

As long as BTCGuild is not stamping more than 51% of the blocks it is immaterial where the hashpower comes from or goes to, or even who is directing it. In fact, if that pledge is given by BTCGuild (or whoever) and they are seen to be going above that then they would lose the power quite quickly I'd assume ... unless the miners really are as idiotically hellbent on over subscribing to one pool as they seem to be.

Moving forward miners should really start using a decentralised mining pool like p2pool https://bitcointalk.org/index.php?topic=18313.0

I know it's very unlikely but.....

gov, master card or paypal could say to btc guild, 50btc and slush hey we will pay you 20 million each for your pools.

they then merge those to destabilise bitcoin with a 51% attack.

Would that even work?

There are many other decentralized pools that are easier to use and without the downsides of p2p.

It would work. Additionally, it would be very easy for a large government to shutdown Bitcoin without any up-front investment.

which?

https://en.bitcoin.it/wiki/Getblocktemplate#For_miners

Luke, eloipool is not decentralized.  It is transparent when using GBT (at the cost of significantly more bandwidth for pushing work).  No pool other than p2pool is decentralized, they're all master->slave.  Pool dictates the work, miners mine it.  Just because the miner could decide to leave if they don't like what they see does not change the definition of decentralized.

p2pool is no more decentralized than GBT pools. GBT pools set down rules (so does p2pool!) and miners make their own work, deciding whether to follow those rules or not.

Name one miner that does that on GBT ...

... and yes just coz you made up a new definition of decentralized, doesn't mean anyone else on the planet cares what you think it means.
We go by what it really means.

Edit: and of course the reality of it is:
If you change what you are doing on p2pool - change the rules - you can end up with your own share chain if you don't follow the rules of the main chain ... and can keep mining ... it's decentralised.
If you change what you are doing on a GBT pool - unless you are ONLY change the transaction selection - you CANNOT return work that the centralised pool will accept - you will lose all that work - you cannot override the rules of the CENTRALISED GBT pool.

You're out of your fucking mind.

http://s7.directupload.net/images/130501/hr2ifcxi.png

So what did you do to stop it?

Did the pool ever reach 40% according to the below linked chart as was the requirement set forth in the OP?

http://blockorigin.pfoe.be/top.php

Right now it's at 40.28%.

First step of mitigation plan started yesterday when we are at 39.78%.  A small decrease in actual speed followed.  I'm expecting to see a continued small drop in speed over the next week as more miners become aware of the change.

I propose that you encourage users of the pool to "add another pool" using "load-balance", and for those users, optionally allow them to select "Connect as load-balanced".

The purpose of this setup is so you can "limit" those "load-balanced" workers to auto-adjust their work, based on worker names. Thus, in times where the pool seems too large, you give us less work, on purpose. This WILL NOT affect us with logins on multiple pools, and will allow you to keep any users who do not use load-balanced setups to maintain a constant rate of work.

You should encourage load-balanced setups, stating the obvious. Having a connection to multiple pools increases your average PPLNS "Luck" to the percentage of pools which you are actively connected to. EG, connecting to one pool, your luck may be 10% one day, 50% another, 90% another... Connected to 50% of the active pools, that same work would bring you 50%/75%/90%, since you have the luck of the other pools PPLNS, in addition to the work done on your pool.

EG, you are playing 6 hands of cards in a 10 hand card game, instead of only having 1 hand of good luck.

That also helps to keep the entire network stable, as your processing just rises on the active connections more, without being hindered by the lower work coming from the other connections. Also, you don't loose "credit" from PPLNS, and are not "pool-hopping", which looses critical processing time in the hops.

In the event that your servers do go down, due to an attack, or just too many incoming work-connections... We loose nothing, and you get all the fastest connections available. (Since it is balancing based off "the most efficient connections" on our side.)

NOTE: The option in CGMiner is (BAT-File: --load-balance) or (CONF-File: "load-balance" : true,), Only works when multiple pools are loaded or "enabled". NOTE: You can solo-mine this way also, while participating in a pool, with your wallet running in "-server" mode. (For those who did not know that was a possibility.)

P.S. I encourage YOU to encourage THEM/US to assist pools who have smaller portions of the pool. That will greatly help-out everyone on the network, more than joining only the top pools. FYI: if we all did this, that would ensure and maintain that no one pool ever dominates over 33% of the network. Might also help to directly talk to other pool operators, and setup a "load-balance monitor that you all share, behind the scenes, with each-other. If one is a little over-burdened, they can let you know, and you can lighten your load balancing limits for that time.

To the BTC Guils comunity.

The Genesis Block has an article that addresses 2 concerns relevant to miners and pools.
http://www.thegenesisblock.com/go-fork-yourself-life-after-a-bitcoin-hard-fork/

First off I was wondering what this community (and eleuthria)  thinks of Dan Kaminsky (http://youtu.be/si-2niFDgtI?t=40m19s) view of ASIC's contribution to mining?

And Secondly what this community (and eleuthria's) thinking of Peter Todd's (http://www.youtube.com/watch?v=4d3LA8KpdMQ) limiting the block size to encourage development of a layer of services on top of Bitcoin to address micropayments and the like. 

The hashrate seems to be growing, its 39% now. And just now, BTCguild found 4 blocks continuously. Gonna reach 51% soon.

I think you should refer to your miners as lemmings solong as the pool holds over a quarter of the network hashrate, hope you can incorporate this in to your mitigation plan asap.

Lemmings = People who want a stable mining experience in order to maximize the usefulness of their mining hardware.

That doesn't sound anything like the video game to me.

If you don't like us mining on Deepbit, er I mean BTC Guild then get the Client developers to incorporate Stratum, GBT and User Defined Difficulty into into the Bitcoin-QT so that people with high hash rate ASIC's have a viable choice of where to mine without having to setup their own private pool.

Let me fix that for you:

Lemmings = People who want a stable mining experience in order to maximize the usefulness of their mining hardware. At the risk of putting the entire network and blockchain in constant jeopardy and completely undermining the consept of a decentralized currency.

If BTC Guild is attracting so many miners, then there's an obvious problem.  Most other pools are shit.  The good pools (IE ones that are stable) have a slow hash rate, so blocks take ages to find.  Even a pool with 25TH is taking nearly a day to find a block, which is...well...crap.

If some of the pool operators would get the finger out and sort out their shit, maybe people wouldn't all crowd to BTC Guild.

You completely ignore the reality that this is caused, largely, by the Bitcoin-qt devs refusing to make the client useful for ASIC mining!

This affects solo mining and, I believe, P2Pool mining.  Get me an answer to why that is, plus a viable alternative!  Then *maybe* I'll accept the moniker of lemming.
Sam

Edit: also none of these comments have anything to do with Eleuthria's mitigation plan.

blockchain reports 46% of blocks are form BTCGuild in the last 24 hours.

Yes.  Blockchain reports lots of garbage.  There's a link on the very first post showing you an accurate chart (one that doesn't classify 35% of the network as unknown, and doesn't use a USELESS 24-hour chart).  And for the record, clicking the extra length on blockchain.info's chart doesn't change the data (this hasn't worked properly in close to a year).

BTC Guild is 35.9% of the network over the last 10 days.



Not to mention it's a necro from 6 months ago when 50% was actually looking like an imminent event.

No offence, just a tip. :)
And while for some pools blockchain is providing a lot of false positives, for BTC Guild it seems to work well. :)

The issue is 24-hours is too short of a period for a meaningful chart.  I stopped giving a damn about what blockchain.info said the % of network for any pool was a long time ago, because even if the pool+network speeds are steady, you'll see the pool swing 5-15% on that chart day to day for BTC Guild.  Other pools can fluctuate to showing more than double their actual share of the network in a 24-hour period, or more.

I don't agree with much of what you say, but I wholly agree with this.  p2pool runs like shit when you start pumping a few tens of gigahashes through it, even on a fast machine.  Why?   Because bitcoin-qt runs like crap, and bitcoind is only marginally better.

IF bitcoin-qt/bitcoind were a lot more efficient, then p2pool would perform WAY better, and more people might use it.  Currently it needs a fast machine to run, and it really is too much like hard work to keep it running nicely.

p2pool only barely runs properly on an i3-3220 (dual core 3.3GHz) - I tried it on a slower AMD machine (Sempron X2 190, dual core 2.5GHz) and I was seeing 1-3s getblock latency.  That's only putting 30GH/s through it.

It is open source, rewrite it to do what you want it to do.

I'm not a coder.  But I know inefficient code when I see it.

Which is of course correct - due to bitcoin mining being a random event.

You seem to be implying that random events shouldn't be random when they are.
I guess it's just the wording ...

You cannot overcome random variance without defining it impossible to estimate shorter time frames.
You simply need to understand that the variance exists and also that there is an expected error in the result ... even at 100 days :P

However, it is also true to say that the network % is not as important as the block % over a short period of time.
So discounting a high, short-term block rate is invalid.
It is the block % that allows you to do a 51% attack, thus you can indeed do a 51% attack with luck and 45% of the hash rate and also fail to do a 51% attack with bad luck and 55% of the hash rate.
Either way, if the issue is the concern of a 51% by someone taking over your pool, if they do see that the pool can, over a short period, sometimes do the equivalent of a 51% due to variance, then the risk is already there.

Point some out in there that you see ...

You seem to think you have all the answers, why don't you?

Your the one who said "I know inefficient code when I see it"
Or where you taking medication at the time?

The hashrate seems good, currently at 31%.

When it runs like shit on anything less than a 3.3GHz i3, and still pegs a core at 100%, then it's OBVIOUSLY inefficient code.  Because code makes a program.  If the program runs like shit, then it's obviously the code that's crap.   Bitcoind doesn't do much, there's no reason for it to need so many CPU cycles and half a gig of RAM.  It's just sloppy.

I might not know how a car engine works, but I know when an engine runs like crap.

You're just being obtuse, you know what I'm talking about (see how I used 'you're' and not 'your'?)

Ah I understand now.
You don't know what yore talking about or what bitcoind does :)
Glad we cleared that up.