Date UTC TXID Address Amount BTC Confirmations
2014-06-27 03:00:34 Comment: Fee order #26868 -0.00409800
2014-06-27 03:00:34 Comment: Payment order #26868 -0.19590200
after i creat this oder, i pay 0.2 btc to nicehash,
BUT this order just disappeard strangely 5 seconds later.
and did not return my 0.2BTC to my account.
and i can not find this order on my List of my past orders
NO order #26868
Order Action Price BTC/GH/Day Total BTC Unspent BTC Completed Accepted GH Rejected GH Limited GH/s
#26863
Cancelled on request
0.48 0.19590200 0.19590200 0.00% 0.00 0.00 2.00
Pool URL
stratum+tcp://stratum.pool.mn:7805
Username
keepwalking1234.tudou20
Password
1
#26712
Completed
0.50 0.19590200 0.00000000 100.00% 33851.94 170.89 2.00
Pool URL
stratum+tcp://stratum.pool.mn:7805
Username
keepwalking1234.tudou20
Password
1
#26683
Completed
0.90 0.39190200 0.00000000 100.00% 37622.74 639.28 5.00
Pool URL
stratum+tcp://stratum.pool.mn:7805
Username
keepwalking1234.tudou20
Password
1
can you deal with this? thanks
Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 285. (Read 794394 times)
June 26, 2014, 10:18:48 PM
June 26, 2014, 09:41:48 AM
@djbert Have you tried my stratum/getwork proxy ? https://bitcointalksearch.org/topic/new-stratumgetwork-proxy-with-web-based-gui-and-pools-management-611338
OK, i have some great news for those of us still using the older getwork type sha256 miners! but a brief explanation first, sorry. I have documented my miner issues in my earlier rantings in this thread about being kicked off nicehash ever since they implemented their DDoS protection measures, necessary of course, but it screwed my sha256 miner over big time. I thought it was nicehash's fault for awhile, but come to find out my miner had issues i wasn't really aware before that keep getting me banned. So I was willing to try anything to get my miner working, and so i followed the suggestion from Pfool about checking out his java proxy, and i am sure glad I did. Pfool obviously did all the work, but Pfool took my numerous debug logs and other network traffic to pinpoint my issues, which after only 5 days, Pfool identified and fixed it! Actually, as i am writing this, my miner is chugging along just fine, and it is great seeing an almost vertical line change show up in my sha256 payout chart on nicehash now.
so here is what you need to do for your old getwork miners to get them working with nicehash again...1. download the latest beta of the java proxy. it can be found here https://github.com/Stratehm/stratum-proxy/releases you have to have java loaded on your computer for it to run. the instructions to get it all running is on the main page of that site.
2. I have a ASICMiner Block Erupter Cube, which only uses getwork, hence the need for a stratum proxy. use the following command line with the java proxy to get it up and running. please note you need midstate enabled (default state with this proxy) for this particular miner.
java -jar stratum-proxy.jar --getwork-listen-port xxxx -h stratum.nicehash.com:3334 -u YOUR BTC Address -p xxxx -n NiceHash --set-extranonce-subscribe true --validate-sha256-getowrk-shares
changes the xxxx's to what you have going on for those options.
Some final notes...
my particular issue with getting banned by nicehash, was that my Cube was submitting shares that were either above or below the target difficulty, and while they were being reported as accepted by the proxy, they were getting rejected by nicehash. this basically looked like the reject share attacked they were DDoS with before, hence the instant ban. Now Pfool has implemented the "--validate-sha256-getowrk-shares" opion to have the proxy validate the shares before leaving to nicehash, and not submitting the ones that don't make the necessary targets. while this has resulted in drastic drop in the acceptance rate reported the Cube (not nicehash, i have nice blue lines
), at least it is not getting banned, and i am able to contribute some decent hash power again. i do want to stress that the latest version is basically a beta version, so i am sure Pfool will address this particular issue when he can, however it may be something that is inherent to getwork to statrum proxies that can't be fixed. i invite Pfool to chime in on anything presented here, especially if i am off base on something. i don't have a shred of programming skills, and my understanding of what is actually happening may be off. either way, my hat is off to Pfool on getting this far with my issue and i look forward to what he has in store for his java proxy. 
June 26, 2014, 08:51:23 AM
Thank you, nicehashdev, for the quick response.
It is now clear what I have already pointed out: the NICE thing here is that we can buy hash power without getting locked into a long term contract in such a volatile market.
On top of that, we decide which coin to mine and handle the coins so mined independently of NiceHash.
To further clarify the "Remaining BTC" concept, I understand that when I place an order for, lets say 24 hours for 1 BTC, at 12 hours into the order I have consumed 0.5 BTC and I have 0.5 BTC not yet consumed so remaining (if I so decide) to cancel the order. So, the cost is not paid upfront but it is gradually consumed by the hour.
All in all, I believe this is a VERY competitive proposal when compared with long term contracts and it suits perfectly the highly dynamic nature of cryptos.
It is now clear what I have already pointed out: the NICE thing here is that we can buy hash power without getting locked into a long term contract in such a volatile market.
On top of that, we decide which coin to mine and handle the coins so mined independently of NiceHash.
To further clarify the "Remaining BTC" concept, I understand that when I place an order for, lets say 24 hours for 1 BTC, at 12 hours into the order I have consumed 0.5 BTC and I have 0.5 BTC not yet consumed so remaining (if I so decide) to cancel the order. So, the cost is not paid upfront but it is gradually consumed by the hour.
All in all, I believe this is a VERY competitive proposal when compared with long term contracts and it suits perfectly the highly dynamic nature of cryptos.
June 26, 2014, 08:37:07 AM
QUESTION 1: I do NOT own the hash power, this remains the asset of the Seller to whom it automatically returns at the end
of time period B. Correct?
of time period B. Correct?
Yes.
I declare a BTC wallet to NiceHash (separate from my deposit wallet) and NiceHash pays into that in bitcoins the value produced by the POOL. Let's call this value C.
QUESTION 2: POOL may be a Litecoin, Dark coin, Noble coin, any coin pool. NiceHash is performing the POOLCOIN -> BTC exchange automatically? If so, isn't the actual coin selection (and not the algorithm) crucial to profitability?
I mean, if I use the hash power to mine Litecoin will I get the same results as when mining Noble coin?
QUESTION 2: POOL may be a Litecoin, Dark coin, Noble coin, any coin pool. NiceHash is performing the POOLCOIN -> BTC exchange automatically? If so, isn't the actual coin selection (and not the algorithm) crucial to profitability?
I mean, if I use the hash power to mine Litecoin will I get the same results as when mining Noble coin?
The only thing you can buy on NiceHash is hashpower. You manage your coins on target pool on your own. You decide when and where to exchange them. We don't exchange any coins.
In the "Statistics" table, I read that Scrypt is currently paying 1.3463 BTC/GH/DAY
In the "Orders" table, I read that order #26042 is paying 1.56 BTC/GH/DAY.
QUESTION: Does this mean that buyer #26042 is paying 1.56 BTC rent to get 1.34 BTC - a guaranteed LOSS of 0.22 BTC?
In the "Orders" table, I read that order #26042 is paying 1.56 BTC/GH/DAY.
QUESTION: Does this mean that buyer #26042 is paying 1.56 BTC rent to get 1.34 BTC - a guaranteed LOSS of 0.22 BTC?
Currently paying value is mainly for providers to consider (whether to put their rigs on NiceHash or no, according to current profit).
Buyers should always check active orders, because "Currently paying" value does not give you much information about how much you should pay for the hashpower - "Currently paying" is only weighted average price. This means that you may get hashing power for price lower than that (usually if you don't need high speed) and if you want to buy all speed available, you will have to bid higher than "Currently paying". Keep in mind that orders are coming and going, that every customer can increase price of order, change speed limit of order and even cancel order at any time. Even one such action can shift price considerably in either direction. Basically, you are competing with other buyers where the goal is to get hashing speed for as low possible price as possible, but at the same time not staying without any hashing power.
When deciding whether to rent hash power, all you have to do is calculate BTC/GH/Day (price Y) for mining certain coin with X hashpower. Then you buy X amount of hashpower for price
The great benefit of NiceHash is that you are not limited to contract like with other rental services. If the coins profitability drop, you simply cancel the order and get remaining BTC back. Other rental services may render you negative profit, because you can't terminate renting contract. NiceHash is the rental service with minimum risk.
Finally, I fail to understand the meaning of "Remaining BTC" column.Remaining BTC of what? ETA hours is what?
Remaining BTC is the amount of BTC still in order and that amount is given back to you in case you cancel the order. ETA is estimated time of completion of order (in hours) if the speed of your order remains unchanged until the end.
June 26, 2014, 07:57:21 AM
Forgive me if I repeat some things here, but I am new to NiceHash concept and I try to figure out exactly what are the benefits of this service.
I've been reading all FAQs but still one crucial thing remains vague: how much am I going to profit from investing X amount of BTC as buyer?
So let me add some clarifications here to "How can I buy hash power" plus "How much to expect" FAQ and ask from the community to correct where I'm wrong.
Comparison with CEX concept:
In CEX I am buying an asset (GHs) at price A which I hold for 1 day. At the end of the day I have income from mining B and I can sell the asset at a price C. My profit (income) or loss from that day is B+C-A.
My risk here is that at the end of the day I may sell at price C lower than A, with the difference C-A being bigger than the mining income B, producing a net loss.
Comparison with Mining Contracts concept:
When buying a mining contract I pay for a specific hash power valued A BTC for a LONG period (usually 1 year).
At the end of the year I can be 100% certain that I have lost A BTC. The seller is paying me C bitcoins on a regular basis. Unfortunately, due to the highly volatile crypto conditions, I run the risk that C payments X 1 year may not be enough to cover my initial investment A.
How can I compute the profit and risk from buying hash power at NiceHash?
At NiceHash I'm renting hash power A for a time period B (let's say 1 day) from a hash power owner (Seller).
NiceHash acts as an intermediary between me (Buyer) and Seller, charging a 2% commission on each leg of the transaction.
QUESTION 1: I do NOT own the hash power, this remains the asset of the Seller to whom it automatically returns at the end
of time period B. Correct?
I am responsible to direct this hash power A to a pool of my chosing, lets name it POOL. POOL must obey certain technical specs (operate with my chosen algo (Scrypt, X11 etc) and be compatible with NiceHash stratum tech.
I declare a BTC wallet to NiceHash (separate from my deposit wallet) and NiceHash pays into that in bitcoins the value produced by the POOL. Let's call this value C.
QUESTION 2: POOL may be a Litecoin, Dark coin, Noble coin, any coin pool. NiceHash is performing the POOLCOIN -> BTC exchange automatically? If so, isn't the actual coin selection (and not the algorithm) crucial to profitability?
I mean, if I use the hash power to mine Litecoin will I get the same results as when mining Noble coin?
If all the above is correct, at the end of the day B I have lost the rent of hash power A and I have gained the value produced by my pool, C.
So with NiceHash my profit (loss) is C-A within a period B.
The NICE thing with NiceHash is that period B can be short enough (hours - days) to allow me to calculate risks with a much more tight error margin than estimating returns of 1 year contracts.
Example:
From NiceHash home page I read Statistics / Orders for Scrypt.
I'm not sure if I read the info there correctly.
In the "Statistics" table, I read that Scrypt is currently paying 1.3463 BTC/GH/DAY
In the "Orders" table, I read that order #26042 is paying 1.56 BTC/GH/DAY.
QUESTION: Does this mean that buyer #26042 is paying 1.56 BTC rent to get 1.34 BTC - a guaranteed LOSS of 0.22 BTC?
The buyer in this case is just betting that his choice of POOL/COIN is so much in the rise this specific time period that it will bring him much more than the 0.22 BTC plus commission?
The Seller, on the other hand, is getting paid upfront a price for his hash power no matter what the market conditions will be.
Finally, I fail to understand the meaning of "Remaining BTC" column.Remaining BTC of what? ETA hours is what?
I apologize for the lengthy post but this is the only way to clear out what I believe is the important staff here: how much is at risk and what can one expect from NiceHash as a buyer.
I've been reading all FAQs but still one crucial thing remains vague: how much am I going to profit from investing X amount of BTC as buyer?
So let me add some clarifications here to "How can I buy hash power" plus "How much to expect" FAQ and ask from the community to correct where I'm wrong.
Comparison with CEX concept:
In CEX I am buying an asset (GHs) at price A which I hold for 1 day. At the end of the day I have income from mining B and I can sell the asset at a price C. My profit (income) or loss from that day is B+C-A.
My risk here is that at the end of the day I may sell at price C lower than A, with the difference C-A being bigger than the mining income B, producing a net loss.
Comparison with Mining Contracts concept:
When buying a mining contract I pay for a specific hash power valued A BTC for a LONG period (usually 1 year).
At the end of the year I can be 100% certain that I have lost A BTC. The seller is paying me C bitcoins on a regular basis. Unfortunately, due to the highly volatile crypto conditions, I run the risk that C payments X 1 year may not be enough to cover my initial investment A.
How can I compute the profit and risk from buying hash power at NiceHash?
At NiceHash I'm renting hash power A for a time period B (let's say 1 day) from a hash power owner (Seller).
NiceHash acts as an intermediary between me (Buyer) and Seller, charging a 2% commission on each leg of the transaction.
QUESTION 1: I do NOT own the hash power, this remains the asset of the Seller to whom it automatically returns at the end
of time period B. Correct?
I am responsible to direct this hash power A to a pool of my chosing, lets name it POOL. POOL must obey certain technical specs (operate with my chosen algo (Scrypt, X11 etc) and be compatible with NiceHash stratum tech.
I declare a BTC wallet to NiceHash (separate from my deposit wallet) and NiceHash pays into that in bitcoins the value produced by the POOL. Let's call this value C.
QUESTION 2: POOL may be a Litecoin, Dark coin, Noble coin, any coin pool. NiceHash is performing the POOLCOIN -> BTC exchange automatically? If so, isn't the actual coin selection (and not the algorithm) crucial to profitability?
I mean, if I use the hash power to mine Litecoin will I get the same results as when mining Noble coin?
If all the above is correct, at the end of the day B I have lost the rent of hash power A and I have gained the value produced by my pool, C.
So with NiceHash my profit (loss) is C-A within a period B.
The NICE thing with NiceHash is that period B can be short enough (hours - days) to allow me to calculate risks with a much more tight error margin than estimating returns of 1 year contracts.
Example:
From NiceHash home page I read Statistics / Orders for Scrypt.
I'm not sure if I read the info there correctly.
In the "Statistics" table, I read that Scrypt is currently paying 1.3463 BTC/GH/DAY
In the "Orders" table, I read that order #26042 is paying 1.56 BTC/GH/DAY.
QUESTION: Does this mean that buyer #26042 is paying 1.56 BTC rent to get 1.34 BTC - a guaranteed LOSS of 0.22 BTC?
The buyer in this case is just betting that his choice of POOL/COIN is so much in the rise this specific time period that it will bring him much more than the 0.22 BTC plus commission?
The Seller, on the other hand, is getting paid upfront a price for his hash power no matter what the market conditions will be.
Finally, I fail to understand the meaning of "Remaining BTC" column.Remaining BTC of what? ETA hours is what?
I apologize for the lengthy post but this is the only way to clear out what I believe is the important staff here: how much is at risk and what can one expect from NiceHash as a buyer.
June 25, 2014, 07:52:21 PM
Information for buyers: Due to increased transaction dust, produced from mining directly into NiceHash deposit address, we can not allow this anymore. Many small incoming transactions are increasing online wallet load and also increasing outgoing transaction fees. We ask you to mine into your personal wallet and then transfer funds in your NiceHash online deposit address - it will be faster (we only require 2 confirmations) and cheaper in the end of the day. Unfortunately we will have to disable mining directly into NiceHash deposit address at the beginning of the next week. Many online exchanges and similar services have implemented this kind of restrictions in the past. Thanks for understanding and thanks for using NiceHash!
Another feature worth considering, payment threshold. Possibly as another password parameter such as "t=0.02" to transfer when balance reaches 0.02 BTC. If multiple values come in then take the lowest value recorded since the last payment.
This could cause troubles, because someone else could use your BTC address and set ridiculous values for payment threshold. The only way to give this option to providers is to force them to register and that is not what we have in plans to do ever.
Are you saying ridiculous in terms of how high or how low the threshold could be set to? High is not an issue as you would use the lowest value received. Low would still be constrained by the existing threshold you have set for per cycle and per day payouts. The worst a bad agent could do is cause the payment to go out before someone wanted it. That would put the provider back to the same payout schedule they have now which I don't see as a major threat.
Regarding accounts, there is an alternative method for controlling settings in a confirmed way. Look at how the simplevert.com pool works. Stored settings such as payout addresses for merged mined coins is controlled using signed messages from the BTC address used. This way only the person who controls that address can change settings yet there is still not a need for collecting user information.
June 25, 2014, 07:00:41 PM
DoS again? or just down for maint?
June 25, 2014, 05:10:29 PM
Information for buyers: Due to increased transaction dust, produced from mining directly into NiceHash deposit address, we can not allow this anymore. Many small incoming transactions are increasing online wallet load and also increasing outgoing transaction fees. We ask you to mine into your personal wallet and then transfer funds in your NiceHash online deposit address - it will be faster (we only require 2 confirmations) and cheaper in the end of the day. Unfortunately we will have to disable mining directly into NiceHash deposit address at the beginning of the next week. Many online exchanges and similar services have implemented this kind of restrictions in the past. Thanks for understanding and thanks for using NiceHash!
Another feature worth considering, payment threshold. Possibly as another password parameter such as "t=0.02" to transfer when balance reaches 0.02 BTC. If multiple values come in then take the lowest value recorded since the last payment.
This could cause troubles, because someone else could use your BTC address and set ridiculous values for payment threshold. The only way to give this option to providers is to force them to register and that is not what we have in plans to do ever.
June 25, 2014, 04:57:44 PM
I would like to second the vote on setting up some sort of payment threshold. Some of us are pretty small time players and it would be nice to have the option of selecting when I wish to cash out.
*BTW, did anybody else notice a hiccup in the sha256 pool this afternoon or is just me?
*BTW, did anybody else notice a hiccup in the sha256 pool this afternoon or is just me?
June 25, 2014, 04:44:11 PM
We have published new sgminer_v5 binaries (linux, windows), build today (60 sec quit fix, high speed fan fix, etc.): https://www.nicehash.com/software/#sgminer
With the win32 compiled version I'm getting the same bin compilation error on all algorithms.
Code:
[14:34:57] Started sgminer 4.2.1
[14:34:57] Loaded configuration file Multi-Algo.conf
[14:34:57] Probing for an alive pool
[14:34:58] NiceHash_Scrypt_multi difficulty changed to 128
[14:34:59] Startup GPU initialization... Using settings from pool NiceHash_Scrypt_multi.
[14:34:59] Building binary ckolivasHawaiigw256l4lg2tc30592nf10.bin
[14:35:08] Initialising kernel ckolivas.cl with bitalign, unpatched BFI, nfactor 10, n 1024
[14:35:08] Initialising kernel ckolivas.cl with bitalign, unpatched BFI, nfactor 10, n 1024
[14:35:08] Building binary ckolivasCedargw256l4lg2tc1920nf10.bin
[14:35:08] Error -11: Building Program (clBuildProgram)
[14:35:08] "C:\Users\Azza\AppData\Local\Temp\OCLEFFB.tmp.cl", line 792: warning: variable
"ySIZE" was declared but never referenced
const uint ySIZE = (N[NFACTOR]/LOOKUP_GAP+(N[NFACTOR]%LOOKUP_GAP>0));
^
"C:\Users\Azza\AppData\Local\Temp\OCLEFFB.tmp.cl", line 844: error: work group
size exceeds the maximum default value for the selected device
__attribute__((reqd_work_group_size(WORKSIZE, 1, 1)))
^
1 error detected in the compilation of "C:\Users\Azza\AppData\Local\Temp\OCLEFFB.tmp.cl".
Frontend phase failed compilation.
Edit: Did the NiceHash developers use the latest version that fixes the Error -11 Building Program bug that was reported on the github site?
June 25, 2014, 03:45:32 PM
I see nothing wrong. Keep in mind following:
- Orders are filled from top to bottom; top orders are filled first. If a lot of new orders appear or a lot of new orders become alive, then the picture you have shown would appear and it takes some time for rigs to get reassigned. We don't reassign rigs constantly, because that would give very bad performance to rig owners; we rather do that in approx. 2 minute intervals (reassigning 100-200 rigs at a time).
- Some of our customers use API, custom pools and can therefore manipulate when order is alive (if their pool terminates connection, then order gets dead and is pushed down the list - you get impression as if that order didn't exists). When this order gets alive again, it will be somewhere in the middle of the list and with 0 miners, waiting to get filled with miners. We do permit this kind of behavior because providers are awarded for connections dropped by remote pools.
- Orders are filled from top to bottom; top orders are filled first. If a lot of new orders appear or a lot of new orders become alive, then the picture you have shown would appear and it takes some time for rigs to get reassigned. We don't reassign rigs constantly, because that would give very bad performance to rig owners; we rather do that in approx. 2 minute intervals (reassigning 100-200 rigs at a time).
- Some of our customers use API, custom pools and can therefore manipulate when order is alive (if their pool terminates connection, then order gets dead and is pushed down the list - you get impression as if that order didn't exists). When this order gets alive again, it will be somewhere in the middle of the list and with 0 miners, waiting to get filled with miners. We do permit this kind of behavior because providers are awarded for connections dropped by remote pools.
June 25, 2014, 02:54:42 PM
Are some people being given priority?
I noticed this problem affecting both scrypt and x13, it may affect the other algos as well.
Here is the problem. I put up an order for hash power, even tho it is above the lowest priced order that is hashing it never starts, even If I increase the price alot it will never start. I noticed alot of people having the same problem. It appears that some people are getting priority to hash first which is really shitty.
I noticed this problem affecting both scrypt and x13, it may affect the other algos as well.
Here is the problem. I put up an order for hash power, even tho it is above the lowest priced order that is hashing it never starts, even If I increase the price alot it will never start. I noticed alot of people having the same problem. It appears that some people are getting priority to hash first which is really shitty.
June 25, 2014, 12:46:18 PM
We have published new sgminer_v5 binaries (linux, windows), build today (60 sec quit fix, high speed fan fix, etc.): https://www.nicehash.com/software/#sgminer
June 24, 2014, 12:01:32 PM
Hi Nicehash dev, is there white list so I can avoid you ban me, I'm using slow internet but my rig so big (~600MB) that give me too many reject (~3% to 7%)
My wallet add is: 17BEAnCpVk88wg8Eszmbw8periW1ZXv9BG (in case u can add me in your white list).
Thank you.
My wallet add is: 17BEAnCpVk88wg8Eszmbw8periW1ZXv9BG (in case u can add me in your white list).
Thank you.
June 24, 2014, 05:13:24 AM
Information for buyers: Due to increased transaction dust, produced from mining directly into NiceHash deposit address, we can not allow this anymore. Many small incoming transactions are increasing online wallet load and also increasing outgoing transaction fees. We ask you to mine into your personal wallet and then transfer funds in your NiceHash online deposit address - it will be faster (we only require 2 confirmations) and cheaper in the end of the day. Unfortunately we will have to disable mining directly into NiceHash deposit address at the beginning of the next week. Many online exchanges and similar services have implemented this kind of restrictions in the past. Thanks for understanding and thanks for using NiceHash!
Another feature worth considering, payment threshold. Possibly as another password parameter such as "t=0.02" to transfer when balance reaches 0.02 BTC. If multiple values come in then take the lowest value recorded since the last payment.
June 24, 2014, 01:35:43 AM
Information for buyers: Due to increased transaction dust, produced from mining directly into NiceHash deposit address, we can not allow this anymore. Many small incoming transactions are increasing online wallet load and also increasing outgoing transaction fees. We ask you to mine into your personal wallet and then transfer funds in your NiceHash online deposit address - it will be faster (we only require 2 confirmations) and cheaper at the end of the day. Unfortunately we will have to disable mining directly into NiceHash deposit address at the beginning of the next week. Many online exchanges and similar services have implemented this kind of restrictions in the past. Thanks for understanding and thanks for using NiceHash!
June 23, 2014, 05:30:41 PM
lol...boy I guess I just picked the wrong time to try out this pool's sha256 situation. Talk about bad timing. I'll give it another go this evening seeing as how it looks like everything is back up!
June 23, 2014, 03:14:39 PM
One feature I'd like to see added is worker identification such as the "address.workerid" format used by some other pools. I have miners running on a couple of machines and it is easier to look at the stats page to make sure everything is running instead of going to look at the other machine.
June 23, 2014, 02:24:48 PM
Can you guys add a way to link payment address to our accounts, so we don't have to go in the worker section and scroll down to find our payment address each time!
No need for NiceHash to do that for you. Just save a bookmark in your browser the next time you are on your payment page. Then you can go directly to the payment page each time without scrolling though the payment list.
June 23, 2014, 10:21:05 AM
Can you guys add a way to link payment address to our accounts, so we don't have to go in the worker section and scroll down to find our payment address each time!
Jump to: