[CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers

[lowbander80]

Good you decided to change country in order to be competitive and keep alive.
Closing is the same as giving up.
I would not wanted to change the pool setting on my miners...

[Panxora_COO]

M.M. Did you receive my message? My CEO Gavin would be willing to meet with you on your turf to discuss whether we could perhaps create something even better for your users? This is about brainstorming. And you would enjoy Gavin, he has a really unique mind and is VERY good at thinking around problems and has real deep knowledge about certain useful things.
Go see the business we are building at www.firstglobalcredit.com. I think we have a similar view of the world.
I am going to keep my skype open (firstglobalcredit) in case you want to discuss.
I think what you've done thus far is pretty amazing.
Marcie

[GigaBit]

After that huge post on /r/Bitcoin, you reverted your decision?

The response to the intent to close the pool were definitely weighing heavily on me.  That was originally why I began to consider selling the pool to keep it running.  After responding to the first wave of inquiries about buying the pool, I started to realize that selling the pool would likely not be possible.  I could not separate myself from the pool, and the only thing going through my head over the last two days was the concern that if I sold it and somebody ruined it, opened it up to vulnerabilities, or wronged the users, it would be my fault even if it happened years after I was gone.

I'd be willing to help, if you're looking for a partner.

I'm Federally incorporated in Canada, where our laws are rather lax and no authority argues for long with me.

We also operate one of the largest independent mines in the country running on 80% free power.

We're also in the works of registering with FinTRAC, the Canadian version of FinCEN, the regulatory body for another project.

Would be easy for me to add your pool to our services requiring MSB licensing.

You got mail, check it out of interested, I don't comment on here often, very busy, too much pessimism.

Peace Out

[Remember remember the 5th of November]

After that huge post on /r/Bitcoin, you reverted your decision?

The response to the intent to close the pool were definitely weighing heavily on me.  That was originally why I began to consider selling the pool to keep it running.  After responding to the first wave of inquiries about buying the pool, I started to realize that selling the pool would likely not be possible.  I could not separate myself from the pool, and the only thing going through my head over the last two days was the concern that if I sold it and somebody ruined it, opened it up to vulnerabilities, or wronged the users, it would be my fault even if it happened years after I was gone.

This would be true. If you sell it, you wouldn't know to whom you'd be selling it and what intentions that person has.

[freedomno1]

After many months of consideration, I have finally made the choice to announce the planned closure of BTC Guild.  Below, I've outlined the closure process/timeline and reasons that this decision was made.


Closing Words

When I got into Bitcoin back in March of 2011, I never expected anything that we've seen over the last 3 and a half years.  I had never built a computer before, never run a server beyond a Gentoo PC in a spare bedroom, and never setup a website that experienced even 0.1% of the traffic BTC Guild gets on an average day.

Bitcoin and BTC Guild have both radically changed my life.  While I am closing BTC Guild, I still plan to remain a part of the Bitcoin community.  I do believe, even in the face of over-regulation, that Bitcoin will continue to grow and become more useful and usable.  I just feel that it is time to move on from BTC Guild, and take pride in the fact that BTC Guild's closure can show that not all Bitcoin businesses end with somebody stealing funds from their users, either by "getting hacked" or outright theft.

It was a good run
Regulations seem to be red taping everything but thanks for all your work on BTC Guild

[RoadStress]

Thank you eleuthria for you last update!

@freedomno1 you may want to read eluthria's last update.

[SVK]

That's the man 

Thank you thank you thank you 

I have all ready put miners for sale lol.

[stan258]

Oh thank goodness.  I pulled my units over alot of anxieties.  They will be brought back tonight. Thanks E.

[eleuthria]

BTC Guild email support has been moved to a ticketing system to allow for better tracking of support requests, and likely bringing in somebody to assist with handling support requests which do not require access to the user's account.  I will still be the only one capable of accessing any user account history/information when a support request requires it.  Support will still be handled via email, but it requests should be answered more quickly and not left unanswered for more than 12-24 hours, depending on the time it was sent and whether or not I need to answer it myself.

[Syke]

I am also exploring ways that the pool could make a transition to coinbase payments to further reduce the amount of funds at risk at any given time.  This probably won't happen for a few months, if it happens at all.

+1. I much prefer direct payouts, and it eliminates a lot of your risk.

[hurricandave]

I am also exploring ways that the pool could make a transition to coinbase payments to further reduce the amount of funds at risk at any given time.  This probably won't happen for a few months, if it happens at all.

+1. I much prefer direct payouts, and it eliminates a lot of your risk.

Does this mean that instead of an hourly disbursement of funds to/for accounts meeting the user's settings minimum threshold from their accumulated balance, that we would have a payment after each/every matured block award which accepted shares were submitted for? Or somehow still utilize a shift scheme to determine contributions?

[Luke-Jr]

I am also exploring ways that the pool could make a transition to coinbase payments to further reduce the amount of funds at risk at any given time.  This probably won't happen for a few months, if it happens at all.

+1. I much prefer direct payouts, and it eliminates a lot of your risk.

Does this mean that instead of an hourly disbursement of funds to/for accounts meeting the user's settings minimum threshold from their accumulated balance, that we would have a payment after each/every matured block award which accepted shares were submitted for? Or somehow still utilize a shift scheme to determine contributions?

One nice thing about PPLNS (and why p2pool uses it) is that it's very easy to make the block reward mined distributed among all the miners it's supposed to pay.
So you wouldn't need to wait until the block matures to get a payout - you'd "just have" the payout in your wallet the moment the block was mined, and it would never touch BTCGuild's wallet at all.
Disclaimer: I don't know what (if anything) Eleuthria has planned for implementing this, this is just how I would do it, if it were me.

[hurricandave]

Would this negate the shift scheme we currently use? I only ask since from time to time it takes less than a minute for the network to solve a block and in the past we/pool had luck getting some of those consecutive blocks, a momentary users restart could leave someone out in the cold after running 30+ days nonstop and Windoze wants an update/restart and the pool was unlucky the prior 8 consecutive hours.

[Luke-Jr]

Would this negate the shift scheme we currently use? I only ask since from time to time it takes less than a minute for the network to solve a block and in the past we/pool had luck getting some of those consecutive blocks, a momentary users restart could leave someone out in the cold after running 30+ days nonstop and Windoze wants an update/restart and the pool was unlucky the prior 8 consecutive hours.

I don't see why you would expect it to change the reward scheme at all.

[hurricandave]

Guess, cause I've been looking around the past weekend at other pools and there seems to be as many different ways to payout as there are pools to use. Kano's is a per block reward system I believe but he also waits till the block matures before distributing it, manually for now. His pool GUI is really slim on info but looks like if you miss the boat on a quick block reward well, you get nothing on the short block, maybe I misunderstood his payout scheme.

[-ck]

Guess, cause I've been looking around the past weekend at other pools and there seems to be as many different ways to payout as there are pools to use. Kano's is a per block reward system I believe but he also waits till the block matures before distributing it, manually for now. His pool GUI is really slim on info but looks like if you miss the boat on a quick block reward well, you get nothing on the short block, maybe I misunderstood his payout scheme.

It's just PPLNS which is the same as BTCGUILD. There's no "missing out" unless you stopped mining a long time before the block is solved (days). The only difference is every last bit of the reward is paid out each time a block is solved.

[hurricandave]

ME go read more

[windpath]

I love p2pool (obviously), and the problem with the p2pool PPLNS system is that it imposes a minimum hash rate to have an expected payout that directly coincides with the overall pool speed.

As the pool speed increases it takes more hashing power to keep a share in the chain, and more and more smaller miners are excluded from the payout.

Eleuthria, if you can come up with a trust-less, decentralized payout structure that supports non-dust size payouts for smaller miners PLEASE fork p2pool.

This has been our #1 obstacle for quite some time and I can not think of anyone better to take on the challenge...

(sorry if this is considered way off-topic here, but what better way for Eleuthria to step down gracefully and protect his legacy then by decentralizing BTCGuild, combining it's hash power with p2pool, and solving a major problem with the p2pool payout system all in 1 foul swoop )

[eleuthria]

I love p2pool (obviously), and the problem with the p2pool PPLNS system is that it imposes a minimum hash rate to have an expected payout that directly coincides with the overall pool speed.

As the pool speed increases it takes more hashing power to keep a share in the chain, and more and more smaller miners are excluded from the payout.

Eleuthria, if you can come up with a trust-less, decentralized payout structure that supports non-dust size payouts for smaller miners PLEASE fork p2pool.

This has been our #1 obstacle for quite some time and I can not think of anyone better to take on the challenge...

(sorry if this is considered way off-topic here, but what better way for Eleuthria to step down gracefully and protect his legacy then by decentralizing BTCGuild, combining it's hash power with p2pool, and solving a major problem with the p2pool payout system all in 1 foul swoop )

Unfortunately, there is no real solution to p2pool's payment system.  You either need to require very high difficulty shares from miners so that any accepted share in the payment chain is a reasonably sized payout, or a very short 'N' factor, so that only the most recent shares get paid.  In either case, the problem is you can only split up the payment of a block so many ways before you end up with people receiving dust.

For example, if you want the minimum payment amount to be 0.005, that means you can only have 5,000 shares in your "to be paid" shares list, give or take a little due to tx fees in the block.  At the next difficulty, we'll round it to 40 billion just for easy math, that would mean the minimum share difficulty allowed would be 8,000,000.

One advantage a centralized pool has is that you can still use this type of system, but you could make it so instead of having to solve a single 8m diff share, you can solve a million diff-8 shares, at which point the pool pushes your account into the list shares that will get paid in the next block.  That list would function as a PPLNS chain, where every time a new share is put onto the list, the oldest one is pushed off, and a block solve would pay the current list.

There are a few issues with this system though, specifically as it comes to "stale" work.  If somebody has a share being paid in the current coinbase, and a new piece of work comes out where their work has been pushed off the payment list, they could purposely remain mining the old work (as long as the block itself isn't stale).  While this can be prevented by making it so their new submissions are considered stale as far as the pool is concerned, they would still get their reward if they solved a block.


EDIT:  Now that I think about it...that flaw should work on p2pool as well... I'm going to bet the math probably works out that somebody attempting to do that doesn't actually gain anything since they're losing out on any credit that would put them back at the front of the payment list again.  Will look into that when I'm a bit more awake.

[Luke-Jr]

There are a few issues with this system though, specifically as it comes to "stale" work.  If somebody has a share being paid in the current coinbase, and a new piece of work comes out where their work has been pushed off the payment list, they could purposely remain mining the old work (as long as the block itself isn't stale).  While this can be prevented by making it so their new submissions are considered stale as far as the pool is concerned, they would still get their reward if they solved a block.

No different than if they were solo mining and claimed the full 25 BTC...
As long as you don't credit stale shares (from the pool's perspective), nobody is hurt.