Couple of questions/clarifications:Steve Sokolowski wrote:Perhaps you could help think this issue of parallelism through, because it seems that you know a lot and could contribute.bellaminer wrote:I have intimate understanding of maintaining complex systems... I was an engineer/programmer for 12 years and the chief architect of a system that was responsible for logging billions of phone/radio communications across complex multi-system deployments. Now I'm a lawyer.. for better or for worse, and I agree that you should make sure you are operating within the law. I have perspective from both sides now and think you are right to be cautious both technically and legally.Steve Sokolowski wrote:
I understand your frustration, and I agree that you should do what you have to do. I apologize that you feel this way and wish that there was something we could do immediately to reduce this concern.
That said, I do want to point out that I think that a few of the expectations from some of the posts could be considered unrealistic. Some customers have suggested that we should just forget about consulting a lawyer, others have suggested we would get an immediate impact from hiring despite the search and training time, a few have expressed possibly unrealistic beliefs about algorithms and parallelism, and the fact that we need to plan to avoid bankruptcy during the next crash, not just during the good times like now, is often discounted.
We're working as hard as possible and want to provide the best quality service. But on the other hand, there are fundamental limitations to what can be accomplished.
I am not going to make any unreasonable demand or otherwise play arm-chair quarterback and tell you how to 'easily' fix things. There never is an easy fix, just trade-offs. Hiring people is not going to necessarily fix anything. I suspect this is a very complex system and it requires a ton of tribal knowledge.. knowledge that exclusively resides with you and another (your brother). It may not be practical to bring anyone on until you can forecast earnings and justify the expense.
Again, I want to bring all my miners here and hope everything can get worked out. I think the key to profitability for you is not necessarily super-inflated coin values, but the sheer number of miners you can service. Come Dec. 1, I am going from 1 miner to 14.. and I think you will very likely see 3x the number of miners you presently have online.
If you are locked into a single-threaded model, which I totally get, then you need to divide into multiple such servers and then average the return across each of the servers... I suspect you already thought of that. Parallelism (within a single application) sounds great in theory, but simply not practical to maintain given how evolving the crypto mining algorithm is.
The critical problem with coin assignment is that there is a limit to how much hashrate can be assigned to a network. If the limit were to be exceeded, then two problems happen: first, so many blocks would be found that many of them would be orphaned; and second, if we exceed 50% of a network, then we actually make less profit because any more hashrate reduces profitability more for our own pool than for other pools.
Therefore, we can't just assign each miner at the same time to the most profitable coin, which would be parallelizable. We need to assign one miner to a coin, increment the amount of hashrate assigned to that coin, assign the next miner to that coin or another one, increment the hashrate, and so on until all miners are assigned.
I have yet to figure out a parallel algorithm for how to do this task. The only parallelism exists between algorithms, since miners can only mine one algorithm at a time. Feel free to think this one through if you have an insight.
The limit for a given network is set by the network, I assume. So for dash, the maximum hashrate is X, whatever X is. You are making sure your total contribution is below a threshold limit. What I don't follow is how there is any room at all, even before your miners are connected?
Second, how are you calculating the threshold limit before you stop assigning miners to that coin?
Forgive me, I'm not that well versed in how these crypto networks work per coin.