Guys, guys, it's all good! H20 just came back from his vacation and tweeted: "The pool wasn't properly recording some blocks starting on the 16th. Stats will be frozen while the pool crunches some numbers.".

See?  He will just "fix" the numbers!  So the exodus can stop now!

j/k, I think it's overdue that h2o suffers for his incredible and repeated unprofessionalism.

Did I miss something?  Betarigs is not using stratum at all, but oldschool http / getwork protocol.  Is there a reason why?  I think this is because mux based his work off of stratum_proxy which exposes http to the miners.

Stratum would be far more efficient with less latency.  In this model that would be important because the pool is proxying for another pool.  If the receiving pool is a coinswitch pool, latency matters big time.  JSON RPC will be faster than http setup/teardown.

Mux,

You are doing a great job.  Keep the features coming and the service honest and you will have a winner.  I know you have a lot on your plate right now and you should focus on stability and payouts, but I can't help but come up with little things I think would make it better.

1- Ability to set price in BTC/MH/DAY, because that's what matters to buyers.

2- Ability to have more than one rig linked to same BTC address

3- Ability to a renter to queue their buy for immediately after the current rental expires.

4- Long-term discounts.  As a rig operator, if a customer is willing to commit to a longer period, I would give them a rebate as this decreases uncertainty for me.

5- Cgminer reports JSON errors when rig not rented.  

6- Upload rig pics

7- Operator contact info (email, IM, etc)


Keep up the good work, looking forward to my payout tonight.  Funny to see the greedy operators though... 0.03 btc/mh/day and higher... lol!

Email worked for me (gmail), but went to spam folder.  I'm really liking this service.  My rig rented out in less than an hour.

Lots of room for improvements and I see this service really taking off.  Some ideas:

Would really like to see the average spot price in btc/mh/day at which people have rented in the last 1h/8h/24h period.  Trending analysis can tell the buyer whether they should rent at a particular rig or not.

For rig owners: dynamic rates that follow the spot price +- a certain % with a floor price.

For rig owners: reputation system so buyers know the best rig operators for uptime, promised vs. real hash rates, etc.

For buyers: Mass buy option to purchase blocks of X Mhash, and this gets split up amongst X rigs.

Mux, you have created something great here.  Hats off.  I truly wish you the best of success with this project.  Is it your full time job?  If not, would you like it to be?

Y U no use stratum?

Signed up, just put my rig up for lease.  0.02 btc/mh/day.  Love the concept of this service.  Genius.

Annnnd... I'm back.  Putting a stop to this experiment.  Not waiting a week, 6 hours was enough to know this won't hold a candle to mc.  Over time, hashbros earnings dropped steadily down to 0.0055 btc/MH/day.  It's curious that hashbros has a profitability index yet they don't seem to mine the coins that are most profitable.

I will promptly stfu now.  Maximum payouts trump everything else.

I have gone and done this.  I have 2 identical 2.2 MH rigs that I am splitting between hashbros and middlecoin for a head to head test.  Will let it run 7 days and report back next week. Currently, hashbros is estimating my earnings at 0.008329 btc/MH/day but that is fluctuating minute by minute.

Jedimstr, I respect you as an old time middlecoin hipster, whereas I'm just a pathetic noob here.  You are probably right that H20 will outperform as he has in the past.   But labelling any criticism at all as just whining/moaning noobspeak and we should all GTFO and STFU is sad.  It won't help improve this pool.  You obviously care about it because you read this thread and post almost everyday.  You don't want it to be better?

Considering the amount of real $$ in play here on a daily basis, it does not seem unreasonable to me to expect better uptime.  Middlecoin is a million dollar business already for christ's sake.

Yep, there seems to be correlation between flatlined stats and the auto-trade bot.  When we come out of a flatline we always have high unexchanged. This is logical considering that the recurring stats issue is caused by database I/O starvation and most likely his autotrade bot is running off the same db.

This current stats freeze is a bit different though.  During the previous stat freezes, the JSON api's that BFPCoin and others use were still updating.  This time they are not.  So it seems to be a bit more than a "front-end" issue.  It's lamentable that we can't seem to get more than 2-3 days uptime on the stats.  Label me a noob and a hater if you wish, but it's not like that at all.  I really like middlecoin, just want to make it better.  Wish he would take me up on my offer of database help.  It's what I do for a living.

