ScryptGuild Closing Down

ScryptGuild is going to be shutting down on September 27, 2014.  The mining servers will halt in 2 weeks, which is August 10th.  Users will have until September 20th to withdraw their balances before the coin daemons and wallets are taken offline.

I would like to thank everybody that has joined ScryptGuild to date.  The pool was a fun new project to work on, solving the problems of maintaining state within multiple coins over a single server to keep shares valid even during switches, and allow fast user switching on demand.  I am very sorry that the pool ended up entering a period of non-development for so long.  The rewrite was something I looked forward to, but the external factors which kept delaying the rewrite ended up pushing a different project into the front of the line.  I do not want the pool to become another ArsBitcoin/Deepbit, where it just continues on with no direction and no updates, dying of atrophy, and as such have decided that shutting down is the proper action to take.

At this time, I'm trying to get another non-pool related project off the ground, which is something I've been putting off for a few years (before BTC Guild even started).  These days, it looks like it's time to work on that project.  It is not only one that I have been wanting to do, but also one which I believe has a much brighter future than a scrypt-coin mining pool.

They've been growing rapidly for months.  Basically they're the most usable pool in China due to how many Bitcoin sites are blocked by the firewall, and that's where the majority of ASICs are made as well (they're used by most the chinese manufacturers for "testing").  I know prior to their post of an English version they were (over the last 2016 blocks) a little over half the size of GHash.io, twice the size of BTC Guild.

I'm thinking it's something else.  The NYC post was put on the website 6 days ago.  We didn't see any change in speed at all until yesterday.

Block timestamps should not be considered the actual times they were made.  The timestamp for the block is part of your header data before you start hashing it, and is based off the pool server's clock.  It also doesn't have to be updated as you continue to hash.  Blockchain.info used to have 'Received time' vs 'Timestamp', but for the last few months that has been broken and they just use the timestamp for both.

Oddly enough, the Eleuthria / Eleutheria connection is something I was completely unaware of until a few years ago when somebody asked me about it in #btcguild.  I don't think ckolivas was the first to ask, but it's possible.  The Eleuthria name was something I made up in high school.  I learned C & C++ programming basics by working on MUDs in middle school and high school.  Eleuthria was a name I came up with for one of the games.  For a swords & sorcery fantasy title, generally more vowels = better, and that's where "Eleuthria" came from.  Pronunciation being 'Eee-loo-three-uh' or 'El-oo-three-uh' (it's shifted over the years).

It wasn't my primary handle on the internet though, I'm not quite sure why I used it for Bitcoin.  Had I known I would end up making BTC Guild, I probably would've picked one that wasn't feminine!

0.01+ triggers hourly, 0.001-0.009 triggers once per 24 hours.

Bolded the part that I hope is how the regulation ends up.  It's clear by the way its written that the target business types are services that convert fiat/virtual currency and places that are being advertised as a way to store and spend virtual currencies with a third party.  That's exactly the type of business the NYDFS was designed to regulate.

I know most believe I'm over-reacting, but those who have gotten to know me over the last few years have probably picked up on the fact that I'm extremely conservative when it comes to business and finances, a stark contrast to the general Bitcoin public.  Given the choice of closing the pool down gracefully with everybody getting what they're owed, or leaving it online and risking everything I've earned to date due to a clearly overreaching regulatory body, I will take the approach that doesn't involve risk.  Not to mention everything owed to users, which would be at risk as well.

You should probably just stick to calling me Eleuthria in order to avoid that confusion.  It even takes me a minute to realize it's referencing me (I have a strong disconnect between online and offline communication).

One of the scrypt coin daemons is locking up.  It's fixed now, but the way it's dropping the pool queries is something that isn't detected as a failure, causing it to just hang.  I'm assuming setting a backup pool should let your miners failover though.  Right now the automated restarting isn't kicking in because the pool is never officially dead.

Under that scenario, the system would be partially hoppable, since if a shift finds 1 or 2 blocks early on, there's a greater than average chance of that shift ending up above expectation by the time it closes.  In shift-based PPLNS, you can't pay blocks to the shift that found them without opening up this hoppable factor.  In the long run, a hopper *would* end up ahead.

Shift 18727 finished at 11:37 AM.  Block 312297 was found at 11:22 AM, before 18727 was complete.  So Block #312297 was not applied to Shift #18727, it was applied to 18726 (and the 9 before it as well).


