SC Guild is just going to run its course.  No new features are going to be added/copied from the main BTC Guild frontend.  I'm done dealing with forkcoins until one of them can prove itself as having any practical use outside of screwing up the hash rates of the BTC network.

Since this isn't I0C which actually stopped working, I have no plans of shutting off SC Guild as long as it can produce $25/mo to cover the two pool servers [and I'd just shut off one pool server rather than the whole SC Guild until it fails to produce $15/mo].


Regarding rejected shares:  This morning I updated to the most recent solidcoind for 64-bit linux.  If the stale rates are still high, there's nothing more I can do about it.  It's using a mostly stock pushpool configuration, but it was receiving a lot of duplicate work from solidcoind itself.

How, just take people' word for it that they mined 'X' I0C?

There is a big difference between a coin losing popularity, and a coin actually breaking which required unrelated developers to come in and fix it at a later time.  Solidcoin isn't going to suddenly stop working making it impossible to transfer money between wallets due to every node denying transactions from each other.

For the time being, I would recommend anybody that -must- connect by a specific IP to use: 78.46.186.26.  I will put up another server later on that is specifically for people with special circumstances.

I0coin literally broke.  The network stopped working.  The entire saga chain lasted one week before breaking down, but it was already broken after just a few days.  I gave warning on I0Guild.  24 hours of warning where you had full withdrawal capabilities, and even then the server stayed up for over 24 additional hours where I responded to withdrawal requests manually.  It took that much extra time just to give payouts enough confirms to reach the exchange before the network imploded.

I started I0Guild and planned on supporting i0coin for as long as it was earning enough to keep the servers online, but when the entire network literally STOPPED WORKING for over a week, I un-provisioned the VPS that it was being served on.  I was not going to waste money leaving a server online running a bitcoin fork that stopped functioning.  At the time it was taken down, we had 114 unconfirmed blocks, because we were almost the entire hashing power of the dead coin.  The total value of it all when I took it offline?  Under 1 BTC at the exchange rates when the server was deleted.

I am not clairvoyant.  The fact that after the i0coin network was dead for a full week and completely broken, unrelated people came in, tweaked the code, and "restored" the network doesn't change the fact that I0C was and still is dead.  What exists now is a completely different coin with different rules.  It just shares the same name and the largest block chain that survived the fallout.

I own BTC Guild.  I know how it works.  (Your Shares / Total Shares) * 50 BTC = Proportional reward.  It is then reduced by your donation percent.


Sorry for the thread hijack [Tycho], but when someone starts stating completely false comparisons like BTC Guild taking fees from individual shares rather than per-block rewards, I have to correct them.

Taking 2% off the block vs 2% off each user's reward results in the exact same payout for each user and the same amount for the pool.  It doesn't matter if you take 2% off the top of the block, or 2% off the individuals rewards.  If everybody on BTC Guild donated 3%, their rewards would be identical to what they would have received on Deepbit assuming their proportion of the block was the same.

The fee/donation at BTC Guild is per block.  There is no difference in the way rewards are determined between BTC Guild and Deepbit, other than the fact that you pick your personal fee based on what additional features you want and what you feel its worth.

The major cause of this week's drop was the introduction all the forkcoins in the last two weeks.  Between I0Coin and Solidcoin, we were missing 500 GH - 1 TH/s on the network for a large portion of the last two weeks.  Even with that large batch of power missing, the decrease was minor.

The BTC price also fell a bit over the last two weeks, so we'll see if we get a fairly large increase after this difficulty finishes (most the fork coins are dying off, and no new ones are in sight).  The miners with higher power costs are starting to turn off GPUs as the price dips lower, so it's going to be interesting to watch how the BTC network behaves.

The rounded ended close to an hour ago, it will be announced/awarded as soon as the hour is up.

You're absolutely wrong.  3% off the top of the block means your rewards are 3% lower.  Donating 2% of your rewards = Your rewards are 2% lower.

Block reward is 50.  Your reward is calculated proportionally, exactly like deepbit.  If you have a donation percent of 2%, your reward is reduced by that percentage.  Assuming you had two blocks with the exact same share counts on BTC Guild and Deepbit, and your contribution was the same number of shares, your reward would be 1% higher.  We use the -exact same- reward system as Deepbit: Proportional.

US West has been taken offline.  The website will also be relocating this weekend.  The new EU (DE) cluster has been expanded more as well to keep everything running smoothly.

I'm sorry, but at this time I do not plan on returning to the plan of implementing diff=2 shares.  The downstream bandwith would be basically the same on your end, only the upstream would be reduced.  I can't imagine what kind of terrible ISP you have that has bandwith caps at 6 GB/month, unless you're mining on a cell phone plan?


In other news, the EU (DE) cluster just doubled in size.  I'm moving US West miners to that server at this time, in an attempt to save on costs while improving overall pool performance.

A second server has been added to SC Guild to assist with the load.  Miners do not have to change any of their settings.  You may see a few more rejects than usual once your client recognizes the new DNS settings, at which point reject rates should be reduced a little.  A third server is being added to the cluster as soon as the ISP provisions the extra server clusters for SC and BTC Guild.

"Since Reset" stats will be added back to SC Guild this weekend, since SolidCoin is showing enough staying power to warrant a few extra features/stats.

I'm pleased to announce the return of EU (DE) servers.  These servers are actually running on new load balancing setup that should completely eliminate long poll delays due to overloaded network interfaces.  You can use the new servers by just entering 'btcguild.com' as the server [not uswest./uscentral., just btcguild.com).  If you want to make sure you always point at these servers unless they are removed, you can also use de.btcguild.com

Stats are updating again, was informed of the apache exploit regarding the request range header.  Restarted apache during a stat update, which sets a switch to stop the server from running it multiple times simultaneously.  Fixed the switch and now everything is back to normal.

I'm adding a new check to the new block code to prevent this from happening in the future.  We had a 600 share round that lasted barely over 2 seconds, so US West hadn't sync'd the round before the round ended.

The new check will ignore these server sync issues if the total shares of a round are under 15,000 [which is about 1 minute on one server].

The blocks from last night have now been properly calculated.

You're going to have high stale rates on SC Guild.  We're a massive pool and the SC network difficulty is not high enough for the 3 minute target time yet.  Stales hit when new blocks are found, because long polls are not instant no matter what server you use.

Your stale rates on SC, once the difficulty is roughly equal to actual hash speed, will be 3.3x what you get on BTC because SC is designed to produce 3.3x as many blocks in the same time frame.


The confirmation bug was fixed this morning.  I was trying to reduce server load but not polling so many transactions at once from listtransactions, and ended up setting the value slightly too low, meaning it wasn't seeing updated confirmations on blocks that were more than 60 transactions deep.

If I offer PPS, it will be a lower rate than DeepBit, since my base proportional rate is 0% (2.5% for comparable deepbit features/invalid insurance).  Tycho's PPS rate is set at a rate of 7% higher than his base rate, which seems to be about where our luck has been from inception (if I use Vladmir's numbers, I _THINK_ we're about 6.5% behind on total BTC production from expected average if you measure June 1st-August 21st, although that discounts a high luck day, and assumes invalid blocks should be 0% rather than ~1%).  Ideally in the long run, luck zeroes in on 0% as the time frame you use grows, so I may offer it even lower and just eat the loss assuming BTC Guild stays alive long enough to get back to the 0% average.

BTC Guild will likely be offering a PPS option in the near future for those who do not like variance, in a similar vein with Deepbit.  I have not decided if PPS will be included on the primary BTC page, or if I want to handle it on a forked page (like pps.btcguild.com).  It will be TRUE PPS, not SMPPS, so the pool's luck will never affect the rates/cause backpay situations.  All donator perks on BTC Guild will be automatically granted to PPS users.

The fee percentage hasn't been decided on yet, I'm going to run the numbers on how low the pool's luck has been since inception as a percentage of expectation [including invalid blocks] to determine how high my risk is based on our current relatively large historical sample size.  Just like Deepbit, over the long run you'll make more with standard proportional, but PPS is a nice insurance level where you have -guaranteed- revenue over any period of time, rather than a "close to average revenue" over a sufficiently long period of time.

My understanding is paraphrased from what I was told by ArtForz, so if I butcher the explanation I hope somebody smarter than me can correct my understanding.

I0Coin put in a time-based difficulty adjustment of 1 week, so if the network died as much as it has, the difficulty would drop without waiting for a ton of blocks that may never get made.  This check SHOULD be run based off the timestamp of the most recent block, so that individual system clock variances don't affect how the node determines what the difficulty should be dropped to.  This wasn't done.  If you turn on a fresh node today, it tries to adjust the difficulty before the chain is even accepted, refusing the valid block chain generated thus far.

Once 7 days have elapsed since the previous difficulty increase (which was from blocks, not time), the nodes that were already up and running with the block chain will likely have variances in the difficulty calculation because they may not be on and checking the NTP server at the exact time the change will occur.  This means all the i0coind nodes out there will have variances in what they think the valid difficulty is, refusing blocks from any node that does not agree.