----------

[alani123]

Sha-256 Contracts have been increased. No Price changes!
If you had a 100 Gh/s contract before, it is now 250 Gh/s. If you had a 1 Th/s contract, it is now 2.5 Th/s.
We are also giving you credit for the time used on your old contract. 60% of the time you have already used in your existing contract will be appended to the expiration date of your contract.
This means if you have had your contract for 30 days already, then 18 more days will be added to the end of your contract to extend it's expiration date.

How long does the Sha256 contract take after purchase to start mining?

[BitJohn]

Sha-256 Contracts have been increased. No Price changes!
If you had a 100 Gh/s contract before, it is now 250 Gh/s. If you had a 1 Th/s contract, it is now 2.5 Th/s.
We are also giving you credit for the time used on your old contract. 60% of the time you have already used in your existing contract will be appended to the expiration date of your contract.
This means if you have had your contract for 30 days already, then 18 more days will be added to the end of your contract to extend it's expiration date.

How long does the Sha256 contract take after purchase to start mining?

Typically its less than an hour, usually much less (thats my guess) Mine didn't take that long. I hit up the developers for a more detailed answer.

[BitJohn]

Sha-256 Contracts have been increased. No Price changes!
If you had a 100 Gh/s contract before, it is now 250 Gh/s. If you had a 1 Th/s contract, it is now 2.5 Th/s.
We are also giving you credit for the time used on your old contract. 60% of the time you have already used in your existing contract will be appended to the expiration date of your contract.
This means if you have had your contract for 30 days already, then 18 more days will be added to the end of your contract to extend it's expiration date.

How long does the Sha256 contract take after purchase to start mining?

It also can depend on the method of payment, and when it clears.

[alani123]

Sha-256 Contracts have been increased. No Price changes!
If you had a 100 Gh/s contract before, it is now 250 Gh/s. If you had a 1 Th/s contract, it is now 2.5 Th/s.
We are also giving you credit for the time used on your old contract. 60% of the time you have already used in your existing contract will be appended to the expiration date of your contract.
This means if you have had your contract for 30 days already, then 18 more days will be added to the end of your contract to extend it's expiration date.

How long does the Sha256 contract take after purchase to start mining?

Typically its less than an hour, usually much less (thats my guess) Mine didn't take that long. I hit up the developers for a more detailed answer.

It's hashing already(!), paid with bitcoin. But just in case:

What would be the right way to come into contact with the devs? Freshdesk? https://mintsy.freshdesk.com

[BitJohn]

Sha-256 Contracts have been increased. No Price changes!
If you had a 100 Gh/s contract before, it is now 250 Gh/s. If you had a 1 Th/s contract, it is now 2.5 Th/s.
We are also giving you credit for the time used on your old contract. 60% of the time you have already used in your existing contract will be appended to the expiration date of your contract.
This means if you have had your contract for 30 days already, then 18 more days will be added to the end of your contract to extend it's expiration date.

How long does the Sha256 contract take after purchase to start mining?

Typically its less than an hour, usually much less (thats my guess) Mine didn't take that long. I hit up the developers for a more detailed answer.

It's hashing already(!), paid with bitcoin. But just in case:

What would be the right way to come into contact with the devs? Freshdesk? https://mintsy.freshdesk.com

Yes if you think its a pressing development issue you can PM me also. Many of the Tier one support on Mintsy are still training.

[profall]

Mining Pool Reviews, Ratings and Rankings. 

www.BlockGen.net

Mintsy is listed on BlockGen, you can review them here: http://blockgen.net/miningPool/94

[augustito]

i cant connect with externals pools in scrypt (nicehash, multipool.us , my own p2pool) , i open a couple of tickets unsolved for almost 5 days... nothing change....

[BitJohn]

i cant connect with externals pools in scrypt (nicehash, multipool.us , my own p2pool) , i open a couple of tickets unsolved for almost 5 days... nothing change....

I mine Multipool no issues. Did you setup the external pool? PM me a ticket# and a screenshot of your multipool setup.

