Status as of Wednesday, December 6, 2017

[Steve Sokolowski]

Good morning!

• We're pleased to announce that we successfully deployed the parallel mining server, two months ahead of schedule. Two instances of the server are already running. Not only that, but Chris was able to figure out how to use iptables to randomly assign miners to one of the two servers, so it's only necessary to connect to port 3333. We'll be removing references on the forums to the other port shortly to eliminate confusion.
• We had planned to open registrations, but the second server is already full. It looks like someone turned on a lot of miners last night and took up all the connections to the second server. Therefore, we'll be creating a third server tonight and will wait to see how much use that gets before determining if we can open a few more users.
• Our plans right now will be to use the new capacity first to allow existing users to expand as much as they would like. Then, if there isn't another bottleneck elsewhere in the system, we'll open registrations a few users at a time. Then, if all demand for new registrations is satisfied, we'll relax the difficulty requirements to draw back smaller miners who have been excised from most pools nowadays.
• We're almost caught up on the backend infrastructure. Bitbucket is set up and the Subversion repository is converted, so the only part remaining is to connect all the Atlassian tools together.
• Constance is learning a lot and should be able to contribute to making website fixes by the end of the week. She is spending a lot of time documenting the setup process in Confluence so that future employees will know how to get started in a day, rather than in a week. She already knows how to compile the website and to use miners. We still need to train her on how to run the mining server and share inserters in her private environment, and how to run Crossbar.io as a local WAMP server.

[mickeekung]

I just know that Constance is a woman.

Dr. Constance Hilliard

Professor, Department of History

http://womensstudies.unt.edu/people/dr- ... e-hilliard

Is that her?

[Steve Sokolowski]

I just know that Constance is a woman.

Dr. Constance Hilliard

Professor, Department of History

http://womensstudies.unt.edu/people/dr- ... e-hilliard

Is that her?

No.

[yeominer]

We had planned to open registrations, but the second server is already full. It looks like someone turned on a lot of miners last night and took up all the connections to the second server. Therefore, we'll be creating a third server tonight and will wait to see how much use that gets before determining if we can open a few more users

PH may have unexpectedly benefited from a nicehash outage, at about 3:30a ET 12/6 and automatic fail-over of a large number of miners that have PH amongst their backup pools. I would not be surprised, if nicehash is now trying to catch up with "damages" from the BCC fork/attack that PH already adjusted earnings for at 12a 12/6.

However, for good measure, and as user gestalt pointed out in response to the respective PH forum post, PPS pools like PH as well as nicehash, may have no legitimate (policy) basis to adjust for shares earned on excessive orphaned blocks. I am interested to see the daily profit report for PH of 12/5 to see whether the "socialized" payout adjustment included a fair portion to be carried by the pool.

For hobbiest miners this may all be written off under goodwill granted to the otherwise friendly and otherwise accommodating PH pool crew. However for "professional" mining operations, and the pool carries that designation in its name, it has to be solid in foundation as to how to deal with any adjustment. Discretionary, unpredictable adjustments in either direction are not acceptable when major hashpower and earnings are at stake.

I invite other professional mining operators for constructive commentary, in an interest to help drive PH to become an exemplary go-to pool for professional miners.

[Steve Sokolowski]

We had planned to open registrations, but the second server is already full. It looks like someone turned on a lot of miners last night and took up all the connections to the second server. Therefore, we'll be creating a third server tonight and will wait to see how much use that gets before determining if we can open a few more users

PH may have unexpectedly benefited from a nicehash outage, at about 3:30a ET 12/6 and automatic fail-over of a large number of miners that have PH amongst their backup pools. I would not be surprised, if nicehash is now trying to catch up with "damages" from the BCC fork/attack that PH already adjusted earnings for at 12a 12/6.

However, for good measure, and as user gestalt pointed out in response to the respective PH forum post, PPS pools like PH as well as nicehash, may have no legitimate (policy) basis to adjust for shares earned on excessive orphaned blocks. I am interested to see the daily profit report for PH of 12/5 to see whether the "socialized" payout adjustment included a fair portion to be carried by the pool.

