Bitcoin Forum
December 07, 2016, 08:34:33 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 [402] 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 »
  Print  
Author Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers  (Read 829079 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
hurricandave
Legendary
*
Offline Offline

Activity: 868



View Profile
November 04, 2014, 06:35:19 AM
 #8021

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?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481142873
Hero Member
*
Offline Offline

Posts: 1481142873

View Profile Personal Message (Offline)

Ignore
1481142873
Reply with quote  #2

1481142873
Report to moderator
1481142873
Hero Member
*
Offline Offline

Posts: 1481142873

View Profile Personal Message (Offline)

Ignore
1481142873
Reply with quote  #2

1481142873
Report to moderator
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 04, 2014, 06:44:16 AM
 #8022

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
Legendary
*
Offline Offline

Activity: 868



View Profile
November 04, 2014, 06:54:11 AM
 #8023

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 04, 2014, 07:17:52 AM
 #8024

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
Legendary
*
Offline Offline

Activity: 868



View Profile
November 04, 2014, 07:32:18 AM
 #8025

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
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 04, 2014, 07:34:35 AM
 #8026

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
hurricandave
Legendary
*
Offline Offline

Activity: 868



View Profile
November 04, 2014, 07:40:16 AM
 #8027

ME go read more Undecided
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
November 04, 2014, 03:11:59 PM
 #8028

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 Wink)

eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
November 04, 2014, 05:12:32 PM
 #8029

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 Wink)

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.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 04, 2014, 06:10:42 PM
 #8030

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. Smiley

eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
November 04, 2014, 06:52:17 PM
 #8031

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. Smiley

Ah, good point.  They would be gambling on solving a block before the network does, and if they're going to make that gamble they might as well just mine an entire block for themselves.  Time change+a few late nights must be taking their toll on my early morning thinking skills.




In the rest of this post, I will be making reference to "super shares".  This is a term for grouping up multiple share submissions at a lower difficulty into a single share that is "big enough" to be put into the list of payments in the next block.

Building off my earlier post, the "5000 super shares" list of users that would get paid on the next block solve is flexible in that it could be altered to be a specific multiple of difficulty, just like PPLNS allows N to be changed to either increase or decrease the window being used.  By lumping share credit into "super shares", you can define a super share as any "difficulty sum".  Miners would continue to work at smaller difficulties like they always have in pooled mining.  Upon reaching the "super share" threshold, they enter the list of addresses to be paid the next time the block updates, and push off the oldest address in that list.

My earlier example of 5000 super shares at 8m diff each would be equivalent to PPLNS where 'N' = network difficulty.  If it was modified to the current pool setting, it would be closer to 32m diff per "super share", which would be 'N' = 4x network difficulty.


EDIT:  Just to clarify, "5000" is just an example where the minimum payment a user would receive is 0.005.  This wouldn't actually create a huge coinbase tx (in terms of data size).  There would not actually be 5000 addresses being paid in the coinbase.  Very fast users would be have multiple super shares in the list.  The fastest user on BTC Guild at this time would be 450-500 of the 5000 super shares paid in each block.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
November 04, 2014, 08:12:21 PM
 #8032

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. Smiley

Ah, good point.  They would be gambling on solving a block before the network does, and if they're going to make that gamble they might as well just mine an entire block for themselves.  Time change+a few late nights must be taking their toll on my early morning thinking skills.




In the rest of this post, I will be making reference to "super shares".  This is a term for grouping up multiple share submissions at a lower difficulty into a single share that is "big enough" to be put into the list of payments in the next block.

Building off my earlier post, the "5000 super shares" list of users that would get paid on the next block solve is flexible in that it could be altered to be a specific multiple of difficulty, just like PPLNS allows N to be changed to either increase or decrease the window being used.  By lumping share credit into "super shares", you can define a super share as any "difficulty sum".  Miners would continue to work at smaller difficulties like they always have in pooled mining.  Upon reaching the "super share" threshold, they enter the list of addresses to be paid the next time the block updates, and push off the oldest address in that list.

My earlier example of 5000 super shares at 8m diff each would be equivalent to PPLNS where 'N' = network difficulty.  If it was modified to the current pool setting, it would be closer to 32m diff per "super share", which would be 'N' = 4x network difficulty.


EDIT:  Just to clarify, "5000" is just an example where the minimum payment a user would receive is 0.005.  This wouldn't actually create a huge coinbase tx (in terms of data size).  There would not actually be 5000 addresses being paid in the coinbase.  Very fast users would be have multiple super shares in the list.  The fastest user on BTC Guild at this time would be 450-500 of the 5000 super shares paid in each block.

If you can figure out how to do this in a manner that is TNO (trust no one), then I think you'll be on to something.  Otherwise, who's to prevent a pool op from putting whatever supershares he wants on the share chain?

One of the great things about p2pool is the TNO principle.  Everything everyone does can be, and is verified on the share chain.  The chain itself contains the payout data, and you get on it by submitting a big enough share.

Your idea is similar to the one I had.  My suggestion was to have lower the share size significantly so that small miners can get on.  That means one of the basic principles of p2pool has to change: work has to stop restarting every time a share is added to the chain.  Instead, like conventional pools, work restarts when a block is found on the BTC chain.  At that point all the nodes use a predetermined algorithm to gather up all the shares since the last block, bundle them together into a "payout" share, and add it to the payout chain.  (That means two chains.)  That way the TNO principle still applies ... every node can independently verify both chains.  Worker data (coinbase?) is based upon the data in the payout chain, so when a block share is submitted, payout happens properly.  Note this also means the current round doesn't count towards payout.

