Status as of Tuesday, April 3, 2018

Discussion of development releases of Prohashing / Requests for features
Forum rules
The Development forum is for discussion of development releases of Prohashing and for feedback on the site, requests for features, etc.

While we can't promise we will be able to implement every feature request, we will give them each due consideration and do our best with the resources and staffing we have available.

For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
mikiko
Posts: 6
Joined: Tue Apr 03, 2018 8:49 am

Re: Status as of Tuesday, April 3, 2018

Post by mikiko » Wed Apr 04, 2018 9:30 am

The proble is, you / your soft sign some users as low luck, but there are no any chart/repoert, where users/miners luck is displayed. Steve Sokolowski you use only general terms. I have filling u don't know how "low luck" have been obtained - using which atributes. Why u or your experts didn't public the example how is it evalued? Why your customer have not acces to data, where he can see what happened, what can do, how manage luck. It si pity tha during 3 days we have not got exact information which numeric values affects customers luck.
"Mine another day ..." why, if I can't see how my luck changes ..... should be only lose more monye ....
isn't it?
spauk
Posts: 161
Joined: Wed Apr 27, 2016 7:33 pm

Re: Status as of Tuesday, April 3, 2018

Post by spauk » Wed Apr 04, 2018 3:09 pm

mikiko wrote:The proble is, you / your soft sign some users as low luck, but there are no any chart/repoert, where users/miners luck is displayed. Steve Sokolowski you use only general terms. I have filling u don't know how "low luck" have been obtained - using which atributes. Why u or your experts didn't public the example how is it evalued? Why your customer have not acces to data, where he can see what happened, what can do, how manage luck. It si pity tha during 3 days we have not got exact information which numeric values affects customers luck.
"Mine another day ..." why, if I can't see how my luck changes ..... should be only lose more monye ....
isn't it?
if i understand it correctly, prohashing is the only one losing money from the low-luck cloud miner scam, not sure if they still forfeit miner's earnings like in the past. i think they're making some real progress on the issue, and there's nothing for regular miners to worry about. i was a bit worried at first if i get identified as a low-luck miner by a false positive, but they would try to resolve it with you if you make a support ticket. the reason there's no solid information for us to see is that they're still working on it, an ongoing investigation (just like if you tried to ask a police investigator information about an ongoing investigation they won't tell you anything).
but i would be interested to know at the end of the investigation which physical mining devices got identified as low-luck miners, if any, but it may be impossible to know if they were rented machines.
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Status as of Tuesday, April 3, 2018

Post by Steve Sokolowski » Wed Apr 04, 2018 6:27 pm

spauk wrote:
mikiko wrote:The proble is, you / your soft sign some users as low luck, but there are no any chart/repoert, where users/miners luck is displayed. Steve Sokolowski you use only general terms. I have filling u don't know how "low luck" have been obtained - using which atributes. Why u or your experts didn't public the example how is it evalued? Why your customer have not acces to data, where he can see what happened, what can do, how manage luck. It si pity tha during 3 days we have not got exact information which numeric values affects customers luck.
"Mine another day ..." why, if I can't see how my luck changes ..... should be only lose more monye ....
isn't it?
if i understand it correctly, prohashing is the only one losing money from the low-luck cloud miner scam, not sure if they still forfeit miner's earnings like in the past. i think they're making some real progress on the issue, and there's nothing for regular miners to worry about. i was a bit worried at first if i get identified as a low-luck miner by a false positive, but they would try to resolve it with you if you make a support ticket. the reason there's no solid information for us to see is that they're still working on it, an ongoing investigation (just like if you tried to ask a police investigator information about an ongoing investigation they won't tell you anything).
but i would be interested to know at the end of the investigation which physical mining devices got identified as low-luck miners, if any, but it may be impossible to know if they were rented machines.
A few thoughts about these issues.

First, we can't talk about this issue because the information we're finding out could implicate some people in a scam. There are legal consequences to making accusations and we aren't confident enough in our evidence yet to make an accusation.

Second, Chris is working on releasing payments to as many people as possible, as he discovered an issue that might cause a few people to be erroneously identified. Unfortunately, the issue doesn't explain all the miners' low luck, but it will further eliminate false positives.

