Hey, we are only online for one day (in pre-launch mode) and we're already at 100+ Mhs ... rest assure that when renters will taste the ease of use, flexible order placement, hassle free hash power renting, etc., the prices will just go up.

Payments are sent in a single transaction for all miners, thus the transaction fee is negligible. Furthermore, transaction fees for outgoing payments are covered by NiceHash and are included in the NiceHash service fee (which is currently set to 0% ). We want the providers to be paid fast, that's why we want to keep multiple payments per day.

Thanks, we hope that this is what will attract all those miners who would like to get a good paying service with a peace of mind (no "worries" if rig goes down, no communication with buyers, etc.).


We would like to cut the old-fashion thinking of "renting a rig". Therefore we introduced a new concept which will need some time for the users to adopt it (that is, renting the hash power). What you're saying is correct - currently there are no limitations possible, because the service is still not in full feature state.

When we'll finish the "placing orders" functionality (probably next week), the process will go like that:

- select algorithm (already done)
- select amount of BTC you are willing to spend (already done)
- select price per hash you are willing to pay (already done)
- optionally select your desired speed (to-do)
- optionally limit the duration of the order (remaining funds are returned to your wallet if all funds are not spent before order expiration time) (to-do)
- optionally set order start expiration date-time (to-do)

This way you'll simply be able to rent the hashpower that you want (for example 100 Mhs) for the price that you're willing to pay (for example 5 BTC/GH/day) (+optionally limit your order for a custom duration). If there is enough hashpower available (you'll be able to see how much hashpower is currently available), your order will be activated instantly, otherwise it will be on hold until the hashpower will become available. If you set start expiration date-time and expire date-time comes before your order could be started, your order will be automatically canceled.

This feature will be implemented in the near future. It's not trivial to automatically detect hash power of rigs, therefore we postponed this feature for a week or so. But yes, you'll be able to see an approximate value of how much hash power is available (besides the one that is currently set to active orders).

Yes, of course. We'll add X11 in the near future (probably next week). If there will be a demand we'll also add other algorithms, without any problems.

Payments are automatic and are issued four times a day if your unpaid balance is greater than 0.002 BTC.

https://nicehash.com/index.jsp?p=faq#faqs3

We've tested BFGminer for gridseed (http://cryptomining-blog.com/1396-download-bfgminer-3-10-0-for-windows-scrypt-mining-on-gridseed-5-chip-asics/) and it works great.

We haven't tested the cgminer-for-gridseed versions - that said it might be that some of the forks of cgminer-3-7-2 with gridseed support might have been patched with upstream patches from latest cgminer and they might work - just give it a try - connect your miner to stratum+tcp://stratum.nicehash.com:3333 - it will start hashing instantly and if all that you'll get are rejects, then your software is not compatible with our service - however if you're getting accepts then you're already earning bitcoins ... btw ... cgminer 3.7.2 is an really old version and we really encourage you to use newer versions or alternatives - besides security patches there are also speed improvements in newer versions/alternatives.

Hejla ... če bi kdo rad kupoval hash power ali pa enostavno dobival dobro plačilo za rentanje svojega hash powerja: https://bitcointalk.org/index.php?topic=562238.0

FOR BUYERS
Buy massive hashing power for mining Bitcoin, Zcash, Ethereum, Monero, and other (un)popular coins.
First fair approach to cloud mining - pay as you mine without upfront payments or contracts.

Start with 0.01 BTC

• Minimum order price is 0.01 BTC for every algorithm

               
No contracts, no risk

• Cancel at any time and get remaining funds back with no cancellation fee

Fast delivery

• Massive hashing power in short amount of time

Mine on your favorite pool

• You are deciding how and when you want to buy hashing power and to which pool to direct it

Real-time statistics

• Follow your workers and their performance

Valid shares only

• Never pay for dead, faulty configured rigs or invalid shares

FOR SELLERS
Sell computing power of your PC, server, workstation, ASIC or farm.

Trusted service

• More than 60,000 daily active miners
• Trustworthy service operating since 2014
• Free software, guides and support

                 
Regular income

• Automatic daily payouts
• Earn Bitcoins for every valid share
• Payouts from 0.001 BTC

Your own pace

• Start and stop when you want
• Connect unlimited mining machines
• Fully anonymous (no registration required)

     

FOR WEBSITE/BLOG OWNERS AND INFLUENCERS
We are offering a referral system for all registered users. You can earn commission from each order placed by customer that you referred - you'll get a percentage of order amount plus some extra mBTC for each order, placed by referred customer. Referral commissions are paid directly into your NiceHash online wallet. If you want to join the referral program, please open an account and ask for referrals at https://new.nicehash.com/support. If you are a larger influencer, we can provide with custom banners and graphics to fit your website/blog.


USEFUL LINKS

• General FAQ for Buyers & Sellers
• How can I configure my miner to work with NiceHash service?
• How to Mine Cryptocurrencies Without a Mining Rig
• NiceHash Miner (Windows GUI miner for GPU/CPU mining)
• Recent payments from NiceHash

FOLLOW US

• NiceHash @ Twitter
• NiceHash @ Facebook
• NiceHash @ ВКонтакте

There is a problem with hashing to pool-eu.hash.so:1337. Someone rented my rig and everything works fine for the renter.

However, LeaseRigs shows pools as Dead and LRP is constantly re-connecting to the pools. What's up?

---

Priority   Status   URL   Username   Accepted   Rejected   Stale   
0   Dead   stratum+tcp://pool-eu.hash.so:1337   worker1   1308304   11184   0   
1   Dead   stratum+tcp://pool-us.hash.so:1337   worker1   0   0   0

---

the stats shows my rig at full speed @ 13.33 MH/s so my rigs are hashing at max speed

---

--192.168.128.102:53751->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.102:53751->share ACCEPTED (diff=1024)
--192.168.128.101:4105->Speed report: 5.588300
--192.168.128.102:4105->Speed report: 3.292000
--192.168.128.103:4105->Speed report: 4.436500
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.102:53751->share ACCEPTED (diff=1024)
Pool connection established: pool-eu.hash.so:1337
Pool failed to authorize: pool-eu.hash.so:1337
Pool connection established: pool-us.hash.so:1337
Pool failed to authorize: pool-us.hash.so:1337
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.103:4105->Speed report: 4.444300
--192.168.128.101:4105->Speed report: 5.595300
--192.168.128.102:4105->Speed report: 3.290000
--192.168.128.101:49824->share ACCEPTED (diff=1024)
Pool connection established: pool-eu.hash.so:1337
Pool failed to authorize: pool-eu.hash.so:1337
Pool connection established: pool-us.hash.so:1337
Pool failed to authorize: pool-us.hash.so:1337
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.102:53751->share ACCEPTED (diff=1024)
--192.168.128.102:53751->share ACCEPTED (diff=1024)
--192.168.128.103:4105->Speed report: 4.488500
--192.168.128.101:4105->Speed report: 5.594800
--192.168.128.102:4105->Speed report: 3.287500
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.103:33316->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.103:33316->share ACCEPTED (diff=1024)
--192.168.128.103:33316->share REJECTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.103:33316->share ACCEPTED (diff=1024)
--192.168.128.103:33316->share ACCEPTED (diff=1024)
--192.168.128.102:53751->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
Pool connection established: pool-eu.hash.so:1337
Pool failed to authorize: pool-eu.hash.so:1337
Pool connection established: pool-us.hash.so:1337
Pool failed to authorize: pool-us.hash.so:1337
--192.168.128.103:4105->Speed report: 4.439000
--192.168.128.101:4105->Speed report: 5.612400
--192.168.128.102:4105->Speed report: 3.274600
--192.168.128.103:33316->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.102:53751->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
Pool connection established: pool-eu.hash.so:1337
Pool failed to authorize: pool-eu.hash.so:1337
--192.168.128.102:53751->share ACCEPTED (diff=1024)
--192.168.128.101:4105->Speed report: 5.569400
--192.168.128.102:4105->Speed report: 3.277000
--192.168.128.103:4105->Speed report: 4.420400
--192.168.128.102:53751->share ACCEPTED (diff=1024)
--192.168.128.102:53751->share ACCEPTED (diff=1024)
Pool connection established: pool-us.hash.so:1337
Pool failed to authorize: pool-us.hash.so:1337
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.101:49824->share ACCEPTED (diff=1024)
--192.168.128.103:33316->share ACCEPTED (diff=1024)

Sorry, miaviator, I didn't see this time-schedule announcement ... and I'm pretty sure many other providers&renters didn't saw it as well ... a short email to all users wouldn't do no harm

Anyway, miaviator&XMK3&djeZo, congratulations on this more or less smooth transition!

Now, when the new server is up&running, here is my top-10 to-do wishlist (high to low priority):

1) merge provider&renter login into a single account with the possibility of changing the password and also introduce 2-factor auth

