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 )
Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 64. (Read 163893 times)
Hoppers just don't have the balls to solo. If you use a pool, behave yourself. Thanks.
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.
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.
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.
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). 
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.
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.
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.
How is "Luck" calculated on the miner stats page, whats the time frame?
User stats now have round duration and time/duration on the list of previous payments.
I'm looking forward to the move to DGM... I'm hoping all the alts get that as well and maybe get 0% fee on alts :-) and after profitability evaluations take place, tx fees also get passed onto miners. 1.5% btc fee, 0% alt fees, tx fees passed on, all dgm.... I could live with that :-)
Switched to DGM.
Please start paying out txfees, too
Please start paying out txfees, too
Personally I think DMG is a dead end... not good for miners but ok for the pool.
Why don't you simply use eligius' payout schema so the pool can never go broke? It's at least fair and easy to understand. 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. Although I would make an exception for elegius... except I want to be able to register a username and have more stats than having to search for a payment address.
If you were to use that with the existing "lock in payment addresses" for each worker/user that would be a winner.
Why don't you simply use eligius' payout schema so the pool can never go broke? It's at least fair and easy to understand. 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. Although I would make an exception for elegius... except I want to be able to register a username and have more stats than having to search for a payment address.
If you were to use that with the existing "lock in payment addresses" for each worker/user that would be a winner.
A bitparking user not happy with the fee increase on PPS asks, Why do pools charge fees?. My response is here.
Personally I don't think a 1.5% pool fee on DGM is too much (of course, I wouldn't complain if it were reduced either!), especially considering you are still providing PPS payouts for the merged mining portion, you have to cover hardware costs, and for your time. Fees on the PPS side should be set high enough to cover long rounds, whatever percentage that ends up coming out to. I don't want to see a situation where fees paid on the DGM side are used to subsidize fees that users on the PPS side should be paying. PPS is a very risky payout scheme for the pool operator and it would probably be best to eliminate it all together.
A bitparking user not happy with the fee increase on PPS asks, Why do pools charge fees?. My response is here.
As a reminder, you said that you will provide info about block duration. Are you working on that? Users could track pool luck and decide how to mine
Luck history has no effect on future luck.As a reminder, you said that you will provide info about block duration. Are you working on that? Users could track pool luck and decide how to mine
Yes, it's on the list of things to do. It makes the "past blocks" stats a bit less useful without it. 
As a reminder, you said that you will provide info about block duration. Are you working on that? Users could track pool luck and decide how to mine
Luck history has no effect on future luck.
As a reminder, you said that you will provide info about block duration. Are you working on that? Users could track pool luck and decide how to mine
Jump to: