Hi,

I would like to know what happens in the following situation.

• An Order is created for a high limit and has 6000-7000 miners assigned.
  
• The Order is canceled and the account is credited the unused amount of BTC including fees.

It is my understanding that it takes time for the miners to switch to another Order.

What happens to the shares that are mined between the Order cancellation and the time the miners switch to another Order?

Is the credit applied at the time of cancellation or is the original Order credited only after all miners and shares are accounted for?

How soon are the credit amounts returned to the account? Immediately or in increments as miners switch?

A detailed response is appreciated.

Thanks!

I checked my wallet and found the refunds for all the orders as you described.   Thank you for pointing that out.

It is very confusing to see an  incomplete order history on the order page or on the order itself. Why does a user have to go hunting for the information?

NICEHASH > here are suggested web site tweaks:

• Add two columns to the 'List of my past orders' page. One for Refunds. One for Net Cost. It is very confusing not to see the whole picture
• Add the same Refunds and Net Cost to the closed Order
• Add a method to download the past orders to csv
• On the Transactions tab of the Wallet page: split the Comments to Order# and Action
• Add a method to download the Transactions to csv so we can analyze our sort and analyze by order
• Add a method to the API to get past orders
• Add a method to the API to get the same information that is on the Wallet tabs: Transactions, Deposits, and Withdrawls

I think the front end changes would help users understand the order life cycle and being able to download data would certainly help if the IRS determines that every transaction needs to be tracked.   The API additions would allow recent history to be shown and graphed.

Would anyone else like to see these suggestions implemented?

I have a an issue that is not being resolved by nicehash support via email.  After 3 back and forth exchanges they simply do not answer my questions and just send back generic replies. It is very frustrating.


Issue - Fees on Dead Orders
I have been using the Nicehash API to build an application to buy and manage orders for ZEC and ZCL.  When the price dips it will cancel an order and create a new order at a lower price based on market conditions. Due to a typo in the pool url the order could not connect and resulted in a dead order.

Each dead order created this way had a 3% fee subtracted from it.  Why?  The order could not connect to a pool.  No mining was done.  The only fee for creating an order is supposed to be .0001.  I have 35 dead orders like this and do not understand why I would pay for mining that did not take place.

Below is a list of all the dead orders where a 3% fee was deducted.

Order	Started	Type	Action	BTC	Unspent BTC	Spent BTC	Completed
#2702342	5/8/2017 15:49	Standard	Cancelled on request	0.01	0.009603	0.000397	0.00%
#2685204	5/5/2017 23:24	Standard	Cancelled on request	0.01	0.009603	0.000397	0.00%
#2682684	5/5/2017 14:24	Standard	Cancelled on request	0.01	0.009603	0.000397	0.00%
#2682410	5/5/2017 13:34	Standard	Cancelled on request	0.01	0.009603	0.000397	0.00%
#2682387	5/5/2017 13:28	Standard	Cancelled on request	0.01	0.009603	0.000397	0.00%
#2682357	5/5/2017 13:22	Standard	Cancelled on request	0.01	0.009603	0.000397	0.00%
#2682336	5/5/2017 13:17	Standard	Cancelled on request	0.01	0.009603	0.000397	0.00%
#2681033	5/5/2017 9:24	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2681030	5/5/2017 9:23	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2681027	5/5/2017 9:23	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2681022	5/5/2017 9:22	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2681014	5/5/2017 9:22	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2681004	5/5/2017 9:21	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680998	5/5/2017 9:21	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680993	5/5/2017 9:20	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680988	5/5/2017 9:20	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680984	5/5/2017 9:19	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680981	5/5/2017 9:19	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680976	5/5/2017 9:18	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680973	5/5/2017 9:18	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680969	5/5/2017 9:17	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680964	5/5/2017 9:17	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680958	5/5/2017 9:16	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680955	5/5/2017 9:16	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680952	5/5/2017 9:15	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680950	5/5/2017 9:15	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680946	5/5/2017 9:14	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680943	5/5/2017 9:14	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680942	5/5/2017 9:13	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680938	5/5/2017 9:13	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2680934	5/5/2017 9:12	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2679557	5/5/2017 4:01	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2679435	5/5/2017 3:31	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2679345	5/5/2017 3:13	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%
#2677613	5/4/2017 21:35	Standard	Cancelled on request	0.04	0.038703	0.001297	0.00%

                  
                  
The total fees deducted on the dead orders are 0.039095 BTC.  This should be .0035 resulting in an overcharge of .035595 BTC

What is the issue with the Statistics Pool > Contributor Hashrates?

The ZEC/Day does not seem correct at all.

I decided to jump in with 30k H/s.  The stats show I should be getting about 8 ZEC per day.


I checked whattomine.com and it says 3.7 ZEC/24Hrs  for 30k H/s.

So far I am getting less than 3 ZEC/24Hrs and losing $.

When is the stats pool page going to reflect a return closer to reality?  It is very misleading.

12.1 was slower for me, about 172 H/s. 
No bios mods or overclock on my cards.

Drivers
win: 16.40.2311
linux: 15.12

I am getting about the same for Gigabyte R9 270 running 12.4.
Average of 4 cards (2 under win, 2 under linux)
H/s: 175
watt: 115-120

When using a browser to monitor on port 3333 a line displaying the ttli % is displayed when ttli kicks in.


This helped me understand how -ttli works.

Currently it only is displayed in the console sometimes if the s key is pressed.

Would it be possible to also display it periodically in the console and in the log file?

Thanks!

Looks like your 270x only has 10 compute units and memory is limited.

This is for the 270 cards:
           

I have two R9 270 (not x) in a Linux 14.04 box with the 15.12 drivers. Using 12.3.  I am getting 172 H/s for each card.
Make sure you set the environment variables as stated in the readme (see script below).
When the zecminer64 starts it reduces the intensity to 4.

bash script:
#!/bin/bash   
export GPU_FORCE_64BIT_PTR=1
export GPU_MAX_HEAP_SIZE=100
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100
/home/me/ClaymoreZCashGPUMinerv12.3/zecminer64

If that is what others are getting for the 380x then it looks like you are ok.

The 270 cards are only 2GB.

You might try playing with the intensity.

Seems like you should be getting more than that.  I get 174 H/s from my R9 270 cards using 12.3.

11:58:54:780   3b9c   ZEC: 03/09/17-11:58:54 - New job from zec-us.suprnova.cc:2142
11:58:54:780   3b9c   target: 0x001085cd (diff: 3966H)
11:58:54:780   3b9c   ZEC - Total Speed: 350.740 H/s, Total Shares: 7196, Rejected: 8, Time: 16:58
11:58:54:780   3b9c   ZEC: GPU0 174.680 H/s, GPU1 176.060 H/s

After upgrading to 12.2 it has run for 3 hours without restarting.

BUT, gpu1 is set to to reduce intensity at 84 (-tt 76  -ttli 80,84) and I have found in the log where it has hit 90. The intensity is reduced (hash goes from 172 to 123 or lower) and the temperature slowly comes down.  I will try reducing the -ttli since there seems to be an over temp condition allowed.

20:05:00:931   43246780   GPU 0 temp = 75, old fan speed = 100%, new fan speed = 100%
20:05:00:934   43246780   GPU 6 temp = 88, old fan speed = 100%, new fan speed = 100%
20:05:00:935   43246780   Gpu 1 -ttli apply delta 4
20:05:03:937   43246780   GPU 0 temp = 75, old fan speed = 100%, new fan speed = 100%
20:05:03:940   43246780   GPU 6 temp = 85, old fan speed = 100%, new fan speed = 100%
20:05:03:940   43246780   Gpu 1 -ttli apply delta 1
20:05:06:942   43246780   GPU 0 temp = 75, old fan speed = 100%, new fan speed = 100%
20:05:06:945   43246780   GPU 6 temp = 89, old fan speed = 100%, new fan speed = 100%
20:05:06:945   43246780   Gpu 1 -ttli apply delta 5
20:05:09:947   43246780   GPU 0 temp = 75, old fan speed = 100%, new fan speed = 100%
20:05:09:950   43246780   GPU 6 temp = 85, old fan speed = 100%, new fan speed = 100%
20:05:09:951   43246780   Gpu 1 -ttli apply delta 1
20:05:12:953   43246780   GPU 0 temp = 75, old fan speed = 100%, new fan speed = 100%
20:05:12:956   43246780   GPU 6 temp = 90, old fan speed = 100%, new fan speed = 100%
20:05:12:956   43246780   Gpu 1 -ttli apply delta 6
20:05:15:958   43246780   GPU 0 temp = 75, old fan speed = 100%, new fan speed = 100%
20:05:15:961   43246780   GPU 6 temp = 86, old fan speed = 100%, new fan speed = 100%
20:05:15:961   43246780   Gpu 1 -ttli apply delta 2
20:05:18:963   43246780   GPU 0 temp = 75, old fan speed = 100%, new fan speed = 100%
20:05:18:967   43246780   GPU 6 temp = 87, old fan speed = 100%, new fan speed = 100%
20:05:18:967   43246780   Gpu 1 -ttli apply delta 3
20:05:21:969   43246780   GPU 0 temp = 75, old fan speed = 100%, new fan speed = 100%
20:05:21:973   43246780   GPU 6 temp = 87, old fan speed = 100%, new fan speed = 100%
20:05:21:973   43246780   Gpu 1 -ttli apply delta 3

turning off watchdog was not helpful.  When the communication to the card stops, it just says to restart the miner.  I could add -r 1 with a reboot.sh but I don't see a difference compared to just enabling the watchdog.

