Status as of Friday, November 7

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.
Post Reply
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Status as of Friday, November 7

Post by Steve Sokolowski » Fri Nov 07, 2014 10:08 am

Here's today's status:
  • It looks like we have made significant progress on bugs and issues, to the point where I don't know of any that are outstanding. If you do know of some, no matter how minor, please report them.
  • The big news is that, last night, I completed and sent for testing a feature that allows miners to select a single coin to mine. Here are three of the reasons why people would want to use that feature:
  • Some people have miners that don't respond well to work restarts. Those people can specify a password argument of c=litecoin, in order to mine litecoins and dogecoins, which have less frequent work restarts. Though litecoins are usually less profitable than the current coin the pool is mining, for these miners they may actually gain more hashrate than the loss in profitability.
  • People who currently work on litecoin-only pools will be able to take advantage of all the other services we provide, like electricity calculations, while still mining litecoins and paying out in litecoins (or whatever else they want).
  • There are many pools out there that are set up for mining a single coin and which pay out in a single coin. That's the most basic implementation of a pool, and it's where pooled mining started (mining bitcoins to be paid out in bitcoins, for example). Some specialty coins have pools of their own. Now, anyone who wants to support a particular network can do so - for example, CNHCoin supporters can mine only CHNcoins and dogecoins, and retain CHNcoins as payout. Note that this implementation "boosts" payouts for such miners, because they get the dogecoins they earn converted into their preferred coin.
  • People who elect not to mine a particular coin can still mine the most profitable coin, which is the default if miners take no action after this change. Reduced profitability caused by other miners selecting sub-optimal coins is passed on only to those miners, leaving most miners unaffected.
  • In other news, the major issue I'm going to look into this weekend is optimizing our hashrate across multiple networks. The idea is that it doesn't always make sense for us to place 100% of the hashrate on a single coin. For example, if no other pools are going to choose eGulden above a difficulty of 15, then, even if it is the most profitable coin, we should not dedicate miners to the coin to raise its difficulty to 20. Instead, we place just the number of miners on the coin to manipulate its difficulty to the optimal profitability, and put other miners on tiny coins like Emeralds, which are earning 14 cents right now but which would have too many orphans if we devoted our entire pool to them. The infrastructure improvements we made during that painful release in early October already support this and the only difficult part of this is determining the algorithm for which miners to assign to which coins, which is difficult because there is no way to test that without the pool's entire hashrate.
As always, comments welcome.
Post Reply