Status as of Saturday, July 29, 2017

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.
GregoryGHarding
Posts: 646
Joined: Sun Apr 16, 2017 3:01 pm

Re: Status as of Saturday, July 29, 2017

Post by GregoryGHarding » Mon Jul 31, 2017 4:20 am

vinylwasp wrote:
vinylwasp wrote:
GregoryGHarding wrote:my gripe is, besides TTL, is there any reason not to at least try the options we've laid out as a community.. i'm sure if steve said ok we will try x, based on user feedback, we would be totally ok with TTL
TTL? Time to Live?
Is this what you're proposing GGH?
GregoryGHarding wrote: i propose a secondary measure. when hashrate/workers hit a maximum limit, disable API requests
Poolside, miners connect to the stratum network service, it's not an API, but regardless you still haven't proposed a model for setting the 'hashrate/workers limit' per account so it's a great idea I support in theory, but I can't see any fair way to implement it.

Are you suggesting an arbitrary hard cap per user, something like Total Pool Scrypt capacity/Number of current registered users = X GH/s per Account?

This would directly penalize the larger professional miners like myself and favor the smaller miners while immediately creating a shadow market for excess capacity that the very small miners may have spare.

I'm totally with you on the idea, we just need a fair way to implement it, and how does any miner get larger than their assigned proportion of the total hashrate? Once you do this, you've also created a market for PH accounts as Steve has pointed out.

I'd also like to know what happens when PH scales? Does each user get more GH/s or does PH auction off the new capacity at the pre-existing GH/s per account so that new users can join?

In the mean time while we're working out a fair way to do this, how do we address the profit seeking swing miners?
swing miners cone fromNH bots measuring price vs ph profitability over x time, once pool hashrate or workers hits a specific threshold cutting bots access off to api will compleatly disable the automates swing miners from calculating the profit, therefor keeping them off the pool. im here to throw the ideas out that are being shares in slack. i have no idea how to implement them, thats the bros job, i have no knowledge of how the backend systems work, i can only go by an "in theory" approach based on users opinions and pooled knowledge between us. the math, implementation, etc, is not my area of expertise, and never have i claimed it to be. but one or maybe more than one of these has to be an answer, raising fees is not the answer, it will just make everyone leave. not only the smaller miners, but because fees are measured in %, the larger miners will feel the impack too. the goal is not to drive away the ligimate rig owners, and reasonable rig renters, but to take the opertunists ability to place large automated orders which cripple the pool both in extimated hashrate limits and abilities to process shares fast enough. i know one things for sure, until the most recent changes, ive never once seen the "your miner is using the wrong algorythm" error before, simply because thats not the case, no i didi not accidently forget or mislable my a= param, i add it to every rig i use. the pool is suffering, and i can only share the opinions of the community that weve gathered together, i cannot comment on the technical details of them, but alot of what steve is saying as feedback from these perposed resoloutions just dont make sense, or are cherry picking situations or flaws with the ideas.. instead of cherry picking, there needs to be a proper thought process of each option.. if you want to find a problem with the theory, you will easly find one, if you want to take the theory, break it down, think of how it will work, and details of them, you begin to see the bigger picture. sorry about the run on paragraphs, its now approaching 6am local time and ive been awake all night thinking of things that can be done to remedy the community outcry also, sorry about the spelling mistakes, same reason.
JKDReaper
Posts: 99
Joined: Fri Mar 31, 2017 11:17 am

Re: Status as of Saturday, July 29, 2017

Post by JKDReaper » Mon Jul 31, 2017 5:38 am

. Economic Measures
The suggestion is not to change fees overall for miners, but to somehow scale them so that there is a deterrent to short term swing mining, and pool hopping. This is the aim, figure out a way.

When I started mining here the 5% fee used to be enough, people told me I was crazy but as profits have grown (scrypt) it's become much more viable to mine on PH, even when paying for NH hashrate.

Steve and Chris do need to plan and scale for new technology (like the Inno A5), but IMO they also need to control the flash crowd swing mining behavior which has a disproportionately negative affect on the pool's stability. People who mine here consistently work towards stability and maximizing their profits by avoiding downtime (this is their economic motivation). NH miners are focused on short term goals, don't really know the underlying mining technology to the same degree, and don't care 1/2 as much.