2) the ability to bulk-hire (mass-hire) multiple rigs at once: one would enter desired hash power and desired rent time -> LeaseRig would select top N rigs to get the desired hash power and the renter would Hire all those rigs with one click (see this: http://files.kobal.org/caveminers/leasrig_bulk_hire.jpg)

3) new provider sign-up with auto-verification (provider would register himself at leaserig, setup his rig and then run the "auto-verification" process -> this would set the rig to 24h mining on selected providers pool ... if the average speed after 24 would be >= declared hashrate, the new provider would be auto-verified ... after that the provider would also have to deposit (declared hashrate * X) BTC funds on a security deposit BTC address on his account, this BTC address would be locked for 7 days, after that it would unlock itself and provider would be able to withdraw his security deposit) ... this way you would get rid of manual adding of users and those manual security deposits)

4) introduce provider reviews (5-stars evaluation + points, weighted by rented hashpower and stability)

5) setup some simple ticket system (for example, osTicket)

6) accept Litecoin as payments

7) separate STATS graphs for actual hashrate (as reported by API) and calculated hashrate (as calculated from accepted shares)

allow provider to "mark rig as non-hirable" -> this would be different from "Disable rig" so that you could "mark rig as non-hirable" even when a rig is already hired -> this would enable provider to put rig in maintenance mode after the current rent ... I know that there is already the workaround by artificially rising the prices to "non-acceptable" and also disabling re-hire option, but this is really clumsy ... I don't wanna mess the prices, I just "mark rig as non-hirable" (the rig would still be displayed, but there would be no "Hire" link and rig would be marked as "non-hirable"

