Status as of Tuesday, November 17

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 Tuesday, November 17

Post by Steve Sokolowski » Tue Nov 17, 2015 9:32 am

Greetings! Here's today's status update.
  • We accomplished two major tasks this weekend. First, we successfully released the version of the mining server we talked about last week that improves performance and attempts to fix some hashrate drop issues. One of the key features here is the addition of a "hashing process." One of the most CPU intensive operations in the mining server is scrypt hashing, which is needed to check the validity of shares. Now, we offload the hashing to a separate process that runs in parallel with the mining server, reducing CPU usage of the main core by over 20%.
  • We made some modifications to the trading server. Previously, we would send full blocks to the exchange with the highest sell price. Now, we split these blocks up and send an appropriate amount to each exchange based on the order books of all the markets in those exchanges. For example, we may find that Bittrex has the best price for GameCredits until we sell 384 of them, but we have 500 on hand to get rid of. Previously, we would send them all to Bittrex, but now we would send 384 to Bittrex and 116 to Poloniex, so that we sell down every exchange's markets until they are equal.
  • We expanded this idea further by then also considering the number of coins already in the exchange, and the number waiting to be confirmed. In the example above, perhaps there are already 100 GameCredits in Bittrex waiting to be sold, and another 100 on the blockchain that we have previously sent but which Bittrex has not yet credited to our account. The current code that is running now will send 184 GameCredits to Bittrex, so that we will eventually sell down the order book on Bittrex to be below Poloniex, and then the remaining 316 GameCredits to Poloniex to fulfill sell orders there.
  • This feature was deployed at about 1:00am. We expect it to earn more profit for us in the short term. While we do not conduct arbitrage, I also expect that this precise selling will have the effect of eliminating arbitrage opportunities for other traders in a large number of altcoins as well over the next few days.
  • Chris was investigating why the our profit report is showing that luck is 8.4% lower than expected over the course of November. He determined that the cause of the problem was that miners were being overpaid when one of the coins in which they were requesting payouts had entered an excluded state. It was possible that if someone requested 90% payouts in one coin and 10% in another, and the 90% coin went into error, then the person would be paid 100x normal earnings in the 10% coin. This issue has been fixed, so we're sorry to disappoint those who were lucky enough to encounter this issue in the past.
Post Reply