[NR 1] Triplemining.com <> BIG jackpot every week <>

[kinlo]

Hey Kinlo, I use CGMiner and I get a retarded amount of stales from Triplemining for some reason. There are a couple other pools that are similar, but I can also achive under 1% from a few others.

At 1 point, I actually had to set my work-scan-time to 10 seconds in order to avoid submitting stales constantly, so if a hash couldn't be achived in 10 seconds, it would move onto the next attempt.

Could you shed some light on why this might be and why my temporary fix worked ?

Could this have something to do with the fact that CGMiner is multi-threaded and has the ability to use a single account for an entire motherboard (if setup that way....4 cards, 1 account?)...just thought I would add that.

Best thing to do for these type of problems is to find me online on our irc channel #triplemining on freenode.  I do not know what is going wrong here, but if you want to help, we can do some testing to see what is exactly going on by monitoring what you are sending to the server and what the server is replying, so we can find the root cause of the problems.

[1714222000]

1714222000

[1714222000]

1714222000

[bitlane]

Best thing to do for these type of problems is to find me online on our irc channel #triplemining on freenode.  I do not know what is going wrong here, but if you want to help, we can do some testing to see what is exactly going on by monitoring what you are sending to the server and what the server is replying, so we can find the root cause of the problems.

I will definately do that with the next block.

Another thing I forgot to mention that I just remembered is that at the START of a block, things seem to go quite well, but as the block progresses things seem to go downhill for me, as I described above.

Has anyone else noticed degraded performance as the block goes on longer ? It's like if the block doesn't get solved quickly, performance degrades over time. I don't think this is an issolated incident, as this might explain why the pool either has extremely SHORT blocks or extremely LONG blocks and nothing in between as it were.....I could be wrong though. See you next block.
Allan

[kinlo]

I will definately do that with the next block.

Have you had any problems lately?  You haven't responded yet...

[bitlane]

I will definately do that with the next block.

Have you had any problems lately?  You haven't responded yet...

No sorry. I actually began merged mining on another pool, but what I can tell you is oddly enough I ran into the exact SAME problem on the pool I am on now as I experienced on Triplemining (lots of stales, only helped using a short work scan time, making me very inefficient with lots of dropped/unsubmitted work) and it turned out to be a routing problem.....as in, the location of the server in question that I was connecting to. The Pool OP then provided me with an alternate server in a different geographical location and everything was solved, although others seemed to connect without consequence. ISP conflicts perhaps.

Just thought I would share, as it seemed to answer my question.....on both fronts.

Cheers,
Allan

[kinlo]

Triplemining is switching to PPLNS, N=24h

As we've discussed before, proportional payouts are not the way to go, and we've discussed PPLNS as a better alternative for our payout system.

We've been working on the idea, and we've decided to switch the pool to PPLNS, where N = 24h effective from the next found block.

This is not PPLNS as other pools implement it, by using the last 24h, people who can only mine at night for example; can have full profit of found blocks.

The new backend is tested and ready, the website will be changed the days following the next found block.

This is good news for the loyal miners of our pool, as the payout will only increase for those committed to mine with us.

[Azrael_PT]

Triplemining is switching to PPLNS, N=24h

As we've discussed before, proportional payouts are not the way to go, and we've discussed PPLNS as a better alternative for our payout system.

We've been working on the idea, and we've decided to switch the pool to PPLNS, where N = 24h effective from the next found block.

This is not PPLNS as other pools implement it, by using the last 24h, people who can only mine at night for example; can have full profit of found blocks.

The new backend is tested and ready, the website will be changed the days following the next found block.

This is good news for the loyal miners of our pool, as the payout will only increase for those committed to mine with us.

Nice, hope my income on the pool increases.
@kinlo - My laptop is coming tomorrow from service.

[organofcorti]

Triplemining is switching to PPLNS, N=24h

As we've discussed before, proportional payouts are not the way to go, and we've discussed PPLNS as a better alternative for our payout system.

We've been working on the idea, and we've decided to switch the pool to PPLNS, where N = 24h effective from the next found block.

This is not PPLNS as other pools implement it, by using the last 24h, people who can only mine at night for example; can have full profit of found blocks.

The new backend is tested and ready, the website will be changed the days following the next found block.

This is good news for the loyal miners of our pool, as the payout will only increase for those committed to mine with us.

Not quite. You do know that PPLNH is hoppable due to the time based nature of the PPLNH score?

You might do better with DGS since you can adjust your own risk, your miners variance and is provably unhoppable. Also you wont have to keep track of shares, just one share per miner.

[kinlo]

Not quite. You do know that PPLNH is hoppable due to the time based nature of the PPLNH score?

I  have not found any evidence, can you provide a link to a technical explanation?

[organofcorti]

Not quite. You do know that PPLNH is hoppable due to the time based nature of the PPLNH score?

I  have not found any evidence, can you provide a link to a technical explanation?