9) show total currently rented hashpower under global STATS

10) user-frendly, adaptive, responsive and mobile devices friendly design

Anyway, keep up the good work!

p.s.: could you please enable ICMP echo (ping) on the new server so that provider can verify latency and possibly debug connection issues from LRP to LeaseRig?

This mess is because LeaseRig has two separate logins - one for renter and one for leaser (provider).

The login for provider is only accessible via link http://23.236.58.114/?page=admin (there is no menu item/icon on LeaseRig maing page to this "provider login"). And once you're logged-in you can not change your provider's password.

The other login is for the renters (customers) - this is via the "LOGIN" menu item on the LeaseRig main page ... and when you're logged in as the customer (renter) you can change your password - but this only changes the password for your's "renter" account ... for the "provider" account still stays intact ...

That said - the first thing on the to-do list would be to merge those two accounts/logins into single one so that one "person" can be leaser&renter at the same time with one account ...

Well, this transition should really be announced in advanced ... you can't just switch to a new server at a random time without even notifying the users ... you could at least send a short email to the providers and to the renters to announce this transition...

You have a typo here. Each line (except the last one) in the JSON format has to end with "," ... the lines after

"thread-concurrency" : "8192"

are not parsed in your case because this line doesn't end with "," ... add comma to the end

"thread-concurrency" : "8192",

and try again.

You can also start cgminer with the --text-only option and also with the --verbose option ... this way you'll be able to see which part of config file wasn't properly loaded.

cgminer --text-only --verbose ... other parameters

@23:30 GMT+1 : "there are only 2365" ... yeah, it's going to be a crazy summer for scrypt

Nice. It might be attractive to also include LiteCoin payments, since LiteCoin is strong again.

I would also vote for optional "auto-trade to BTC". As a provider I don't want to do manual trading at all, so it would be great if you would add the option for "auto-trade to BTC". When leaser would pay in DOGE or LTC, you would do instant auto-trade to Crytpsy (with the Auto-Trade option "Immediate & Complete sell") and provider would receive BTC only.

OK, but if someone rents 300Mhs for 1h and then later 300MHs for 72h your graph would show the exact same spike ... that's why I'm saying that you should also show the actual rented power...

Hmm, these stats are great, but they puzzles me; a couple of things:

1. You should note what is on y axis (I guess it's "Rated price (BTC/MH/s)", it's quite obvious, but anyway ...).

2. You should display the y scale for other values as well (at least "Hired hashing speed (MH/s)") ... otherwise I have no idea what was the value of "Hired hashing speed (MH/s)" in a particular point in time.

3. Are you sure that the "Hired hashing speed (MH/s)" is correct? I don't believe that it fluctuates that much ... are you showing the exact hired power for each particular point in time, or are you showing the power that was rented in a particular point of time (for example, on "Thu Mar 06 21:45:39 CET 2014" Scrypt 3.35 MH/s has been rented) - so, are you counting rent events or actual rented power?

djeZo, you made unnecessarily confusion with those graphs. It's not good to mix apples and oranges. You should create two separate graphs for hashrate and for "hash-from-shares". If realtime hashrate from miner API is not available, don't display hashrate graph and display only "hash-from-shares" graph. Or at least display a warning under the current hashrate graph when your calculating hashrate from shares (and not getting realtime hashrate from miner's API).

You can enable cgminer logging in the script/command line where you're starting cgminer; do like this:

cgminer ...cgminer-options... 2>>cgminer.log

This will redirect full cgminer logs into cgminer.log and so you'll be able to check what happened with cgminer just before it crashed.