EDIT/ADDED LATER: What you are probably noticing is that the block wasn't applied to 18726 (and the 9 before it) until after 18727 was finished.  This is probably because the block didn't have an extra confirmation yet.  The shifts a block is going to be paid to are determined when the block is FOUND, not when it has a 2nd confirmation.  This is why the most recently closed shift can occasionally get an extra block paid to it (and also why the luck graphs don't include the most recently closed shift).

It depends on my mood when you ask me.  I've enjoyed it mostly, though sometimes you get those days where you have a flood of emails from completely clueless people.  I'm terrible as a customer service person when the other side is missing a few nuts & bolts.  I'm more than happy to help and explain things to people under most circumstances, but only if the other side is listening.

I have put time into preparing more formal closure processes though, so I guess you can say I've been looking to retire from the pool business (even though that could be years away).  Being in this game since early 2011, I've seen a lot of Bitcoin businesses go bust, "get hacked", or walk away without notice.  I've always wanted to make sure that when BTC Guild eventually goes away (and it will SOMEDAY), it does so on a positive note.  

It's also no secret that I'm a pessimist when it comes to the future of mining centralization and the fate of public-only pools.  Part of that line of thinking has occasionally made me think of closing sooner rather than later, just because of the fact that if BTC Guild had any sort of compromise or payout error, the likelihood of recovery is significantly lower than it would have been last year (like when the 0.8 upgrade cost the pool [me] 1200 BTC).  While I doubt something like that would happen again (it certainly wouldn't be as big of a loss), it is a potential obstacle with ending on a positive note, and as such is a risk that I'm always factoring into my decisions.

I don't believe there is any way to do it after the fact, other than removing the 2FA (most sites with 2FA should let you remove it by using the already enabled 2FA) and adding it again.  I generally take a screen grab of the QR code and save it to a TrueCrypt volume as my backup.

If you didn't save the token used to setup your 2FA and lose your phone, you are SOL.  If you're not, then that means they will remove 2FA, eliminating the security it provides.  Making exceptions just means your system is vulnerable to social engineering.

You don't like the obscene luck spike followed by 2 long blocks?  Kinda sad nobody posted yesterday during that run .

Sorry, but my experience with ASICs outside of Avalon (batch 1 & 2), BE Blades and USB Erupters is pretty much limited to anecdotes and observations.  As such, the only one I *know* has the issues with difficulty are Dragon Miners, but that doesn't mean others might not have similar problems.

There's been so many bitcoin site hacks over the years that if you've been in it long enough it's all but guaranteed you have an email on a list somewhere.  If you're lucky, you used a throw-away/spam only address.  MtGox and Bitstamp both had database compromises that at the very least dumped a complete list of all their users emails on multiple occasions.

Just be careful about opening attachments as usual (aka: don't do it).  I probably get about a dozen a week with .jar files attached pretending to be invoices/miner screenshots.

There was a display error on the Recent Block rewards caused by the poor luck yesterday.  The recent block rewards is a calculated set of numbers, since your actual rewards are only stored per shift, not per block.  The calculations didn't work when a block was in the recent blocks list that was more than about 30 hours old, because the page didn't have all the information cached for shifts that old.


There's no documentation on the BTC Guild API.  It's simple JSON, and all of the fields are named in a manner that gives their description.  You can copy and paste the output of the API page into a JSON parser which will give you a very easy to read breakdown of all the possible fields.

We have a couple months before anything is really known at this point.  Logically, NY state should not be able to enforce this regulation against any company without a nexus in NY, even though the proposed regulation is trying to claim differently.  The problem is whether or not there is some federal law/agreement that would allow them to extend their authority.  The other problem is that even if they have no authority to do so, it doesn't mean they can't try.

There's also the chance that other states jump on board with the NY regulation.  If that happens, there's no guarantee how much time companies in other states will have to react before they become targets.

At least from what we've spoken about so far, wizkid057 (Eligius) appears to believe there is no legal threat to businesses not based in NY.  I'm much more conservative, and as such have been preparing for the worst.

There's no need for manual withdraw on ScryptGuild.  Set your payout to 0.001 and the full balance gets paid within 24 hours (set it to 0.01 and it's within the hour).  It doesn't truncate the decimals nor does it only send the amount you set on ScryptGuild.