Status as of Monday, September 15

[Steve Sokolowski]

Here's what happened over the weekend:

• I spent most of Saturday trying to resolve errors with some coins, and was able to make little progress. We determined that the small number of coins that don't work (like Krugercoin) aren't worth spending so much time to support. There are some other coins that have fixable errors that we were able to resolve. I don't plan on spending any more time on reducing lost blocks, as we seem to already have reached a limit with that.
• Some coins disabled themselves because our coins weren't maturing. That was a valid error condition. It turns out that these coins end up with such a low hashrate that we mine them, and then the coin has 30 minutes until the next block when we aren't mining. The issue with these coins is that even if they are the most profitable, we might never actually sell our coins because the blockchain never advances far enough from the other miners after we leave.
• We are ready to more widely advertise the pool, but aren't willing to go that far until we can get scrypt ASICs to verify that work restarts are within reasonable limits. The ASICs, which were originally scheduled to arrive September 2, are now estimated for tomorrow. If they arrive and work, we may be able to start advertising this weekend. If not, then we'll need to delay the project by a third week until we can order from yet another seller.
• On Sunday, given that we were blocked waiting for the ASICs, I started implementing Poloniex, and was able to get their trade data being received by the pool. The next step in that integration is adding the concept of an "exchange error," so that exchanges can be disabled if they go down or start returning invalid data. I'd say it will take two more weekends before we can be at the point of testing Poloniex on the Dev server. Adding Poloniex will make the pool more profitable, because there are coins that are only traded at Poloniex, and because if the sell price of a coin that is sold at both Poloniex and Cryptsy is higher at Poloniex, we can sell coins at the higher exchange (and buy payout coins at the lowest exchange).
• I disabled some "history" auditing tables that are useful in debugging and accounting, but which cause up to 15 rows per share to be inserted into the database. That shouldn't make any difference now, but might speed things up in the future as more shares are submitted.
• Kristof discovered a bug where the price of bitcoins had been stuck at 585.01 since June 21, because the update script had not been running. No money was lost as a result of this bug and no earnings were affected, but there were two effects. The first is that past earnings may show up as too high, and the second is that past payouts were being delayed too long because the payout threshold was too high (but the money would still be paid eventually). The decrease in "miner earnings" recently is largely attributed to the correction of this bug, not because people are actually making less money.
• It may be worth considering paying out 100% of everything earned and wiping statistics up to now to correct for that mistake, or perhaps it doesn't matter all that much.
• If you have noticed any bugs, we welcome comments and want to fix them before launch. Without Kristof's tip on that issue, we might not have noticed until the next bubble.
• Please offer your comments on the minimum payout threshold. Is it acceptable, or do people want to be paid at lower thresholds even if that causes us to have to raise fees to pay the transaction costs?

Finally, the price of dogecoins is causing significant losses. Whoever it was who set his or her payout to dogecoins should be congratulated because he made a killing this week. When the price of altcoins goes up, we lose money because we have to buy the payout coins at a higher price, and we make money when the price of coins goes down. We should make the money back during the next crash. For those interested, you can see the profit report at http://shoemakervillage.org/temp/profit-2014-09-15.jpg. I'd like to make that report publicly viewable, but it's CPU-intensive and would require time for me to optimize it enough for widespread viewing.

[cryptorific]

• As to the payouts, I would actually like higher thresholds mostly because now i have a ton of .01BTC and 1LTC inputs and it'll cost me to move them later on. Ideally it'd be nice to be able to set my own threshold, eg multiples of $5 from $5-$25 or something along those lines. I know you're hesitant to hold onto alot of funds but if the pool gets big you'll be holding onto alot of funds with a $5 threshold or $15.
• The reports would be cool to see, perhaps generating weekly reports rather than daily reports would more realistic, though I'm not really sure if the miners care all that much besides it being an assurance you won't skip town one day with their funds.
• How do you plan on implementing poloniex? It seems like it'd be very tricky to keep the right amount of reserves on each exchange. One minute cryptsy could be the better place or buy and the next it could be poloniex and you probably dont want to have to do exchange to exchange transfers to keep reserves balances. The algorithm for that seems a bit daunting...

[Steve Sokolowski]

I spent a few hours yesterday figuring this out. It involves a change in concept from there being an "exchange" to there being "coin exchanges." Some coins could have 1 exchange, some could have 3, and so on, because not all coins are traded at all exchanges. The exchanges could also be down or in error, so now the system will have errors associated with each exchange-coin combo. If there is an outlier price, that allows the system to function as if there are one fewer exchanges.

We decided that, at first, the price paid to miners will be the average price across exchanges to account for slippage. Later, we may offer the lowest buy price and the highest sell price in calculations, increasing profitability even further.

As to how the purchasing and selling is implemented, when a share is submitted, if it is necessary to do so, payout coins are purchased immediately at the cheapest exchange. When the block matures, if necessary, the block is sold at the most expensive exchange. We only deal in bitcoin-altcoin pairs, not altcoin-altcoin pairs, which means that we will only ever have a shortage or an excess of bitcoins in an exchange. That greatly simplifies the algorithm, because the only issue we have to worry about is if we run out of bitcoins on one of the exchanges. But that means that we have to have excess bitcoins on another exchange, so if that were to happen, we can rebalance them manually once per day to minimize transaction fees. The database can do that automatically or send an E-Mail to Chris to do it. We'll quickly find out which exchanges have lower prices by which exchange has a lot of altcoins and few bitcoins in it.

I don't think this issue is all that complicated. In fact, it will probably be easier to do all of this than it was to resolve the lost blocks issues. Understanding code written by other people takes at least ten times longer than writing your own code. I'd be surprised if this takes longer than it did to receive the ASICs, or to figure out why so many blocks were lost.

-----

As to holding balances, I don't see how it would be feasible for us to hold larger balances. Consider that, in order for us to continue working on this pool, we need to earn about $200/day. That means that the amount of money the pool will be holding in hot wallets at midnight will be at minimum $8,000 (because we delay payments for 1 day as a reserve), and that's if everyone is mining one coin. $8k won't cause us to go bankrupt, but if the pool makes $250k/year in profits, that means we need to be custodian of $32k or so on that server even at this payout threshold of $5. At $40, for example, that means we would be trusting our security for a quarter million dollars, which I'm sure you'll agree isn't worth the risk. If you have another suggestion to reduce the risk, then I'm willing to listen to it.