Status as of Friday, March 13

[Steve Sokolowski]

Here's today's status:

• Enough has been said about the profitability enhancements coming this weekend, so you can read about them in other posts.
• After this, we were thinking of one more round of profitability enhancements. There are two things we can focus on. The first is optimizing the coin selection algorithm to take into account block times rather than just difficulty. Rather than just not overload the small networks as we do now, we can calculate the expected block time and assign people to coins so that blocks occur every 2s (or whatever time is determined to be ideal to avoid orphans).
• The second focus is on multiple merge-mined coins. In addition to dogecoins, there are other coins like leafcoins that can be merge-mined. While it would seem to make sense to merge mine all 10 coins at once, doing so would increase the number of work restarts, and many mining rigs can't handle work restarts well. I think the way we would implement this is to use the latest block in these networks only when we have a new block in the primary network, and the rest of the time there would be no payment for the merge mined coins. Whether those few extra cents would actually be worth the effort of adding the feature needs to be determined.
• JiveTonto has been very helpful with his suggestions for improvements to the website. The website has not been a focus of development over the past six months because we wanted to focus on profitability first; now that we will be close to optimal, I will probably work on the website in April. I want to change the website from the current tables to a publish-subscribe model where data updates will be displayed in real-time. For example, users will be able to open a page and watch their balances increase with every share. I think it's feasible to accomplish this by the end of April.
• By May, we should have a good idea of the pool's future potential. Chris puts the "proof of concept" level at 20GH/s for a sustained period. If that is reached, we can apply everything we've done to coins with other algorithms in a few weeks. Doing so will require $3000 or so in server costs, so we are waiting for customers to demonstrate that they are satisfied with scrypt mining before we make that level of commitment.

[JiveTonto]

so for my understanding your thinking of making your stratum assign the hashrate to the pools not only on profitablitiy alone. so e.g i have 3 miners two 44mhs and a 700khs

is my thinking correct in that you would place the 44mhs on something like nyan(LOW DIFF MODERATE coin RATE) and the other 44 on something like star or stable coin? and the 700khs on something more like infinite or fastcoin?



^all dependent on the profitability of said coins in the range at the time.



so i wont find both my 44mhs trying to mine the like of infinitecoin ect?

[Steve Sokolowski]

so for my understanding your thinking of making your stratum assign the hashrate to the pools not only on profitablitiy alone. so e.g i have 3 miners two 44mhs and a 700khs

is my thinking correct in that you would place the 44mhs on something like nyan(LOW DIFF MODERATE coin RATE) and the other 44 on something like star or stable coin? and the 700khs on something more like infinite or fastcoin?



^all dependent on the profitability of said coins in the range at the time.



so i wont find both my 44mhs trying to mine the like of infinitecoin ect?

That's correct. The goal is to limit orphaned blocks and coin switches. If the pool would find blocks more often than every three seconds or so, then the remainder of the hashrate is assigned to more difficult coins.

In addition, powerful miners are never assigned to easy coins. If a miner sets a static difficulty of 65536, for example, then it will never be assigned to coins that are easier than the static difficulty, because that would waste shares. Instead, miners that can mine easier shares are put on the easier coins, while the miners with high static difficulties are put on less profitable, but less frequent, coins.