Re: Status as of Saturday, July 29, 2017
Posted: Mon Jul 31, 2017 4:20 am
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.vinylwasp wrote:Is this what you're proposing GGH?vinylwasp wrote:TTL? Time to Live?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 TTLPoolside, 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.GregoryGHarding wrote: i propose a secondary measure. when hashrate/workers hit a maximum limit, disable API requests
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?