For hobbiest miners this may all be written off under goodwill granted to the otherwise friendly and otherwise accommodating PH pool crew. However for "professional" mining operations, and the pool carries that designation in its name, it has to be solid in foundation as to how to deal with any adjustment. Discretionary, unpredictable adjustments in either direction are not acceptable when major hashpower and earnings are at stake.

I invite other professional mining operators for constructive commentary, in an interest to help drive PH to become an exemplary go-to pool for professional miners.

Our policy (at https://prohashing.com/help.html) states that when we caused an error, we pay out what users would have reasonably earned plus a 15% bonus. Per the policy, in this case, we withdrew $40,000 from the bank and paid customers at the rate of the blocks that would have been earned had that orphan incident not occurred, plus 15%. Those changes were already applied and if you exceeded the payout threshold, already paid.

I can't speak for Nicehash's policies, so you'll have to submit a support ticket to them about what they plan to do for their customers.

On a different note, that whole incident is an extremely scary event that should wake people up. That was 25% of the entire scrypt hashrate that one person owned that was able to destroy a coin. This happened in the past with Yocoin, and other coins as well once they become profitable to mine. I'm not exactly sure what the reason for doing that is, because the price of BCC crashed immediately after the incident, and Yocoin also became worthless.

I've added a task to our JIRA to develop a feature to respond to these attacks for the future. If Gamecredits comes under attack, then the plan will be to devote all hashrate to orphaning the blocks that are creating the orphans. We will also need to modify our policies to warn customers that if that happens again, we may favor saving the attacked network over earning profit, for the good of the industry. The idea that someone can control so much hashrate and get away with something like this is very disturbing, and I think it is imperative that we come up with a solution as quickly as possible.

[yeominer]

Steve your viewpoint, financial disclosures and thoughtful commentary is much appreciated, and common interest as well as immediate business interest need always be balanced carefully. At the point where and aggregator of hashpower makes political ("defending a coin vs. maximizing immediate profit") decisions on (re-)distribution of hashpower, pls sincerely consider to solicit prior user agreement, laying out the scenarios and criteria for any rule to apply and how to respond in these cases (notwithstanding building a reliable technical capability).

To work for a cause requires to be able to afford that or else one might become a salvage case oneself. Pro miners likely work against heavy financing burdens, and rely an every paid share earned to actually make a dent against the overwhelming industrial miners antpool and btccs of this world.

I believe transparently engineering rules to your aforementioned scenarios will promote community and solidarity, hence shape a stronger business partnership. To vote with their feet is easy as never before in the case of users (hobbyists as well as pro miners) pointing their hashpower at their preferred (backup) pools.

On that note, you may want to look into the model of voting-by-hashpower on pool propositions / changes / developments like slush pool has.

[AppleMiner]

Now that the pool has multiple parellel servers seems this would be even easier than before.
Have 3333 load balance people, have 4444 be the NO vote server and 5555 be a YES vote server.
Track how much hash comes in on port 4444 vs 5555 and let the users vote with their hashrates.

[Steve Sokolowski]

Now that the pool has multiple parellel servers seems this would be even easier than before.
Have 3333 load balance people, have 4444 be the NO vote server and 5555 be a YES vote server.
Track how much hash comes in on port 4444 vs 5555 and let the users vote with their hashrates.

A password argument would be more useful for this idea, but it's the same thing.

The problem with your premise is that the people who vote "NO" make more money and get the benefit of eliminating the attackers. The people who vote "YES" participate in the defense and make less profit temporarily. That's not fair.

[AppleMiner]

I was thinking more for voting options, not whether to support a coin that is under attack or not.

Planned events that we would have time to make group-pool decisions on not spur of the moment/we only have 10 minutes to respond to a situation type events.

[holygoof]

Indeed, users should be given the option, and pw argument or choosing one of the servers sounds like a way to offer that option. With that said, I would prefer the pw argument, in case I'm not around and my machines could be used for defense at a moment's notice