It's an explanation, but not a technical proof:

https://bitcointalk.org/index.php?topic=39832.0

[kinlo]

Not quite. You do know that PPLNH is hoppable due to the time based nature of the PPLNH score?

I  have not found any evidence, can you provide a link to a technical explanation?

It's an explanation, but not a technical proof:

[url]https://bitcointalk.org/index.php?topic=39832.0/url]

Oh that case.  Right.  Yes it is correct that all PPLNS pools are hopable by hopping correctly when the difficulty changes.  However, the difficulty changes are very low, and only once every 2 weeks.  So yeah, if you really want you can do it but the effort is not worth the profits.

[organofcorti]

Not quite. You do know that PPLNH is hoppable due to the time based nature of the PPLNH score?

I  have not found any evidence, can you provide a link to a technical explanation?

It's an explanation, but not a technical proof:

[url]https://bitcointalk.org/index.php?topic=39832.0/url]

Oh that case.  Right.  Yes it is correct that all PPLNS pools are hopable by hopping correctly when the difficulty changes.  However, the difficulty changes are very low, and only once every 2 weeks.  So yeah, if you really want you can do it but the effort is not worth the profits.

Actually, i meant this ->

Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.

[kinlo]

Actually, i meant this ->

Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.

Please hop the pool, what you are saying is that the pool is more profitable if the hashrate rises.  When you join, the hashrate rises, so basicly you're saying that everybody should join the pool.

There is a difference between theoretical exploits and something we should worry about...  I consider all this FUD, while it is nice to know the underlying mathematics, and while there are real pitfalls to evade, some issues are irrelevant imho....

[organofcorti]

Actually, i meant this ->

Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.

Please hop the pool, what you are saying is that the pool is more profitable if the hashrate rises.  When you join, the hashrate rises, so basicly you're saying that everybody should join the pool.

There is a difference between theoretical exploits and something we should worry about...  I consider all this FUD, while it is nice to know the underlying mathematics, and while there are real pitfalls to evade, some issues are irrelevant imho....