Third, there has been an influx of new forum users who are clamoring for information about what is going on. They often register, start talking about this issue within five minutes, and talk about nothing else in their posts or in their chat. While I understand that people are concerned, the number of long-time posters who are concerned is significantly lower (or zero) than the number of these new users who only talk about this one issue.

Fourth, miners who have normal luck will see their payments fully paid, including from the days they had a really, really bad day. We're not stealing money; it may just take some extra time for some users until we are able to improve the algorithm.

In regards to the issue of our being the only pool that suffers the issue, based on what we have found so far, we believe that every pool suffers from this problem because the people mining are not aware they are being scammed. However, we suspect that because many pools are pay-per-last-N-shares who take a cut of every block found, they never lost any actual money and therefore never performed a detailed analysis of what is going on. None of the open source pool software to our knowledge does anywhere close to the level of accounting that we do.
mikiko
Posts: 6
Joined: Tue Apr 03, 2018 8:49 am

Re: Status as of Tuesday, April 3, 2018

Post by mikiko » Thu Apr 05, 2018 2:52 am

A few thoughts about these issues.

First, we can't talk about this issue because the information we're finding out could implicate some people in a scam. There are legal consequences to making accusations and we aren't confident enough in our evidence yet to make an accusation.

Second, Chris is working on releasing payments to as many people as possible, as he discovered an issue that might cause a few people to be erroneously identified. Unfortunately, the issue doesn't explain all the miners' low luck, but it will further eliminate false positives.

Third, there has been an influx of new forum users who are clamoring for information about what is going on. They often register, start talking about this issue within five minutes, and talk about nothing else in their posts or in their chat. While I understand that people are concerned, the number of long-time posters who are concerned is significantly lower (or zero) than the number of these new users who only talk about this one issue.

Fourth, miners who have normal luck will see their payments fully paid, including from the days they had a really, really bad day. We're not stealing money; it may just take some extra time for some users until we are able to improve the algorithm.

In regards to the issue of our being the only pool that suffers the issue, based on what we have found so far, we believe that every pool suffers from this problem because the people mining are not aware they are being scammed. However, we suspect that because many pools are pay-per-last-N-shares who take a cut of every block found, they never lost any actual money and therefore never performed a detailed analysis of what is going on. None of the open source pool software to our knowledge does anywhere close to the level of accounting that we do.
Sorry I am one of the customers which have had blocked account. I used Nicehash and tryed mine like u suggested somevere in this forum.... so I look at the price and mine using NiceHash if I evaluate that it is profitable.
It is clear process, price is on your web, mine using your soft, I only order hash power. Evaluation of profit is did by your pool, so wat is wrong.
I had mined some money few days before blocking, but was not payed and your pool blocked my account because "low luck" which I can see nowhere.....
I have no info wich mining has low luck, becouse Average Mining Efficiency was high, i fond 15 blocks, nothing was rejected, everthing akcepted 30. of march by your soft .......
I still mine, now pack prefered by you, I mine for 3 days .... but still low luck. I am nervous for missing information and blocked account ..... i think that is normal!!!!
and more over I payed for hashpower to you ......
vinylwasp
Posts: 95
Joined: Mon Oct 31, 2016 3:42 am
Location: Singapore

Re: Status as of Tuesday, April 3, 2018

Post by vinylwasp » Thu Apr 05, 2018 4:20 am

Steve Sokolowski wrote:Good morning!
  • Last night, Chris successfully changed the load balancer so that it would better allocate connections to mining servers. Previously, we allocated 1/4 of all IP addresses to each server. Now, two servers have 3/16 of IPs, and the other two have 5/16 of IPs. That should improve CPU usage, and efficiency, until more mining servers become available in two days.
Using an IP based load balancing algo explains a lot Steve, this suggests that an IP with 500 L3+s gets the same share of PH resources as a IP with a single L3+. Can your load balancer support any of the algorithms that attempt to use some measure of server workload to distribute connections? E.g., Least Connections, Weighted Response Time or any of the more advanced L5-L7 Software algos?

Even DNS Round Robin would be better than a fixed arbitrary assignment based on IP address.
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Status as of Tuesday, April 3, 2018

