doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
April 30, 2013, 12:03:30 AM |
|
User stats now have round duration and time/duration on the list of previous payments.
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
Reckman
|
|
April 30, 2013, 02:49:47 AM |
|
How is "Luck" calculated on the miner stats page, whats the time frame?
|
|
|
|
roy7
|
|
April 30, 2013, 03:04:58 AM |
|
My primary issue with most payment schemes are that they punish users when they have punish miners who have downtime --- more than they reward miners who don't have downtime. Which is why I only mine on pure pps or prop pools. Keep in mind DGM pays all miners fairly, whether you mine part time or full time at the pool. Full time miners don't get rewarded at the expense of part timer miners who get punished. Everyone gets the share of reward due them for the mining work contributed. DGM is also non-hoppable. Prop pools are hoppable, and PPS pools have a high risk of pool bankrupcy.
|
|
|
|
firefop
|
|
April 30, 2013, 03:24:41 AM |
|
My primary issue with most payment schemes are that they punish users when they have punish miners who have downtime --- more than they reward miners who don't have downtime. Which is why I only mine on pure pps or prop pools. Keep in mind DGM pays all miners fairly, whether you mine part time or full time at the pool. Full time miners don't get rewarded at the expense of part timer miners who get punished. Everyone gets the share of reward due them for the mining work contributed. DGM is also non-hoppable. Prop pools are hoppable, and PPS pools have a high risk of pool bankrupcy. As I said, I don't agree that DGM pays all miners fairly. It by design excludes pool hoppers from fair payments for hashes generated. I really do not understand this idea that hopping somehow hurts other miners on the pool or damages the pool somehow. The only exception to this would the pool being unable to handle the increased traffic and it amounting to a ddos attack that prevented other miners from getting work - I think stratum has gone a long way to mitigate this as a concern. as for pps pools having a risk of the pool going broke... yes, I understand that... I'm not denying that DGM is less risky for the pool. I'm simply not seeing the advantage of it as a miner.
|
|
|
|
Littleshop
Legendary
Offline
Activity: 1386
Merit: 1003
|
|
April 30, 2013, 03:32:29 AM |
|
My primary issue with most payment schemes are that they punish users when they have punish miners who have downtime --- more than they reward miners who don't have downtime. Which is why I only mine on pure pps or prop pools. Keep in mind DGM pays all miners fairly, whether you mine part time or full time at the pool. Full time miners don't get rewarded at the expense of part timer miners who get punished. Everyone gets the share of reward due them for the mining work contributed. DGM is also non-hoppable. Prop pools are hoppable, and PPS pools have a high risk of pool bankrupcy. As I said, I don't agree that DGM pays all miners fairly. It by design excludes pool hoppers from fair payments for hashes generated. I really do not understand this idea that hopping somehow hurts other miners on the pool or damages the pool somehow. The only exception to this would the pool being unable to handle the increased traffic and it amounting to a ddos attack that prevented other miners from getting work - I think stratum has gone a long way to mitigate this as a concern. as for pps pools having a risk of the pool going broke... yes, I understand that... I'm not denying that DGM is less risky for the pool. I'm simply not seeing the advantage of it as a miner. It is to the advantage of the NON hopping miner to mine on a DGM pool. Of course if you are a hopper, you are welcome as well.
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
April 30, 2013, 03:33:54 AM |
|
How is "Luck" calculated on the miner stats page, whats the time frame?
Luck is difficulty divided by number of shares for the round. So it's luck for the round (current block being mined).
|
|
|
|
roy7
|
|
April 30, 2013, 03:35:42 AM |
|
DGM pays hoppers their fair share of whatever work they actually did. They aren't punished or paid less. But neither do they get an unfair advantage. (In a proportional pool where someone can hop, hoppers can make more per share than full time miners.) Saying "It by design excludes pool hoppers from fair payments for hashes generated" is the opposite of what DGM's design is. DGM's design is that everyone (including hoppers) are paid fairly for the work they contribute, whether they hop or not.
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
April 30, 2013, 03:39:46 AM |
|
I really do not understand this idea that hopping somehow hurts other miners on the pool or damages the pool somehow.
The chance of solving a single share is constant. So it suits a miner to mine that share wherever it can get the highest price. On a proportional pool, that pays out blockvalue divided by totalshares, the hopper will want to mine wherever the total number of shares are lowest. Say there are two pools, one with 10 total shares so far and one with a million. It would be better for the hopper to mine at the pool with 10 total shares as it would get 1/11 of the block value if it finds the block. It would only get 1/1,000,001 if it found it in the second pool. So the hopper moves around mining at whatever pool has the lowest number of shares, which will be one that has found a block most recently. So the hopper is getting more money this way than if they weren't hopping. This means the miners that aren't hopping are getting less money due to the actions of the hopper. The pool loses out too because it gets a huge influx of hashrate at the beginning of the round and then, as it goes longer, it drops off leaving it with a low hashrate and even less chance of finding a block. Other miners get disillusioned and leave. I think these are the main arguments made for those that think hopping is bad.
|
|
|
|
firefop
|
|
April 30, 2013, 04:41:34 AM |
|
I really do not understand this idea that hopping somehow hurts other miners on the pool or damages the pool somehow.
The chance of solving a single share is constant. So it suits a miner to mine that share wherever it can get the highest price. On a proportional pool, that pays out blockvalue divided by totalshares, the hopper will want to mine wherever the total number of shares are lowest. Say there are two pools, one with 10 total shares so far and one with a million. It would be better for the hopper to mine at the pool with 10 total shares as it would get 1/11 of the block value if it finds the block. It would only get 1/1,000,001 if it found it in the second pool. So the hopper moves around mining at whatever pool has the lowest number of shares, which will be one that has found a block most recently. So the hopper is getting more money this way than if they weren't hopping. This means the miners that aren't hopping are getting less money due to the actions of the hopper. The pool loses out too because it gets a huge influx of hashrate at the beginning of the round and then, as it goes longer, it drops off leaving it with a low hashrate and even less chance of finding a block. Other miners get disillusioned and leave. I think these are the main arguments made for those that think hopping is bad. I'm following the logic up to the point where the hopper leaves the pool. (if the pool finds a block before he leaves everyone wins). Now assuming he's left... hash rate decreases... hopper has generated a large amount of shares... I'm still not seeing how it decreases the chance of finding a block for the pool... lets do some mental math here... Assume pool hash rate is 100gh/s for non-hoppers. (average time to generate a block is ~4.5 days) Assume that a hopper (or lots of them) bring another 10 th/s to the pool at the start of a round. (average time to find a block for hoppers if they just had a pool ~1 day) How long are the poolhoppers likely to stay? less than 10mins on average before some pool finds a block somewhere and they all switch. Assume 10 mins on average of hoppers mining at the pool. Assume every hash generated was a valid share. ~ Case of average round: Total shares for hoppers at pool over 10 mins : 6,000,000,000 shares Total shares for legit miners over the 4.5 days : 38,880,000,000 shares So an average round, you have 15% of the total shares going to the hopper, and 85% of them going to the normal miners. 3.75 btc to hoppers. 21.25 btc to miners. ~ Case of extremely lucky round: 2 blocks back to back (and we'll even say 10 mins before that second block is found). Total shares for hoppers : 6,000,000,000 shares Total shares for legit miners : 60,000,000 shares so on this round the 1% of the shares are going to non-hoppers with 99% going to hoppers - who then probably stay at the pool until some other pool finds a block. 25.75 to hoppers. 0.25 btc to miners. ~ Case of extremely bad luck: Takes 9 days to find the block. Total shares for hoppers at pool over 10 mins : 6,000,000,000 shares Total shares for legit miners over the 4.5 days : 77,760,000,000 shares 7% of shares to hoppers, 93% to miners. 23.25 btc to miner 1.75 btc to hoppers ~ In the scenario of back to back blocks with a relatively long round length miners get an extremely small payment due to lack of shares. But this of a block they likely wouldn't have been able to generate so quickly without the pool hoppers hashing power. In the average case miners lose 15% of the reward for the block to the hoppers. In the case of bad luck the miners lose 7% of the reward to hoppers. As the round time extends the 'loss to hoppers becomes less and less. ~ Now I don't know if you noticed but these numbers are run as if the hoppers had 10 th/s. Is this realistic or is this greatly inflated? Imo it's greatly inflated since network hash rate is only ~80th/s... My only point with all this is that it doesn't really hurt the legitimate miners in any real way, given the differences between their actually hashing and the inflated estimation of hoppers (2 orders of magnitude). Yes they lose in average round 15% of income - which they could just as well lose if the pool grows to 115gh/s --- while the pool loses the added income from more short rounds. and if the pool hoppers are actually closer to 1% of network than 10% of network (which is what I suspect) then there's even less of an income loss for miners (1.5% and 0.7%). So all you're really doing is limiting the potential benefits to the proportional pool of the occasional botnet or high hash rate hoppers hitting it. Of course we can't know the actual percentage of hoppers... but it's an interesting thing to think about.
|
|
|
|
kwaaak
|
|
April 30, 2013, 05:36:51 AM |
|
Hoppers just don't have the balls to solo. If you use a pool, behave yourself. Thanks.
|
|
|
|
alexKKK
Member
Offline
Activity: 82
Merit: 10
|
|
April 30, 2013, 07:08:17 AM |
|
Doublec, hi,
we have some problems with speed now, looks like it is 10% lower than should be according to my miner stats. Do you confirm it ?
UPD: just checked it now it returned to normal speed )
|
|
|
|
zapeta
|
|
April 30, 2013, 12:33:50 PM |
|
The hopping discussion has been done to death and it isn't really relevant to the thread.
In short, if you want to pool hop, and a pool you used to hop isn't friendly to that anymore too bad, so sad.
|
|
|
|
roy7
|
|
April 30, 2013, 02:15:00 PM |
|
I'm following the logic up to the point where the hopper leaves the pool. (if the pool finds a block before he leaves everyone wins). Now assuming he's left... hash rate decreases... hopper has generated a large amount of shares...
I'm still not seeing how it decreases the chance of finding a block for the pool... lets do some mental math here...
If he leaves, he'll get paid for whatever shares he did submit while he was mining. The shares he submitted 3 hours ago before leaving (if no block has been found yet) have the same value as someone else who was also mining at the same speed/difficulty/etc and stuck around and didn't leave. Your mining right now does not change the value of the shares you submitted 3 hours ago. So an average round, you have 15% of the total shares going to the hopper, and 85% of them going to the normal miners. 3.75 btc to hoppers. 21.25 btc to miners. In the average case miners lose 15% of the reward for the block to the hoppers.
No reward has been "lost". The hoppers put in 15% of the work and got 15% of the reward. That's totally fine. Case of extremely lucky round: 2 blocks back to back (and we'll even say 10 mins before that second block is found). Total shares for hoppers : 6,000,000,000 shares Total shares for legit miners : 60,000,000 shares so on this round the 1% of the shares are going to non-hoppers with 99% going to hoppers - who then probably stay at the pool until some other pool finds a block. 25.75 to hoppers. 0.25 btc to miners.
Again in this example they got their fair share. No problem. Case of extremely bad luck:
Takes 9 days to find the block.
Total shares for hoppers at pool over 10 mins : 6,000,000,000 shares Total shares for legit miners over the 4.5 days : 77,760,000,000 shares
7% of shares to hoppers, 93% to miners. 23.25 btc to miner 1.75 btc to hoppers
What you are ignoring here is that the hoppers leave when the round goes long, not before. On average, a full time miner who never leaves will see short and long term blocks and it'll all average out so they get block reward * 1/D reward per share submitted. But a hopper rocks the boat by only mining until a round goes long. So on short rounds he gets paid more than B * 1/D since the total of total shares was < D. In long rounds he gets his proportional share except he abandoned ship when total shares submitted so far = D, so the miners left are mining with a block round going down on each new share submitted but the hopper is over on some other short pool mining at a per share value that is high. There are threads dedicated on "how to hop" most profitably. Worth a read if you aren't seeing why hoppers in proportional pools hurt loyal miners who never leave. My only point with all this is that it doesn't really hurt the legitimate miners in any real way, given the differences between their actually hashing and the inflated estimation of hoppers (2 orders of magnitude). Yes they lose in average round 15% of income - which they could just as well lose if the pool grows to 115gh/s --- while the pool loses the added income from more short rounds. Nothing is lost in the average round. The hoppers put in X% work and got paid X% of the reward. As it should be. Hoppers don't care about the average case, they want to benefit from the short blocks while leaving loyal miners to work off the less profitable final shares of a long block. This is why some types of PPS systems (SMPPS, RBPPS, etc) end up collapsing. Too few people will work on the shares needed to finish the current block when their reward for doing so is less than mining someplace else. CPPSRB is one method of solving that specific issue by paying most recent miners first, so if you keep mining you'll get paid the full PPS value and there's no incentive to abandon the pool. So all you're really doing is limiting the potential benefits to the proportional pool of the occasional botnet or high hash rate hoppers hitting it. The only "benefit" is finding blocks faster, which doesn't increase earnings to loyal miners because they are the ones mining alone in long rounds when the expected reward of each new share they submit is less than B * 1/D since the total number of shares submitted is already over D. If you prefer pools that can be hopped or you prefer to hop yourself that's fine. You have the freedom to do so. It just bugs me to see people misrepresent systems like DGM by claiming it does the opposite of what it really does.
|
|
|
|
Chemicalbro
|
|
April 30, 2013, 07:02:37 PM |
|
Houston, we have a problem.
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
April 30, 2013, 07:09:03 PM |
|
Houston, we have a problem.
Crashed bitcoind. I'm in the process of restarting it.
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
April 30, 2013, 07:12:59 PM Last edit: April 30, 2013, 07:36:34 PM by doublec |
|
Pool is back up now.
Edit: And we're down again. Investigating.
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
April 30, 2013, 08:00:08 PM Last edit: April 30, 2013, 08:13:34 PM by doublec |
|
Pool is back up but the PPS servers are having issues. I've temporarily redirected them to DGM while I investigate.
Edit: And we're down again, sigh. I'll comment here when we're stable.
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
April 30, 2013, 08:34:26 PM |
|
Someone is currently trying to break into the pool server via social engineering with my hosting provider. I'm working on it and in discussion with my hosting provider.
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
April 30, 2013, 08:41:14 PM |
|
If anyone receives email from chrisdouble.co.nz, domain registered today, that is not me.
|
|
|
|
iCEBREAKER
Legendary
Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
|
April 30, 2013, 08:51:27 PM |
|
Someone is currently trying to break into the pool server via social engineering with my hosting provider. I'm working on it and in discussion with my hosting provider.
Time for a clever honeypot. Go Cuckoo's Egg on them. Hack the hackers, like a Boss.
|
██████████ ██████████████████ ██████████████████████ ██████████████████████████ ████████████████████████████ ██████████████████████████████ ████████████████████████████████ ████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ████████████████████████████████ ██████████████ ██████████████ ████████████████████████████ ██████████████████████████ ██████████████████████ ██████████████████ ██████████ Monero
|
| "The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy." David Chaum 1996 "Fungibility provides privacy as a side effect." Adam Back 2014
|
| | |
|
|
|
|