Toomim Bros GPU mining software and cloud mining

Mining
1013

@Breasal, our records show that we have delivered 96% more hashrate to you over the last 24 hours than we promised. If you are not seeing that hashrate on your pool, could you please send a screenshot of your pool dashboard to support@toom.im?

@zcashrpc, I don’t know your username with us. According to our records, we should be overdelivering to all of our customers, so the “Last Seen Sat 05 Nov 2016 18:55:34 EDT (2 days ago)” line suggests that something is wrong either with your pool or an unknown issue on our end. Can you send me your username and maybe some screenshots of your pool’s dashboard?

1014

Dear Toomim, could you please find the time to reply to my emails? Thanks

1 Like
1015

dont worry guys, only 60 sol/s from old r9 290 cards now with claymoores. :cry:

1016

takes a 200$ ebay card about 2 weeks to make that , sorry for your loss
edit: but CONGRATS TOOMIN bros, or are they taking that life long vacation he talked about in the video already

1017

60 Sols?

Its 80 Sol/s with a 290

1018

65-75 depending how you mod and what card / how hard you want to push it yes

1019

I wonder if his miner is still worth 125k?

1020

He never said his miner is worth 125k

He said its worth $750,000.

1 Like
1021

I thought he asked for 125k if he’s going to opensource. Claymore doubled the hashrate yet will never earn 100k out of his zcashminer.

1022

He did mention something about $750K the first week. How much lost profit he would get if he released it for free. Maybe it was $125K.

1023

Wonder how much it’s worth now

1 Like
1024

Now that claymore is raging like a bull, I think no one would pay for it even $1.

3 Likes
1025

toomim. It’s been 17 days, not even a whole month… Your “company” is a worse flop than I ever thought it could be. I honestly hope someone files a complaint.

It’s definitely amateur hour in that warehouse. How are you still struggling to deliver hash rate weeks after launch? Quit pretending you know what’s going on, you’re probably just pushing buttons at this point.

1026

Actually, our systems are running quite strong, as @jtoomim described a week ago, and again 4 days ago. We have been overdelivering hashes to each customer by at least 1.75x for the past week. It sounds like you are not a customer.

1027

1.95x average over the last 24 hours, actually.

1028

Yes, and despite the two days of downtime at launch, all customers have been caught up with their total net sum of hashes owed as well.

1029

We’ve delivered 1.58x as many cumulative hashes as our customers were owed, actually.

(Our current and cumulative performance does not excuse our poor performance at launch.)

1030

For your calculations, are you taking into account that a hash earlier when the difficulty is lower is more valuable than a hash later when the difficulty is greater (even when holding the price of ZEC constant)?

Addendum: The slow start further complicates the comparison between two hashes at two different points in time.

My point is that in order to accurately compensate for a lost hash at a later point in time, the change in difficulty (between when the hash was lost and when compensation hashes occur) needs to be accounted for (as well as the changing block reward during the slow start).

1 Like
1031

I’ll answer that for Mike.

A hash is a hash. For the statistic above, we are using the total number of hashes delivered, as recorded in our database. This is not an estimate of cumulative revenue, but merely a measurement of total work done.

Measuring the ZEC that would have been mined cumulatively is a different issue. I just ran some numbers on a python script that uses the difficulty for each block and the varying slow-start reward, and it looks like our customers should have earned about the same amount by now if we had constantly hashed at 1.0x versus if we did what actually happened (0x for 2 days, 1x for 2 days, then 1.75-2.0x since). It would vary from customer to customer, though, depending on whether they got more or less than they were owed on days 2-3.

We are not hashing at 1.95x instead of compensating customers for the downtime. We are doing it in addition. I do need to finish up the compensation plan, though; mea culpa for not getting it out by now.

Here are some interim numbers to tide you over. These are the ideal revenue for someone with 1 H/s active since block 0 hashing on a perfect pool (comprising 100% of the network hashrate) with 0% fees and with 0% orphan rate:

0.0013592462 ZEC by block 1637 (t = +48 hours) – when we came mostly online
0.0017693052 ZEC by block 2803 (t = +96 hours) – when we began to exceed targets
0.0037666281 ZEC by block 8872 (t = +350 hours) – now

Let’s say customer B got this (with a perfect pool, etc):
0% for the first 48 hours
75% for 48-96 hours
175% for 96-350 hours

B would have earned roughly:
0.0000000000 ZEC by block 1637 (t = +48 hours)
0.0003075442 ZEC by block 2803 (t = +96 hours)
0.0038028593 ZEC by block 8872 (t = +350 hours)

Our actual performance was better than this Customer B model for most of our customers. Customer B represents roughly the 20th percentile for what our customers received.

Our compensation plan will be based solely on the 0.0013592462 ZEC/(H/s) and 0.0017693052 ZEC/(H/s) numbers, and will ignore everything that came after t = +96 hours.

Edit: These numbers were all 1/4 of what they should have been due to a bug in my python estimator code. Fixed.

Edit 2: I made a mistake with the block 8872 lines. I had used the amount for block 5228 by mistake. It has been corrected to 0.0037 and 0.0038 ZEC.

1032

I see; I didn’t realize that the compensation plan was a separate matter. Thanks so much for answering my question.

1 Like