Post by Steve Sokolowski » Thu Apr 05, 2018 8:30 am

vinylwasp wrote:
Steve Sokolowski wrote:Good morning!
  • Last night, Chris successfully changed the load balancer so that it would better allocate connections to mining servers. Previously, we allocated 1/4 of all IP addresses to each server. Now, two servers have 3/16 of IPs, and the other two have 5/16 of IPs. That should improve CPU usage, and efficiency, until more mining servers become available in two days.
Using an IP based load balancing algo explains a lot Steve, this suggests that an IP with 500 L3+s gets the same share of PH resources as a IP with a single L3+. Can your load balancer support any of the algorithms that attempt to use some measure of server workload to distribute connections? E.g., Least Connections, Weighted Response Time or any of the more advanced L5-L7 Software algos?

Even DNS Round Robin would be better than a fixed arbitrary assignment based on IP address.
That's not exactly true. Each connection uses the same amount of resources as any other connection. That's why the IP address space is not divided equally among the servers. The previous algorithm was to take the 4th modulo of the IP addresses, but there was one modulo that had more connections than others. That's why Chris now allocates 3/16 of the addresses that have the most connections to one server, and 5/16 to another, and so on.

The ideal way to do this would be to have the same number of connections associated with each server. The best algorithm for this is simply to assign connections at random to the servers. The problem with that algorithm is that if a server goes down, then all the people connected to it start trying to connect again, and instead of being assigned to the same server once it comes back up, the random algorithm assigns them to the other three servers and they stay connected.

Perhaps you can help. What we need is a "repeatable random" algorithm. Once a connection is made, that same person needs to be assigned to the same mining server the next time that person connects. Ideally, there would be no lookup dictionary. Do you have any suggestions?
User avatar
CSZiggy
Posts: 662
Joined: Wed Jan 31, 2018 2:44 pm

Re: Status as of Tuesday, April 3, 2018

Post by CSZiggy » Thu Apr 05, 2018 11:58 am

Steve Sokolowski wrote: That's not exactly true. Each connection uses the same amount of resources as any other connection.
So a miner with 1 machine uses the same resources connecting in as a miner with 50 machines running?
Seems like the single got more resources than needed or the 50 miner is lacking some.
Or are each one of those 50 machines its own connection?

Are the SHA-256 miners getting/using the same resources as a x-11 or a scrypt miner's connections?

If I was running an Equihash rig, would I get the same resources allocated when I connected if I was hashing at 40 or 4000 depending how many video cards I had on the mobo of the mining rig? How high would the hash have to be in order to have needed more than the default resources when connecting in? Is there a case when a miner would have needed more than they were assigned which brings out the swapper?
User avatar
CSZiggy
Posts: 662
Joined: Wed Jan 31, 2018 2:44 pm

Re: Status as of Tuesday, April 3, 2018

Post by CSZiggy » Thu Apr 05, 2018 12:21 pm

Steve Sokolowski wrote:Perhaps you can help. What we need is a "repeatable random" algorithm. Once a connection is made, that same person needs to be assigned to the same mining server the next time that person connects. Ideally, there would be no lookup dictionary. Do you have any suggestions?
INCOMING IP ADDRESS

A.B.C.D

A x 16^3=AA
B x 16^2=BB
C x 16^1=CC
D x 16^0=DD

SERVER ASSIGNED NUMBER = mod( (AA+BB+CC+DD) , # of servers )
As the number of servers goes up or down the mod should rebalance over time.
As long as they connect in from the same IP they should hit the same server, unless the servers have increased or decreased since last connection.


We used a variation of this in college with ID numbers to generate usernames, using IP instead ID numbers and using hex 16 instead of dec 10 and I think that same allocation might work. What do you think?
Fausto
Posts: 5
Joined: Wed Jan 03, 2018 6:47 pm

Re: Status as of Tuesday, April 3, 2018

Post by Fausto » Sun Apr 08, 2018 6:29 am

I listen to your advice and returned to the pool BUT still , running another long day and no payment and still the "luck" obscure thingy.
Can you please, just let my payment go out?
I don't think I will be back here again. This thing is just taking my time and money for a loss.
Please, just make your system pay me my balance please.
Post Reply