Status as of Saturday, July 29, 2017

VanessaEzekowitz wrote:As one of the smaller miners, raising the pool fee would probably drive me away, depending on how much of a rise it is.

hes proposing double, so 10%

I must have missed that. 10% ... well, my first reaction to that is not appropriate for polite company.

VanessaEzekowitz wrote:my first reaction to that is not appropriate for polite company.

Amen. 10% is a joke. There wont be a Prohashing anymore if it becomes 10%.

And herein lies a big problem here. Someone misinterprets whats been said, rails against it and then starts a new discussion which is miles away from the starting point.
Problem statement: "As long as PH is more profitable than mining on any other pool, any new capacity will be exhausted by miners seeking profit."

In theory, the market could drive PH to scale until all the X11 and Scrypt in the world is mining here. (perhaps this explains the DDoS attacks). An extension of this statement is seen in the behavior of swing-miners and can be stated: "As short-term PH profitability increases, so does the probability that NH and other short term hash-rate will be directed to PH and have a negative impact on pool performance"

There's been a number of methods to limit users/miners/connections and hashrate proposed so lets look at them.

1.) Limit User registrations: - existing user buys more or faster miners, NH user buys 10x more hashrate, or 2-100 miners band together under a single account - this idea is easily sidestepped and fails completely.

2.) Limit connections: User builds local stratum proxy (single connection), OR user buys 10x faster miners (uses same number of connections) - solution fails, and penalizes any PH miner wishing to grow their capacity

3.) Limit hashrate: Theoretically this has potential, but how does PH decide how much hashrate a user should get? Can any of the promoters of this control come up with a fair way of deciding who gets how much MH/s even if you did limit new registrations as well?

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?

GregoryGHarding wrote:

VanessaEzekowitz wrote:As one of the smaller miners, raising the pool fee would probably drive me away, depending on how much of a rise it is.

hes proposing double, so 10%

.

That was only a finger in the air suggestion to illustrate the point and only to be imposed on anyone who mines briefly during times of high profits. The exact way to calculate that would require some kind of statistical variance model for the account.

I also proposed lowering fees for long term miners of which I am certainly one of those, in late 2016 I was around 20% of the pool, and have doubled my miners since then.

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

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?

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?

launch, live.. means the same

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?

Every STEP you took degraded the performance ..... particularly the 30 seconds delay to wait for NovaExchange and Yobit shares..... try to process them BEFORE and not after main shares..... and of course High Diff gave the final stroke.....