You would point your BTC rigs to the regular servers, and your scrypt rig to the scrypt server.  They'll be on different ports.

The scrypt coins will be mined as those coins, and credited to your account as such.  There will not be a convert to BTC option.

They won't be ported over, but your BTC Guild worker names will work for SHA256 or Scrypt.



The current plan is a toggle in the Settings menu to enable Scrypt (display only, it will work without it, similar to NMC).  This will add a button to the top of each settings/statistics page (Workers, Withdrawals, PPLNS Stats, and Pool Stats).  You will be able to pick which one is the default (SHA or Scrypt).  You will toggle between them with a button near the top of those pages (similar to the Support sub-pages).  The dashboard will update similar to how it does when you enable NMC, though the layout will change slightly due to needing to show 3 or 4 coins instead of 1 or 2.

A small update will be coming to the site in early May.  ScryptGuild is going to be merging into BTC Guild, but only for the "stable" scrypt coins (currently LTC+DOGE).  The goal of the merge is to make it so users with no interest in scrypt mining on BTC Guild will not have to see any wasted space/information about it.  It will be a toggle in the Settings page, similar to NMC, but more information will be available than just basic balance information.

Miners which opt in will be able to mine LTC, DOGE, or have the pool switch between the more profitable of the two.

Yes, I'm sure it's related to the news that the pool won't be seeing a bunch of new coins pop up.

Just to be clear, the merge will not happen on short notice.  The current plan is once I have BTC Guild's frontend ready for allowing Scrypt coins as well as BTC, I will post a notice on ScryptGuild stating that the pool is now available on BTC Guild, and is recommended for all users.  At that point, I will give people one full month to clean out any remaining balances on ScryptGuild.  The ScryptGuild pool will still be operational during that time to give users time to move over.  The pool server (not the web server) will turn off one week before the site shuts down.

I'm expecting this will probably happen around May 1st - May 7th, meaning the site will remain available until June 1st - June 7th.  I'm pretty slow when it comes to website design, especially when I've been extremely happy with how BTC Guild's frontend has worked out.  I don't want the merger to disrupt/alter the interface for users that are not interested in it, so I have to be very careful with how/where the integration shows up.

The pool applies a penalty to LTC because the difficulty is so high in comparison to the pool speed.  Most users complained very loudly when the pool went hours without any coins to show for it.  If that penalty was removed, it would probably be 90%+ of our time spent on DOGE+LTC.  Right now we hit WDC mostly as a result of the DOGE difficulty adjusting fairly quickly.

This is pointless, there's nothing about BTC Guild which rewards faster users more for their shares than slower users.  If you are 100 GH/s you will make twice as much as 50 GH/s...as it should be.

The only thing I can possible imagine for making a sub-pool style mining account is if you're so slow you can't hit the minimum payout level...in which case you should probably stop trying to mine.


Looks like somebody is just trying to steal from others, especially considering the splitting of mined coins mentioned was purely: Coins / # of Users => Per user payment.

Slush has been 2% since at least April...of 2011.  I don't think it has ever been any different.  When I first started mining before starting BTC Guild, the options were Deepbit (3% prop with paid orphans) and Slush (2% score without paid orphans), basically identical payments (orphan rate ~= 1% historically).

EDIT:  He had a single day at 0% fee celebrating the pool's third anniversary.  As far as I can tell, that is the only time in Slush's history that the fee was not 2%.

I like how you're mentioning hefty fees while mining on a pool with the same fee (and no merged mining).

Could you?  Yes.
Should you?  Not in this lifetime, CPU mining has been dead for a long time now, it is too slow to even bother (in SHA256 you will never earn enough to even pay the transaction fee to spend what tiny fraction of a coin you mine in your lifetime).

That's exactly the point.  Multicoin mining is still profitable, but it requires *constantly* adding new coins because they only remain profitable for a *very* short time, and they die off almost entirely just as fast.  Meanwhile, LTC/DOGE are the most profitable Scrypt coins the *majority* of your time spent mining, and the gap between multicoin pools with every coin and just switching between LTC+DOGE is constantly shrinking.  Compared to straight LTC, it's worth doing, but compared to LTC+DOGE switching, you're talking very marginal gains.

Slush's (flawed) anti hopping system is purely based on the timing of individual shares.  Basically, the more recent a share was submitted, the more its worth.  It has nothing to do with user or worker.  A share submitted now is worth more than one submitted a minute ago.  A share submitted 30 minutes ago is virtually worthless due to the discrepancy between the score that share earned vs the score a recent share earns.

Quite a few are sticking with ScryptGuild (we've only really lost one power user for the main drop in hash rate).  The merger with BTC Guild *will* keep profit switching between LTC and DOGE.  It will also be extendable similar to ScryptGuild so I could add more coins later.  Auto convert is unlikely though.

As stated on the previous page (and bold red on the first post), the pool is going to be shutting down/merging into BTC Guild over the next month or so.  After the announcement the fastest user (~1/4th the pool's speed) moved to a scrypt-n coin.

Sometimes the pool is only on a coin for a few seconds.  If you don't get a submission in that time frame, you won't see any shares for that coin when the shift closes.  There's also some people who decide to mine specific coins which the auto switcher doesn't hit in the same shift.

Generally when using testnet, it's recommended you use a 'testnet-in-a-box' setup where you have your own private testnet, especially if you're using it to test mining of any kind.

Why would you want the pool to shrink?  Higher speed = less variance.  You'd get less per block but more blocks.

Users weren't able to enter a P2SH style wallet address (they start with a 3 instead of a 1, and my script used to validate an address didn't properly validate them), so they couldn't use an address that required multiple signatures in order to spend the funds, which is the point of an M-of-N type transaction.  One example scenario for an M-of-N style address is your funds can't be spent unless both your PC and your phone sign the transaction to send coins somewhere, effectively adding 2 factor authentication to the address itself.  I'm not familiar with how it has been implemented in client implementations or web wallets, it's not something I've ever found a need for personally.

P2SH itself had a bit of a history about 2 years ago, where miners (mostly pools even back then) had to "vote" by including /P2SH/ in the coinbase before rules enforcing stricter requirements for p2sh transactions came into effect.  You can get a little information on the background of it (BIP 16) here: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki

Something that was implemented long ago but not used much.  It's something a few online (and offline?) wallets have started using.  P2SH allows for M-of-N escrow style transactions.

Applied a small fix to the wallet validation code to support P2SH addresses for your withdrawal address.

Low profits on switching coins will be permanent unless all multi-coin pools die.  The pump & dump phase where every crappy scrypt coin had it's moment in the spotlight is over.  Scrypt-N is semi resistant to multipools until they develop an extension to stratum which lets the server embed the particular brand of scrypt-n into the work packets and a miner supports it.  It would be trivial to implement and once one pool does it the others will follow (the only thing stopping it is the lack of mining software that supports the ability to change algorithms via stratum command).