I use kill-a-watts and other such tools at work (datacenter).  By far the best watt meter is the Belkin Conserve Insight.  Easy to find, cheap, goes to 1800w, but the killer feature is that the display part is on a cord, not at plug level like the killawatt.  So you can put it on your desk and directly monitor the results of your OC'ing, undervolting, etc.

http://www.walmart.com/ip/Belkin-Conserve-Insight-Energy-Use-Monitor/15120603

No one has mentioned the 270's yet.  Here's my experience:

Asus R9 270 : Unlocked.  1.100/1030/1400 = 440 kh 7 days stable.  120 W draw per card

Gigabyte R9 270: VOLTAGE LOCKED!  Tried 1.100v and 1.150v in VBE7, flashed BIOS, no errors, but the cards hang on boot when X starts.  Running stock, these cards draw 30w more per card than the Asus 270's, for a just a slight 10 kh improvement.

On top of that the Asus cards are quieter and cooler.

Couldn't agree more.  H20 is like a fund manager for our collective hashrate.  I think this is what gives him the performance edge over the other, purely automated pools.  The analogy in the traditional investment world would be mutual fund (middlecoin) vs ETF (the others).

I have no doubt that actively managing our 15 GH is a full-time job.  I don't want him to waste his time on server issues.  I want him to concentrate on the coin trades.

The costs aren't 3K a day I can tell you that.  He's looking at maybe 10K a month max including all the servers he has in the different AZ's.  h20 has some trading magic that others (including myself, wafflepool, hashcows, trademybit, etc) cannot replicate.  This is his secret sauce.  This is why he gets 3%.  I don't want to build a new pool, I just want to make middlecoin suck less.

Actually shares.time is indexed already.  The table is over-indexed for such high transaction velocity.  He needs help.  I've offered my services via PM 3 days ago during the previous stats incident, no reply.  I do this for a living and would appreciate a little more professionalism put into the backend.

EDIT: Today's results seem to confirm my theory that the auto-trade algo is affected by database I/O issues.  We came out the stats freeze with very little exchanged BTC.

He also flat-out said : "My database code isn't very efficient. And the more shares I have, the slower it goes.".  Having seen the table and the query I'm shocked we even made it to 15 GH. How many 1024 diff shares per second would that be anyway?  Not sure how to calculate that.

Last time this happened, he posted his issue here: http://pastebin.com/TQ206qQj

His share table inserts one row for EVERY share submitted by EVERY miner.  This table has 4 indexes on it.  This makes every insert or update expensive on the I/O.  His stats query then does a select count(shares.*) from ALL THOSE shares, further hammering his I/O while shares are still being submitted.  This is a classic database paradigm with many ways to solve it.  Some very easy!

H20, please reply to my PM.  Database optimization is my day job.  I can help.

This.  It's unlikely to be a software issue because a) it works most of the time and b) he has said the database needs "catching up".  This is a classic indicator of database I/O starvation.  H20 is using AWS and for a database of this nature, you need high I/O.  Amazon offers EBS storage blocks, but these have terribly variable performance and low IOPS.  They did create two new SSD instances types (HI1, I2) but those are all sold out.  So he's probably struggling with dropped database connections, long running queries, dropping and re-adding EBS volumes to his software raid 10, etc.

The coin trading algo is most likely database driven as well, and very time-sensitive, so my concern is that coin trading efficiency suffers when this happens as well.

This amateur hour bullshit is really starting to piss me off.  h20 may be a coin trading wizard, but he clearly doesn't know dick about IT ops.  I bet he uses software raid and ebs volumes to back his mysql db.  Database needs to "catch up"?  Please.  He needs to profile his database queries and get some REAL i/o.  Not this ebs shit.  CloudSigma is all ssd, would be a good choice.

Is it just me or would a scrypt asic not look like this at all?  It would either be a big, big die with lots of expensive as hell eDRAM and a memory controller, or go external and put some expensive GDDR5 chips on the PCB. Basically, it would wind up looking like a GPU, no. So... this is bullshit?

I can say that I had same issue when I tried wafflepool for a day.  The same settings that were stable on middlecoin (although pushed to the limit) were causing lockups on wafflepool.  Wafflepool switched difficulties far more often, maybe this has something to do with it.  I had to go back to almost stock clocks to mine there.

BTW: my not-so-empirical test showed waffle was about 70% less profitable.  My theory is that their hashrate is still small, so when the switch to a coin, they have low chance of finding a block.  This is compounded by spending only a few minutes on each coin, leading to lower payouts.  If this makes sense, then we all should thank mimiminer and sfire.