OK then. But keep in mind this is not theoretical and you can model it and the likely outcomes for yourself (this is me not trying to hard to convince you now that prop pools are on their way out and I'll have to hop the less hoppable pools)

[kinlo]

OK then. But keep in mind this is not theoretical and you can model it and the likely outcomes for yourself (this is me not trying to hard to convince you now that prop pools are on their way out and I'll have to hop the less hoppable pools)

There will always be poolhopping, every system has it's drawbacks.  But unless someone points out that there is more then a few percents more profit you can make due to the payment system chosen, I don't think neither me, nor most people will loose any sleep over it.  In the end there are other considerations such as transparency and ease of use which have to be considered too.  Proportional is indeed a big problem, as there was much more to gain from it, so that's why we needed to change....

[organofcorti]

OK then. But keep in mind this is not theoretical and you can model it and the likely outcomes for yourself (this is me not trying to hard to convince you now that prop pools are on their way out and I'll have to hop the less hoppable pools)

There will always be poolhopping, every system has it's drawbacks.

No, not every system is hoppable. Normal PPLNS isn't if you do it right. It's just time based PPLNH is.

But unless someone points out that there is more then a few percents more profit you can make due to the payment system chosen, I don't think neither me, nor most people will loose any sleep over it.  In the end there are other considerations such as transparency and ease of use which have to be considered too.

What's hard about vanilla PPLNS?  

Maybe showing how your miners will be negatively affected by PPLNH *without* pool hoppers it might make more sense for you.

PPLNH is a drawback for your miners if the pool hashrate drops. Think about it. Your non-poolhopper hashrate is about 30Ghps. On average that would be a block solved every two days, so already your PPLNH|H=24 is equivalent to PPLNS|N=1/2. If your hashrate drops to 20, PPLNH|H=24 is equivalents to PPLNS|N=1/3.  A week? PPLNS|N=1/7.

This is a huge increase in variance for your miners. Variance doesn't change with hashrate under PPLNS. As your miners see their variance increase, they'll leave since the whole reason to be in a pool is to decrease variance away from solo mining variance, not tend toward it.

And if you're thinking about varying H if the hashrate reduces, then you're halfway to PPLNS anyway.

Edit: and if you want a low variance method that doesn't mean keeping track of 24 hours worth of miner submission history, try the double geometric payout method. It's not as scary as it looks on first blush, it's being used at a few other pools already, and your miners get reduced payout variance.

[urstroyer]

Triplemining is switching to PPLNS, N=24h

As we've discussed before, proportional payouts are not the way to go, and we've discussed PPLNS as a better alternative for our payout system.

We've been working on the idea, and we've decided to switch the pool to PPLNS, where N = 24h effective from the next found block.

This is not PPLNS as other pools implement it, by using the last 24h, people who can only mine at night for example; can have full profit of found blocks.

The new backend is tested and ready, the website will be changed the days following the next found block.

This is good news for the loyal miners of our pool, as the payout will only increase for those committed to mine with us.

Just my 2cents:

Someone has to pay the bill for pool hopping, to bad those people will be your loyal miner.
Don't put them into a disadvantage again moving your system from a hoppable to another (maybe less) hoppable method.
PPS and DGM will be the future. I think DGM would be perfect for TripleMining, you just have to adjust the parameter to your needs.

Maybe you wanna sleep a night over your decision.

[kinlo]

No, not every system is hoppable. Normal PPLNS isn't if you do it right. It's just time based PPLNH is.

the "normal" PPLNS you are talking about is a bit more complex then the PPLNS most implement.   Do you know any pool that implements PPLNS correctly so no differencechanges can be hopped?   But still nevertheless, the difficultychanges are only limited...

PPLNH is a drawback for your miners if the pool hashrate drops.

This is a huge increase in variance for your miners. Variance doesn't change with hashrate under PPLNS. As your miners see their variance increase, they'll leave since the whole reason to be in a pool is to decrease variance away from solo mining variance, not tend toward it.

Variance does change with hashrate in PPLNS, if N is small enough.   The only thing that is true is that people not loyal to the pool will not get any money if they poolhop due to the fact that the rounds are often > 24h, but this is also true for about 50% of PPLNS, N=1/2D.   So yes, in the end, non-loyal users are punished the most, poolhoppers will not get any pay when the round is >24h.  But those loyal, which are the miners that mine every day, will make up for that later on.

So basically what you are saying is that the variance is higher then for example a PPS.  This is true.  This is true for all PPLNS systems.  But loyal users - users that mine every day, will not notice, as they meet the requirement to always be inside the payment window.  And this is also fair.  This pool gives you some variance on the pools luck.  with PPS you don't have any variance, with PPLNS systems you will earn more if the pool is lucky.  This is not a disadvantage... If the pools lucky, you get your share.

I still fail to see any reason why this system would be cheat-able (getting - statistically proven - more earnings by hopping the pool) except for the difficulty hopping - which I still haven't seen that it is just more then a theoretical remark that is practically useless.

I really appreciate everybody's thoughts about this, and I welcome all feedback.  If someone can point out any way to hop the pool, in a way that can be both statistically proven and relevant (the variance of the pool due to the PPLNS nature will be greater at this moment then the possible rewards you can get from difficulty hopping, so this is irrelevant as it is practically unfeasible), I will change the payout system again, so the pool cannot be cheated.

[kinlo]

Someone has to pay the bill for pool hopping, to bad those people will be your loyal miner.
Don't put them into a disadvantage again moving your system from a hoppable to another (maybe less) hoppable method.
PPS and DGM will be the future. I think DGM would be perfect for TripleMining, you just have to adjust the parameter to your needs.

Maybe you wanna sleep a night over your decision.

You are correct that someone has to pay the bill for poolhopping, and I agree that loyal miners should not be the victim of the abuse.   PPS and DGM are great payout systems, however, they are not the only ones that are hop-proof.  The difference between the systems is in variance and the way the payout system handles the pool's luck.  I've chosen this system to allow luck to increase the payouts for the miners. But this does not make this system any less valid or worse.  It's just a decision, do you wish to always get the same payout, or do you wish to get some part of the luck/bad luck a pool has?  Regardless of which decision you take, these systems are fair.

I still have not yet seen that the system we are using is actually hoppable.  Therefore I will closely monitor the pool, and if I see anyone successfully perform poolhopping, I will change the payout system.  I will also change when someone can show me a mathematically proven model. However, unless I've missed something, most people only say that the variance is not stable.   This is correct, but a feature, loyal users will benefit from this...

[organofcorti]

I still have not yet seen that the system we are using is actually hoppable.  Therefore I will closely monitor the pool, and if I see anyone successfully perform poolhopping, I will change the payout system.  I will also change when someone can show me a mathematically proven model. However, unless I've missed something, most people only say that the variance is not stable.   This is correct, but a feature, loyal users will benefit from this...

How will you know the pool is being hopped if you don't know how miners are trying maximise their share value? Just look for unusually lucky miners? I think you need to look for a results from first principals or from a good simulation. Otherwise you're in the dark.

[kinlo]

How will you know the pool is being hopped if you don't know how miners are trying maximise their share value? Just look for unusually lucky miners? I think you need to look for a results from first principals or from a good simulation. Otherwise you're in the dark.

You are correct that you cannot just see problems by looking at the pool alone.   But by "monitoring the pool" I understand a lot more then just looking at logs or statistics.  I mean monitoring the community and how they formulate ideas on how hopping can be done and abused on our payment system.

Running simulations is also a good idea, I'll try to make some time for that next week to see if I missed anything in my initial analysis.  But again, since I don't see any evidence of being hoppable, I'll stick to the current setup for now