[ThePhwner]

A few things I'd like to note after using the beta and official product for several weeks:

1. The proxy remains inconsistent. Some pools do not work at all (Antpool) and some pools report double hash rate (F2Pool).

2. The current system is unfair to rig owners. There's no way to communicate with the renter, and in multiple instances, we've had a renter pick a bad pool. Then we get dinged with the fee, and the lost mining time. Per Mintsy policy, the decision to refund is based 100% on hash rate. In a system where owner and renter can communicate, we can provide support to ensure the renter is mining.

3. Support simply closed 2 tickets I filed when the proxy was clearly malfunctioning.  I spent a great deal of time ensuring that ~20 S3 units were updated to use the custom cgminer and for a few weeks, successfully rented the Ant Farm to satisfied renters. But when the proxy went wonky and support just closed tickets with no response, we pulled everything but 600 Gh/s.

4. Taking in to account point #1, the inconsistent hash reporting, it seems that basing rental refunds solely on reported hashrate, is a roll of the dice.

5. We should be able to add extra time to a rental if something goes wrong on our end. Right now the only way to compensate is to move another miner to the rental or take the loss. We prefer to keep our reputation up by extending rentals if needed and we can't do that.

That being said, I have enjoyed the altcoin pools. But, for now, we are done with Mintsy.

[jonnybravo0311]

My experience thus far with Mintsy has been twofold: a purchased SHA256 mining contract (1TH/s for 90 days) and pointing my own hardware here.

First, here is the good news.  The mining contract which I purchased was given a boost to 2.5TH/s and extended.  This was an unexpected surprise and I'm very thankful for it.  I've actually got a relatively decent chance to come out positive now.

The UI is easy to navigate and you can switch coins at will.  If you've got a cryptsy account, you can hook it up directly using your trade key.  Any alt coins you mine get paid out to your cryptsy wallets automatically.  Bitcoin mining payouts are a manual process.  Stats are plentiful, too.  You can look at your average hash rate, see found blocks, pool hash rate, expected time to block, etc.

On the hardware side, I've had issues aplenty.  Since the pool is also listed in the alt coin service announcements, that's where I first reported my problems.  You can see my posts at this link: https://bitcointalk.org/index.php?topic=786492.msg11256333#msg11256333.

My main concern is that when my gear is pointed to this pool via MRR, it fails.  Even though I've got the latest version of cgminer with the nicehash #xnonce patch as required, it simply does not connect from MRR.  Workers are constantly restarting or refusing to hash and fall back to secondary pools.  When I connect my gear directly to the pool, things work as expected.

I have not attempted to connect to and mine external pools with either my contracted hash or my own gear, so I don't have any comment on others' experiences doing so.

Huh... I wonder if I could setup an infinite loop.  Here's the scenario:

I setup an external pool here for MRR.  On MRR, I setup my primary pool to point back here.  So, I'd be telling Mintsy to mine on MRR and MRR would say to mine on Mintsy.  I might try that for fun after my gear's current rental ends (assuming it's not immediately rented again).

That makes me think of another scenario.  If a purchased contract can be pointed to an external pool, could that pool be MRR?  I'd be able to rent my contract out on MRR.  Another thing I might try.

[BitJohn]

My experience thus far with Mintsy has been twofold: a purchased SHA256 mining contract (1TH/s for 90 days) and pointing my own hardware here.

First, here is the good news.  The mining contract which I purchased was given a boost to 2.5TH/s and extended.  This was an unexpected surprise and I'm very thankful for it.  I've actually got a relatively decent chance to come out positive now.

The UI is easy to navigate and you can switch coins at will.  If you've got a cryptsy account, you can hook it up directly using your trade key.  Any alt coins you mine get paid out to your cryptsy wallets automatically.  Bitcoin mining payouts are a manual process.  Stats are plentiful, too.  You can look at your average hash rate, see found blocks, pool hash rate, expected time to block, etc.

On the hardware side, I've had issues aplenty.  Since the pool is also listed in the alt coin service announcements, that's where I first reported my problems.  You can see my posts at this link: https://bitcointalk.org/index.php?topic=786492.msg11256333#msg11256333.

My main concern is that when my gear is pointed to this pool via MRR, it fails.  Even though I've got the latest version of cgminer with the nicehash #xnonce patch as required, it simply does not connect from MRR.  Workers are constantly restarting or refusing to hash and fall back to secondary pools.  When I connect my gear directly to the pool, things work as expected.

I have not attempted to connect to and mine external pools with either my contracted hash or my own gear, so I don't have any comment on others' experiences doing so.

Huh... I wonder if I could setup an infinite loop.  Here's the scenario:

I setup an external pool here for MRR.  On MRR, I setup my primary pool to point back here.  So, I'd be telling Mintsy to mine on MRR and MRR would say to mine on Mintsy.  I might try that for fun after my gear's current rental ends (assuming it's not immediately rented again).

That makes me think of another scenario.  If a purchased contract can be pointed to an external pool, could that pool be MRR?  I'd be able to rent my contract out on MRR.  Another thing I might try.

I shared this with the development team to see if we can better integrate the MRR stuff, and NiceHash. Thanks for the great feedback!

[ThePhwner]

I shared this with the development team to see if we can better integrate the MRR stuff, and NiceHash. Thanks for the great feedback!

Wondering if you have any feedback on the items I provided above. Specifically the functioning of your proxy and communication with renters. We spent a great deal of time trying to support your service and were quite disappointed.

Additionally, multiple posts here note the lack of response from support. Perhaps you could shed some light on that.

[bitsolutions]

A few things I'd like to note after using the beta and official product for several weeks:

1. The proxy remains inconsistent. Some pools do not work at all (Antpool) and some pools report double hash rate (F2Pool).

Odd that Antpool doesn't work.  I've seen the f2pool issue myself and know why it happens on certain poorly designed stratum proxies, it basically indicates a pretty bad flaw in the share validation logic which might even relate to the Antpool issue.

2. The current system is unfair to rig owners. There's no way to communicate with the renter, and in multiple instances, we've had a renter pick a bad pool. Then we get dinged with the fee, and the lost mining time. Per Mintsy policy, the decision to refund is based 100% on hash rate. In a system where owner and renter can communicate, we can provide support to ensure the renter is mining.

Hopefully your rigs were failing over, if they are not then Mintsy's proxy must have some serious issues.

[jonnybravo0311]

2. The current system is unfair to rig owners. There's no way to communicate with the renter, and in multiple instances, we've had a renter pick a bad pool. Then we get dinged with the fee, and the lost mining time. Per Mintsy policy, the decision to refund is based 100% on hash rate. In a system where owner and renter can communicate, we can provide support to ensure the renter is mining.

I like the way MRR handles this scenario.  If the renter's pool goes offline, or fails, and the renter doesn't have a backup, MRR effectively looks dead to your gear.  Your gear then fails over to whatever pools you've setup as backups so you as the rig owner don't lose any time.

For example, I've got my rigs setup like this:

pool 1 - stratum+tcp://us-east01.miningrigrentals.com:3333#xnsub
pool 2 - stratum+tcp://us-central01.miningrigrentals.com:3333#xnsub
pool 3 - stratum+tcp://104.131.12.128:9332

So, if a renter screws up, my gear fails over to my p2pool node.

@BitJohn, setting up something similar on Mintsy would be extremely useful, and alleviate the problem reported by ThePhwner.

[BitJohn]

2. The current system is unfair to rig owners. There's no way to communicate with the renter, and in multiple instances, we've had a renter pick a bad pool. Then we get dinged with the fee, and the lost mining time. Per Mintsy policy, the decision to refund is based 100% on hash rate. In a system where owner and renter can communicate, we can provide support to ensure the renter is mining.

I like the way MRR handles this scenario.  If the renter's pool goes offline, or fails, and the renter doesn't have a backup, MRR effectively looks dead to your gear.  Your gear then fails over to whatever pools you've setup as backups so you as the rig owner don't lose any time.

For example, I've got my rigs setup like this:

pool 1 - stratum+tcp://us-east01.miningrigrentals.com:3333#xnsub
pool 2 - stratum+tcp://us-central01.miningrigrentals.com:3333#xnsub
pool 3 - stratum+tcp://104.131.12.128:9332

So, if a renter screws up, my gear fails over to my p2pool node.

@BitJohn, setting up something similar on Mintsy would be extremely useful, and alleviate the problem reported by ThePhwner.

I will get with the developers and see what we can do.

[ThePhwner]

A few things I'd like to note after using the beta and official product for several weeks:

1. The proxy remains inconsistent. Some pools do not work at all (Antpool) and some pools report double hash rate (F2Pool).

Odd that Antpool doesn't work.  I've seen the f2pool issue myself and know why it happens on certain poorly designed stratum proxies, it basically indicates a pretty bad flaw in the share validation logic which might even relate to the Antpool issue.

2. The current system is unfair to rig owners. There's no way to communicate with the renter, and in multiple instances, we've had a renter pick a bad pool. Then we get dinged with the fee, and the lost mining time. Per Mintsy policy, the decision to refund is based 100% on hash rate. In a system where owner and renter can communicate, we can provide support to ensure the renter is mining.

Hopefully your rigs were failing over, if they are not then Mintsy's proxy must have some serious issues.

They were not failing over. This was the subject of 2 tickets which were simply closed after several days. For a few weeks the proxy seemed to be working, but we had 2 rental where the proxy messed up, the renter got nothing, we still had to pay our end of the fee, and lost all the mining time.

[lobogil]

Hey ThePhwner - you could take some of your own crap support advice:



and then:

Maybe you can choke on your Twinkies.

So happy to see this ex-BAN admin scammer getting the same treatment he gave to many others on his scam pool 

[bitsolutions]

They were not failing over. This was the subject of 2 tickets which were simply closed after several days. For a few weeks the proxy seemed to be working, but we had 2 rental where the proxy messed up, the renter got nothing, we still had to pay our end of the fee, and lost all the mining time.

That's pretty bad, if an upstream pool connection fails the proxy should either fail all the connections to a backup or cut all its downstream connections so the miners failover to backups. They also shouldn't rely on upstream hash-rate validation as it could be inaccurate due to extremely high diff or other weird pool issues it should be measured on the downstream miner connection side.

[malickie]

I bought a scrypt cloud miner from mintsy and sadly a Lot of External sites I point at do not function at all.  suprnova, nicehash/westhash etc.  So I went and just pointed at their own servers and so far so good there.  Just wish I could point the miner at different altcoins than mintsy has listed.  Pretty much when I figured out that issue I have just had the miner pointed at Litecoin in hopes that I will come out ahead of what I spent.

[ThePhwner]

They were not failing over. This was the subject of 2 tickets which were simply closed after several days. For a few weeks the proxy seemed to be working, but we had 2 rental where the proxy messed up, the renter got nothing, we still had to pay our end of the fee, and lost all the mining time.

That's pretty bad, if an upstream pool connection fails the proxy should either fail all the connections to a backup or cut all its downstream connections so the miners failover to backups. They also shouldn't rely on upstream hash-rate validation as it could be inaccurate due to extremely high diff or other weird pool issues it should be measured on the downstream miner connection side.

Agree completely. There's a lot of potential here for a great service but these are the exact weaknesses that caused us to pull all but 600 Gh/s. It's kind of fun to have a little hash there to mine some alts (MZC has been doing well past couple days) but it's not worth the effort to put our larger rentals up and risk this scenario. My guess is that digitalX doesn't have a big team behind Mintsy but its frustrating that these core issues remain unacknowledged and unaddressed.

We are used to the models/functions of the other sites, where true failover occurs if the renter picks a bad pool, etc.

I'd like to see these issues addressed, as again, there is potential here. Especially for anyone who likes a few alts on the side.