ZEC - Total Speed: 172.517 H/s, Total Shares: 98, Rejected: 0, Time: 00:12
ZEC: GPU0 172.517 H/s, GPU1 0.000 H/s
ZEC: 02/25/17-11:50:24 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (159 ms)!
ZEC: 02/25/17-11:50:25 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (158 ms)!
GPU0 t=74C fan=100%, GPU1 t=57C fan=80%
ZEC: 02/25/17-11:50:41 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (158 ms)!
ZEC: 02/25/17-11:50:43 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (159 ms)!
ZEC: 02/25/17-11:50:46 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (159 ms)!
ZEC: 02/25/17-11:50:58 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (159 ms)!
GPU0 t=73C fan=100%, GPU1 t=51C fan=80%
WATCHDOG: GPU 1 hangs in OpenCL call, you need to restart miner
WATCHDOG: GPU 1 hangs in OpenCL call, you need to restart miner
WATCHDOG: GPU 1 hangs in OpenCL call, you need to restart miner
WATCHDOG: GPU 1 hangs in OpenCL call, you need to restart miner
WATCHDOG: GPU error, you need to restart miner
ZEC: 02/25/17-11:51:27 - SHARE FOUND - (GPU 0)

It was already set to -i 1

I have two computers each with two cards (R270 now getting 172 H/s).  One runs windows 10 the other ubuntu 14. These have been running fine on 11.1

After upgrading to 12.1 I saw about an 11% bump in h/s.

Windows runs fine but the linux box is restarting claymore every 3 to 20 minutes. It is using crimson 15.12 driver (fglrx-15.302).  There appears to be some issue with OpenCL.  I tried "-i 1" and "asm 0" but no change.  Is there anything else I can try?

12:31:10:922   7a7a2780   GPU 6 temp = 63, old fan speed = 80%, new fan speed = 80%
12:31:10:930   7a7a2780   GPU0 t=69C fan=60%, GPU1 t=63C fan=80%
12:31:10:930   7a7a2780   em hbt: 1, fm hbt: 24,
12:31:10:930   7a7a2780   watchdog - thread 0, hb time 270
12:31:10:930   7a7a2780   watchdog - thread 1, hb time 402
12:31:10:930   7a7a2780   watchdog - thread 2, hb time 133
12:31:10:930   7a7a2780   watchdog - thread 3, hb time 5
12:31:10:930   7a7a2780   watchdog - thread 4, hb time 63268
12:31:10:930   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 5, hb time 62960
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 6, hb time 63134
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 7, hb time 63397
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   OC v5, Reset control for GPU 0, close miner right now if you want to use default control from Catalyst
12:31:10:932   7a7a2780   OC v5, Reset control for GPU 6, close miner right now if you want to use default control from Catalyst

I thought I'd try some solo mining. I have a local proxy set up and it seems to be working but I get the following message:

Miner detected that you use local pool or local proxy.
This mode is not currently supported and will cause less performance.
ZEC - Total Speed: 267.202 H/s, Total Shares: 1244, Rejected: 16, Time: 23:02
ZEC: GPU0 134.060 H/s, GPU1 133.142 H/s


Why is solo mining not supported and how much performance hit is there?

I had a problem getting 1.4.10 to sync over the last week also while solo mining. It would catch up for awhile then fall behind.  I tried upgrading to 3.0.0 and still had sync problems (tried cache settings, adding nodes and other things suggested) and waited for over 20 hours. Only ended up syncing 46 blocks but my computer and disk were actively adding files to the chaindata folder.  I finally created a new data folder pointed --datadir switch to it and used the --fast switch (with 3.0.0) to pull all the chaindata.  Was able to sync and start mining again in two hours.  And it is staying synced.  BTW I also used a cache of 4096 (computer has 24GB of ram) and the computer is on a gigabit connection (your download time may vary).

It just seems there is something messed up with all the attacks on the chain(or maybe my database was corrupt), but starting new clears it up (or bypasses it, since all that is downloaded are header data and transaction receipts, for most of the history). The old chaindata folder was 31GB. The new chaindata folder is 9GB.  According to this: https://github.com/ethereum/go-ethereum/pull/1889  it sounds like it actually pulls all the data for the most current 1024 blocks at the time of the sync.

I was able to restore it from the Avast vault, set it as an exception, and fire it back up.  Working now.  Thanks!

Avast blocked my v2 windows wallet so I tried downloading the latest version and it blocked that too.

Url: https://raw.githubusercontent.com/CryptographicAnomaly/CGA-Binaries/master/CryptographicAnomaly_v2.zip

Infection: Win32:Malware-gen


Has something changed in the wallet to cause it to be recognized as an infection?
Any work around?

How is the "proper fork" determined?

Is there any block explorer?  The digital mint has been dead for about a month.