There may be something I'm overlooking here, but that's the basic principle. 

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
cryptouser
Full Member
***
Offline Offline

Activity: 178


O__o


View Profile
November 04, 2014, 10:44:33 PM
 #8033

A brief update on the weekend's events:  BTC Guild is not closing down in the near future.  BTC Guild is not being sold in the near future.  I am beginning to go over options with some colleagues in other countries and lawyers to consider moving BTC Guild to another country.  This may involve taking on a partner, but I would maintain the primary role in the management and operations of the pool itself.  More on this will be made available as it develops.

That process will be the answer to the concern over regulation.  The second part, the concern about the cost of a successful compromise of the pool, is something I am working on addressing.  I have already made some changes to the pool hot wallet to significantly decrease the amount of funds kept online.  It will mean failed withdrawals may happen more frequently (we haven't had that happen in many months), though it is preferable to have a few withdrawals delayed for 12-24 hours than have the site shut down due to a compromise.

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.

Great news Smiley

Thank you !
clanbake
Member
**
Offline Offline

Activity: 84


View Profile
November 06, 2014, 04:32:51 AM
 #8034

you didnt sell it to the noobs at GAW, they have nothing to do with btcguild?
Scala
Newbie
*
Offline Offline

Activity: 8


View Profile
November 06, 2014, 02:41:33 PM
 #8035

A brief update on the weekend's events:  BTC Guild is not closing down in the near future.  BTC Guild is not being sold in the near future.  I am beginning to go over options with some colleagues in other countries and lawyers to consider moving BTC Guild to another country.  This may involve taking on a partner, but I would maintain the primary role in the management and operations of the pool itself.  More on this will be made available as it develops.

That process will be the answer to the concern over regulation.  The second part, the concern about the cost of a successful compromise of the pool, is something I am working on addressing.  I have already made some changes to the pool hot wallet to significantly decrease the amount of funds kept online.  It will mean failed withdrawals may happen more frequently (we haven't had that happen in many months), though it is preferable to have a few withdrawals delayed for 12-24 hours than have the site shut down due to a compromise.

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.

Thank you for keeping you AWESOME pool working. I mainly mine on Bitminter and BTC Guild and really appreciate your passion, dedication and commitment to the Bitcoin miner's community  Cheesy
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
November 06, 2014, 05:25:44 PM
 #8036

you didnt sell it to the noobs at GAW, they have nothing to do with btcguild?

Correct, the pool was not sold/transferred/partnered with anybody.  As of this moment, absolutely nothing has changed.  In the future, the pool might be moved overseas and take on a partner who would establish a new corporation (or foreign equivalent) in their country.  I'll have more information on that front late this month.  That will not actually take place unless the legal/regulatory environment forces me to move the pool, but I'm going to be making preparations so it can happen seamlessly.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
clanbake
Member
**
Offline Offline

Activity: 84


View Profile
November 06, 2014, 06:20:06 PM
 #8037

you didnt sell it to the noobs at GAW, they have nothing to do with btcguild?

Correct, the pool was not sold/transferred/partnered with anybody.  As of this moment, absolutely nothing has changed.  In the future, the pool might be moved overseas and take on a partner who would establish a new corporation (or foreign equivalent) in their country.  I'll have more information on that front late this month.  That will not actually take place unless the legal/regulatory environment forces me to move the pool, but I'm going to be making preparations so it can happen seamlessly.

Awesome! Thank you. All miners back to btcguild Smiley

I heard that the "ceo" from GAW was interested. I'm sure he would come up with, yet, another way to rip people off and I don't want to be a part of it.

Thanks again man!
Sir Alan
Full Member
***
Offline Offline

Activity: 221


View Profile
November 06, 2014, 09:33:25 PM
 #8038

you didnt sell it to the noobs at GAW, they have nothing to do with btcguild?
Straying slightly OT, having never heard of GAW I went to take a look:
Quote from: GAW web site
Hashlets have 99.9% uptime, are guaranteed to never break down, and have decreasing fees over time, which already start at the record low rate of $.08/day per MH.
Guaranteed never to break down?  This must be some new miracle of electronic engineering.  I wonder where the other 0.1% went?

$.08/day per MH?  Even if it's a typo and they mean GH, I cannot see how anybody except the operator can make money at that price; the equivalent of a single S3+ at (say) 450GH would cost $36 per day, and could never earn that much.

1Eeyore17YeHrbJW5Q3pSdV8sXujkdrrFc
Gws24
Sr. Member
****
Offline Offline

Activity: 465


View Profile
November 06, 2014, 09:59:19 PM
 #8039

GAW is mostly scrypt so no typo

Sir Alan
Full Member
***
Offline Offline

Activity: 221


View Profile
November 06, 2014, 10:05:30 PM
 #8040

GAW is mostly scrypt so no typo
That explains it.  Thanks.

1Eeyore17YeHrbJW5Q3pSdV8sXujkdrrFc
Pages: « 1 ... 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 [402] 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!