Economic penalties work in all other markets, why not here?
How do you define "swing miners"? Just want to be clear...But based on what you've said, I take it to mean anyone who doesn't own 5 L3s or whatever...More or less, big owners. You speak of economics, and yes, to a degree the big owners bring in a large portion of the income for the pool. And you talk about "pool hopping"...define this also. Is this someone who doesn't have their account connected 16 hours a day? 18? 24? I'm not trying to be dismissive, but again, based on what your saying, this is someone who is connected nearly 24/7.

My point is this...I firmly agree that NH is a huge portion of the problem here. But what about the NH users who don't flood the pool, the ones who send 250mh at a time? (I loathe NH, and do not use it, for clarity) What about the MRR renters? What about the people sending their little orbs or blades hash here? What about the people who point their 500mh hash at another pool for a few hours at a time to take advantage of a specific coin or situation? The list goes on...You want to eliminate those? Well obviously can't give you a %, but I'd be willing to bet this list covers a pretty large portion of the miners here. Your proposal, while it may work, would work for yourself and many others but kill nearly as many, or more, other miners.

Economic penalties work in any other market? If you define this as killing the little guy because he can't afford to keep up...Then you could be right. I won't repeat what I've said a couple times, bit if were talking economics, basic economics tells you to keep ALL your customers with a satisfactory product. Prices increase, that's given in any market, but to increase them with the intention of driving half your base away is just not a sensible plan. You find a way to keep all you can, while improving your product.

I'm not going to go point by point to your list of ideas that "fail completely", but like with those or this one of yours, no idea is flawless. But proposing to make this guy pay more because he can't afford to have that persons miners or whatever is like saying, "we've been in the game longer or have more money, so we should have this pool". The other ideas proposed (that I've read at least) make an attempt to help everyone, not just the "elite". To go as far as to say that the little guy should pay vastly more than the big guy for no other reason than what boils down to be so that the big guy keeps his and the little guy gets screwed is not viable. Using your own dismissing of limiting new accounts...What happens when those is done and even bigger miners or farms step in and you become the little guy? Do you get "fee"d out too? Its a slippery slope.

Again, I don't pretend to know all the answers, and I've not spoken out about any idea I'm "behind", my goal in my responses is direct...Find a way to improve the pool without loosing their customers. At least try before blanketly eliminating your customer base. This is a very technical business without a doubt, but its still a BUSINESS! There are things that can, and should, be at the very least tried and given a chance before you start pushing customers away, INTENTIONALLY. Honestly, shut it down if that's what is planned...I'll speak with some certainty on this aspect as its the basis of my entire career...This pool will fail if you take this approach. Not immediately, but it will happen...And no one here wants that.
vinylwasp
Posts: 95
Joined: Mon Oct 31, 2016 3:42 am
Location: Singapore

Re: Status as of Saturday, July 29, 2017

Post by vinylwasp » Mon Jul 31, 2017 6:47 am

GregoryGHarding wrote: swing miners cone fromNH bots measuring price vs ph profitability over x time, once pool hashrate or workers hits a specific threshold cutting bots access off to api will compleatly disable the automates swing miners from calculating the profit, therefor keeping them off the pool.
Sorry GGH, I've got almost 20 years in InfoSec and experience tells me that if you block access to the API/WS, they'll just screen scrape the page to get the same data, register a different account and use that for the algo, or someone will set up a service and resell the data to the swing traders. It simply won't work for more than a day.

You're over simplifying my proposed economic solution too.

What I've repeatedly said is lower (or nett neutral) fees for long term miners (that could be defined as as little as 4-10 days with low hashrate variance), and a penalty payout rate for miners who swing large amounts of hash onto and off the pool over short periods (say less than 3 days).

NB: these are finger in the air examples!! Steve and Chris can look at the data and create their own algo to define who these miners are.

As it currently stands, there's 2-300 GH/s that comes and goes depending on profitability. These miners (sic) are rewarded by very high profits while they mine (relative to those of us who mine constantly and average our profit out over high and low periods), while the rest of us are penalized by the negative service impacts that they seem to bring to the pool.

Personally I don't fancy paying more for a Platinum SLA just so I can be assured that when these events happen my miners have priority, and that's the normal way you'd fix this if this were any other kind of IT service.
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Status as of Saturday, July 29, 2017

Post by Steve Sokolowski » Mon Jul 31, 2017 7:11 am

I'm going to write a new post, but what I found is that I was able to achieve amazing performance with this new architecture for database inserts. It requires 100x less CPU for these operations.

I don't think it will be necessary to enact any other measures because of that, but I'll confirm over the day today.
Post Reply